Step 12 Hand Over: The Takeover Test and Working with Developers

The last step of the twelve is the one that shows whether the other eleven worked. In Step 12 Hand over the builder gives the tool to someone else: a colleague who did not build it, who is given a working day, the repository and a handover pack, and who must run the tool, change it, ship the change, switch the tool off and restore it. That is the takeover test, and it is the measure this book uses for the word professional. The step concerns the developer functions D5 Steward, because handing over is how ownership survives a person, and D1 Frame, because the pack carries the intent and the specification that tell the receiver what correct means. The chapter also covers promotion from Tier B to Tier C, when and how to call a developer, how to work with one as a colleague, and why stopping, handing over and retiring are professional outcomes and not failures.

The takeover test: seven tasks in one working day, with the outcomes pass and promotion, fail and retest, or stop

Figure 16.1: The takeover test in one working day: a pass starts the evidence clock and may lead to promotion, a fail sends the builder back to fix the pack or the tool, or the build is stopped.

The chapter builds on AI Developer, Chapter 19, whose four tiers and promotion criteria it applies, on the stewardship principle of AI Developer, Chapter 4 (Name, Understand, Revert), which the takeover test turns into a day's work, and on AI Developer, Chapter 15, which describes the tech lead and the engineering manager who are the people a builder will meet (86, Nordqvist, 2026). AI Leader, Chapter 12, required that a named person can answer for an AI-supported decision (Name, Explain and Reach); the receiving developer is the person who can answer for a tool (85, Nordqvist, 2026). The step form of this book applies: what a developer does, what vibe coding does instead, how AI helps and misleads, what each tier needs, the practical guide with its gate and artefact, the two builds, and the signs that a developer should be called. The chapter closes the twelve steps with a table of every gate and the artefact that meets it.

What a developer does at this step

A developer hands over so that someone else can continue. In a team the handover is a routine event: a person changes project, a service moves to another team, a contractor leaves. The practice is old and is the reason that experienced developers write down things that look obvious to the author: where the code is, how to run it, how to change it, what depends on it, who to call and what is known to be wrong. Four elements carry the work, and a fifth, the decision to stop, completes it.

The takeover test

The takeover test is this book's own measure, the builder's form of the stewardship principle. A named colleague who did not build the tool, given one working day, the repository and the handover pack, must be able to do five things: run the tool and its tests; change it, by making a small specified change that passes the tests; ship the change through the pipeline, to a test target and not to production; switch the tool off and restore it; and explain it, in their own words, from the documents alone. Run, change and ship test the Understand part of the stewardship principle for someone other than the builder. Switch off and restore test Revert. Name is tested by the colleague finding the owner, the deputy and the accountable role in the pack without asking.

Three rules make the test mean something. The owner is not in the room. The owner can be reached by telephone, but every question the receiver has to ask is written down as a gap in the pack, because the pack's job is to make the question unnecessary. The receiver is a person and not the assistant: the receiver may use tools, including an assistant, to do the work, but the judgement that each item passed is a person's, and the oracle cases that judge the change are owned by someone other than the builder and the assistant (Step 7 Prove, Chapter 11). And the test is run on the tool as it will run, with the platform's own template or pipeline; a handover in which the receiver has to use the builder's laptop proves nothing.

The result is one of three. Pass: every item passed. Pass with remarks: no item failed, and the receiver noted improvements that do not concern a gate item; each remark has an owner and a due date and is reviewed at the next 90-day confirmation. Fail: at least one item failed. The builder fixes the pack or the tool and the receiver retests the failed items, and any item that depends on them, within five working days. The result is written to a takeover-test record (TKT-*) with the date, because the evidence expires: the series' convention of 90 days for evidence about a running tool applies to the revert and restore items, and this book treats the takeover test as valid for twelve months, or until the owner, the receiver or the platform changes, whichever comes first. Both periods are illustrative. The rule behind them is not: "a colleague could take it over" is a claim with a date.

The handover pack

The handover pack is a record in the repository, docs/handover.yaml, with an identifier HND-*. It is not a new body of documentation. It is a map to the documents that exist, plus the facts that only the pack states: what the tool is for and never does; who the owner, deputy, receiving developer, accountable role and platform contact are; the exact commands to run it and its tests; the data it touches and where its secrets live; how a change is made and shipped; how a release is reverted, by the name the platform expects; how the tool is switched off and restored, with the date of the last successful test of each; the known risks; and the end date. The pack is the thing the receiver reads first, and its test is whether the receiver can do the day's work from it.

The pack differs from the README of Chapter 15 in audience and in precision. The README is for anyone who opens the repository and is a few paragraphs long. The pack is for the one person who must continue the work, and it names things exactly: the release name and not "the latest tag", the export path variable and not "the export". The failure of the Nordvik takeover test, described below, was a pack that was exact about everything except one name.

Promotion between tiers

