Step 11 Own: Documentation, Updates, Review and Sunset

A tool is finished on the day it ships, and it is owned for every day after that. This chapter covers Step 11 Own, the step in which the builder turns a working tool into one that still works, can still be explained and can still be switched off two years later, when the builder has moved to another team and the assistant that helped to write it has been replaced by a newer one. It concerns the developer function D5 Steward: owning software over time, with release, operation, maintenance, ownership, documentation and the authority to revert. Step 10 Run (Chapter 14) kept the tool running from day to day. Step 11 asks what keeps it owned: a named owner and a deputy, documentation that someone else can use, a routine for updates, review dates that expire evidence, a drill that shows the deputy understands the tool without the assistant, and an end date decided at the beginning. Step 12 Hand over (Chapter 16) then tests all of it on a colleague.

Figure 15.1: Lifecycle of an owned tool: a record with owner, deputy and sunset date, a 90-day review, the deputy's drill, the rule for a role event and the three outcomes at the sunset date.

The chapter builds on the stewardship principle that Chapter 4 took from AI Developer, Chapter 4: a named person passes the tests Name, Understand and Revert, and AI may draft, generate, explain and, within a mandate, execute, but may not own (86, Nordqvist, 2026). AI Developer, Chapter 12, showed that the principle does not expire at the release, and AI Developer, Chapter 19, gave the tiers and the register entry for a tool built by someone who is not a developer. AI Leader, Chapter 12, set out the answerability tests that the stewardship tests generalise (85, Nordqvist, 2026). The chapter follows the step form: 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.

What a developer does at this step

A developer expects software to outlive the attention of the person who wrote it. The expectation is practical: code that people depend on has to be fixed, updated, explained to newcomers and eventually removed, and each of those jobs needs someone who is responsible for it. Five habits carry the work.

An owner and a deputy, by name

