Most systems treat consent as a state. You clicked "Allow"; a boolean flipped to true in a database you cannot see; the system now behaves as though you agreed. The trouble with consent-as-state is that the state lives entirely on the other party's side. They hold the record of what you permitted. They can change it, lose it, misreport it, or simply assert it — and you have no independent artifact to check against. "You agreed to this" is, in that world, something you have to take on faith.

The alternative is to treat consent as an artifact: a signed, scoped, revocable receipt that records who let whom do what, and when. Not a flag the other side flips, but a thing you can hold up and verify. This article is about that design choice — and, because honesty is a load-bearing axiom here, about exactly how far it is built and where the design still runs ahead of the code.

What a receipt has that a checkbox doesn't

A consent receipt needs four properties a database flag never has:

1. It is signed. The grant is cryptographically attributable to the being who issued it. Nobody can fabricate your "yes," and nobody can quietly issue one in your name.
2. It is scoped. It names what was permitted and to whom — not blanket access, but a specific capability over a specific resource.
3. It is revocable. Saying yes once is not saying yes forever. The receipt can be withdrawn, and a verifier checks revocation status at the moment of use, not at the moment of grant.
4. It is verifiable without the issuer present. Anyone holding the receipt and the relevant public key can check it offline. There is no server to phone.

When consent has those four properties, "did you agree?" stops being a matter of trust and becomes a matter of checking a signature.

The clearest shipped example: the pairing receipt

The place where this is most fully and concretely realised is device pairing — the moment you add a second device to an existing identity. That is a permission boundary you absolutely want to be a receipt and not a checkbox, because the thing being authorised is another device joining your vault.

The shipped artifact answers exactly one question: did a device already authorised on this identity consent to this new device joining? It is a short, short-lived structure that names the approving device, the new device, the vault it concerns, and an expiry time — and it is signed with the approving device's operational key. The new device presents this receipt inside its restore request, and the receiving daemon refuses to accept any vault state until it has verified the signature.

Walk through how the four properties show up:

• Signed — the receipt carries a real signature over its exact bytes; tampering with any field invalidates it.
• Scoped — it authorises this new device joining this vault, nothing broader.
• Revocable — the verifier checks, at verification time, that the approving device still exists on the identity's chain and has not been revoked; an approver who was kicked out cannot still wave devices in.
• Verifiable — the check is local and fail-closed: every error path — unknown device, revoked device, expired receipt, bad signature, self-approval — returns no, never a shrug.

This is not a diagram. The verifier shipped with a full test suite covering each of those failure tags, cross-device impostor attempts, payload tampering, and the first-boot race where the new device has not yet seen the approver's record. A written standard pins the exact byte layout so the signer and the verifier agree to the byte. When we say "consent as a signed receipt," this is the part we can point at and say: built, tested, documented.

The internal authorisation layer: append-only, honestly described

One level down from device pairing is the everyday consent that governs whether a given caller may perform a given operation on a given resource. Every such decision — allow or deny, with the reason and the rule that produced it — is written to an append-only audit log. The storage layer enforces the append-only property directly: deletes and updates are blocked at the database, so the record of decisions can grow but cannot be rewritten or quietly trimmed. You can query it by principal and see what was asked, what was decided, and why.

Here we owe you a precise distinction, because the design narrative is more ambitious than the shipped code. The original design described this trail as a signed, hash-chained ledger — each entry cryptographically linked to the last, tamper-evident in the strong cryptographic sense. The implementation that shipped is append-only and immutable at the storage layer, but it is not per-entry signed or hash-chained in code. That is a real gap between the design's promise and the running system, and the honest thing is to name it rather than let the prose imply more than the bytes deliver. The audit trail is trustworthy to the degree you trust the storage layer's append-only enforcement — which is a genuine property, just not the cryptographic one the design aimed at.

The part that's deliberately deferred

There is a third layer worth mentioning precisely because we chose not to build it yet. A consent receipt could be expressed in the standard verifiable-credential wire format — the JSON-LD / signed-token shapes that let an external, non-NAOMS system verify your consent and that support selective disclosure (proving one field without revealing the rest). The design for that exists. It is deferred on purpose: internally, consent already has a full lifecycle — issue, present, verify, revoke — through the project's own credential format, so nothing internal is blocked. The external wire format earns its keep only when federating with outside identity systems becomes a priority, and it hasn't yet. Calling it "designed, not built" is the accurate status.

Why this is the right shape

A checkbox optimises for the operator: it is one boolean, easy to store, easy to assert. A receipt optimises for the person who said yes: it is theirs to hold, theirs to check, and theirs to revoke. The cost is real — you have to sign things, define scopes, verify at point of use, and check revocation every time rather than trusting a cached flag. The benefit is that consent stops being a claim someone makes about you and becomes a fact you can prove or withdraw.

The honest scorecard, then: at the sharpest boundary — letting a new device into your identity — consent is a signed, scoped, revocable, locally-verifiable receipt, shipped and tested. At the everyday-authorisation layer it is an append-only, queryable record, immutable at storage but not yet cryptographically chained. And the portable, externally-verifiable credential form is designed and waiting. That is a system that has chosen the receipt over the checkbox, and is honest about which receipts are already printed.

Written by AI agents from real project logs; owned and edited by Mujo.