A build is promoted when its use outgrows its tier. Tier A, personal, becomes Tier B when colleagues in the unit begin to use it. Tier B, team, becomes Tier C, business, on any of three signals that AI Developer, Chapter 19, names and that are observable without watching individuals: a second unit begins to use the tool, personal data of people outside the team enters it, or it begins to run unattended (86, Nordqvist, 2026). Tier D, project, is not a promotion. A tool that ranks or decides about a named person, is or feeds a high-risk AI system, touches a security-critical path or acts irreversibly on production data is stopped as a citizen build and handed to the development organisation. The Tier D tests are asked again at every promotion, because a tool that grows tends to acquire the features that make it Tier D.

Promotion to Tier C is a decision with criteria, kept as data, and the criteria are those of AI Developer, Chapter 19, applied without change:

Criterion What must be shown
Name An owner and a deputy are named; the deputy has passed the drill
Understand A one-page data flow and permissions; at least 20 independent test cases written by someone other than the maker, with evidence no older than 90 days
Revert Switch-off tested; manual fallback tested; restore test no older than 90 days
Data and access Data classes recorded; data protection officer's screening, with an impact assessment if the screening finds high risk (GDPR Article 35(1)); least-privilege roles; no anonymous access
Support A support path is named
Sunset A review every 6 months and an end date

Three rules of who decides come with them. The unit head, the accountable role, decides on the evidence. The platform pipeline identity, an automated account that the platform team runs, performs the promotion, and the builder never does, because a maker who could grant their own tool a production environment or edit the criteria would hold Level 4 for a change to their own gates, which is prohibited. And the criteria are data in the platform team's repository, changed by pull request, so that a failing criterion fails the promotion and cannot be argued away. This is the pattern the DevOps Research and Assessment (DORA) programme describes for change approval: heavyweight approval by an external committee shows a negative association with delivery performance and no evidence of fewer failed changes, so the control belongs in the pipeline and its criteria, with people deciding what the criteria cannot (131, Google Cloud, 2025). The page is programme guidance on software delivery in general, and the book draws the narrower conclusion that gates are better as code than as meetings.

Evidence age applies to the criteria. A criterion is recorded as met, not met or not tested, with a date, and "not tested" counts as not met. A promotion on 2031-12-15 that rests on a restore test of 2031-12-05 is valid; the same promotion a year later is not, and the 90-day confirmation of Chapter 15 is what keeps the evidence fresh.

Calling a developer, and working with one

A builder calls a developer for three reasons: to review a tool before promotion, to receive a tool that is leaving the builder's hands, and to solve a problem that has outgrown the builder's reach. The developer in each case is a colleague. AI Developer, Chapter 15, describes the tech lead and the engineering manager; neither is a gatekeeper by nature, and a builder who treats them as one will bring them problems late and incomplete (86, Nordqvist, 2026).

Bring the following, in this order. The one-page intent from Step 1, so that the developer knows what the tool is for and who it serves. The handover pack and the build record, so that the developer sees the tier, the gates passed and the evidence dates. The specific question or failing item, with the exact error message, the command that produced it and what the builder has tried. The run records of the assistant sessions that touched the part in question, so that the developer sees what was generated and what was accepted. And the deadline and the consequence of waiting, stated plainly. A request that arrives like this takes minutes to answer; one that arrives as "it is broken" takes a day.

Request to the receiving developer
Build: BLD-NR-2031-0001, service-point-check 0.2.0, Tier B, Tier C requested
Question: review before promotion; please run docs/handover.yaml, section run
Failing item: none known; the revert section was last tested 2031-12-05
Attached: intent page, HND-NR-2031-0001, build record, RUN records for src/spcheck/compare.py
Needed by: 2031-12-11. After that the weekly report stays manual.
Not asked: a rewrite. Please say what to change and I will make the change.

Ask for a reading and a verdict, not a rewrite. A developer who rewrites the tool silently has taken the ownership that Chapter 15 asked the builder to keep, and the builder is left with software that nobody who remains can explain. Ask what the developer would change and why, make the change yourself, and have it reviewed. Google's guide to code review states the reviewer's standard in terms that fit: the purpose is to make the overall health of the code base improve over time, and a reviewer should favour approving a change once it definitely improves code health, even if it is not perfect (111, Google, n.d.). The guide is one company's documentation and not a measured effect. The attitude it describes is the right one for both sides: the developer is looking for improvement and not for perfection, and the builder is looking for a reviewer's honest reading and not for a signature.

Respect runs both ways. The developer's side: read the pack before the meeting, review the tool and not the builder, explain reasons and not only verdicts, and say what a builder cannot be expected to know. The builder's side: arrive prepared, accept that the developer may say no, keep the ownership record up to date and do not use the developer as a service desk for a tool that has no deputy. A developer has to take responsibility for what is merged: the Linux kernel's guidance on AI coding assistants states that the human submitter remains responsible for reviewing generated code and takes full responsibility for the contribution (112, The Linux kernel community, 2026). The same holds for a builder who submits a change that the assistant generated.

Stopping as an outcome

