A consent architecture that survives an audit and a vendor migration

Sooner or later someone asks a business to prove that a particular person agreed to a particular message: a regulator, a carrier investigating complaints, a court, or the customer. Most messaging stacks can say whether they may send today. Very few can say what they were allowed to do eighteen months ago, and why. This piece describes a design that can answer both, and that keeps working when you change messaging vendors. It assumes you already accept the idea in consent is a data model: consent is a ledger of events, not a single yes/no flag.

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

• subject: the contact identity, not the channel address. Phone numbers and email 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: the time of the event itself, with time zone, not the time the row was inserted.
• mechanism: web form, keyword, verbal, imported, inferred.
• evidence_ref: a pointer to the artefact, such as a form submission id, a call recording id or an 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 framework offers a "soft delete" here, resist it. The history is the asset. (Where a data subject's erasure request applies, handle it as a documented, separate process with legal advice, rather than as routine editing.)

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

Purpose and channel are never empty. 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 can be legitimate under some rules and in some markets. Mixing it with explicit grants is not.

May I send? Given subject, channel, purpose and now: the latest event wins, expiry is applied, and the default is 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 at a past timestamp. This is the one an audit asks, and the one a flag-based model cannot answer.

Show me everything for this person. A data 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.

Not in the CRM, not in the marketing platform, not in a vendor's contact list either. All three are legitimate readers of the ledger; none is a good home for it, because the ledger has to outlive each of them and answer questions about periods when a different system was in place.

Push the derived state to vendors (suppression lists, preference syncs) but keep the ledger. In practice that means a small internal service that other systems call, which is more work than a column on the contact record, and far less work than reconstructing history later.

The EU AI Act's transparency obligations, which apply from 2 August 2026, create a fact of the same shape: this person, on this channel, at this time, was told they were interacting with an AI system. See Article 50 for messaging teams.

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.

This design is not free. An append-only table grows forever, so you need archiving and a retention policy agreed with legal counsel. The "may I send?" query must be fast, which means caching, and caches can be briefly stale after a withdrawal; keep their lifetime short and treat withdrawals as urgent. And teams used to editing a contact record will need to learn to append instead.

One append-only table, six essential fields, a few invariants and three queries. It is a modest piece 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.

• The gap nobody fills: service-to-service identity: how systems prove they are acting for a specific customer when they read or write this ledger.
• Federating systems without merging them: why "one source of truth per fact" matters when several systems share contacts.