A grant is not a consent receipt: two different questions

One asks whether a piece of software may touch a file. The other asks whether a person agreed to something, and whether you can show it. A pod answers the first and carries nothing at all for the second.

The two questions, side by side

	A grant	A consent record
Asks	may this agent read this resource?	did this person agree to this use, and when?
Evaluated by	the server, on every request	a human, an auditor, a regulator
Lives	beside the resource	in an evidence store
Is about	capability	lawfulness
When it disappears	future requests fail	nothing about the past changes

Neither implies the other, and this is the whole point of the page.

A grant without consent is ordinary: someone gives an application access to a folder containing information about other people who were never asked.

Consent without a grant is equally ordinary: a person agrees to a use of their data and hands over nothing, because the other party already has it.

Why conflating them is the expensive mistake

"They shared it, so they consented" is the error, and it is attractive because a grant is machine-readable and consent is not.

A grant is a fact about a key. It says an agent could read something. It says nothing about who understood what, or what they were told the data was for.
Consent is a claim about a person at a moment, which is why regulations that care about it ask you to demonstrate it rather than assert it.
Revoking a grant does not withdraw consent, and withdrawing consent does not revoke a grant. They are different levers on different systems, and neither pulls the other.

What a pod grant actually carries, which is less than people assume

Read our own code: a grant names a resource, an agent, and a set of modes. That is all.

There is no purpose field. No statement of what the data may be used for, no scope, no expiry, no record of what the person was shown when they clicked share.

And our grant listing has a timestamp field we never fill, shared_at is populated with the empty string. A share in our interface does not record when it happened. That is a small thing to fix and an honest thing to publish, and "you can see everything you have shared" is doing less work than it sounds like.

So: a pod tells you what is currently permitted. It is not a record of what anyone agreed to.

The evidence ledger exists, in a different product, and it is not pod's

Stated with the scope attached, because the alternative is borrowing a credential:

Another Solidus product carries a consent ledger with a purpose, a scope, a capture time, an evidence blob, and a subject reference that is a salted hash rather than a raw identity. Withdrawal is modelled as a new record rather than an update, because a consent history is evidence and rewriting evidence defeats it. Two real write sites exist, with an append-only test guarding the table.

The same search style finds the audit-log writers across five files.

That design is good, and it is not on this surface. Pod does not call it. A pod grant does not produce one. Anyone reading this page as "so Solidus has consent receipts for pods" has read it backwards.

What each one is actually good for

Use a grant when the question is can this application open this file right now, enforcement, in the request path, machine-evaluated.
Use a consent record when the question is can we show, later, that this person agreed to this, evidence, out of the request path, human-evaluated.