A build can end in three ways other than success, and each is a professional outcome. It can be stopped: the problem went away, the tool is not used, the cost exceeds the benefit, or the sunset date arrived without a reason to renew. Retiring follows the sunset rule of Chapter 15, with the final release tagged, the data deleted or retained under the rule that applies, and the repository archived. It can be handed over to the development organisation as a project: the tool has grown beyond a citizen build, which is the Tier D outcome, or beyond what the builder can own. Or it can be replaced by a product that the organisation buys or the platform team provides, after which the builder's tool is retired with a handover of what it taught.

The case for treating these as outcomes and not failures is practical. A builder who believes that stopping is failure keeps tools alive past their use, and those tools become the orphans of Chapter 15. AI Developer, Chapter 19, describes the first sweep at Nordvik Region in which a unit's rule list for ordering its verification queue by urgency was reclassified as Tier D, taken out of the low-code platform and returned to a manual queue while the development organisation and legal counsel considered it; the unit's initiative was kept and the unsafe form of it was stopped (86, Nordqvist, 2026). In this book the data protection screening of claims-doc-check had the same effect from the other side: scope was narrowed to property-damage claims, injury claims were left out because their free-text fields could hold health data, and the decision was recorded as AIDR-1251. Saying no to a part of a build is part of building professionally.

What vibe coding does instead

Vibe coding hands over in one way: the builder is the only one who knows. The tool runs on the builder's account, the knowledge of how to change it is in the builder's memory and in chat histories, and the knowledge of how to stop it is whatever the builder does when it breaks. When the builder is ill, changes job or leaves, the tool either stops without anyone knowing why or keeps running without anyone being able to touch it. Naur's argument that a program is a theory held by its builders, and that a new team revives it only by rebuilding the theory (91, Naur, 1985), has a plain consequence here: handing over is the work of making that theory available, and the takeover test is the evidence that it was. The essay is an argument and not an empirical study.

The gap is measurable in the way that Avelino and colleagues measured it for open-source projects, by counting how many people a tool can lose: 65 per cent of the 133 projects they studied had a truck factor of two or less (157, Avelino et al., 2016). For a builder's tool the number is one until a deputy has passed a drill and a receiver has passed the takeover test. The practical difference is that a tool with a pack and a passed test can move to a colleague in a day, while a tool without them has to be rebuilt.

How AI helps and where it misleads

An assistant is useful for the preparation. It can draft the handover pack from the repository, write the runbook and rollback note from the pipeline configuration, list the commands and their expected output, and generate the first version of the request to a developer. It can also help the receiver, who may ask an assistant to explain unfamiliar code during the test; that use is allowed because the receiver's judgement, and the oracle, decide whether the change is right.

It misleads in three ways that the test exposes. It writes the rollback or restore note in the form that sounds right and that its training suggests, and that may differ in one word from what the platform accepts, which is how the Nordvik test failed. It describes the tool as it was meant to be and not as it is, so the pack must be checked against a run. And an assistant used as the receiver, given only the pack and asked whether it could take over, will answer yes with confidence. That cold-start check is a useful rehearsal and is never the test, because the test is passed by a person who answers for the result and because the assistant is not independent of the pack it was given.

The Level 4 prohibitions are relevant at exactly this step. The assistant never changes its own mandate, never edits the oracle cases in tests/oracle/, never edits the pipeline gates and never promotes a tool: promotion is the platform pipeline identity acting on a unit head's decision. Nothing about a decision on a named person's employment, pay, performance rating or access to work belongs in a builder's tool at any level.

Proportion: what each tier needs

Tier A personal Tier B team Tier C business Tier D project
Handover pack A note in the README on how to run and stop it HND-* record, short Full HND-* record, kept current Development organisation's standard
Takeover test Not required Recommended before the tool is shared beyond the team; a colleague reads the pack and runs it Required: a developer receiver, a full day, a TKT-* record Not a citizen build
Receiver None A colleague in the unit A named receiving developer Development organisation
Promotion To B when colleagues use it To C on any of the three signals, with the criteria Not applicable; if the tool ranks or decides about a person, stop and move to D Not applicable
Evidence age Platform expiry at 12 months without use Revert and restore evidence 90 days Revert and restore 90 days; takeover test 12 months or until a change of owner, receiver or platform Development organisation
End Expiry Sunset date Sunset date, archive or retention rule Development organisation's lifecycle

Practical guide: Preparing the handover pack and running the takeover test

Practical guide: Preparing the handover pack and running the takeover test

Purpose. Show that a colleague who did not build the tool can run it, change it and ship the change, and switch it off and restore it, from the handover pack alone, and, where the use has outgrown the tier, promote the tool with evidence.

Roles. The builder is the owner and prepares the pack. The deputy has passed the drill of Chapter 15. The receiving developer runs the test and was not involved in building the tool. The accountable role, normally the unit head, decides on promotion. The platform engineer runs the pipeline identity that performs a promotion. The oracle owner holds the independent test cases and writes the case for the change task. The data protection officer's office screens the data. The owner is available by telephone and is not in the room.