The owner is the person who answers for the tool: who is called when it fails, who decides about changes and who can say why it behaves as it does. The deputy is a second person who can do the same when the owner is absent or has left. Both are named people, not departments, because a department cannot be called at night and cannot pass the Name test. The accountable role, normally the unit head, stands behind both and appoints a new owner when the post changes hands. The three roles sit in the ownership record, an OWN-* file in the repository (a repository is the folder, with its full history, in which the tool's files are kept under version control). The record says who the owner and deputy are, where the documents are, when the record was last confirmed, when it must next be confirmed and when the tool ends.

The reason to insist on names is empirical, if not about AI. Bird and colleagues studied ownership in two releases of a large operating system and found that measures such as the number of low-expertise contributors to a component and the share of work held by its top owner were related to faults before and after release (90, Bird et al., 2011). The study is correlational and concerns one company's code. It supports a design choice and does not prove a mechanism: a component with a clear principal owner is easier to keep right. The same body of work concerns the deputy. Avelino and colleagues estimated how many developers a project can lose before it is in trouble, the "truck factor", for 133 popular open-source projects on GitHub, and found that 65 per cent had a truck factor of two or less (157, Avelino et al., 2016). Open-source projects are not a regional authority's tools, and the figure is a reminder, not a forecast. It turns the deputy into a measurable thing: the number of people who can explain a tool, and the date on which that number falls to one.

Documentation that survives the builder

Documentation has one job at this step: to let someone who did not build the tool use it, change it and stop it. A short list does that. A README is the first file a newcomer opens and says what the tool is, what it never does and how to run it. A specification says what correct means (Step 4 Specification, Chapter 8). A runbook says what to do when the tool fails and how to switch it off (Step 10 Run). Decision records say why a design was chosen; Nygard's short note on documenting architecture decisions proposes one small text file per significant decision, kept with the project, so that a newcomer can learn the reasons and not only the result (44, Nygard, 2011). A changelog says what changed in each version. A handover pack (Chapter 16) gathers the pointers to all of these for the person who takes over.

None of this replaces understanding, and the limit is old. Naur argued in 1985 that a program's essential content is a theory held by the people who built it, which the program text and its documentation do not fully carry, and that a program is revived by a new team rebuilding that theory (91, Naur, 1985). The essay is an argument and not an empirical study. The book draws a practical conclusion from it: documents are necessary, they are tested by someone who rebuilds the understanding from them, and the test is the explain-it-back drill of this chapter and the takeover test of Chapter 16.

Updates: dependencies, platforms and models

A tool stands on other people's work, and that work changes. A dependency is a package of other people's software that the tool uses: PyYAML, which reads configuration files, and pytest, which runs tests, are the two dependencies of both builds of this book. A dependency receives fixes, some of them security fixes, and eventually stops receiving them. The runtime, here Python 3.12, is the same. The platform is the environment the tool runs in, such as the scheduled-job template of Nordvik Region or the group pipeline of Hansa Mutual, which the platform team changes on its own schedule. A model, where a tool calls one, is a dependency with a retirement date: one provider's documentation states that applications relying on its models may need occasional updates, that requests to retired models fail and that publicly released models carry at least 60 days' notice (31, Anthropic, n.d.). Neither build calls a model at run time, which removes one dependency. A builder whose tool does call one records the model version and the published retirement date in the ownership record, and puts the date in the calendar.

The developer's routine is small and regular. Once a month, on a fixed day, update the dependencies on a branch, run the full tests and the independent oracle cases, and merge if they pass. Security notices from the platform team arrive between the monthly rounds and are handled the same way. The step is cheap when it is regular and expensive when it is skipped for a year, because a year of changes arrives together and the test that fails cannot be traced to one of them.

Review dates and evidence age

Everything the builder has shown so far carries a date: the tests passed on a day, the restore worked on a day, the deputy explained the tool on a day. A claim of that kind expires, because the platform, the dependencies, the export formats and the people change. The series applies the same rule to resilience and coverage claims and to the register entries of AI Developer, Chapter 19: "tested" without a scope, a date and a result is not evidence, and "not tested" counts as not met. This book uses 90 days for evidence about a running tool. The owner therefore confirms the ownership record at least every 90 days: opens it, checks that every field is still true, re-runs the tests and the restore test, and writes the new date. The 90 days are the owner's cycle. The register review by the unit head is a second, slower cycle with its own period by tier, 12 months for Tier B and 6 months for Tier C in AI Developer, Chapter 19 (86, Nordqvist, 2026). The owner's cycle keeps the evidence fresh, and the unit head's review decides whether the tool should continue.

The end, decided at the beginning

Software has an end, and the cheapest time to decide it is at the start. A sunset date is a date in the ownership record on which the tool ends unless the owner shows that it is still used and still passes review. It is not a prediction. It forces a decision in place of drift, and it gives the deputy and the unit head a date to plan from. At the sunset date there are three outcomes: renew, with evidence; retire; or hand the tool over to the development organisation as a project, which is the right outcome when the tool has outgrown a citizen build, for instance because it has become a Tier D candidate.

Retiring is work. Wright, writing on deprecation in the Google engineering book, observes that removal is hard because users depend on behaviour that merely happens to work and because the cost of keeping a system is hard to see, and that an abandoned system that still has users needs an explicit owner whose main goal is removal (158, Wright, 2020). The book is a practitioner's account and not research, and the point holds for a builder's tool too. Two legal constraints shape the end. A public authority such as Nordvik Region must treat source code and design documents of a tool that supported its work as potential records, because public records may be disposed of only within section 10 of the Archives Act and any deviating rules, and whether such material is a public document is, on the book's own reading, a question for the archivist and counsel: the Region retires a repository by tagging a final release and moving it to an archive with the archivist's agreement, not by deleting it. Data protection law asks that personal data are kept in identifiable form no longer than necessary for the purposes of processing (GDPR Article 5(1)(e)) (4, European Union, 2016), so a tool that holds such data deletes its working files on a stated schedule and, at the end, its copies. Where the two rules appear to conflict, legal counsel decides, and the ownership record says which rule was applied.

When the builder changes job

The owner leaves more often than the tool does. The rule that follows is simple and is about the tool, not about the person. When the personnel process records that an owner or deputy changes post, the accountable role names a new owner within a set time; this book uses 30 days. The new owner receives the tool through the handover pack and passes the explain-it-back drill. If nobody is named in time, the tool becomes read-only or its job is disabled, then archived. A tool without an owner is not a tool that anyone has chosen to keep. The register is checked against role events and never against anyone's activity: nothing in this step logs how often a named person used a tool, and nothing should.

What vibe coding does instead

Vibe coding stops at the first working version. The tool exists on the builder's account, the builder remembers what it does, and the assistant that helped has no memory of the work unless a record was kept. Four failures follow, and each can be named in advance.

The first is the orphan. AI Developer, Chapter 12, reports for Nordvik Region an inventory in which 31 per cent of the Region's 96 repositories had no living owner (86, Nordqvist, 2026). The figure is the series' worked example for the fictional Region and is illustrative; the mechanism is the one described above and is observable in the studies cited: ownership concentrates in few people. The second is the dependency that rots: a tool left alone for a year runs against fixes it never received, and the first update then arrives with a year of changes. The third is the explanation that exists only in a conversation. The builder asked, the assistant answered, the tool worked, and the reason is in a chat history that nobody else can open and that the builder may never read again; this is Naur's theory, held in a head that has left. The fourth is the open end: nobody decided when the tool should stop, so it runs, holds personal data and reaches a platform that has changed, until it fails in front of users.

The gap, then, is not in the first version. It is in the second, third and tenth year, and the builder who has practised Steps 1 to 10 has already done the hard part. Step 11 keeps what was built from decaying.

How AI helps and where it misleads

An assistant is good at the documentation work that builders postpone. It can draft the README from the repository, write the first version of the runbook from the code and the pipeline file, list the dependencies with their versions, propose the changelog from the commit history and prepare the monthly update branch. It can also act as the newcomer: given only the README and the repository in a fresh session, it can report which instructions it could not follow. That check is useful and is not the takeover test, because an assistant has no stake in the outcome and fills gaps with plausible guesses.

It misleads in three ways. It documents the intended behaviour and not the actual one, so a README produced from the code reads confidently and may be wrong about what the tool does when its input is odd. It writes commands that look right and were never run; a runbook is only as good as the date on which someone ran each line. And it produces explanations the builder then reads and nods at, which feels like understanding and is not. The explain-it-back drill exists because the Understand test has to be passed without the assistant: the deputy explains the tool from memory and from the files, and only then may the assistant be asked to check the explanation against the code. In that order the assistant corrects the deputy. In the opposite order it teaches the deputy to repeat the assistant.

The ownership record, the review dates and the sign-off on any change to the mandate are the builder's. The assistant may draft the record and may not confirm it, because confirming is the claim that someone checked. The Level 4 prohibitions apply as in Chapter 4: the assistant never changes its own mandate, the test oracle or the pipeline gates, and never acts irreversibly on production data, whether the occasion is a feature or a clean-up.

Proportion: what each tier needs

The weight of the step follows the tier of Chapter 6, set by what can go wrong. Tier D is not a citizen build, and its ownership is the development organisation's under AI Developer, Chapter 12.

	Tier A personal	Tier B team	Tier C business	Tier D project
Owner and deputy	The maker; no deputy needed	Owner by name; deputy by name	Owner and deputy by name, accountable role named	Not a citizen build
Ownership record	One line in the README	OWN-* record in the repository and a register entry	OWN-* record, register entry and developer contact	Development organisation's record
Documentation	README with the purpose and how to run	README, specification, runbook, changelog	All of Tier B plus decision records and the handover pack	Development organisation's standard
Updates	When the maker uses it; the platform expires it after 12 months without use	Monthly dependency round	Monthly round, evidence of tests, security notices handled	Development organisation's pipeline
Review	None beyond the platform's expiry	Owner confirms every 90 days if the tool is shared; unit head reviews yearly	Owner confirms every 90 days; unit head reviews every 6 months	Development organisation's review
Explain-it-back drill	Not required	Deputy, once, and after an owner change	Deputy, at least yearly and after any role event	Named developer under the Name, Understand and Revert tests
Sunset	Expiry by the platform	Date in the record	Date in the record, archive or retention rule stated	Development organisation's lifecycle

Practical guide: The ownership pack

The ownership pack is the set of records, files and routines that make Step 11 checkable: the ownership record, the README and the documents it points to, the update routine, the dated evidence, the drill and the sunset rule. The practical guide below builds the pack and ends in a gate that can be shown.

Practical guide: Writing the ownership record and running the explain-it-back drill

Purpose. Leave the tool with named owners, documents a newcomer can use, an update routine, an evidence cycle and an end date, and show by a drill that the deputy understands the tool without the assistant.

Roles. The builder is the owner. The deputy is a colleague who will take over when the owner is away or gone; for the drill the deputy does the work and the owner watches. The accountable role, normally the unit head, signs the record. The receiving developer is told that the pack exists and reads it for Step 12. The assistant drafts documents and is not present in the room for the first half of the drill.

Inputs. The repository with the specification, tests, runbook and pipeline file from Steps 4 to 10; the build record BLD-*; the mandate manifest MND-*; the tier decision of Step 2; the platform's rules on retirement and records; the calendar.

Steps.

1. Name the roles. Write the owner, the deputy and the accountable role into the ownership record, each with a role title and a start date. The deputy agrees in writing, because a deputy who has not agreed is a hope and not a deputy.
2. Write or update the README. Use the skeleton below. Run every command in it on a clean copy of the repository and record the date. A command that was not run does not stay in the README.
3. Set the update routine. Choose the fixed day for the monthly dependency round and the rule for security notices. Put both in the ownership record and in the calendar of the owner and the deputy.
4. Set the review cycle. Confirm the record today, set every_days to 90 and compute next_due. List the triggers that force an early review: owner or deputy leaves, a source or export format changes, the platform changes.
5. Run the explain-it-back drill. The deputy sits with the repository and the README, without the assistant, and answers six questions aloud: What does the tool do and for whom? What does it never do? Where does its data come from, where does it go and who can reach it? What happens if it fails and who is told? How is a change made and shipped? How is it switched off and restored? The owner takes notes and does not prompt. Each question the deputy cannot answer is a documentation gap and is written into the README or the runbook. When the deputy has answered, the assistant may be asked to check the answers against the code, and each discrepancy is recorded.
6. Record the result. Write the date, without_assistant: true and the result into the ownership record. A drill with gaps is repeated after they are closed.
7. Set the end. Write the sunset date, the renewal rule and the end-of-life rule, including the archive or retention rule for the data and the code.
8. Run the check. Run the small script below. It reads the record and reports missing fields, an overdue review, a next-due date that does not follow from the last confirmation, a missing or failed drill and a reached sunset date.
9. Sign. The accountable role signs the record. The build record BLD-* shows Step 11 as passed with the date.

Exit gate. Step 11 is finished when the builder can show, on one screen each: an ownership record with owner, deputy and accountable role by name, a review confirmed within the last 90 days and a sunset date; a README whose commands were run on a clean copy within the last 30 days; and the result of an explain-it-back drill by the deputy, passed without the assistant, within the last 30 days. "I could explain it" is not the gate; the dated drill is.

Artefact. The ownership record OWN-*, with the README, the runbook and the decision records it points to, in the repository.

The ownership records

The two records are the artefacts of the builds in this book. They agree with docs/BUILDS.md and the builder profiles. The service-point-check record is at Tier B on the day it is confirmed; the tool becomes Tier C in Chapter 16, when it first runs on a schedule. Hanna Wikström chose 90 days for the confirmation cycle although a Tier B tool needs only a yearly review, because the tool was about to become Tier C.

id: OWN-NR-2031-0001
status: active
subject:
  build: BLD-NR-2031-0001
  repository: service-point-check
  scope: Weekly comparison of opening hours and notices for service points SP-01 to SP-24
  tier: B                      # promoted to C in Chapter 16
owner:
  name: Hanna Wikström
  role: product owner, e-services team
  since: 2031-10-15
deputy:
  name: Elin Berg
  role: business analyst, e-services team
  drill:
    kind: explain-it-back
    date: 2031-12-02
    without_assistant: true
    result: passed
accountable: Gunilla Roos
documents:
  readme: README.md
  specification: docs/specification.yaml
  runbook: docs/runbook.yaml
  decisions: docs/adr/
  handover: docs/handover.yaml
  changelog: CHANGELOG.md
updates:
  dependencies: monthly, first Monday, branch plus full test run
  runtime: follows the platform scheduled-job template
  model: none at run time; the build assistant is recorded in MND-NR-BLD-2031-01
review:
  confirmed: 2031-12-02
  every_days: 90
  next_due: 2032-03-01
  triggers: [owner or deputy leaves, source export format changes, platform template changes]
owner_leaves:
  new_owner_within_days: 30
  otherwise: read-only, then archived
sunset:
  date: 2033-08-31
  renewal: owner shows use and passes review
  end_of_life: final release tagged, repository archived with the archivist's agreement

The Hansa Mutual record differs where the tool does. It is Tier C from the start, it names a receiving developer, it records the data it touches and the data protection screening of AIDR-1251, and its change rule says that the rules file changes only on a written request from the head of claims operations' office, so that the tool's business content is owned by the people who own the business.

id: OWN-HM-2031-0001
status: active
subject:
  build: BLD-HM-2031-0001
  repository: claims-doc-check
  scope: Missing documents in motor property-damage claim files, with draft request texts
  tier: C
  out_of_scope: motor_injury
owner:
  name: Katarzyna Nowak
  role: team lead, motor claims, Polish service centre
  since: 2031-10-30
deputy:
  name: Marek Zieliński
  role: senior claims handler
  drill:
    kind: explain-it-back
    date: 2031-12-03
    without_assistant: true
    result: passed
accountable: Joanna Kaczmarek
receiving_developer: Tomasz Wrona
documents:
  readme: README.md
  specification: docs/specification.yaml
  runbook: docs/runbook.yaml
  decisions: docs/adr/
  handover: docs/handover.yaml
  changelog: CHANGELOG.md
data:
  classes: [claim identifier, claim type, document types received, country, language]
  logged: claim identifiers and counts only
  data_protection_screening: AIDR-1251
updates:
  dependencies: monthly, first Tuesday, branch plus full test run in the group pipeline
  rules: rules.yaml changes only on a written request from the head of claims operations' office
  model: none at run time; the build assistant is recorded in MND-HM-BLD-2031-01
review:
  confirmed: 2031-12-03
  every_days: 90
  next_due: 2032-03-02
  triggers: [owner or deputy leaves, claims export columns change, new claim type in scope]
owner_leaves:
  new_owner_within_days: 30
  otherwise: job disabled, then archived
sunset:
  date: 2033-08-31
  renewal: owner shows use and passes review
  end_of_life: final release tagged, repository archived under the group's records rules

A README skeleton

The README is plain Markdown, a format in which headings, lists and code are written with a few symbols and which every Git service displays. The skeleton below is the one that service-point-check carries. Each heading answers one question that a newcomer asks in the first hour.

# service-point-check

Compares the opening hours and notices of the Region's 24 service points in the
citizen portal, the phone-service script and the notices spreadsheet, and writes a
weekly mismatch report to the e-services wiki.

## What it never does
It never writes to the portal, the phone script or the notices spreadsheet.
It reads and reports only. It holds no personal data of residents.

## Run it
    python3.12 -m venv .venv && .venv/bin/pip install -r requirements.txt
    .venv/bin/python -m pytest -q
    .venv/bin/python -m spcheck.cli --week auto --data data/synthetic

## How it works
sources.py reads the three exports, compare.py applies rules R1 to R3 from
docs/specification.yaml, report.py writes the Markdown report, cli.py ties them together.

## Change it and ship the change
Branch, change, run the tests and the oracle cases in tests/oracle/ (owned by
Saga Edvardsson; do not edit them), open a pull request. The pipeline ships by release name.

## Switch it off, revert, restore
See docs/runbook.yaml and docs/handover.yaml.

## Who to call
Owner Hanna Wikström, deputy Elin Berg, platform team Maja Lindqvist.

## When it ends
2033-08-31 unless renewed. See OWN-NR-2031-0001.

A check that does not need a developer

The script below turns the exit gate into something that fails loudly. It needs only Python 3.12 and PyYAML, the two things the builds already use. It reads an ownership record, compares the dates with today's date and prints every problem. Run it from the repository root at the start of every confirmation, and add it to the pipeline so that an overdue record shows as a failing check and not as a forgotten task.

"""Check an ownership record: required fields present, review not overdue."""
import sys
from datetime import date, timedelta
import yaml

REQUIRED = ["id", "owner", "deputy", "accountable", "review", "sunset", "documents"]

def check(path, today):
    rec = yaml.safe_load(open(path, encoding="utf-8"))
    problems = [f"missing field: {k}" for k in REQUIRED if k not in rec]
    if problems:
        return problems
    rev = rec["review"]
    if today > rev["next_due"]:
        problems.append(f"review overdue since {rev['next_due']}")
    if rev["confirmed"] + timedelta(days=rev["every_days"]) != rev["next_due"]:
        problems.append("next_due does not follow from confirmed and every_days")
    drill = rec["deputy"].get("drill", {})
    if drill.get("result") != "passed" or not drill.get("without_assistant"):
        problems.append("explain-it-back drill missing or not passed without the assistant")
    if today >= rec["sunset"]["date"]:
        problems.append("sunset date reached: renew or retire")
    return problems

if __name__ == "__main__":
    today = date.fromisoformat(sys.argv[2]) if len(sys.argv) > 2 else date.today()
    found = check(sys.argv[1], today)
    print("\n".join(found) if found else "ownership record in order")
    sys.exit(1 if found else 0)

Run on 2031-12-20 against the Nordvik record it prints ownership record in order; run on 2032-03-10 against the Hansa record, whose review fell due on 2032-03-02, it prints review overdue since 2032-03-02 and exits with a failure code. The script checks the record and nothing else. It does not show that the README is true or that the drill was honest, which is why the gate asks for the drill itself and for commands run on a clean copy.

The explain-it-back drill in detail

The drill tests the Understand part of the stewardship principle for the deputy, not for the owner. The owner already understands the tool, and the risk is a deputy who agreed to the role without learning the content. Four rules keep the drill honest. The deputy works without the assistant, because the claim being tested is that someone can explain the tool without it. The owner does not prompt, because a prompt is a hint. Every question the deputy cannot answer is recorded as a gap in the documents and not as a failure of the person: the person was never given the explanation, and the repair is to write it down. And the drill is repeated after an owner change, a platform change or a gap that the first run exposed, because the evidence is dated. A drill that has passed once, in a year when nothing has changed, is still a claim with an age; the next confirmation will ask for it again.

The two builds at this step

Nordvik Region: service-point-check. Hanna Wikström reached Step 11 in the first days of December 2031, after the first release (v0.1.0, 2031-11-12) and before the scheduled release (v0.2.0, 2031-12-08). She wrote the README and the runbook with the assistant, ran every command on a clean checkout and found two that did not work as written: the setup line named a requirements file that sat in a different folder, and the line that ran the report on synthetic data lacked the --data option. Elin Berg, a business analyst and not a developer, did the explain-it-back drill on 2031-12-02 with the repository open and the assistant closed. She answered five of the six questions at once. She could not say who would be told if the scheduled job failed, because the alert route had not been written down, and that gap went into the runbook the same day. The ownership record OWN-NR-2031-0001 was confirmed on 2031-12-02 with its next review due on 2032-03-01. The sunset date is 2033-08-31.

Hansa Mutual: claims-doc-check. Katarzyna Nowak confirmed the ownership record on 2031-12-03 after the explain-it-back drill by Marek Zieliński, her deputy, who is also the author of the independent oracle cases and therefore knows the tool from the outside. The drill found that Marek could explain the rules and the three draft languages but could not say where the job's output files went or for how long they stayed. The answer was that the group pipeline writes missing.csv and the drafts into the job's output folder and deletes them after 30 days, a rule that existed in the pipeline configuration and not in the README. It was written into the README and the runbook. The 30-day deletion is the storage-limitation rule of GDPR Article 5(1)(e) applied to a working copy of claimant data (4, European Union, 2016). Dr. Sabine Vogel's screening, recorded as AIDR-1251, stays attached to the record. OWN-HM-2031-0001 has its next review due on 2032-03-02.

The gate status that goes into the two build records:

# docs/build-record.yaml, extract
BLD-NR-2031-0001:
  step_11_own:
    gate: ownership record, README run on clean copy, deputy drill without the assistant
    artefact: OWN-NR-2031-0001
    evidence_date: 2031-12-02
    result: passed
    evidence_valid_until: 2032-03-01
BLD-HM-2031-0001:
  step_11_own:
    gate: ownership record, README run on clean copy, deputy drill without the assistant
    artefact: OWN-HM-2031-0001
    evidence_date: 2031-12-03
    result: passed
    evidence_valid_until: 2032-03-02

Across the degrees of delegation

The table gives the highest degree of delegation for what the builder's assistant may do at this step. For most builders the tool is a conversational assistant (Mode 1) or an agentic work tool inside the sandbox (Mode 3), as in the mandate MND-NR-BLD-2031-01 and MND-HM-BLD-2031-01. The ceiling is not a licence.

Work at this step	Highest degree	Condition
Draft the README, runbook and changelog	Level 2 Supervised	The owner runs every command on a clean copy before it stays
Prepare the monthly update branch and run the tests	Level 3 Bounded	In the sandbox, on a branch, with no push to main and no pipeline trigger
Check the deputy's explanation against the code	Level 1 Assisted	After the deputy has answered; the assistant does not lead the drill
Confirm the ownership record or the drill result	Level 0 Advisory	Only the owner and the accountable role confirm
Change the mandate, the oracle cases or the pipeline gates	Not delegated	Level 4 prohibition: owned by a person and changed by pull request
Delete data or code for a sunset	Level 0 Advisory	Irreversible on production data; a person decides and a developer reviews

Nordvik Region and Hansa Mutual

Both organisations ended Step 11 with an owner and a deputy who are named, a README run on a clean copy and a deputy's drill that exposed one gap each, closed the same day. The difference lies in what the gap was. At Nordvik the unanswered question was about the alert route, and the repair was a line in the runbook. At Hansa it was about retention, and the repair recorded a rule that the pipeline already enforced. Both gaps were found by a person who was not the builder, without the assistant, which is the reason for the drill. Both records carry the sunset date 2033-08-31 and a 90-day confirmation cycle. The evidence of Step 11 is valid until the next confirmation, 2032-03-01 for Nordvik and 2032-03-02 for Hansa. After those dates the gate shows as not met until the owner confirms again.

When to call a developer

Call a developer, usually the receiving developer, when any of the following is true. The stop signs are about the tool, not about the builder's competence.

• The tool has acquired a second unit of users, personal data of people outside the team or unattended running, and the record still says Tier A or B. Promotion needs a developer's review (Chapter 16).
• A dependency update fails the tests and the cause is not obvious after the assistant has been asked once and the answer has been checked. Do not accept a change that makes the tests pass by editing them.
• A security notice concerns a dependency of the tool and the platform team's advice does not settle it.
• The deputy cannot pass the drill after the gaps were closed, or both owner and deputy are leaving. The tool has no steward; a developer should decide whether it moves to a team, becomes a project or is retired.
• The tool has begun to rank or decide about a named person, to feed a high-risk AI system or to touch a security-critical path. That is Tier D, and the development organisation takes it over as a project.
• The sunset date has arrived and renewal would need a change that goes beyond what a builder should ship alone.

Summary

This chapter concerned Step 11 Own and the developer function D5 Steward. A tool is owned for every day after it ships, and ownership is a record: an owner and a deputy by name, an accountable role, documents that let a newcomer use, change and stop the tool, an update routine, a 90-day cycle in which evidence is refreshed, and a sunset date decided at the beginning. Studies of ownership and of how few people many projects depend on give the reason for names and for a deputy, with limits stated: they concern large companies and open-source projects, not a regional authority's small tools, and they are correlational. Naur's argument that understanding lives in people and not in documents gave the reason for the drill.

Vibe coding stops at the first working version and leaves the orphan, the rotting dependency, the explanation that lives in a chat and the open end. The assistant helps to draft the README, the runbook and the update branch, and misleads by documenting intention, by writing commands that were never run and by supplying explanations that feel like understanding. The explain-it-back drill therefore runs without it, and the Level 4 prohibitions hold: the assistant does not change its own mandate, the oracle or the gates and does not delete production data. The tiers set the weight of the step, from a line in the README at Tier A to the full pack with a developer contact at Tier C, and Tier D is not a citizen build.

In the two builds, Hanna Wikström and Katarzyna Nowak each ended with a confirmed ownership record, a README run on a clean copy and a deputy who passed the drill after one documentation gap was closed. The gate for Step 11 is a set of dated artefacts and not a feeling of readiness. It is expected, and not yet measured, that organisations which keep ownership records and review dates will find fewer orphaned tools; the illustrative inventory of AI Developer, Chapter 12, gives a baseline of 31 per cent to compare against. Chapter 16 takes the last step: a colleague who did not build the tool runs, changes and ships it and switches it off and restores it, and the builder learns what a handover pack must contain, when a tool is promoted from Tier B to Tier C and how to work with a developer as a colleague.

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. Bird, C., Nagappan, N., Murphy, B., Gall, H. & Devanbu, P. (2011). Don't Touch My Code! Examining the Effects of Ownership on Software Quality. Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, 4-14. (90, Bird et al., 2011)
4. 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)
5. Nygard, M. (2011). Documenting Architecture Decisions. Cognitect blog, 15 November 2011. (44, Nygard, 2011)
6. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), 253-261. (91, Naur, 1985)
7. Anthropic. Model deprecations. Claude Platform documentation. (31, Anthropic, n.d.)
8. Wright, H. (2020). Deprecation. Chapter 15 in Winters, T., Manshreck, T. & Wright, H. (eds), Software Engineering at Google. O'Reilly Media. (158, Wright, 2020)
9. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)