Consent artefact

One event, captured completely

A consent artefact is a record of a single consent event. It answers a narrow question: at this moment, on this channel, this identified person was shown this notice and took this affirmative action for this purpose. Everything else, the campaign that followed, the contact’s later withdrawal, the aggregate report, belongs to other structures. The artefact is the primary evidence, and its value comes from being specific enough that someone who was not there can reconstruct what happened.

The word artefact is deliberate. An artefact is something produced by an act and left behind, not a field someone typed later. A boolean column called consented, set to true by an import script, has no artefact value because there is no act behind it and no context around it. When a regulator, an auditor or a customer asks how you know, the artefact is the thing you hand over. If the answer is that the CRM says yes, you have a status, not evidence.

That framing changes what you build. Instead of a mutable flag on a contact record, you build an event that is written once, carries its own context, and is never edited. Corrections happen by appending a new event that references the old one, which is how you keep both the original claim and the fact that it was later corrected. Immutability is not a technical preference here; it is what makes the record trustworthy.

The fields that make an artefact defensible

A defensible artefact carries at least nine facts. The identifier of the person, in a form you can resolve later. The purpose, named at the level of the actual use rather than a broad category like marketing. The notice version, with a pointer to the exact text shown. The timestamp with a timezone, not a local time without an offset. The channel and collection point, such as a checkout form, a WhatsApp keyword or an inbound call. The wording of the affirmative action itself. The language the notice was presented in. The withdrawal path offered at that moment. And a hash or signature that lets you detect later alteration.

Two of those are usually missing and both matter in India. Language is the first: a notice served only in English to a Hindi-speaking customer is hard to defend as informed, and the DPDP framework expects notices to be available in the languages listed in the Eighth Schedule. The second is the withdrawal path. Consent that is easy to give and hard to withdraw fails the symmetry the Act requires, so the artefact should record not just that a withdrawal route exists but which route was shown at that moment.

The wording of the action is subtler than it looks. Pre-ticked boxes, implied consent from continued browsing and bundled agreements covering several purposes in one click are all weak under a standard that asks for a clear affirmative act. Recording the exact label of the button is what lets you show the act was affirmative, specific and separate from other terms. A record that says accepted terms and conditions proves only that something was accepted, not what.

An artefact is not a ledger, and the difference is structural

This is the distinction that causes the most confusion, so it is worth stating plainly. A consent artefact covers one event. A consent ledger is the append-only system of record that holds every artefact for a contact, in order, across every purpose and channel, including withdrawals. The artefact is a document; the ledger is the library, the index and the rule that nothing is ever removed from the shelf. You can have a thousand perfect artefacts and no ledger, and you will still be unable to answer whether a person is currently contactable for a given purpose.

The ledger adds three things an artefact cannot carry on its own. Sequence, so you can tell whether the latest event was a grant or a withdrawal and which notice version it referenced. Materialised state, a derived current answer per purpose that sending systems can query cheaply at send time. And reconciliation, the ability to compare what the ledger says against what each channel tool believes and find the drift before a campaign exposes it. An artefact alone cannot tell you that WhatsApp thinks the contact is subscribed while email thinks they withdrew.

The other direction matters too. A ledger without artefacts is a list of assertions with no underlying proof. Many systems have the sequence right, grant then withdrawal then re-grant, but cannot produce the notice text that was shown at each step. That passes a dashboard review and fails an evidentiary one. Build both: the artefact as the immutable evidence, the ledger as the ordered index over it, and a current-state projection that is derived rather than typed.

Not a notice, not a policy, not a preference centre

Three neighbouring documents get mistaken for the artefact. The notice is what the person is shown before consenting: the itemised statement of data sought, purpose, rights and grievance route. It is an input to the artefact, and the artefact references its version. A privacy policy is the organisation-level description of practice, written once and updated occasionally; it cannot substitute for a notice at a collection point because it does not describe this form, these fields and this purpose.

The preference centre is the interface where a person reviews and changes their choices. It generates artefacts when someone changes a setting, but the interface itself is not evidence. The evidence is the event the interface produced. This distinction matters during a redesign: teams often replace the preference centre and lose the historical records because the events were stored as rows in a table owned by the old front end.