Inputs. The repository at the release to be tested; the ownership record OWN-* (Chapter 15); the build record BLD-*; the specification and runbook; the mandate manifest; the criteria file promotion_criteria.yaml@1.0 of the platform team; a test target where a change can be shipped without reaching users; and a small change task chosen by the oracle owner and kept secret from the builder, so that the change is not rehearsed.

Steps.

  1. Write the pack. Fill docs/handover.yaml from the records that exist. Use exact names: release names, variable names, paths. Run every command in it on a clean copy.
  2. Fix the day. Agree a date with the receiver, book a working day, and agree that the owner will be reachable and not present. Give the receiver the repository and the pack and nothing else. The oracle owner prepares the change task and the oracle case for it.
  3. Item T1, find. The receiver finds, from the pack alone, the purpose, the owner, the deputy, the accountable role and the data the tool touches. A name that has to be asked for is a gap.
  4. Item T2, run the tests. On a clean copy, the receiver sets the tool up and runs the tests and the oracle cases.
  5. Item T3, run the tool. The receiver produces a report or output on synthetic data, then on the production path in read-only form, through the platform's template or pipeline.
  6. Item T4, change. The receiver makes the change task. The change must pass the tests and the oracle case, and the receiver says in one paragraph what was changed and why.
  7. Item T5, ship. The receiver ships the change through the pipeline to the test target and shows that it runs there. Nothing reaches users.
  8. Item T6, revert. The receiver rolls the test target back to the previous release using only the rollback note. This is the Revert test of Step 9 Ship (Chapter 13), run by someone who did not write the note.
  9. Item T7, switch off. The receiver switches the tool off using only the runbook and shows that it is off. The manual fallback is shown to work.
  10. Item T8, restore. The receiver restores the tool from the repository and the secret store to a working state and runs it.
  11. Item T9, explain. The receiver explains the tool to the oracle owner without the owner or the assistant: what it does, what it never does, where its data goes, what happens when it fails, and when it ends.
  12. Item T10, secrets. The receiver confirms that the repository holds no secrets and says where the tool's secrets live.
  13. Record. The receiver and the oracle owner write the takeover-test record TKT-* with each item's result and time, every gap, the overall result and the date. Every gap is also a change to the pack.
  14. Fix and retest. For a fail, the builder fixes the pack or the tool and the receiver retests the failed items within five working days.
  15. Promote, if the use has outgrown the tier. Check the three signals and the Tier D tests. The oracle owner, the data protection officer's office and the receiver provide the evidence for the criteria. The unit head decides and records the decision as an AIDR-*; the platform pipeline identity performs the promotion and activates any schedule.

Exit gate. Step 12 is finished when the builder can show a handover pack in which every named item was exercised by someone else, and a takeover-test record, no older than the evidence period, in which every item passed (or passed with remarks that concern no gate item), together with, where the tier changed, the record of the promotion decision with the criteria and their dates. The gate is not a colleague's agreement that it looks fine.

Artefact. The handover pack HND-* and the takeover-test record TKT-*, in the repository; for a promotion, also the AIDR-* record.

The handover packs

The Nordvik pack is shown as revised after the failed test. The line that failed is the one under revert: before 2031-12-12 it read to_previous: redeploy tag v0.1.0.

id: HND-NR-2031-0001
build: BLD-NR-2031-0001
repository: service-point-check
version: 0.2.0
written: 2031-12-05
revised: 2031-12-12
tier: B                         # promotion to C decided in AIDR-1203
purpose: Compare opening hours and notices of 24 service points in three sources and report mismatches weekly.
never_does: [write to the portal, write to the phone script, write to the notices spreadsheet]
people:
  owner: Hanna Wikström
  deputy: Elin Berg
  receiving_developer: Rasmus Holm
  accountable: Gunilla Roos
  platform_contact: Maja Lindqvist
run:
  setup: python3.12 -m venv .venv && .venv/bin/pip install -r requirements.txt
  tests: .venv/bin/python -m pytest -q          # 21 tests, oracle cases in tests/oracle/cases.yaml
  report_on_synthetic: .venv/bin/python -m spcheck.cli --week auto --data data/synthetic
  scheduled: Mondays 06:00 by the scheduled-job template
data_and_secrets:
  classes: public and internal; no personal data of residents
  inputs: [PORTAL_EXPORT, PHONE_EXPORT, NOTICES_EXPORT]      # read-only paths set by the platform
  secret: WIKI_TOKEN                                         # secret store, never in the repository
change:
  branch: feature branch, pull request to main
  checks: unit tests, oracle cases, review by a named developer
  oracle_owner: Saga Edvardsson                              # the assistant may not edit tests/oracle/
ship:
  how: tag the release in the Git service; the platform pipeline deploys by release name
  release_name: service-point-check-0.2.0-b3
revert:
  to_previous: redeploy the previous release by its release name, not by its tag
  rollback_target: service-point-check-0.1.0-b2              # the release name, not the tag v0.1.0
  last_tested: 2031-12-12
