Design the exit

Draw the exit on the first diagram, next to the sign-up, because if you leave it for later it will never be drawn at all. Almost every system is designed with enormous care for the way in — the onboarding is smooth, the consent screen is one tap, the account materializes in seconds — and almost none is designed for the way out. That asymmetry is not an accident of scheduling. It is the shape of the incentives. The product wants to acquire the person and retain the person, and everything about how it is built pulls in that direction: the data flows in easily, accumulates quietly, and is engineered to stay. The exit, if it exists, was bolted on later, under legal pressure, in the narrowest form counsel would accept. Build it first instead, deliberately, as a real feature — because the exit is where you find out whether the standing you granted was ever real.

The system you cannot leave

Consider what the exit actually looks like in most products the moment a person tries to use it. To see what the system holds about them, they file a request — a support ticket, an email into a queue, a form that promises a response within some number of business days — and then they wait, and often what comes back is partial, or a link to a raw export no human can read. To correct an error in that record, there is usually no path at all: the field is wrong, the person can see it is wrong, and there is simply no button that changes it, because the system was built to ingest facts, not to be argued with about them. To take their data somewhere else, portability, there is nothing — the data exists, but only in a shape that serves the system that holds it, never in a shape the person could carry elsewhere. And to delete the record, to actually leave, they meet the dark pattern: the deactivate that only hides, the delete that quietly retains, the flow with one more confirmation than anyone expects and a footnote admitting the data lingers.

Set that reality beside the language of the policy, which speaks confidently of the person's rights — to access, to rectify, to erase, to move. The words are there. What is missing is the ability to exercise them without an ordeal, or at all. And this is where the idea of standing stops being abstract. A person who cannot see what a system holds on them, cannot correct it when it is wrong, cannot take it with them, and cannot make it stop, does not have power over their own record — whatever the policy says they have. Consent granted at the door means little if the door only opens inward. The rights are real on paper and unreachable in practice, which is a particular kind of dishonesty: not the denial of standing, but the performance of it.

A right you cannot exercise on your way out the door is not a right they gave you; it is a sign on a locked room saying you are free to leave.

Build the way out as a feature

So the directive: treat access, correction, portability, and deletion as first-class features, specced and built from the start, and make each of them genuine. Genuine is the whole of the word. Access means the person can see what you hold on them, on demand, rendered legibly — not a promise of a raw dump in thirty days but a surface they can actually read. Correction means that when they show a fact is wrong, the fix propagates: it reaches the downstream systems, the derived records, the copies, so the error is gone everywhere it traveled and not just cosmetically patched at the source. Portability means the export is usable — structured, documented, complete enough that another system could actually take it, not a hostile PDF that technically discharges the obligation and helps no one. Deletion means the data is gone when the person says go, verifiably, not deactivated and retained against the day it might prove useful.

The deeper reframing is about how you regard the person leaving. In the acquire-and-retain frame, every exit is a leak — a loss to be minimized, a flow to be slowed with friction, a number on a dashboard to be defended. That frame produces exactly the systems described above, because it treats the person's ability to leave as damage. Invert it. Make the ease of leaving a design goal, held to a standard the way you hold onboarding to a standard. A person who can leave cleanly is a person who chose to stay, and that is the only version of retention worth having. The one who cannot leave was never really consenting to be there; they were merely captured, and a captured population is not the same asset as a committed one, however similar the metrics look from inside.

This is not a heavier system so much as an honest one. Most of the machinery already exists — the data is stored, the fields are known, the identity is authenticated. The work is to route those capabilities toward the person the record is about rather than only toward the operators who run it, and to hold the result to the plain test a feature must pass: can the person it concerns see, correct, move, and leave without an ordeal. If they cannot, the rights are decoration.

The honest hard parts

None of this means the exit is unconditional, and the imperative is worth less if it pretends otherwise. There is a distinction that has to be drawn carefully, because getting it wrong in either direction does harm. Removing a person's operative data — the profile that feeds decisions, the relationship that keeps the system acting on them — is one thing, and it should be honored. Destroying the audit trail of decisions already made about them is another thing entirely, and it should not be. If a consequential decision was rendered, the record that it happened — the grounds, the rules in force, the evidence consulted — is part of how that decision stays accountable, and erasing it does not serve the person so much as erase the proof of what was done to them. You can end the relationship and stop using the data without deleting the receipt of decisions past. Exit removes the person from the machine; it does not have to rewrite the history of the machine's conduct. Design the deletion so it distinguishes the two — clears the operative record, preserves the narrow accountability trail — and say plainly which is which.

Two more honest constraints. The exit must be authenticated, because access and correction are powerful, and a way for a person to see and change their own record is also, if built carelessly, a way for someone else to see and change it for them. The door that lets the real person out must not let an impostor in; the authentication that protects the account has to protect the exit too, or the feature becomes an attack surface wearing the language of rights. And some retention is legitimately required — legal holds, safety obligations, the accountability record itself — and where it applies it should be honored. But required narrowly, named specifically, and defended on its merits, never invoked as a blanket excuse to keep everything forever because keeping is easier than letting go. The legitimate exceptions are few and nameable. If your retention cannot be stated in a sentence a person would accept, it is not an exception; it is the old incentive in a new costume.

So when you scope the next system that will hold data about people, scope the exit into it on the first pass — the access they can read, the correction that propagates, the portability that is usable, the deletion that deletes, authenticated so it cannot be turned against them, bounded only by retention you could defend out loud. Build the way out with the same care you spend on the way in. The standing you claim to give a person is only as real as their ability to walk away with their record in hand — and the exit is where you, and they, find out whether you meant it.

— Dispatches · Summit Cognitive