A fourth thing that is not an artefact is a screenshot. A screenshot of a form with a ticked box proves that a form existed and that someone could tick a box. It does not tie the box to an individual, a time or a notice version. Screenshots are useful as design evidence in a review and useless as consent evidence in a dispute, and offering one when asked for proof is a reliable way to lose the argument.

What the DPDP Act asks of the record

Under the Digital Personal Data Protection Act, consent has to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative act, and limited to the personal data necessary for the stated purpose. Each of those adjectives lands on the artefact. Specific means the purpose is named and not bundled. Informed means the notice was actually presented. Unambiguous means the act was affirmative rather than inferred. Free and unconditional mean the consent was not a condition of an unrelated service.

The Act also requires that withdrawal be as easy as giving consent, and that the consequences of withdrawal be borne by the fiduciary rather than used as a penalty against the principal. For the artefact this creates a symmetry requirement: if consent was captured by a single tap on a checkout screen, withdrawal cannot require an email to a support address. Record the withdrawal route on the artefact so the symmetry can be demonstrated later, and keep the same route working for as long as the record exists.

The Rules add operational expectations around notice presentation, language availability and the role of consent managers. A consent manager is an intermediary registered with the Board that lets a principal give, manage and withdraw consent across fiduciaries in one place. If a customer uses one, the withdrawal may arrive through a channel your team never built. The artefact model has to accept an event whose source is a consent manager, with the same fields and the same hash discipline, rather than treating it as an exception handled by email.

Capturing artefacts where consent actually happens

In an Indian revenue stack consent arrives through at least six doors: a website form, a WhatsApp keyword, an inbound or outbound call, a retail counter, a partner or reseller, and an app permission screen. Each door produces a different shape of evidence and each needs the same normalisation on the way in. A WhatsApp STOP or START keyword is a clean event with a timestamp and a number. A recorded call is messier: the agent read a script, the customer said yes, and the artefact has to store the script version, the recording reference and the segment boundaries rather than a transcript nobody will read.

Voice is where most Indian programmes are weakest. A call centre that captures consent verbally and writes a note into the CRM has an assertion, not an artefact. The fix is procedural as much as technical: a fixed script with a version number, a recording retention policy, a pointer from the artefact to the exact recording and offset, and a rule that the agent cannot proceed to the offer until the consent step is logged. The same discipline applies to field sales, where a paper form needs a scanned image, a form version and an operator identity attached to the digital record.

Partner-sourced consent is the hardest case because you did not witness the act. The defensible pattern is to require the partner to deliver the artefact with the lead: notice version, purpose, timestamp, channel and the partner’s own reference. If a partner cannot supply that, the lead should enter your system as unconsented and be re-permissioned by you directly. Accepting a partner’s assurance that consent exists is how a large, well-run programme ends up with a block of contacts nobody can defend.

Storage, integrity and the retention puzzle

The storage pattern that works is object storage with write-once semantics, an index in a relational table for querying, and a hash chain per contact so that a missing or altered record is detectable. Write the artefact as JSON with a stable schema version, hash the canonical serialisation, and store the hash alongside the record and in the next record’s chain. This is not blockchain and does not need to be; a hash chain plus restricted write access answers the realistic threat, which is an internal edit during a dispute rather than a nation-state attack.

Retention is where the puzzle sits. Marketing data should be deleted when the purpose is served or consent is withdrawn, but the evidence of consent and withdrawal should be kept for as long as you might have to defend the processing. Those two obligations pull in opposite directions. The resolution is minimisation: after the retention period, strip the artefact down to the identifier, the purpose, the timestamps, the notice version and the hash, and delete the free-text context and any message content. You keep the proof and lose the personal detail that made it risky.

Access control matters as much as storage. An artefact contains an identifier and a behavioural trace, so it is personal data in its own right. Restrict bulk export to a named role, log every read of a full record, and make the default query return counts rather than rows. The most common breach in this area is not a sophisticated attacker; it is an analyst exporting the consent table to a spreadsheet to answer a question and then sharing the spreadsheet.