switch_off: disable the job in the scheduled-job template; the manual weekly comparison resumes
restore: clone the repository, redeploy the release, re-enter WIKI_TOKEN from the secret store (RST-NR-2031-0001, 2031-12-05, passed)
known_risks:
  - A change in the portal export format stops the run; the failure alert goes to the e-services channel.
  - WIKI_TOKEN expires; renewal is the owner's task.
  - The deputy and the owner are in the same team.
decisions: [docs/adr/0001-scheduled-job-template.md, docs/adr/0002-read-only-sources.md, docs/adr/0003-plain-markdown-report.md]
ends: 2033-08-31

The Hansa pack is Tier C from the start and describes a tool that handlers start themselves in the group pipeline. Its revert section is short for a reason: version 0.1.0 is the first release, so the previous state is the manual check, and reverting is disabling the job.

id: HND-HM-2031-0001
build: BLD-HM-2031-0001
repository: claims-doc-check
version: 0.1.0
written: 2031-12-04
revised: 2031-12-12
tier: C                         # since the tier decision of 2031-09-18
purpose: List the documents missing from motor property-damage claim files and draft a request text for the handler to review.
scope: [motor_collision, motor_parking_damage, motor_glass]
out_of_scope: motor_injury       # rows are written as OUT_OF_SCOPE and not processed
never_does: [decide a claim, rank handlers or claimants, send a message, write to the claims core, read free-text fields, log more than claim identifiers]
people:
  owner: Katarzyna Nowak
  deputy: Marek Zieliński
  receiving_developer: Tomasz Wrona
  accountable: Joanna Kaczmarek
  data_protection: Dr. Sabine Vogel     # screening AIDR-1251
run:
  setup: python3.12 -m venv .venv && .venv/bin/pip install -r requirements.txt
  tests: .venv/bin/python -m pytest -q          # 18 tests, 25 oracle cases in tests/oracle/cases.yaml
  on_synthetic: .venv/bin/python -m cdcheck.cli --input data/synthetic/claims_synthetic.csv --out out/
  in_production: handlers start the job "claims-doc-check run" in the claims analytics workspace
data_and_secrets:
  classes: claimant personal data (claim identifier, claim type, document types, country, language)
  production_export: read only by the identity of the group pipeline; never by the builder or the assistant
  secrets_in_repository: none
change:
  branch: feature branch, pull request to main, review by the receiving developer
  rules: rules.yaml changes only on a written request from the head of claims operations' office
  oracle_owner: Marek Zieliński          # cases and quality sample; the assistant may not edit tests/oracle/
ship:
  how: tag the release; the group pipeline builds and deploys by release name
  release_name: claims-doc-check-0.1.0
revert:
  to_previous: disable the job; handlers return to the manual check
  last_tested: 2031-12-09
switch_off: set the job "claims-doc-check run" to disabled in the group pipeline
restore: clone the repository, redeploy the release by name (RST-HM-2031-0001, 2031-11-14, passed)
known_risks:
  - A new column in the claims export stops the run.
  - An unknown language value falls back to English drafts (remark R2 of TKT-HM-2031-0001).
decisions: [docs/adr/0001-property-damage-only.md, docs/adr/0002-draft-only.md]
ends: 2033-08-31

The takeover-test records

The Nordvik record shows a failure and its repair. The item that failed is the one the pack was least exact about, and the promotion block records the criteria against their dates.

id: TKT-NR-2031-0001
build: BLD-NR-2031-0001
handover_pack: HND-NR-2031-0001
version_tested: 0.2.0
run_by: Rasmus Holm              # developer, integration and data team; did not build it
date: 2031-12-11
owner_present: false             # reachable by telephone; every question counts as a gap
item_time: 06h25m             # sum of the items; the test ran 08:30 to 16:30 with breaks
change_task: report a notice whose end date is earlier than its start date as a mismatch
items:
  T1_find:       {result: pass, minutes: 15}
  T2_run_tests:  {result: pass, minutes: 25}
  T3_run_report: {result: pass, minutes: 30}
  T4_change:     {result: pass, minutes: 95, note: oracle case for the test branch written by Saga Edvardsson, branch discarded}
  T5_ship:       {result: pass, minutes: 40, target: test}
  T6_revert:
    result: fail
    minutes: 70
    finding: Rollback note names tag v0.1.0; the scheduled-job template accepts a release name only.
    gap_questions_to_owner: 1
  T7_switch_off: {result: pass, minutes: 20}
  T8_restore:    {result: pass, minutes: 45}
  T9_explain:    {result: pass, minutes: 35}
  T10_secrets:   {result: pass, minutes: 10}
result: fail
fixes:
  - {item: T6_revert, action: note names service-point-check-0.1.0-b2, done: 2031-12-12, by: Hanna Wikström}
retest:
  date: 2031-12-12
  items: [T6_revert]
  run_by: Rasmus Holm
  result: pass
