002. The specification
A shared language
for responsible data.
STATUS: EARLY DESIGN DRAFT
This page describes the proposed shape of OPS. It is a starting point for discussion, not a published interoperability contract or a certification.
Our first focus is consent and preferences. A small, clear specification gives us something useful to implement and verify before expanding.
01 / The questions
What should every implementation answer?
- What use of data is being requested, and by whom?
- What choice did the person make?
- Which notice and policy did that choice refer to?
- What is permitted now, including later withdrawal or changes?
- What evidence supports the decision?
02 / Proposed concepts
Start with clear building blocks.
- Subject.
- An application-scoped reference to the person making a choice. Avoid embedding personal data when a reference is sufficient.
- Purpose.
- A specific, understandable reason data is used, with its own identifier and version.
- Preference.
- A person's current choice for a purpose or channel. A preference is not automatically a legal basis for processing.
- Consent event.
- A record of a grant, refusal, or withdrawal, including time, scope, notice version, and collection context.
- Decision.
- A result that tells an application whether a requested use is permitted under its configured policy, with the reason and policy version.
- Receipt.
- A portable record of the choice and its context, designed to provide evidence while limiting unnecessary personal data.
03 / Proposed behavior
The details that earn trust.
- For uses configured to require consent, missing or withdrawn consent results in denial.
- A changed choice updates the effective state while preserving an appropriately retained record of the change.
- Repeated submissions of the same event do not create conflicting choices.
- Subjects and decisions stay isolated between applications or tenants.
- Integrations receive changes and can be tested for enforcement, including withdrawal.
Applications must enforce decisions at the point of use. A receipt alone does not prevent data from being processed.
04 / Open questions
What still needs to be defined.
API contracts, event schemas, receipt retention, identity linking, policy precedence, change propagation, and mappings to existing privacy standards all need review.
Data rights, lifecycle policies, and AI permissions belong in the longer-term vision. They are outside the first implementation's proposed scope.