The problem
Residents of one housing estate were receiving private parking charges, and each was dealing with theirs alone: the same operator, the same signs, the same disputed ground, and no way to see that the cases formed a pattern. A shared register would let residents log their notices, see the pattern, and put it in front of the people who could act on it: the landowner, the operator's trade association and the vehicle licensing agency.
The idea existed as a one-page concept note. Someone had to turn it into a service that handled personal data lawfully, and do it quickly.
How the work was divided
One person and an AI did the work, and the split between them was fixed before it began and never broken.
- The AI drafts. It reads the law at source, proposes what the service must do and why, and writes down the trade-offs behind every proposal.
- The person decides. Nothing the AI writes counts until a named person has read it and signed it off. They can accept, reject, or ask for a change. They never edit the AI's words by hand.
- Every decision says why it exists. Each one points to a real reason above it: a duty in law that was read, a risk, a stated aim. A checker runs on every change and refuses anything that cannot show its reason.
- The paperwork is produced from the decisions, not written beside them. If a decision changes, the privacy notice built from it is out of date until it is rebuilt, and the checker says so.
The point of the arrangement is that the AI can be fast without being trusted. Everything it produces is visibly unaccepted until a person puts their name to it.
The first evening
The person's instruction was short: work out the requirements first, name the company that would be legally responsible for the data, and commit to how long data is kept as numbers rather than principles.
In one evening the AI read the note, confirmed the company on the public register, read fourteen provisions of data-protection law at source, and proposed 85 decisions: two aims, fourteen legal duties each with the date it was read, seven risks, four assumptions, six things the service would deliberately not do, and a requirement and a check for every behaviour. The retention periods came as proposals with their trade-offs written out: identifiers erased twelve months after a case closes, the whole register erased two years after the last notice.
The hand-over was one line: 85 proposals, none yet accepted. The person read the trade-offs and signed each one.
- Named the company and demanded numbers, not criteria
- Read the trade-offs before signing anything
- Read every provision it cited, at source
- Wrote down who pays for every requirement that binds someone
Reading the law back
Asked to check its own legal reading, the AI found that all fourteen duties held, that four understated their provision, and that six duties were missing entirely: telling the regulator about a breach, designing for privacy from the start, contracts with suppliers who handle the data, the rest of people's rights over their data, consent for cookies, and a duty so new it had come into force that summer, which puts complaint handling on a thirty-day clock.
The lesson transfers to anyone doing this with an AI: a first pass from the well-known articles misses the procedural duties every time, and asking for a second, deliberate reading is cheap. The six became duties on the register that evening, each with a requirement and a check.
An assumption that was wrong
One assumption said all the data stayed in the United Kingdom. Asked to test that against where the service would actually run, the AI found two suppliers for which it was not true: the network that shields the site from attack, which handles traffic wherever its nearest point happens to be, and the email service, which sends from Ireland and keeps its logs in the United States. The assumption was rewritten to what was true, the legal basis for the transfers was added, and the privacy notice grew a sentence.
The person then set a hard rule: all data encrypted, stored and in transit. The hosting on offer did none of that by default. That one instruction settled the database question, a dedicated instance on an encrypted disk rather than the shared one, and produced three requirements with checks.
A decision reversed without pain
The AI proposed a service with no accounts: a resident would get a secret link, shown on screen once, and an email address would be optional and never stored. The person agreed and it was recorded. The next day the person asked how logging in by email code would work, assuming that was the plan. It was not. The AI said so and set out the cost of each option: the link kept less data but could not be recovered if lost; the code stored an email address but could. The person chose codes.
The reversal took an afternoon rather than a rewrite. Because every decision records what depends on it, the AI could find everything the old design had touched: the sign-in rules, the session rules, the screens, the privacy notice, the record of processing. Each was redone and signed off again. The old decision was not deleted; it survives as a note on why the new one was made. Nobody had to remember what depended on what.
- Chose recoverability over minimal data, knowing the price
- Signed off the reversal decision by decision
- Named the cost before the choice, not after
- Kept the reversed decision as a record rather than erasing it
Walking the journeys
The person asked for the requirements to be split into what residents need and what the system must do, and for each resident's path through the service to be written out step by step, with every screen named.
Doing so found two gaps that the requirements alone had passed every check with. One journey promised a resident a fresh link that nothing had been required to provide. Another put the whole administrative area behind sign-in, which nothing had required either. Both became requirements with checks within the hour. A list of rules is checked by reading it; a journey is checked by walking it, and walking finds different things.
Paperwork that cannot go stale
The service needed a legitimate-interests assessment, a record of processing, a privacy notice, five covering letters for escalating a pattern, and six letter templates for residents. All of them were produced from the agreed decisions rather than written alongside them. Change a retention period and the record of processing is out of date until it is rebuilt; the checker refuses to let it drift.
The privacy notice had a reading-age target. The first draft came out at about fourteen; rewritten, about nine. The measurement became a permanent check.
Then the person read the built site as a resident would and sent back three faults the AI had not seen. "Address" on its own read as a postal address. The notice said the register would put the pattern before the authorities, when the register only makes it possible for residents to do so. One sentence pointed residents at a developers' website. Those three became rules about naming, then a check that runs with the rest, and on its first run the check found two more faults nobody had noticed. That is the collaboration in one paragraph: the person's judgement, the AI's reach, and a record that holds both.
Challenging the work, five times
A checker can prove that every decision has a reason. It cannot tell whether the reason is a good one, whether two decisions quietly contradict each other, or whether a rule is stronger than the aim it serves. So a second kind of review, nine questions asked of the whole record, was run five times over the three days, each time after a change big enough to hide something.
The first pass found eighteen decisions that mentioned others without being connected to them, five that treated a legal duty as optional, and a plan that would have sent case-by-case detail to the press. The fifth found one contradiction, between how notices were stored and how records were listed. Each pass was cheaper than the last.
Signing off, and a service
Within a day of the first proposal, the person had signed off every one of them. Over the next two days the specification went through twenty editions, the person amending and re-signing each morning and the AI answering the questions the build raised. The service was built against the specification and refuses to build if the specification has moved on without it.
At the time of writing the service is running, one real notice has been logged, the registration fee to the regulator has been paid, and two things wait on the person alone: re-signing two documents whose wording changed, and signing off six late proposals.
Who did what
| Only the person could | Only the AI would | Both, through the record |
|---|---|---|
| Name the responsible company; set the stance that the register helps residents act and never acts for them | Read fourteen legal provisions at source in an evening and cite each with its date | Argue about retention in writing, with reasons, rather than in chat |
| Choose email codes over the secret link, knowing an address would be stored | Find everything the reversal touched, by following the connections | Keep the reversed decision as a record instead of erasing it |
| Sign off, re-sign after every amendment, sign the assessment, pay the fee | Run the nine-question review five times without tiring | Keep the checker satisfied at every change |
| Read the built site as a resident would and catch "address" | Turn that catch into a rule and a check that found two more | Let the rule outlive both of them |
What went wrong, and what caught it
- Signatures swept into the AI's changes. The person was signing off decisions while the AI was still working, and the AI's next save picked up those signatures as if they were its own. Caught by reading the change before saving the next. Fixed by a stricter habit, and the signatures were re-recorded under the person's name.
- An edition label applied in the wrong place, leaving the specification pointing at an edition that did not exist. Caught by the checker on the next run, before anything was built on it.
- The AI was wrong about its own tools. It believed one thing could not be done; the person was sure it could. It could. The AI's note to itself was corrected in the same session.
- A wrong count in a change description, twice. Corrected in the next description; history was left as it was.
- A storage design that fitted one notice per resident, when residents can have several. Caught on the fifth review by holding two agreed decisions side by side. Fixed at its source, so no other project inherits it.
- A note meant for maintainers reaching residents. Caught by the naming check on its first run in the built service, not by any person reading.
Time
| Phase | The AI, elapsed | The person, attention |
|---|---|---|
| Specification to its first edition, fully signed off | about 3 h 00 | about 1 h 00 |
| Twenty further editions, the built service, the wording review | two working days, two sessions | two days, iterating and signing |
The first column is from timestamps; the second from the number and length of messages. The AI's hours include waiting on its tools. The person's include reading twenty-six replies and five documents, and signing off a hundred and eighty-five times.