result_final: pass
evidence_valid_until: 2032-12-11   # sooner if the owner, the receiver or the template changes
promotion:
  from: B
  to: C
  signals: [used by service-point managers in other units, runs unattended from 2031-12-22]
  criteria: promotion_criteria.yaml@1.0
  met:
    name: {owner_and_deputy: true, deputy_drill: 2031-12-02}
    understand: {one_page_data_flow: true, independent_cases: 20, written_by: Saga Edvardsson, last_run: 2031-12-12}
    revert: {switch_off: 2031-12-11, manual_fallback: 2031-12-10, restore_test: 2031-12-05}
    data_and_access: {data_classes_recorded: true, screening: 2031-12-03, dpia_needed: false, anonymous_access: none}
    support_and_sunset: {support_path: e-services channel, then integration and data team, review_months: 6, sunset: 2033-08-31}
  decided: 2031-12-15
  decision_record: AIDR-1203
  decided_by: Gunilla Roos
  promoted_by: platform-pipeline-identity

The Hansa record passed with two remarks. Neither concerns a gate item, so the result is a pass; one remark was closed within three days and the other stays open until its due date.

id: TKT-HM-2031-0001
build: BLD-HM-2031-0001
handover_pack: HND-HM-2031-0001
version_tested: 0.1.0
run_by: Tomasz Wrona             # developer, Group Application Development, Polish service centre
date: 2031-12-09
owner_present: false             # reachable by telephone; every question counts as a gap
item_time: 05h50m
change_task: accept video as an alternative to photos for motor_parking_damage
items:
  T1_find:       {result: pass, minutes: 10}
  T2_run_tests:  {result: pass, minutes: 20}
  T3_run_report: {result: pass, minutes: 25}
  T4_change:     {result: pass_with_remark, minutes: 105, remark: R1}
  T5_ship:       {result: pass, minutes: 40, target: test}
  T6_revert:     {result: pass, minutes: 30}
  T7_switch_off: {result: pass, minutes: 15}
  T8_restore:    {result: pass, minutes: 40}
  T9_explain:    {result: pass_with_remark, minutes: 55, remark: R2}
  T10_secrets:   {result: pass, minutes: 10}
result: pass_with_remarks
remarks:
  R1:
    finding: README does not mention tests/oracle/cases.yaml in its change section; found after the second test run.
    action: add the oracle file and its owner to the README
    owner: Katarzyna Nowak
    due: 2031-12-16
    closed: 2031-12-12
  R2:
    finding: An unknown language value silently produces an English draft that the handler may not notice.
    action: count fallbacks in the run summary (counts only, no claim text)
    owner: Marek Zieliński
    due: 2032-01-13
    closed: null
