When a subject pulls their consent, we do not delete the record. We write a revocation event and flip the record’s status.
{
"id": "rev_22b9",
"consent_record_id": "rec_7f3a",
"subject": "user_123",
"revoked_at": "2026-07-10T09:00:00Z",
"reason": "user_requested_revocation"
}
The next time anything verifies against that record, it gets a no.
{
"allowed": false,
"decision": "deny",
"reason": "consent_revoked",
"consent_record_id": "rec_7f3a"
}
Deleting the record would feel tidier and would be a mistake. Keep it, and you can still answer two separate questions honestly: was this allowed when it happened, and is it allowed now. Throw it away and you have lost the first answer to clean up the second.
Revocation cannot reach into a model whose weights already learned the data. It cannot pull back a copy a partner already holds, or one sitting in a cache somewhere. You cannot un-train a model, and any consent product that implies you can is selling something. What revocation can do is make every future check fail and leave a dated record that the cleanup obligations downstream can hang off.
That is the real reason to check at the point of use. If collection was the only place you ever enforced anything, a revocation has nothing to act on. Enforce at use, and a withdrawal takes hold the next time a check runs. The short cache lifetimes from the last post are just how you keep the window between “withdrawn” and “actually stopped” small.
Every verification can write an audit event. This is the thing the verification response was pointing at.
{
"id": "audit_91ac",
"consent_record_id": "rec_7f3a",
"actor": "model_pipeline_7",
"asset": "conversation_export",
"purpose": "llm_training",
"decision": "allow",
"checked_at": "2026-06-28T10:20:01Z",
"enforcement_point": "fine_tuning_pipeline"
}
One object that says who used what, for which purpose, under which record, what was decided, and where it happened. The reason it beats a folder of screenshots is that the question you actually get asked is never “do you have a policy.” It is “show me the decision for this asset, on this date, by this pipeline,” and a policy document has no answer to that.
An audit log you can quietly rewrite later is just a better-looking story. The floor is append-only: events get written, never updated, ordered by time. If you also need to defend the log itself, optional cryptographic anchoring chains each event to the one before it and pins the chain to an outside timestamp, so a missing or altered event shows up rather than slipping by. This is where the older protocol work, the signatures and the anchoring, actually pulls its weight: sitting under the audit trail as proof, not on the front page as a slogan.
Write an event for every decision, denials included, since the denials are usually the ones you end up needing to prove you made. And keep the export boring and stable, the kind of thing a legal or security team can pull on their own, because an audit trail that needs an engineer and a one-off query is a trail nobody ever checks.
The revocation and audit objects are specified in the draft spec, and the agent memory example runs through a grant, a use, a revocation, and the denial that comes after.
]]>The question is small. Four nouns and a time.
{
"subject": "user_123",
"asset": "conversation_export",
"purpose": "llm_training",
"actor": "model_pipeline_7",
"requested_at": "2026-06-28T10:20:00Z"
}
The answer carries more than a yes or no, because a bare boolean is no help an hour later when something has gone wrong and you are trying to work out why a row got skipped.
{
"allowed": true,
"decision": "allow",
"reason": "active_consent_record_found",
"consent_record_id": "rec_7f3a",
"checked_at": "2026-06-28T10:20:01Z",
"audit_event_id": "audit_91ac"
}
The fields that earn their keep beyond allowed are reason, which is a code you can branch on instead of a sentence you have to parse, and audit_event_id, which points at the stored record of the decision. “We checked” should be something you can show someone, not something you assert.
It comes down to one call and one branch, put where nothing after it runs unless the answer was yes.
const result = await oconsent.verify({
subject: "user_123",
asset: "conversation_export",
purpose: "llm_training",
actor: "model_pipeline_7"
});
if (!result.allowed) {
await skipAsset(result.reason);
} else {
await runPipeline();
}
Handle the deny path deliberately, with the reason, rather than letting it slip through. And if verify throws or times out, treat that as a deny as well. A check that fails open is not really a check, it is a formality you are paying for.
Branching on a fixed set of codes is what stops every caller from parsing prose. Allows come back with one of active_consent_record_found, purpose_allowed, actor_allowed, or scope_valid. Denials carry no_consent_record_found, consent_expired, consent_revoked, purpose_not_allowed, actor_not_allowed, or scope_violation. The gap between no_consent_record_found and consent_revoked is the gap between never having had permission and having had it and lost it, and your logs should be able to tell those apart on their own.
The same call sits in front of every place data crosses into AI use: a fine-tuning job reading a row (fine_tuning_pipeline), an agent writing a fact to memory (agent_memory_store), a retrieval step hitting a vector index (vector_search_gateway), a dataset export (dataset_export_job), a handoff to a partner (data_sharing_api), an evaluation run against real data (evaluation_harness). Naming the spot lets the audit trail later say not just what was decided but where.
A dataset is not one check. It is a few million. Two things are worth knowing. Group the checks by (subject, purpose, actor) and most of those millions collapse into a handful of real decisions. And think twice before caching a result, because a cached allow is only as current as your appetite for missing a revocation. Keep the lifetime short and let revocation win the tie. That last point is where this stops being simple, and it is what I want to write about next.
The request and response objects are in the draft spec, and there are full flows on the examples page.
]]>The job it has to do is narrow. When a model or a pipeline is about to touch some data, something has to decide whether that is allowed, in code, with nobody around to ask. So the record has to stand on its own and answer one question: can this actor use this asset for this purpose, today.
Here is one in full.
{
"id": "rec_7f3a",
"subject": "user_123",
"asset": "conversation_export",
"purpose": "llm_training",
"actor": "model_pipeline_7",
"scope": {
"allowed_operations": ["train", "evaluate"],
"excluded_operations": ["resell", "share_external"],
"geography": ["SG", "US"],
"retention_days": 365
},
"issued_at": "2026-06-28T00:00:00Z",
"expires_at": "2027-06-28T00:00:00Z",
"status": "active",
"proof": {
"type": "signed_timestamp",
"hash": "sha256:..."
}
}
Let me walk through it.
subject is who the data is about. asset is the thing being used. actor is who wants to use it. All three are required, and that is on purpose: if you cannot name all of them, you do not really have a decision to make. Name the asset at whatever level you can actually enforce on. If you only ever store coarse dataset names, you will regret it the first time someone asks to revoke a single conversation instead of the whole set, so the field goes as fine-grained as you need.
This one looks trivial and is not.
"purpose": "llm_training"
It is a string from a known list, never free text, and that limitation is the reason a machine can use the record at all. The common values are llm_training, model_finetuning, agent_memory, personalization, evaluation, research, and partner_sharing, and you can add your own. The one rule is that you do not rename them later. A purpose name is a contract, so renaming it quietly invalidates every record that used the old one, which is the kind of thing you do exactly once.
Purpose says what for. Scope draws the edges.
"scope": {
"allowed_operations": ["train", "evaluate"],
"excluded_operations": ["resell", "share_external"],
"geography": ["SG", "US"],
"retention_days": 365
}
allowed_operations is the actual grant. Anything not on that list is denied, so leaving something off is a choice rather than an oversight. excluded_operations is nearly redundant against that, and we kept it anyway, because someone reading their own record should see “train, fine; resell, never” written down instead of having to infer it. geography and retention_days are the dull constraints that turn out to carry most of the weight in any real conversation with a legal team.
"status": "active"
The values are active, expired, revoked, and suspended. Verification reads this almost first, because most denials in practice are not “no record exists.” They are “a record exists and it is no good now.” Dead records stay; we do not delete them. That is what lets you say later whether a use was fine at the time even if it would be refused today.
"proof": { "type": "signed_timestamp", "hash": "sha256:..." }
A signature over the record and a timestamp that does not lean on the collector’s own clock. If you need to defend the record harder than that, there is optional cryptographic anchoring underneath, but most people will not, and I would rather it sit there as an option than crowd out the description of what a record is.
Three things we would not bend on. The record is tied to a purpose, so a grant for evaluation cannot wander into a grant for training. It is self-contained, so a verifier can decide from the record plus the request without phoning home to wherever consent was first collected. And it maps onto LLMConsent-style records deliberately, so the same object can travel between systems that were never built to talk to each other.
The rest of the object model is in the draft spec, and the developer guide shows how to issue and check one in code.
]]>Consent to use your data is treated as none of those things. You click “I agree,” and the only record of what you agreed to lives with the company that benefits from the agreement, in a format they alone control. They can lose it, reword it, or read it generously in their own favour. When a regulator asks for proof, they produce a log they wrote about themselves. That is not evidence. It is a story.
oConsent treats a yes the way the world treats a deed.
A consent record names who the data is about, who may process it, for exactly which purposes, and for how long. The subject signs it with their own key, so it cannot be forged in their name or edited after the fact without the signature breaking. An independent timestamp, drawn from the NIST Beacon and from Bitcoin, fixes the date beyond the collector’s word. The proof is entered on a public chain, while the detail stays off it. From then on, anyone holding the record can verify it is real, current, and valid for a given use, without anyone’s permission. Revocation is entered the same provable way, so “I took it back” is as solid as “I agreed.”
That whole lifecycle is not a sketch. It is written, tested, and runnable today, in a Python SDK, a command line, and Solidity contracts you can read end to end. You can issue and verify a record this afternoon.
The honest frontier is short and specific. The records carry a hash commitment now, where the design calls for full zero-knowledge proofs, so a processor could demonstrate valid consent without revealing the underlying detail. That is the next major build. Ethereum is wired; other chains are open ground. There is no hosted product, by choice, because right now the protocol is the product. All of that lives on the ledger, stated plainly, because a project about proof has no business asking you to take its word.
One small thing, since it is the whole point: this site sets no cookies, runs no third-party trackers, and serves its own fonts. Reading this does not feed you into anyone’s analytics. That should be the floor for a privacy project, not a feature.
oConsent is small and open on purpose. The most useful thing you can do is read the protocol and try to forge a record it would accept. After that the open work is concrete: the zero-knowledge proofs, more chains, sharper docs. The code is here, and contributing tells you where to start. If you would rather just watch it grow, the feed is the no-tracking way to do it.
]]>