← RECORD 004 / WRITING & REFERENCE BUILDSBUILD 02
CONSENT ARCHITECTURE · HYPOTHETICAL PRODUCT · CODED, KEYBOARD-OPERABLE
Wrenfield Consent Desk
A screen for managing consent, built so that what the operator sees and what the system stores can never say different things. The product is invented; the thinking is real.
PROBLEM
Consent screens show on or off, but the system stores a history. When the two disagree, staff give wrong answers about personal data, in writing.
APPROACH
Replace the on/off switch with four named states, each displayed next to the one line of stored fact that backs it up.
RESULT
A working, keyboard-operable component where the screen cannot claim more or less than the record. Slower to skim; much harder to get wrong.
A REFERENCE BUILD · A WORKED EXAMPLE, NOT CLIENT WORK. EVERY NAME, PURPOSE AND TIMESTAMP HERE IS INVENTED.
01 · THREE TERMS, DEFINED
The whole argument rests on three terms. Here is exactly what they mean.
- CONSENT RECORD
- The stored history of a permission: who asked, on what legal basis, for what purpose, when it was captured, and when it lapses. This is what the organisation actually holds.
- OPERATOR
- The staff member who reads this screen and answers questions about the data: a support agent, a privacy officer. Not a lawyer, and usually under time pressure.
- SUBJECT-ACCESS REQUEST
- A person's legal right to ask an organisation what data it holds on them and on what basis. The reply has a deadline, and it becomes written evidence the moment it is sent.
02 · THE PROBLEM
Consent screens show on or off. The record underneath holds a history.
Who asked, on what legal basis, for what purpose, when it was given, and when it lapses. None of that fits in an on/off switch. And when the switch and the record disagree, nobody notices until the worst possible moment.
That moment is a subject-access request, a person's legal right to ask what you hold on them. An operator reads the screen and answers from it. If the screen says "on" and the record says "expired eight months ago," the operator has just given a wrong answer about the organisation's legal position, in writing, to the person most likely to escalate. The interface caused that, not the operator.
The claim this build tests: if the screen only ever shows what the record stores, the operator cannot give a wrong answer, because there is nothing else to answer from.
03 · WHAT WE TRIED FIRST
We built three simpler versions first. None of them held up.
Each version was judged against one test: when a question arrives, does the operator's answer come from the stored record? All three failed it, each in a different way.
REJECTED 01
The detail drawer
The status on top, the full record hidden behind a click. Honest on paper, but people answer from what they can see, and in testing nobody opened the drawer. Facts you have to ask for are facts that don't get read.
REJECTED 02
Toggle plus status badge
Keep the familiar on/off, add a small label for "expired." But the label is decoration: withdrawn, expired, and never-asked still all look like "off," and people report what the switch says, not what the label says.
REJECTED 03
Just show the log
The full event history next to the switch: completely honest, and unreadable under pressure. It makes the operator do the interpreting on their worst day. The log is evidence; what the operator needs is an answer with the evidence attached.
04 · THE DESIGN
The design that survived: each state shown beside the stored fact that backs it up.
Select a state. The panel shows what the operator's screen says and, beside it, exactly what the record stores. Keyboard: ← → HOME END.
WHAT THE SCREEN SAYS
Analytics consent is active for this account.
The expiry date is always shown, because consent that never expires is a default setting, not a record of consent.
WHAT THE RECORD STORES
- basis
- consent
- purpose
- product analytics
- captured
- 2026-03-14 09:22 UTC
- lapses
- 2027-03-14
Invented data. No product, no client, no real subject records.
DECISION
The expiry date can never be hidden or cut off, at any screen size. "Granted" is only honest with its end date in view, so the layout treats that date as essential, not as fine print.
DECISION
The stored record is set in typewriter-style type; the screen text is not. The type alone tells you which side is explanation and which side is evidence. You learn it once and never think about it again.
05 · WHY FOUR STATES
An on/off switch hides three different duties behind "off."
GRANTED
Always shown with its end date. Consent that never expires is a default setting, not a record of consent.
WITHDRAWN
Keeps the original grant alongside the withdrawal, because the operator may have to prove what was lawful when.
EXPIRED
On a switch this looks the same as withdrawn. It is a different duty (stop collecting, and you may ask again), so it gets its own state.
NEVER ASKED
No record at all is its own state. Showing it as "off" is the most common way these screens mislead.
06 · A REQUEST ARRIVES
The build in use: answering a subject-access request without guessing.
- 01A request lands: "Tell me what you hold on me, and on what basis." The clock starts. The reply is legally due, and it is written evidence the moment it is sent.
- 02The operator opens that person's consent desk. The state and the record sit side by side: there is no drawer to forget, no log to decipher, no switch to take on faith.
- 03The reply is built from the stored facts (basis, purpose, captured, lapses), copied, not guessed. If the state is WITHDRAWN, the record still holds the original grant, so the reply can state what was lawful when, not just what is lawful now.
- 04Six months later, the reply is re-read in a review. It matches the record, because it was never anything other than the record.
07 · LIMITATIONS & STATUS
What this build does not settle.
READING COST
Four named states are slower to scan than a green dot, and the expiry date adds a line the operator can't skip. We accept the cost: this screen is read carefully a few times a day, not skimmed a thousand times.
SCALE
The demo shows one person and one purpose. A real desk needs search, lists, and bulk changes. The rule "no state without its stored fact" has to survive that scale, and this build does not yet prove it does.
THE RECORD MUST EXIST
The design assumes basis, purpose, captured, and lapses are stored as real fields. Where they aren't, no screen can honestly display them. The fix starts in the data model, not the interface.
STATUS · CODED, KEYBOARD-OPERABLE, INVENTED DATA · PUBLISHED BECAUSE THE ARGUMENT IS FINISHED
ALSO PUBLISHED · BUILD 01
Kilnmoor Fleet Console
A monitoring console for industrial equipment: nine channel states kept distinct, ranked by deviation without moving a single row.