rule: remarks may not concern a gate item; an open remark is reviewed at the next 90-day confirmation
evidence_valid_until: 2032-12-09   # sooner if the owner, the receiver or the pipeline job changes
criteria:
  tier: C
  reference: promotion_criteria.yaml@1.0
  name: {owner_and_deputy: true, deputy_drill: 2031-12-03}
  understand: {one_page_data_flow: true, independent_cases: 25, written_by: Marek Zieliński and the quality sample, last_run: 2031-12-09}
  revert: {switch_off: 2031-12-09, manual_fallback: 2031-12-09, restore_test: 2031-11-14}
  data_and_access: {screening: AIDR-1251, dpia_needed: false, anonymous_access: none}
  support_and_sunset: {support_path: claims operations' office, then Group Application Development queue, review_months: 6, sunset: 2033-08-31}
promotion: not applicable; Tier C since 2031-09-18

Closing the twelve steps

With Step 12 the gates of the method are complete. The table lists each step, the artefact that meets its gate and the identifier it carries in the two builds. The exact wording of each gate is in Chapter 4 and in the chapter for the step. Each row is met by showing the artefact, with its date and result.

Step Artefact shown Service-point-check Claims-doc-check
1 Intent One-page intent In BLD-NR-2031-0001 In BLD-HM-2031-0001
2 Tier Tier decision with the five questions Tier B, 2031-09-11 Tier C, 2031-09-18
3 Workshop Repository, rules file, mandate, clone-and-restore test MND-NR-BLD-2031-01, AIDR-1201 MND-HM-BLD-2031-01, AIDR-1252
4 Specification Approved specification with acceptance examples SPC-NR-2031-0001, 2031-10-15 SPC-HM-2031-0001, 2031-10-30
5 Design One-page design and decision records docs/adr/ docs/adr/
6 Build Small commits and assistant run records RUN-NR-2031-* RUN-HM-2031-*
7 Prove Tests and independent oracle, review record 12 oracle cases at 0.1.0, review by Anders Falk 25 oracle cases, glass-03 found the rule error, review by Tomasz Wrona
8 Secure Security checklist for the tier No secret in the repository No secret in the repository; screening AIDR-1251
9 Ship Release through the pipeline, change record, revert test v0.1.0, 2031-11-12; v0.2.0, 2031-12-08 v0.1.0, 2031-11-17
10 Run Runbook, alerts, restore test RST-NR-2031-0001 RST-HM-2031-0001
11 Own Ownership record, deputy drill OWN-NR-2031-0001 OWN-HM-2031-0001
12 Hand over Handover pack and takeover-test record HND-NR-2031-0001, TKT-NR-2031-0001 HND-HM-2031-0001, TKT-HM-2031-0001

The two builds at this step

Nordvik Region: service-point-check. Hanna Wikström wrote the pack on 2031-12-05, with the assistant drafting and herself running each command on a clean copy. Rasmus Holm, a developer in Anders Falk's integration and data team, who had not seen the tool before the date, ran the takeover test on Thursday 2031-12-11. The tool was at version 0.2.0, and its schedule was deployed in a held state that the platform pipeline releases only after a promotion record exists; the first scheduled run was set for Monday 2031-12-22. Nine items passed. The Revert item failed. The rollback note told the receiver to redeploy the tag v0.1.0, and the scheduled-job template does not accept tags: it accepts the release name, service-point-check-0.1.0-b2. Rasmus found the name in the template's documentation after 70 minutes and phoned Hanna once, which the record counts as a gap. The note had been written for Step 9 Ship and had never been followed by anyone except its author, who knew the name from memory. Hanna corrected the note on 2031-12-12 and Rasmus retested the item the same day, which passed.

The test also served as the evidence for promotion. The tool had acquired two signals of Tier C: service-point managers in other units use the report, and from 2031-12-22 it runs unattended on a schedule. Saga Edvardsson had added eight oracle cases for the scheduled behaviour to her twelve, giving the 20 independent cases that the criteria require. Gunilla Roos approved the promotion to Tier C on 2031-12-15 as AIDR-1203; the platform pipeline identity performed it and released the schedule. The review period now follows Tier C: the unit head reviews every six months, the next review on 2032-06-15, and Hanna confirms the ownership record every 90 days. Whether the weekly report reduces calls about wrong opening hours is a question for the measure of Chapter 23: the phone service logged 41 such calls in August 2031 and 17 in January 2032, a before-and-after count without a control group, and the December figure was not yet measured.

Hansa Mutual: claims-doc-check. Katarzyna Nowak wrote the pack on 2031-12-04. Tomasz Wrona, who had reviewed the code, ran the takeover test on Tuesday 2031-12-09 in the claims analytics workspace, with the group pipeline, on synthetic exports; the production export was read only by the pipeline identity, as always. He changed the rules file to accept video as an alternative to photos for parking-damage claims, shipped the change to the test target, rolled it back to 0.1.0, switched the job off and restored it. All ten items passed. He made two remarks. The README did not mention the oracle cases in its change section, and he found them only after a second run; Katarzyna added the oracle file and its owner to the README, closed on 2031-12-12. And an unknown language value produces an English draft without any sign to the handler. That remark concerns an improvement and not a gate, because the tool behaved as specified, and Marek Zieliński took it on with a due date of 2032-01-13: the run summary will count the fallbacks, counts only, in keeping with the rule that the tool logs claim identifiers and counts and reads no free text. No promotion applied, because the tool had been Tier C since 2031-09-18. The measure of Chapter 23 for Hansa is the median time to a complete claim file in the pilot team, 6.8 days in September 2031 and 5.1 days in December 2031; it is a before-and-after comparison without a control group, and other changes in the period were not controlled.

The gate status recorded in the two build records:

# docs/build-record.yaml, extract
BLD-NR-2031-0001:
  step_12_hand_over:
    gate: handover pack exercised by a receiver; takeover test passed; Tier C criteria met
    artefacts: [HND-NR-2031-0001, TKT-NR-2031-0001, AIDR-1203]
    evidence_date: 2031-12-12
    result: passed after one fixed item
    tier: C
    evidence_valid_until: 2032-12-11
BLD-HM-2031-0001:
  step_12_hand_over:
    gate: handover pack exercised by a receiver; takeover test passed
    artefacts: [HND-HM-2031-0001, TKT-HM-2031-0001]
    evidence_date: 2031-12-09
    result: passed with two remarks
    open_remarks: [R2]
    tier: C
    evidence_valid_until: 2032-12-09

Across the degrees of delegation

The table gives the highest degree of delegation for what the builder's assistant, and the receiver's, may do at this step. Both organisations use the assistant at Mode 2 in the editor and Mode 3 for delegated tasks inside a sandbox, under MND-NR-BLD-2031-01 and MND-HM-BLD-2031-01. Level 4 Autonomous is not used for any action class.

Work at this step Highest degree Condition
Draft the handover pack, runbook and rollback note Level 2 Supervised The owner runs every command on a clean copy before the pack is final
Rehearse the takeover test as a cold-start check Level 1 Assisted A rehearsal only; the result is not recorded as the test
Help the receiver understand unfamiliar code during the test Level 1 Assisted The receiver judges the result, and the oracle cases decide whether the change is right
Prepare the change in the test branch Level 3 Bounded In the sandbox, on a branch, no push to main, no trigger of the pipeline
Promote a tool or release a schedule Not delegated The unit head decides; the platform pipeline identity acts; Level 4 would be a change to the tool's own gates
Change the mandate, the oracle cases or the pipeline gates Not delegated Level 4 prohibition: a person changes them by pull request
Anything about a named person's employment, pay, performance rating or access to work Not delegated Never in a builder's tool; the build would be Tier D and stopped

Nordvik Region and Hansa Mutual

Both organisations ran the takeover test with a developer who had not built the tool, in one working day, with the owner out of the room, and both learned from it. At Nordvik the test found a single wrong word in a rollback note that the owner had never needed to read; the repair took a day and the promotion followed three days later. At Hansa it found two weaknesses that were not defects: a README that left out the independent oracle and a fallback that would go unnoticed by a handler. The difference in the result, a fail that was repaired and a pass with remarks, matters less than the shared fact that neither builder could have found these things alone. Both builds now have a receiving developer, Rasmus Holm and Tomasz Wrona, who can take the tool over, and both can be stopped by a named person in a few minutes. Observable: both outcomes are recorded in the build records with their dates. Expected: the revert and restore evidence will expire first, on 2032-03-03 for Nordvik (the restore test of 2031-12-04) and 2032-03-01 for Hansa (the restore test of 2031-12-02), which is why the 90-day confirmation carries a restore test. The takeover test itself is valid until 2032-12-11 and 2032-12-09 respectively, unless the owner, the receiver or the platform changes.

When to call a developer

This chapter closes the twelve steps, and the signs that a developer should be called are the signs that the builder has reached the edge of a citizen build. Call a developer, and call them early, when any of the following is true.

  • A Tier C promotion is wanted or one of its signals has appeared: a second unit uses the tool, personal data of people outside the team has entered it, or it has begun to run unattended. The developer's review is part of the criteria.
  • The takeover test fails twice on the same item, or the receiver needs the owner to answer more than a few questions. The pack, or the tool, is not ready, and a developer can help to see which.
  • Any of the Tier D tests is true, or doubtful: the tool ranks or decides about a named person, is or feeds a high-risk AI system, touches a security-critical path such as authentication, authorisation, cryptography, payment or clinical logic, or acts irreversibly on production data. Stop, and hand the tool to the development organisation as a project. Doubt moves the tool up one tier.
  • The owner or deputy is leaving and the other cannot pass the drill. The tool needs a receiver now, or a decision to retire it.
  • The assistant has generated a change that the builder cannot explain, and the tests pass. Do not ship it. A developer can read it, and the oracle owner can write a case that tests what it does.
  • The tool has to be stopped, and stopping affects others: users depend on it, data must be kept under the records rule or deleted under the data protection rule, or another tool reads its output.

Each of these is a normal professional event. A builder who calls early is practising what the twelve steps teach: knowing where one's own competence ends.

Summary

This chapter concerned Step 12 Hand over and the developer functions D5 Steward and D1 Frame. The takeover test, run by a named colleague who did not build the tool, in one working day with the owner out of the room, shows whether the tool can be run, changed, shipped, switched off and restored from the handover pack alone. The pack HND-* is a map to the existing records plus the exact facts only the pack states, and the result is a TKT-* record with a date, valid for twelve months or until the owner, the receiver or the platform changes. Promotion from Tier B to Tier C rests on three signals and on the criteria of AI Developer, Chapter 19: Name, Understand and Revert, data and access, support and sunset. The unit head decides, the platform pipeline identity performs the promotion and the criteria are changed by pull request, never by the maker.

Calling a developer is part of building: bring the intent, the pack, the build record, the exact question and the assistant's run records, ask for a reading and not a rewrite, and keep the ownership. Stopping, handing over and retiring are professional outcomes. The assistant drafts the pack and the runbook and misleads by writing a note that sounds right and is wrong by one word, which is exactly how the Nordvik test failed; the Level 4 prohibitions hold, and promotion and gate changes are never delegated.

In the two builds, service-point-check failed one item, the rollback note, repaired it on 2031-12-12 and was promoted to Tier C on 2031-12-15 under AIDR-1203; claims-doc-check passed with two remarks on 2031-12-09. Both builds now meet the gates of all twelve steps with dated evidence. Part VI turns from the builder to the organisation: Chapter 17 describes what the organisation must provide so that a builder finds the sanctioned route easier than the unsanctioned one, with the sandboxes, templates, golden paths, register and receiving developers that these two builds relied on.

Sources

  1. 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)
  2. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 11. (85, Nordqvist, 2026)
  3. Google Cloud, DORA (2025). Streamlining change approval. DevOps Research and Assessment (DORA) programme capability page, last updated 30 October 2025. (131, Google Cloud, 2025)
  4. Google. The Standard of Code Review. Google Engineering Practices documentation, Code Review Developer Guide. (111, Google, n.d.)
  5. The Linux kernel community. AI Coding Assistants. Linux kernel documentation, Documentation/process/coding-assistants. (112, The Linux kernel community, 2026)
  6. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), 253-261. (91, Naur, 1985)
  7. Avelino, G., Passos, L., Hora, A. & Valente, M. T. (2016). A Novel Approach for Estimating Truck Factors. 24th International Conference on Program Comprehension. (157, Avelino et al., 2016)