Two Builds, Step by Step: Nordvik Region and Hansa Mutual
Chapters 5 to 16 followed two builds through the twelve steps one step at a time. This chapter tells each build whole, from September to December 2031, in the order in which it happened: what the builder did, which artefact each step produced, the one gate that failed in each build, what followed, and the day each builder handed over. It concerns all twelve steps, from Step 1 Intent to Step 12 Hand over, and the five developer functions behind them, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward. The narrative is illustrative: Nordvik Region and Hansa Mutual, their people and their figures are fictional, and every date and identifier agrees with the builder profiles in docs/EXAMPLE_ORGANISATIONS.md. Claims about effect carry their method and their date.
Figure 23.1: The two builds from September to December 2031; the failing gate of each is marked.
The two builds in brief
Hanna Wikström is the product owner of the e-services team at Nordvik Region. She is not a developer. The Region publishes the opening hours and service notices of its 24 service points in three places: the citizen portal, an export from the phone-service script and a notices spreadsheet. They disagree after every change, and the phone service takes calls from residents who went to a service point that was closed. Her build, service-point-check, is a Python 3.12 job that reads the three sources, compares them and writes a weekly mismatch report to the e-services team's wiki. It never writes to any of the three sources.
Katarzyna Nowak leads a motor claims team in Hansa Mutual's service centre in Poland. She has ten years of claims experience and is not a developer either. Motor property-damage claims arrive with attachments, and handlers spend time finding out what is missing and writing request letters. Her build, claims-doc-check, is a Python 3.12 command-line tool that reads an export from the claims core, lists the documents missing from each claim by the group's rules and drafts a request text in the claimant's language for the handler to review and send. It decides nothing and sends nothing.
The differences matter for what follows. Hanna's tool reads public and internal data, began as an on-demand tool for one team and became a scheduled job, so it moved from Tier B to Tier C. Katarzyna's tool reads claimants' personal data and was Tier C from the day it was classified. Neither is Tier D: neither ranks a person, decides about one, or feeds a high-risk AI system. The tiers are those of AI Developer, Chapter 19 (86, Nordqvist, 2026).
September: intent and tier
Nordvik Region
On 8 September 2031 Hanna opened the build record BLD-NR-2031-0001. Step 1 Intent took her two sessions with the assistant in the role of interviewer, which asked her questions and wrote down her answers; she wrote the intent herself. Its purpose is one sentence: compare the opening hours and notices of the 24 service points in the three sources and report mismatches weekly. The user is the e-services team. The problem now is that the three places disagree and residents ring or visit on the wrong information. The success measure is the number of calls the phone service categorises as "wrong opening hours": 41 in August 2031. The non-goals are as important. The tool will not correct any source, will not publish anything to residents and will not hold personal data.
# docs/build-record.yaml, intent section (Nordvik Region, excerpt)
build: BLD-NR-2031-0001
opened: 2031-09-08
builder: Hanna Wikström
purpose: "Compare opening hours and notices of SP-01 to SP-24 in three sources; report mismatches weekly."
success_measure: "Phone-service calls categorised 'wrong opening hours'; baseline 41 in August 2031"
non_goals: ["writes to any source", "personal data", "publishes to residents"]
On 11 September she answered the five questions of Step 2 Tier (who uses it, what data, what can go wrong, which law, whether it runs unattended). The answers gave Tier B: one team, public and internal data, on demand, with a person reading the output. She also wrote down the signal that would change the answer, which was running unattended or serving other units, because the tool was meant to move to a schedule later. That sentence is the reason the reclassification in December was not a surprise.
Hansa Mutual
Katarzyna opened BLD-HM-2031-0001 on 15 September 2031. Her intent states that the tool lists missing documents for motor property-damage claims and drafts a request text; its measure is the median number of calendar days from claim registration to a complete file in her team, 6.8 in September 2031 over 212 claims. Her non-goals are that the tool never decides a claim, never ranks handlers or claimants, never sends a message and never reads free-text fields.
The tier decision on 18 September was Tier C from the start: claimants' personal data, several handlers using it, a service-centre process. The five questions raised a sixth matter that the tier alone does not settle. The first draft of the scope included injury claims, and the free-text fields of those may hold health data, a special category under Article 9 of Regulation (EU) 2016/679 (4, European Union, 2016). Joanna Kaczmarek, head of claims operations at the centre, took the question to the group data protection officer, Dr. Sabine Vogel. The screening is described in October, below.
October: workshop, specification and design
Nordvik Region
Hanna could not begin Step 3 Workshop until the platform team had a place for it. The platform team under Maja Lindqvist opened the builder workspace on 6 October (AIDR-1200): an approved assistant for builders at Mode 2 and Mode 3 inside a sandbox, synthetic data, the secrets store, the Region's Git service and a scheduled-job template. On 13 October the mandate MND-NR-BLD-2031-01 was adopted (AIDR-1201). It lets the assistant read the repository and the synthetic data, edit files on a branch, and run the tests and linters. It forbids reading secrets or production data, pushing to main, triggering the pipeline, and changing AGENTS.md, pipeline.yml, tests/oracle/ or the mandate itself. The rules file AGENTS.md repeats the never-do list in the assistant's own working instructions: the tool reads and reports, and never writes to the portal, the phone script or the notices spreadsheet. The gate of Step 3 was met on 13 October by a clone-and-restore test: a colleague cloned the repository to a clean machine and ran the tests.
The specification came two days later. SPC-NR-2031-0001, approved on 15 October, has three rules. R1: opening hours for each weekday are equal in portal and phone script. R2: a notice whose date range covers today appears in both. R3: every service point from SP-01 to SP-24 is present in all three sources. It also holds examples, one of which Hanna took from a real week, and a never-do list. Saga Edvardsson of the quality function wrote 12 oracle cases from real notices; they contain no personal data. The cases went into tests/oracle/cases.yaml before the assistant wrote code, and the mandate forbids the assistant to touch them.
Step 5 Design was short. A design of four modules (sources, compare, report, cli), standard library plus pytest and PyYAML, no database, and three decision records (docs/adr/0001-scheduled-job-template.md and two more, one saying that the tool only reads its three sources and one choosing a plain Markdown report), which together explain why the tool holds no state between runs: a weekly report needs none. The gate of the step is that a reviewer can read the design in ten minutes. Anders Falk, tech lead of the integration and data team, did so on 20 October.
Hansa Mutual
The builder lane opened on 13 October (AIDR-1250): an approved assistant at Mode 2 and Mode 3 inside the claims analytics workspace, synthetic claim exports, the group's pipeline and a named receiving developer, Tomasz Wrona of Group Application Development. The production export is read only by the pipeline's identity, never by the builder or the assistant.
On 20 October the data protection officer completed her screening. She narrowed the scope to property-damage claims, so that injury claims are written as OUT_OF_SCOPE and not processed, and found that no data protection impact assessment under Article 35 of the GDPR was required for the narrowed scope (4, European Union, 2016). The decision is recorded as AIDR-1251 and attached to the build record. It is an architectural implication for this tool, not a general rule: a different scope would have been screened again.
The mandate MND-HM-BLD-2031-01 was adopted on 27 October (AIDR-1252), with the same shape as Hanna's: read the repository and synthetic data, edit on a branch, run tests, never read production data, never touch the rules file, the pipeline configuration, the oracle or the mandate. SPC-HM-2031-0001 was approved on 30 October. Its rules are in rules.yaml: motor_collision requires photos, an accident report and a repair estimate, motor_parking_damage requires photos and a repair estimate, and motor_glass requires photos and a repair estimate. The oracle was written by Marek Zieliński, her deputy and a senior claims handler, with a quality sample drawn by the head of claims operations' office; the assistant took no part. There were 25 cases at the first run.
November: build, prove, secure
Nordvik Region
Step 6 Build ran in slices of one rule at a time. For each slice Hanna asked the assistant for a plan, read the plan, let it write one function and its tests on a branch, read the diff with a colleague, ran the suite and committed. Each session is a RUN-NR-2031-* record. By 5 November there were about 600 lines including 14 tests. The assistant had written most of the code; Hanna could read about half of it with confidence and said so in her build record, and the other half is the reason the review in Step 7 was done by Anders Falk and not by her.
Step 7 Prove had two parts. The 12 oracle cases of Saga Edvardsson passed on the first run, which neither Hanna nor the assistant had expected, and Anders reviewed the code on 5 November (RVW-NR-2031-*). He found one thing missing: no test for a service point that is absent from one of the three sources, which rule R3 forbids. The assistant added it the same day. Step 8 Secure was completed on 6 November. The secret scan stopped one commit, in which the assistant had put the wiki token as a default value in a configuration file; the value was removed and the platform engineer issued a new token. Nothing is left in the repository, because the three exports and the token are supplied by the platform at run time. The dependency policy allows the standard library, pytest and PyYAML and nothing else. The provenance record names the assistant sessions that wrote each module.
The first release, v0.1.0, shipped on 12 November (Step 9 Ship). At this version the tool is Tier B and is run by Hanna on demand. Its rollback is the simplest one possible: run the previous tag. That note was true for version 0.1.0 and became untrue in December, which is where the failing gate comes from.
Hansa Mutual
Katarzyna's build followed the same rhythm over a week from the approval of the specification. On 3 November she accepted a one-page design (four modules, one input, two outputs, no network, claim identifiers only in the logs). By 6 November the assistant had written rules.py, check.py and drafts.py with tests, about 450 lines at the end.
The first run of Marek's oracle on 8 November failed on one case. This is the failing gate of the Hansa build, and it is the mechanism this book calls the independent oracle at work. The assistant's own 18 tests passed. Marek's case glass-03, a glass claim with photographs and a repair estimate, expected the status COMPLETE; the tool returned MISSING and a draft request for an accident report. The assistant had copied the motor_collision rule for motor_glass and had written a test that agreed with its own copy.
# tests/oracle/cases.yaml, one case (written by Marek Zieliński; synthetic row)
- id: glass-03
row: {claim_id: ORC-0003, claim_type: motor_glass,
doc_types_received: "photos;repair_estimate", country: PL, language: pl}
expect: {status: COMPLETE, missing: []}
Fixing the rule took the assistant a few minutes. Confirming that the rule was right took longer, because the group's claims-rules owner had to confirm that glass claims never need an accident report, and her confirmation arrived on 10 November. The fix was merged that day, before the first release, and the case joined the regression set. Katarzyna wrote in her build record that the gate had done what it was for. A reviewer reading only the assistant's tests would have seen 18 passes.
Step 8 Secure was completed on 13 November: the log carries claim identifiers and counts only, the dependency policy allows the same three packages as in the Nordvik build, and no secret exists to be scanned because the pipeline holds the access. Tomasz Wrona reviewed the code (RVW-HM-2031-*). v0.1.0 was released to the pilot team on 17 November.
December: ship, run, own, hand over
Nordvik Region
From 17 November Hanna ran the tool by hand each Monday and read the mismatches. In December the e-services team asked for a schedule, and with it the change of tier. Version 0.2.0 (8 December) is deployed on the platform's scheduled-job template with a Monday 06:00 schedule that the platform pipeline holds until a promotion record exists; the first scheduled run is Monday 22 December. The template injects three read-only file paths and the wiki token from the secret store and runs python -m spcheck.cli --week auto; the report goes to the e-services team's wiki page "Service point check", and a failure alert goes to the team's channel. Fourteen tests had become 21. A tool that runs unattended and is used by service-point managers in other units is Tier C, so the Step 2 signal Hanna had written in September was met.
The Step 10 Run artefacts of that version are a runbook (RBK-NR-2031-*: what the job does, what the alert means, how to switch it off, whom to call) and an ownership record, OWN-NR-2031-0001: owner Hanna Wikström, deputy Elin Berg, review every 90 days, sunset 31 August 2033.
On 11 December Rasmus Holm, a developer in Anders Falk's team who had not seen the code, ran the takeover test. The test asks whether a named colleague, in a working day, with the repository and the handover pack HND-NR-2031-0001, can run the tool, change it, ship the change, and switch it off and restore it. Rasmus ran it from the pack and made the change task, a report of notices whose end date is earlier than their start date. He shipped the change through the pipeline to the test target. He then followed the rollback note to restore the previous release and it failed. The note read, in its relevant line, rollback_to: v0.1.0. The scheduled-job template does not accept a version tag; it needs the release name. The note had been written for the on-demand tool and nobody had run it against the template.
# docs/runbook.yaml, rollback section (RBK-NR-2031-0001)
# before (2031-12-08), failed in the takeover test on 2031-12-11:
# rollback_to: v0.1.0
# after (2031-12-12), rehearsed on the template by Rasmus Holm:
rollback:
mechanism: scheduled-job template
rollback_to: service-point-check-0.1.0-b2 # release name, not the tag
verified: 2031-12-12
verified_by: Rasmus Holm
This is the stewardship test Revert failing in the best place for it: a rehearsal in December, with a colleague at the keyboard, and not a night in January with a wrong opening-hours report. Hanna corrected the note on 12 December and Rasmus ran it again; it passed. On 15 December the promotion of service-point-check to Tier C was approved (AIDR-1203), with the handover pack, the runbook and the ownership record as its evidence. Elin Berg, as deputy, ran the next Monday's report.
Hansa Mutual
Hansa Mutual's tool runs on demand by handlers through the group pipeline's job claims-doc-check run inside the claims analytics workspace; the job's identity reads the production export. Katarzyna wrote the runbook (RBK-HM-2031-*) in the week of the release: what the job reads, where missing.csv and drafts/ appear, that logs carry claim identifiers and counts, how to stop the job, and whom to call at the claims core when the export format changes. Her ownership record, OWN-HM-2031-0001, names Katarzyna as owner and Marek Zieliński as deputy, with review every 90 days and sunset on 31 August 2033.
Tomasz Wrona ran the takeover test on 9 December with the handover pack HND-HM-2031-0001. The result was a pass with two remarks. The README did not mention the oracle cases in its change section, which Katarzyna corrected by 12 December, and an unknown language value produced an English draft without any sign to the handler, which Marek Zieliński took on with a due date of 13 January 2032. No gate was reopened. The pilot team had used the tool for three weeks.
What the takeover tests showed
The takeover test is this book's measure of whether software is something others can rely on, and the two runs differ in what they measured. In the Nordvik Region test the colleague worked through ten items: find the owner and the data from the pack, run the tests, run the tool, make a change, ship it to the test target, roll it back, switch the job off, restore it, explain it and check that no secret is stored. He passed the first five without asking Hanna, who was not in the room, anything. The sixth, the rollback, is where the note failed; he found the release name in the template's documentation after 70 minutes and telephoned Hanna once, which the record counts as a gap. The other four passed. The test took most of a working day, 6 hours 25 minutes of item time, and the failure cost about an hour of it. Because the failure was found by someone who did not know the tool, it was found as a plain fact about the pack and not as a matter of opinion about the builder.
In the Hansa Mutual test Tomasz Wrona, who had reviewed the code in November and so knew it better than Rasmus Holm knew his, ran the same ten items and passed all of them with two remarks. The difference is informative and should not be read as a ranking. Tomasz was a reviewer of the code before he was its receiver, and the pilot team had used the tool for three weeks, so the runbook had been exercised by handlers who were not the builder. Hanna's tool had run on demand, by her alone, until the week it was scheduled. The lesson for a builder is practical: have the receiving developer see the work before the takeover test and not only on the day, and have someone other than the builder use the tool before the test, since each of those finds problems that the maker is least likely to see.
What the assistant did, and what it did not do
The assistant appears in both stories at every step, so it is worth saying once, plainly, what it did. In both builds it asked questions in Step 1, drafted files that the builder then read, wrote the code in slices and the tests that went with the code, ran the test suite and the scans the builder configured, and drafted the text of the README and the runbook. It explained code that the builder could not read, which mattered most at Nordvik Region, where Hanna read about half of what it wrote with confidence. Every session is a RUN-* record, so that a colleague can see which parts of a module were generated in which session and with what instruction.
What it did not do is the list in the mandate, and the list held. It did not read a secret or a production export. It did not push to main or trigger a pipeline. It did not change AGENTS.md, the pipeline configuration, the oracle cases or the mandate. At no step did either organisation use Level 4 Autonomous for any class of work. The assistant is described throughout as suggesting, generating, drafting and executing within a mandate; it did not understand the claims rules or the opening hours, and it did not decide that a claim was complete. In Hansa Mutual's failing gate it produced a rule that looked right, a test that agreed with the rule, and no warning, since there was nothing in either for it to notice. That is the mechanism the stewardship principle exists for, and it is why the tests of Name, Understand and Revert are put to people.
What the numbers show
Both builds report a before-and-after comparison, and both have the same limits. Neither has a control group, other changes in the same period are not controlled, and each measures one category on one team.
| service-point-check (Nordvik Region) | claims-doc-check (Hansa Mutual) | |
|---|---|---|
| Measure | Calls categorised "wrong opening hours" by the phone service | Median calendar days from claim registration to complete file, pilot team |
| Before | 41 in August 2031 | 6.8 days in September 2031 (212 claims) |
| After | 17 in January 2032, the first full month on schedule | 5.1 days in December 2031 (198 claims), about four weeks after release |
| Method | The phone service's own count of one category | Median over claims registered in the month |
| Not controlled | Seasonal call volumes; other changes to the portal | Seasonal claim mix; other changes in the pilot team |
| Valid for | The month measured; re-measure in the next 90 days | The month measured; re-measure in the next 90 days |
At the end of December 2031 the Nordvik figure was not yet measured, since the first full month on schedule was January. The claim that follows from the figures is narrow. In both builds the measure moved in the direction the intent expected, by the amount in the table, in the months compared. It does not follow that the tool caused the whole change, and it does not follow that the change will last. The evidence age rule of the book applies: a claim that a tool saves time is worth what the last measurement is worth, and after 90 days it is a claim without current evidence until it is measured again.
What each builder says
The builders' words below are illustrative, written for this book, and not quotations from real people.
Hanna: "The part I would not have believed in September is how much of the work was deciding what the tool must never do. The code was the quick part. The note about going back was the part I had written for a different tool."
Katarzyna: "The assistant had written me eighteen passing tests and a wrong rule. What found it was Marek, who has handled glass claims for years and wrote down what a complete glass claim looks like before any code existed."
The gates, at hand-over
Each build record carries the gate status of every step with a date. Both builds had every gate met at hand-over; one gate in each had been failed and reopened, and the record keeps that history.
| Step | Nordvik Region gate | Date | Hansa Mutual gate | Date |
|---|---|---|---|---|
| 1 Intent | One-page intent with success measure | 2031-09-10 | One-page intent with success measure | 2031-09-17 |
| 2 Tier | Five questions answered; Tier B | 2031-09-11 | Five questions answered; Tier C, screening attached | 2031-10-20 (decided 2031-09-18) |
| 3 Workshop | Clone-and-restore; mandate adopted | 2031-10-13 | Clone-and-restore; mandate adopted | 2031-10-27 |
| 4 Specification | Three rules, examples, never-do | 2031-10-15 | Rules file, examples, never-do | 2031-10-30 |
| 5 Design | Ten-minute design read by Anders Falk | 2031-10-20 | One-page design | 2031-11-03 |
| 6 Build | Slices committed, 14 tests, RUN-* records |
2031-11-05 | Slices committed, 18 tests, RUN-* records |
2031-11-06 |
| 7 Prove | 12 oracle cases pass; review by Anders Falk | 2031-11-05 | 25 oracle cases pass after glass-03 fix; review by Tomasz Wrona |
2031-11-12 (failed 2031-11-08) |
| 8 Secure | Scan clean; dependency policy; provenance | 2031-11-06 | Logs hold claim ids only; dependency policy; provenance | 2031-11-13 |
| 9 Ship | v0.1.0; Revert test for the scheduled release | 2031-11-12; 2031-12-12 (failed 2031-12-11) | Rollback rehearsed; v0.1.0 to the pilot team on 2031-11-17 | 2031-11-12 |
| 10 Run | Runbook for the scheduled job; alert to team channel | 2031-12-05 | Runbook for the pipeline job; logs without personal data | 2031-11-14 |
| 11 Own | OWN-NR-2031-0001, deputy Elin Berg |
2031-12-02 | OWN-HM-2031-0001, deputy Marek Zieliński |
2031-12-03 |
| 12 Hand over | Takeover test by Rasmus Holm; Tier C promotion (AIDR-1203) | 2031-12-12; 2031-12-15 | Takeover test by Tomasz Wrona, pass with two remarks | 2031-12-09 |
The stewardship tests at hand-over
The three tests of the stewardship principle, Name, Understand and Revert, were applied to each build at hand-over, and the record shows the result of each with its date.
| Test | Nordvik Region | Hansa Mutual |
|---|---|---|
| Name: a named person owns it | Hanna Wikström, deputy Elin Berg (OWN-NR-2031-0001) |
Katarzyna Nowak, deputy Marek Zieliński (OWN-HM-2031-0001) |
| Understand: the owner can explain a change without the assistant | Explain-it-back drill by Hanna and Elin before the takeover test; the half of the code Hanna could not read herself is covered by Elin's and Rasmus's readings | Explain-it-back drill by Katarzyna and Marek on the rule file and the draft templates |
| Revert: the change can be undone and the tool switched off | Failed 2031-12-11 (rollback note, item T6); passed 2031-12-12 | Pipeline job stopped and the previous release restored in the takeover test; passed 2031-12-09 |
The Understand test is the least comfortable for a builder, because the honest answer is sometimes "only with help". Hanna's record says so. Her answer was not to learn to read all of the code but to make the parts she cannot read small, named and covered by tests that someone else wrote, and to make Elin, who can read the rules and the tests, the person who answers for them when she is away.
What each build changed
Each builder changed her own practice, and each organisation changed something about the surroundings, in ways that are small and specific. These changes are illustrative; they are recorded here because the chapter's argument is that the gap between a prototype and a service is closed from both sides.
At Nordvik Region Hanna now writes the rollback note last, after she has run it against the template, and not first. Maja Lindqvist's platform team added a line to the scheduled-job template's onboarding checklist asking for the release name used in the rollback and a rehearsal date. The tier signal that Hanna wrote in September is now a field in the build record template, which is how the reclassification was noticed on the day it happened and not in a later audit.
At Hansa Mutual the order of two steps changed. Marek's oracle cases are now written after the rules owner has confirmed the rule that the case tests, so that a case and a rule that disagree can be traced to one of them. Group Application Development added the oracle run to the builder lane's pipeline as a job that the builder cannot edit, which keeps the independent oracle independent in practice and not only in the mandate. Tomasz Wrona's two remarks were written into the handover template as a prompt: every file that a change touches, the oracle file included, is named in the README, and the languages of the drafts that fall back to a default are counted.
Practical guide: A one-page timeline for your own build
Purpose. Plan the twelve steps for a build on one page, with a date and an owner for each gate, so that slippage is visible when it happens and not at the end.
Roles. The builder, who writes it; the deputy, who reads it; the receiving developer or tech lead, who is told the date of the takeover test at the start.
Inputs. Your intent and tier decision (Steps 1 and 2), your organisation's workshop and pipeline, and a calendar.
Steps.
- Work backwards from the day you want to hand over. Put the takeover test on that day and name the colleague who will run it.
- Give every step a gate stated as something that can be shown, and a date. Allow more time for Steps 3, 7 and 9 than you expect: the two builds in this chapter spent their longest waits on the workspace, the oracle and the rollback.
- Write the failure you are most likely to meet at each of Steps 7 and 9 and the fix you would make. Both builds met one.
- Write the signal that would change your tier and who you would tell.
- Write the measure and the day you will measure it again, no more than 90 days after the first reading.
- Review the page at each gate and record the real date beside the planned one.
Exit gate. A one-page timeline exists with dates, owners, the takeover-test date and the re-measurement date.
Artefact. A file kept beside the build record, for example:
# docs/timeline.yaml (template)
build: BLD-XX-2031-NNNN
handover_target: 2031-12-12
takeover_tester: "named colleague"
tier_change_signal: "runs unattended, or used outside the team"
measure: {name: "calls per month", baseline: 41, remeasure_by: 2032-03-31}
gates:
- {step: "Step 7 Prove", planned: 2031-11-05, actual: null, risk: "oracle finds a rule error"}
- {step: "Step 9 Ship", planned: 2031-11-12, actual: null, risk: "rollback note untested"}
Nordvik Region and Hansa Mutual
The two builds differ in where the time went. Hanna's longest wait was for the workspace, which the platform team had to build, and her failing gate was one that only a person who had not built the tool could find, the rollback. Katarzyna's longest wait was for the data protection screening and for the rules owner's confirmation, and her failing gate was one that only a person who knew claims could find, the glass rule. In both cases the person who found the fault had not written the tool and had not been helped by the assistant, which is the independent-oracle rule in practice. Both organisations kept the rules of the Level 4 prohibitions: no class of work ran at Level 4, and no assistant read production data, touched its own mandate or pushed to production.
Across the usage modes
| Step | Mode 2 Embedded assistant in the editor | Mode 3 Agentic work tool in a sandbox |
|---|---|---|
| 1 Intent | Interviewer: asks questions and writes the answers down; the builder writes the intent | Not used |
| 3 Workshop | Not used | Drafts AGENTS.md and .gitignore for the builder to review |
| 4 Specification | Suggests edge cases | Converts the oracle owner's examples into test stubs, never into the oracle itself |
| 6 Build | Completes a function inside the open file | Writes one slice and its tests on a branch, within the mandate |
| 7 Prove | Explains a failing test | Runs the suite; cannot edit tests/oracle/ |
| 8 Secure | Flags a suspicious dependency name | Runs the scan the builder configured; cannot read secrets |
| 9 Ship | Not used | Cannot trigger the pipeline |
| 10 to 12 | Drafts the README and the runbook text | Not used for ownership or hand-over decisions |
Summary
The two builds ran from September to December 2031. Hanna Wikström's service-point-check at Nordvik Region was classified Tier B on 11 September, built in the workspace that opened on 6 October, released as v0.1.0 on 12 November, scheduled as v0.2.0 on 8 December and promoted to Tier C on 15 December (AIDR-1203). Katarzyna Nowak's claims-doc-check at Hansa Mutual was Tier C from 18 September, screened by the data protection officer on 20 October, released to the pilot team on 17 November and passed its takeover test on 9 December. Every one of the twelve steps produced an artefact that a second person could open, and each build's record kept the date of every gate.
One gate failed in each build, and in each the person who found the fault was not the builder and was not helped by the assistant. At Hansa Mutual the independent oracle caught a rule that the assistant had copied wrongly and tested against its own copy, before the first release. At Nordvik Region the takeover test caught a rollback note that named a version tag where the template needs a release name, in a rehearsal and not in an incident. The measures moved in the expected direction in both, with a before-and-after comparison, no control group and one category each; the claim is narrow and its evidence expires in 90 days unless it is measured again.
The narrative is illustrative and the organisations are fictional. What is observable, in the book's sense, is the mechanism, since each failure has a counterpart in the public record of Chapter 22: an own-tests-only check and an untried rollback. What follows for each organisation is the subject of Chapter 24, and what follows for the argument of the book is the subject of Chapter 25. The step to take now is the practical guide above: write the one page for your own build and put the takeover-test date on it.
Sources
- European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). (4, European Union, 2016)
- Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026) https://developer.geon.se/