A consent architecture that survives an audit and a vendor migration

This piece assumes you already accept that consent is a ledger rather than a flag. It describes what to put in the ledger.

One append-only table. Every row is an immutable fact that happened at a moment:

• subject — the contact identity, not the channel address. Addresses change; the person does not.
• channel — sms, whatsapp, email, voice. Never "all".
• purpose — service, transactional, marketing, research. A closed list, versioned.
• action — granted, withdrawn, expired, disclosed.
• at — timestamp, with timezone, of the event itself, not of the row's insertion.
• mechanism — web form, keyword, verbal, imported, inferred.
• evidence_ref — a pointer to the artefact: form submission id, recording id, inbound message id.
• actor — who recorded it. A person, a system, an import job.
• source_system — where it originated, which matters enormously after an acquisition or a migration.

One row, appended, never updated. Everything the three queries need has to be on it, because reconstructing a missing field from application logs is the work this design exists to avoid.

Nothing is ever updated or deleted. A withdrawal is a new row. If your ORM offers a soft delete here, resist it — the history is the asset.

No row without an evidence reference. "Imported from legacy" is an acceptable evidence type if you record it honestly; a blank field is not.

Purpose and channel are never null. A grant that does not say what it is for and where it applies cannot be enforced, and a system that stores it will over-apply it.

Inferred consent is marked as inferred. Some rows will come from behaviour rather than a statement. That is often legitimate. Mixing it with explicit grants is not.

May I send? Given subject, channel, purpose, and now: latest event wins, expiry applied, default deny. This runs in the send path, so it needs an index and a cache with a short, bounded lifetime.

What did we hold, then? The same query with a timestamp. This is the one an audit asks, and the one a flag-based model simply cannot answer.

Show me everything for this person. A subject access request. If assembling it takes a week of engineering time, you do not have a consent architecture; you have logs.

In your systems, not a vendor's. You are accountable for it, you must produce it after switching platforms, and retention obligations outlast contracts. A consent record that only exists in a console you may cancel is a liability with a renewal date.

Push the derived state to vendors — suppression lists, preference syncs — but keep the ledger.

The AI transparency obligation that took effect on 2 August 2026 creates a fact of the same shape: this person, on this channel, at this time, was told they were interacting with an AI system.

Same table, with an action of disclosed. The alternative — a second system, with its own timestamps and its own gaps — is how organisations end up unable to answer a simple question about their own behaviour.

The honest way to check this design: assume you replace your messaging vendor next quarter. Can you export the ledger, import it elsewhere, and answer all three queries on day one?

If yes, the architecture is sound. If no, you have built a dependency you did not intend to buy.

One append-only table, six fields, three invariants, three queries. It is a week of work and it is the only part of a messaging stack that answers to a regulator rather than to a vendor. Build it before the first send, because retrofitting it means reconstructing history you no longer have.