What's inside a consent receipt: the five claims

The five claims

• consent_scope, what was agreed to.
• data_use, the specific purpose. Not a category; the actual use.
• expiry, until when.
• revocation, whether it is still valid, checked live rather than assumed.
• attribution, who granted it, tied back to the granter's own identity where relevant.

Read as a set, they answer the question a grant cannot: not "may this software open this file", but "did this person agree to this use, and is that agreement still good."

The one that is hard, and it is revocation

Four of the five are just fields. They can be written into a document and signed, and the document is then as trustworthy as its signature.

Revocation is different, because it is a claim about now. A receipt that says "valid unless withdrawn" is worthless without somewhere to ask.

So the honest reading of the schema is: four claims are cheap and the fifth is the whole engineering problem.

What a receipt is not, and this is the part worth publishing

It is evidence of an agreement. It is not a determination that the processing was lawful.

A perfectly formed receipt can record a consent that was not valid, because it was not freely given, because the purpose was described too vaguely to be informed, or because consent was the wrong basis for that processing in the first place. The document proves what was recorded. It does not prove that recording it was enough.

Anyone selling a receipt as compliance has skipped that step, and it is the step regulators actually examine. Nothing on this page is legal advice.

Receipt and ledger are two different objects

A ledger is the organisation's evidence. A receipt is the person's.

The consent ledger that exists in another Solidus product records purpose, scope, a capture time, an evidence blob and a salted subject reference, with withdrawal modelled as a new record rather than an update, because rewriting evidence defeats it.

That is a controller-side record, it belongs to a different product, and pod does not call it.

The difference matters more than it sounds: a ledger is held by the party with an interest in the outcome. A receipt held by the subject is the only version where the person can produce evidence without asking permission, and that version does not exist anywhere in this estate today.

Where pod actually stands, which is further back than either

A pod grant records a resource, an agent and permission modes. No purpose, no scope, no expiry.

And it does not record a time, shared_at is populated with the empty string in our own code, while the permission fields beside it are populated correctly, so the omission is specific rather than a broken read.

A surface that cannot tell you when you shared something is not close to telling you what you agreed to.

The commercial section of the source is refused

The internal note carries a proposed price range, marked in its own text as not final.

No price appears on this page. A number described internally as provisional becomes a quoted figure the moment it is published, and this estate has already been bitten by figures escaping their caveats. Pricing also belongs to a different surface entirely.