Consent accountability

Consent accountability means being able to prove, after the fact, that consent was given, what it covered, and that it was honored, right up to the instant it was withdrawn. Agreely models this with a handful of objects that fit together cleanly.

#The objects

• Catalog the organization's declared (category, purpose) pairs. A declaration of what data you hold and why, and the source of the citizen-facing views.
• Consent request an offer issued to a person for a set of catalog items. It is signed by the company and delivered as a secure deep link.
• Receipt the signed, independently verifiable Verifiable Credential that records the person's answer, carrying both the company's signature and the person's passkey assertion. A manual or offline consent instead yields a company-attested receipt, which carries the company signature alone.
• Enforcement record the single authoritative status row a check reads, keyed per cell for a given customer and carrying a consentRef, a status (active, revoked, expired, or erased), and an assurance tier. It never stores a citizen DID.
• Check the synchronous allow-or-deny for one (customer, category, purpose) cell.

#The (category, purpose) grid

A catalog entry is one cell in a grid: a category of data (what) crossed with a purpose (why). Phone number x Billing is a different cell from Phone number x Marketing. Consent is always granted, checked, revoked, and erased at this cell granularity, never at the level of "the customer" or "the data" as a whole.

Each catalog entry carries a human display label and a normalized key. The key is the label trimmed, internal whitespace collapsed, and lowercased. The catalog, the approval, and the check all key off these byte-identical normalized strings, which is why every API surface accepts the raw human label and normalizes server-side. Clients must never normalize.

#The check: synchronous, single-read, fail-closed

The check is the heart of enforcement. It resolves one (company, customer, category, purpose) cell to allow or deny by reading exactly one thing: the status of that cell's enforcement record, via a single per-cell indexed read.

no record        -> deny  / status "none"     (default-deny)
status "active"  -> allow / status "active"   + consentRef
"revoked"        -> deny  / status "revoked"  + consentRef
"expired"        -> deny  / status "expired"  + consentRef
"erased"         -> deny  / status "erased"   + consentRef

Three properties make this trustworthy:

1. Deny is a 200. A decision, allow or deny, is always a successful result. Deny is not an error; only auth, validation, rate-limit, and outage are errors.
2. The chain is never read. The enforcement record's status is authoritative the instant a grant or revoke commits. The check never touches the on-chain registry, the indexer, or any anchor state. The chain is proof, not the read path.
3. Fail-closed. Absence of a record denies by default, and an unreachable Agreely denies by default in every SDK. Allowing requires a positive, active record.

#Instant granular revoke

A revoke flips the enforcement record for that one consentRef to revoked in a single indexed write. Because the check reads that same status, the very next check denies, with zero chain wait. There is no propagation delay, no cache to invalidate, and no eventual consistency window.

Revocation is keyed by consentRef and scoped to the active row, so revoking a superseded cell (one whose consentRef was re-pointed by a later re-grant) matches zero rows and can never deny a newer, valid grant.

#Independent verifiability

Every grant produces a receipt that an auditor can verify without trusting Agreely: recompute the commitment from the claim and salt, verify Merkle inclusion against the anchored root, verify the company signature against the company's DID key, and verify the person's passkey assertion against the COSE key that was valid at grant time. The verify recipe walks all four checks.

#Next

• The consent lifecycle: offer, passkey approval, receipt, enforcement record, check, and the two assurance tiers.
• Unlinkability: why the company side and the citizen side cannot be trivially joined to re-identify a person.
• Privacy and erasure: crypto-shred erasure and the honest destruction boundary.
• Honest boundaries: what Agreely proves and what it deliberately does not.
• The protocol for the cryptography underneath.