Access logging is the control that makes the rest credible. Every read of a full artefact should record who read it, when, from where and why, and bulk exports should require a second approval. That log is itself personal data and needs its own retention rule, which is a pleasing recursion but a real obligation. Without it, an internal misuse of the consent store is indistinguishable from normal operations, and the first sign of trouble is a customer complaint rather than an alert.

What a checkbox alone cannot prove

Consider a realistic dispute. A customer says they never agreed to marketing calls and asks how their number was obtained. The team searches the CRM and finds a contact record created fourteen months ago with a field reading opted in, a source of website and no other detail. The website has since been redesigned twice. There is no notice version, no timestamp, no form identifier and no record of what the checkbox label said. The organisation can prove that a record exists. It cannot prove that the customer agreed to anything in particular.

Now consider the same dispute with artefacts. The record shows a form submission on a specific date at a specific time, the notice version served, the exact label of the checkbox, the language, the IP-derived region and the confirmation message that was sent. The person can be shown what they saw. If they still dispute it, the disagreement is about interpretation of a document both parties can read, which is a very different conversation from one where the organisation has nothing.

The lesson is not that every record must be perfect. It is that the marginal cost of capturing context at the moment of collection is small, and the cost of reconstructing it later is usually impossible. A form that writes an artefact costs a few milliseconds. A migration that tries to infer consent from historical campaign engagement costs a legal review and often ends with deleting the list, which is the correct outcome and an expensive one.

Putting the artefact inside an agent workflow

An agent that sends messages, books meetings or places calls needs a consent check that runs on every action, not on the campaign. The pattern is a pre-action gate: before the tool call executes, the runtime queries the current consent state for the contact and the purpose, and refuses if the state is missing, withdrawn or stale against the notice version. The refusal is logged with the same detail as a success, because a blocked action is also evidence that the control works.

The gate should be boring and central. If each channel integration implements its own check, the checks diverge and one of them will be wrong. A single consent service exposing a current-state query and an append endpoint, called by email, WhatsApp, voice and ads sync, keeps the rule in one place. The service answers one question with a timestamp and a reason code, and it never returns a bare boolean, because a boolean invites the caller to cache it past its validity.

Human gates belong at the transitions rather than on every message. A campaign launch, a list import, a new purpose and a change to the notice are the four moments where a named person should approve and where the approval itself becomes an artefact. Below that line, automation can act on the stored state without a human, which is the only way the control survives a busy quarter.

Measuring whether your artefacts are any good

Five numbers tell you whether the evidence layer is healthy. Coverage is the share of contactable records with at least one artefact, and it should never be 100%, because records imported without evidence should be visibly unconsented rather than quietly assumed. Completeness is the share of artefacts with all required fields present, which catches integrations that write a partial record and call it done. Version currency is the share of active consents referencing a notice version that is still in force, which catches the slow drift after a policy rewrite.

The fourth is withdrawal latency, the ninety-fifth percentile time from a withdrawal event to the contact being uncontactable on every channel. Measure it end to end, including the ad audience sync, and measure it separately per channel because WhatsApp and email rarely fail at the same rate. The fifth is reconciliation drift, the count of contacts where the ledger says subscribed and a channel tool says otherwise. A monthly reconciliation job that reports drift as a number, rather than fixing it silently, is the control that keeps the whole system honest.

Run an audit sample every quarter. Pull fifty artefacts at random, and for each one ask a person who was not involved in building the system to reconstruct what happened using only the record. If they cannot state the purpose, the notice and the act, the record is not doing its job, and the fix is usually a field that was left optional because the integration was shipped in a hurry.

Benchmark against a real request rather than an imagined one. Take the last five disputes or access requests your team handled and try to answer each from artefacts alone. The time it takes, and the number of questions that required a human memory, is a better measure than any dashboard percentage. Repeat the exercise after a quarter and compare, because the point of the metric is to show whether the evidence layer is getting better at answering the questions people actually ask.