The Method: Twelve Steps, Four Tiers and the Takeover Test

This chapter defines the method that the rest of the book teaches, and every later chapter takes its terms from it. It concerns all twelve steps by their exact names: Step 1 Intent, Step 2 Tier, Step 3 Workshop, Step 4 Specification, Step 5 Design, Step 6 Build, Step 7 Prove, Step 8 Secure, Step 9 Ship, Step 10 Run, Step 11 Own and Step 12 Hand over. Behind them stand the five developer functions of AI Developer, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, which are the professional practice that each step teaches a builder to carry out (86, Nordqvist, 2026). The chapter defines the steps with the gate that ends each one and the artefact that meets the gate; restates in full the four tiers (A personal, B team, C business, D project) that AI Developer, Chapter 19, set for people who build and are not developers; gives the proportion table of what each step requires at each tier; defines the takeover test, the book's measure of the word professional; applies the stewardship principle and the independent test oracle to the builder; sets out the mandate under which the builder's assistant works and the Level 4 prohibitions that apply to it; and ends with the build record BLD, the one file that carries a whole build.

Figure 4.1: The twelve steps in four groups, the tier decision, the mandate, the independent oracle, the takeover test and the build record.

A few terms are used from the first paragraph and are defined here once. A builder is a person who is not a developer and builds software, usually with an AI assistant. A developer is the professional. A gate is a condition that ends a step and that is met by showing something; a step is never finished by saying so. An artefact is the thing that is shown: a file, a record, a test result, kept with the code. An assistant is the AI system that suggests, drafts, explains or, within a mandate, carries out work for the builder. A mandate is the written statement of what the assistant may read, change, run and reach. A repository is a folder whose every change is kept with its author, its date and a note of why. The takeover test is defined below.

Two records at the start

Both builds of this book begin with a build record. On 2031-09-08 Hanna Wikström, product owner of the e-services team at Nordvik Region, opened BLD-NR-2031-0001 for a tool that she called service-point-check. A week later, on 2031-09-15, Katarzyna Nowak, a team lead in the motor claims team of Hansa Mutual's service centre in Poland, opened BLD-HM-2031-0001 for claims-doc-check. Neither is a developer. Each had an assistant, a problem that cost her colleagues time, and a first version within days. What each lacked, on the day the record was opened, was an answer to the questions that decide whether a tool can be relied on: who else can run it, how it is changed safely, who stops it, and what happens when its builder is away.

	BLD-NR-2031-0001	BLD-HM-2031-0001
Build	service-point-check	claims-doc-check
Builder, deputy	Hanna Wikström, Elin Berg	Katarzyna Nowak, Marek Zieliński
Opened	2031-09-08	2031-09-15
Tier decision	B on 2031-09-11, C on 2031-12-15	C on 2031-09-18
Receiving developer	Rasmus Holm, in the integration and data team	Tomasz Wrona, Group Application Development
State of the record at the start	Twelve gates, all not started	Twelve gates, all not started

The rest of this chapter defines what stands in them.

Why a method

A list of good habits does not make a builder's tool dependable, for a reason that has nothing to do with the builder's diligence: habits cannot be checked. A builder who says that the tool has been tested has said something that a colleague can neither confirm nor refute, and the same is true of secure, backed up and ready. Chapter 3 described twelve disciplines that a developer practises and that a build by conversation usually skips. The method turns each discipline into a step with a gate, so that progress is a matter of showing an artefact, and a reviewer can read the evidence in a few minutes instead of taking the builder's word.

The method has three further properties. It is proportionate: the tier sets how much of each step applies, so that a personal macro is not asked for what a tool holding claimants' data must have. It is owned: every build has a named owner and a deputy, and the assistant is never the owner. And it is dated: every gate records when it was met and with what result, and evidence expires, because the software, the platform and the model beneath it change. These properties are the series' own conclusions applied to a new person, the delegation ladder and the stewardship principle of AI Developer, Chapter 4, and the answerability principle of AI Leader, Chapter 4 (86, Nordqvist, 2026); (85, Nordqvist, 2026). The method as a whole is the book's own and has not been evaluated in a controlled study; the thesis section of the book states what would show it wrong, and Chapters 20 and 25 judge it.

The twelve steps

The table gives each step with its purpose, its gate, its artefact and the developer functions behind it. The wording of the gates is the wording that Chapters 5 to 16 use, and each of those chapters teaches one step in full.

Step	Purpose	Gate: shown, not asserted	Artefact	Functions
1 Intent	Say what is being built, for whom and how success will be known	The user named in the intent has read it and says it describes the problem; the builder's manager has read it	One-page intent, section 1 of the BLD record	D1
2 Tier	Decide how much structure the work needs	The five questions are answered in writing, the tier is decided with the signals that would change it, and the manager has countersigned; where personal data of others is involved, the data protection officer has screened it	Tier decision, section 2 of the BLD record	D1, D2
3 Workshop	Prepare a place to work that can be trusted	The deputy clones the repository on another machine and, from the README alone, runs the tests and the tool on synthetic data (the clone-and-restore test)	Repository with README, AGENTS.md, the mandate MND-*-BLD-*, environment configuration without secrets	D3, D5
4 Specification	Write down what correct means	Every rule has at least one example and one failure case, the never-do list is written, the oracle owner is named and is neither the builder nor the assistant, and the process owner has approved	Specification record SPC-*	D1
5 Design	Decide the technology, the data and the access	A developer or architect has read the one-page design in ten minutes and can say where the data lives, who can reach it and how the tool is switched off	One-page design with three to five Architecture Decision Records (ADR)	D2
6 Build	Make the first version in small slices	Every slice is committed with passing tests, the builder has read each diff against the plan, every assistant session has a run record, and the tool runs from a fresh clone	Commits and run records RUN-*	D3
7 Prove	Show that it works, by something other than the assistant's word	Tests derived from the specification pass, the independent oracle cases pass and were written by neither the builder nor the assistant, and a person other than both has reviewed	Verification plan VER-*, review record RVW-*, dated results	D4
8 Secure	Make it safe at the level the tier requires	The security checklist of the tier is completed item by item with result and date, the secret scan is clean, the dependencies are recorded, and the screening is attached where personal data is involved	Provenance record PRV-* and the completed checklist	D4
9 Ship	Release through a path that can be undone	The release was made by the pipeline and not by the builder's hands, the version is tagged, and the Revert test is done: the previous version was restored by following the rollback note	Change record CHG-*, release notes, rollback note	D5
10 Run	Watch, back up and support what was built	A person other than the builder receives the failure alert, a restore test has been done with date and result, and the runbook lets a colleague stop the tool	Runbook manifest RBK-*, restore-test record RST-*	D5
11 Own	Keep the tool owned over time	Owner and deputy are named, the deputy has passed the explain-it-back drill without the assistant, and the review and sunset dates are set	Ownership record OWN-* and a README that explains	D5
12 Hand over	Hand over, promote or stop	A named colleague has passed the takeover test in a working day	Handover pack HND-* and the takeover-test result	D5, D1

The method is not a waterfall. A builder returns to Step 4 when the first slice shows that an example was wrong, and to Step 2 when a second unit asks to use the tool. What does not change is that a step is closed by its gate, and that an expired gate is open again.

Step 1 Intent is where a builder who started with a prompt writes down the problem, the user, the measure and the non-goals. Its gate uses the user and the manager as readers because the commonest failure of a build by conversation is a solution to a problem that nobody confirmed. Step 2 Tier is the step that decides how heavy the rest will be, and it is the only step with a stop sign: a build that lands in Tier D leaves the method at this point and goes to the development organisation. Step 3 Workshop makes the building place trustworthy before any code is written: version control, separate places for experiments and for users, secrets kept out of the files, synthetic data, and the project rules file AGENTS.md and the mandate for the assistant. The clone-and-restore test is the first time that someone other than the builder touches the work.

Step 4 Specification gives the work its oracle, the means of deciding whether behaviour is correct. Step 5 Design makes, and records, the decisions that the assistant would otherwise make by default. Step 6 Build is the step that vibe coding already does, and the method changes only how: in small slices, with a plan before code, the diff read and a record kept. Step 7 Prove and Step 8 Secure are the steps that the conversation leaves out, and both rest on checks that the assistant did not write. Step 9 Ship, Step 10 Run and Step 11 Own carry the tool through release, operation and years of use. Step 12 Hand over closes the method with the takeover test.

Two rules apply to every gate. The first is evidence age: a gate that records a check on running software (tests, restore, review, scan) carries the date and the result, and the evidence is valid for 90 days for a tool in Tier B or Tier C. The figure is illustrative and follows AI Developer, Chapter 19, which applied 90 days to tests of a running tool because the platform, the connectors and the model beneath it change (86, Nordqvist, 2026). When the age is passed, the gate is expired and counts as not met. The second is that a gate cannot be waived by the person who is to pass it. The tier decides which gates are required, as the proportion table below shows, and a waiver for a stated reason, recorded and countersigned by the manager, is part of the record. A gate that is simply not mentioned is not met.

The four tiers

The tiers set the weight of the method by what can go wrong, and they are restated here in full from AI Developer, Chapter 19, whose definitions are the book's own and illustrative (86, Nordqvist, 2026). A register without tiers treats a personal macro and a benefits tracker alike; tiers let the lightest build carry the lightest load and send the heaviest to the people who own such work.

Tier	Test	Who answers	What follows
A, personal	Used only by the maker; no personal data of others; no write access to shared systems	The maker	Counted in the platform inventory without an individual entry; the platform expires it after 12 months without use
B, team	Used by colleagues in one unit; internal data only; no personal data of people outside the team	The unit head, with the maker named	Register entry; sandbox environment; review every 12 months
C, business	Personal data of citizens, customers or staff; money; a record of the organisation; more than one unit; or unattended running	A named owner and a deputy	Promotion gates, developer review, support path, review every 6 months
D, project	Ranks or decides about a named person; is or feeds a high-risk AI system; touches a security-critical path (authentication, authorisation, cryptography, payment, clinical or life-safety logic); or acts irreversibly on production data	The development organisation, as for any project	Not a citizen build: mandate, impact assessment, AI Decision Record and a named developer for review

A high-risk AI system is a term of the AI Act; the classification rules are in Article 6 and Annex III of Regulation (EU) 2024/1689 (1, European Union, 2024). A builder does not need to settle the classification alone: if the tool ranks or scores people, or feeds something that does, it leaves the method and goes to the development organisation, and Chapter 6 teaches how to see that. Tier D is the Level 4 prohibitions applied to a different builder, not a punishment: a tool in a security-critical path has a named developer's review whoever wrote it. The tiers do not rank people. The same case handler may own a Tier A macro and a Tier C tracker, and the tier belongs to the build, not to the builder.

A prototype becomes production by use, not by code. Three signals mark the crossing and each can be seen without watching any individual: a second unit begins to use the tool, personal data of people outside the team enters it, or it begins to run unattended. Any of the three moves a Tier B build to Tier C, and the build record is where the move is written down. service-point-check shows the crossing exactly. It began as a tool that Hanna ran on demand for one team on public and internal data, which is Tier B, and it became Tier C on the day it was to run on a schedule and serve service-point managers in other units, because two of the three signals then applied. claims-doc-check was Tier C from the first day, because claimants' data enters it. The decision for each is recorded with the signals that would change it, as Chapter 6 shows.

Proportion is part of professionalism, and so is saying no. A builder who stops at Tier A, because the tool will only ever serve its maker, has made a professional decision, and so has one who sends a Tier D idea to the development organisation on the day it is recognised.

Proportion: what each step requires at each tier

The proportion table says, for each step, what a build at each tier must show. It is the book's own judgement, illustrative like the tiers, and the organisation may set stricter requirements. The cells say what the gate asks of the tier. Where a cell asks for review, it means review by a person other than the builder and the assistant.

Step	Tier A, personal	Tier B, team	Tier C, business	Tier D, project
1 Intent	Three sentences in the README: purpose, user (yourself), what done looks like	One-page intent read by the unit head and the user	One-page intent with baseline and target for the success measure, approved by the process owner	Business case of a project
2 Tier	Self-check of the five questions	Recorded in the build record, read by the manager	Recorded, countersigned by the manager, screened by the data protection officer where personal data is involved, with reclassification signals	Stop and refer
3 Workshop	Repository with README and history; no secrets in files	Adds AGENTS.md, two environments, synthetic data and the platform's standard mandate	Adds an own mandate approved by the manager, a secret store, and the clone-and-restore test with the deputy	The development organisation's own route
4 Specification	Five examples in the README	SPC record with examples and failure cases	SPC record approved by the process owner, one example per rule, never-do list, oracle owner outside the builder	The development organisation's own route
5 Design	A note of where the data lives	Half a page: where data lives, who can reach it, one ADR	One-page design and three ADRs, read by a developer or architect	The development organisation's own route
6 Build	Commit habit	Slices, plan before code, run records	Slices, plan kept in the repository, run records for every session	The development organisation's own route
7 Prove	Run it on known cases yourself	Automated tests from the specification and cases from a second person	VER plan, independent oracle, review by a developer	The development organisation's own route
8 Secure	No secrets in files; nobody else's data	Checklist, secret scan, dependency list	Full checklist, PRV record, data protection screening, logs without personal data, developer review of access	The development organisation's own route
9 Ship	Copy to where it is used and keep the previous version	Tagged version, release notes, previous version kept for rollback	Pipeline only, CHG record, Revert test	The development organisation's own route
10 Run	You notice	A named channel for failure and a one-paragraph runbook	RBK runbook, alert to a person, restore test no older than 90 days, cost limits, support path	The development organisation's own route
11 Own	Your name in the README	OWN record with deputy; review every 12 months	OWN record, explain-it-back drill, review every 6 months or as the register sets	The development organisation's own route
12 Hand over	Note the end date	Short handover pack; a colleague runs, changes and switches off	Full HND pack; takeover test by a developer, all items	The development organisation's own route

Both builds chose reviews every 90 days, which is stricter than the table's minimum for Tier B and Tier C; the reason is the evidence age above, since a review that is older than 90 days no longer tells the owner what is true today. The table is also kept as data in the repository of the organisation that provides the builder workspace, so that the platform can check a build record against it. A fragment shows the form; the values are illustrative.

proportion:
  version: "1.0"
  tiers: [A, B, C, D]
  steps:
    7_prove:
      A: {gate: "run on known cases yourself", independent_oracle: false, review: none}
      B: {gate: "tests from SPC and cases from a second person", independent_oracle: true, review: colleague}
      C: {gate: "VER plan, independent oracle, RVW", independent_oracle: true, review: developer, evidence_max_age_days: 90}
      D: {route: development_organisation}
    9_ship:
      A: {gate: "previous version kept"}
      B: {gate: "tagged version, release notes, rollback by tag"}
      C: {gate: "pipeline only, CHG, Revert test", promoted_by: pipeline_identity, evidence_max_age_days: 90}
      D: {route: development_organisation}
  changed_by: pull-request-to-platform-team

The takeover test

The takeover test is the measure the book uses for the word professional. A named colleague who did not build the software, given a working day, the repository and the handover pack, can run it, change it and ship the change through the pipeline, and switch it off and restore it. Four verbs carry the definition and each answers a question that the owner's absence would raise: run (can it be started and does it give the right result), change (can it be altered safely), ship (can the alteration reach users by the normal path) and switch off and restore (can it be stopped and brought back). The test is the builder's form of the stewardship principle, applied to the tool instead of to a single change: the colleague passes Name, Understand and Revert on behalf of the organisation, so that the tool does not depend on one person's memory.

Who runs it and how

The test is run by a person who did not take part in the build: at Tier B, a colleague in the unit who is neither builder nor deputy; at Tier C, a developer, the receiving developer named in the register. At Tier A it is not run, and the build record carries an end date instead. The builder is present for one purpose, to answer questions, and every question the colleague asks is written down with its answer, because a question that had to be asked is a finding: the handover pack did not say it. The working day is eight hours. The colleague works from the repository and the handover pack alone, on synthetic data and in the environment that the organisation provides, and the pipeline identity, not the colleague's hands, promotes the change.

The test has ten items. The sixth is the Revert test as the colleague performs it, and it is the item that a builder who has only ever shipped forward is least likely to have practised.

takeover_test:
  record: HND-NR-2031-0001          # the handover pack the colleague works from
  runner: "a named colleague, not the builder or the deputy"
  time_box: "one working day, eight hours"
  builder_role: "answers questions; each question is logged as a finding"
  items:
    - {id: T1,  name: find,       check: "from the pack alone: purpose, owner, deputy, accountable role, data"}
    - {id: T2,  name: run_tests,  check: "set up from a clean copy; the tests and the oracle cases pass"}
    - {id: T3,  name: run_report, check: "produce the output on synthetic data, then on the production path read-only, through the template or pipeline"}
    - {id: T4,  name: change,     check: "make the change task; tests and oracle case pass; say in one paragraph what changed and why"}
    - {id: T5,  name: ship,       check: "ship the change to the test target; nothing reaches users"}
    - {id: T6,  name: revert,     check: "roll the test target back to the previous release using only the rollback note"}
    - {id: T7,  name: switch_off, check: "stop the tool from the runbook alone; the manual fallback works"}
    - {id: T8,  name: restore,    check: "restore from the repository and the secret store; run it"}
    - {id: T9,  name: explain,    check: "explain the tool to the oracle owner without the owner or the assistant"}
    - {id: T10, name: secrets,    check: "the repository holds no secrets; say where they live"}
  pass: "all ten items pass in the day; a failed item is fixed and re-run, not argued"
  result_fields: [runner, date, items, findings, fixed_on, rerun_on]

A pass and a fail

A pass means all ten items succeed within the day, with a list of findings that may be non-empty. The findings are the useful output: they say where the pack is thin. A fail means that an item does not succeed, and the rule is that the item is fixed and re-run, not argued. Nothing is gained by calling the colleague's trouble a misunderstanding. service-point-check was tested on 2031-12-11 by Rasmus Holm, a developer in Anders Falk's integration and data team, and failed on one item, the Revert test: the rollback note named a version tag, and the scheduled-job template of the platform does not accept a tag but needs the release name. Hanna corrected the note on 2031-12-12 and the item passed on re-run. Promotion to Tier C was approved on 2031-12-15 (AIDR-1203). claims-doc-check was tested on 2031-12-09 by Tomasz Wrona and passed with two remarks. Chapter 16 teaches the test in practice, and Chapter 23 tells both days in full.

The stewardship principle for a builder

AI Developer, Chapter 4, states the stewardship principle in one sentence and three tests. AI may draft, generate, refactor and, within a mandate, execute; it may not own. For every change in production a named developer or team passes three tests (86, Nordqvist, 2026). The method applies the same principle to the builder, with one adjustment: the builder is the named owner, and therefore the person who must pass the tests, with a deputy who passes them too.

Name. The owner is identifiable, in the ownership record OWN-*, to colleagues, to the support path and to an auditor, by name, with a deputy. A tool whose maker has changed job passes only if the record names someone who has taken over. In a study of Windows Vista and Windows 7, Bird and colleagues found that measures of ownership, such as the number of low-expertise contributors and the share of changes held by the top owner, were related to pre-release faults and post-release failures, with one correlation, post-release failures in Windows 7, not significant (90, Bird et al., 2011). The study concerns human contributors in two projects of one company, and the book's reading of it is that code without a clear owner has weaker quality; it is not evidence about builders' tools.

Understand. The owner can explain what the tool does and why, without the assistant that generated it. The builder's form is the explain-it-back drill of Step 11: switch the assistant off and ask the owner or the deputy to say what the tool does, which rule each part serves, what it assumes and what would break it. Naur argued in 1985 that programming is the building of a theory, a grasp of how the program relates to the world it serves, which is held by the people who built it and is not carried by the program text alone (91, Naur, 1985). The essay is an argument, not a measurement, and predates AI tools; it states what the drill protects. For the builder the point is practical. The builder holds the theory of the process the tool serves, since the builder knows the opening hours, the claim types and the exceptions, and that knowledge is the one thing that an assistant cannot supply. The drill tests that the builder has also acquired enough of the theory of the tool to explain it.

Revert. The owner has the authority, the access and the time to stop, roll back or fix the tool, outside the pipeline that shipped it. For a builder this means three things. The switch-off is written in the runbook and can be done by a colleague. The previous version can be restored by a rollback note that has been followed once. And the stop does not depend on the assistant: if the assistant, the pipeline or the platform is itself the problem, the owner can still halt the tool. This is the stop path of AI Operations, Chapter 17, in the builder's hands (83, Nordqvist, 2026).

The independent oracle

The stewardship principle has a corollary for evidence. A test has two parts: the input that exercises the software and the oracle, the means of deciding whether the behaviour is correct. Barr and colleagues, in a survey of the literature, describe the test oracle problem as the difficulty of distinguishing correct from incorrect behaviour (89, Barr et al., 2015). Generating code is cheap and deciding that it is right is the expensive part, and the temptation, for a builder who cannot read the code, is to ask the assistant for the tests as well. The test oracle must be independent of the generator. Tests that the assistant wrote for its own output verify less than they appear to, because a misreading of the rule is built into both the code and the test, and both then agree. The builder's version of the corollary has three parts. The cases that decide correctness come from the specification of Step 4, or from a person who holds the process knowledge. The oracle owner is someone other than the builder and the assistant, named in the specification. And an assistant never edits the oracle: the directory that holds the oracle cases is protected in the mandate.

The two builds carry the evidence for why this matters. In claims-doc-check the assistant had copied the rules for collision claims into the rule for glass claims, and its own tests passed, since they restated the rule it had written. The oracle case glass-03, written by Marek Zieliński from a real claim type, failed, and the error was fixed on 2031-11-10, before the first release. A second model that reviews the first model's work is not an oracle in this sense, because errors across models are correlated, and it is useful only as an extra reader; AI Purple, Chapter 15, develops independence as a principle for a loop in which AI is on both sides of a check (82, Nordqvist, 2026).

Claims with evidence

A builder's statement that the tool is tested, secure, backed up or ready is a claim, and a claim carries its scope, its method, its date and its result. "Tested" in a build record reads: 14 automated tests and 12 oracle cases, passing on 2031-11-05, review by Anders Falk. "Backed up" reads: restored from the release tag onto the platform template on 2031-12-05, output matched on synthetic data. A statement without these parts is a hope, and the record marks anything not checked as not tested, which counts as not met. This is the rule of AI Developer, Chapter 4, that a claim about productivity, security, readiness or competence carries scope, method, date, result and expiry, applied to the builder (86, Nordqvist, 2026).

The assistant's mandate

The mandate is the written statement of what the builder's assistant may do, kept in the repository as MND-*-BLD-* and read by the assistant through the project rules file AGENTS.md. It exists because an assistant that is told nothing acts on whatever it can reach, and because a rule that lives only in the builder's head cannot be shown to a reviewer. The two builds have one each: MND-NR-BLD-2031-01, adopted on 2031-10-13 (AIDR-1201), and MND-HM-BLD-2031-01, adopted on 2031-10-27 (AIDR-1252). Chapter 7 teaches how to write one. Its content has four parts: what the assistant may read, what it may change, what it may run and what it may reach, and for each the highest degree of delegation.

Action class	May the assistant do it?	Highest degree
Read the repository and the synthetic data	Yes	Level 3 Bounded: no approval per read
Read secrets, production data or production configuration	No: it has no access	None
Edit files in the repository, on a branch	Yes	Level 3 Bounded: the branch can be discarded
Run the test suite and the linters in the sandbox	Yes	Level 3 Bounded: reversible and local
Commit	Drafts the message and the change	Level 1 Assisted: the builder reads the diff and commits in own name
Push to main, trigger the pipeline, promote a release	No	None: the pipeline identity promotes
Change AGENTS.md, pipeline.yml, tests/oracle/ or the mandate itself	May suggest in conversation; never edits	Level 0 Advisory
Reach the network, other repositories or other systems	Only what the sandbox provides	As stated in the mandate

Every session in which the assistant changed something is recorded in a run record RUN-*, with what was asked, what changed and what the builder accepted. A fragment of the Nordvik mandate shows the form; the values follow docs/BUILDS.md and the mandate is shown in full in Chapter 7.

mandate:
  id: MND-NR-BLD-2031-01
  adopted: 2031-10-13
  decision: AIDR-1201
  builder: Hanna Wikström
  approved_by: Gunilla Roos          # the builder's manager; the assistant never approves its own mandate
  assistant: "the approved assistant of the builder workspace"
  usage_modes: [2, 3]
  may:
    - {class: read,  scope: [repository, data/synthetic], ceiling: "Level 3 Bounded"}
    - {class: edit,  scope: [branch], ceiling: "Level 3 Bounded"}
    - {class: run,   scope: [tests, linters], ceiling: "Level 3 Bounded"}
  may_not: [read_secrets, read_production_data, read_production_configuration,
            push_to_main, trigger_pipeline, edit_agents_md, edit_pipeline_yml,
            edit_tests_oracle, edit_this_mandate]
  records: {run_record: "RUN-NR-2031-*", every_session: true}
  level_4: {used: false}

The ceilings in the fragment are those of the workspace profile. The mandate of Chapter 7 lowers them per class of work, for example generation at Level 2 and review at Level 0.

The delegation ladder and the Level 4 prohibitions

The ladder has five rungs, the autonomy levels of the series, applied here to the builder's assistant. At Level 0 Advisory the assistant suggests and explains. At Level 1 Assisted it drafts, and the builder reads, edits and commits. At Level 2 Supervised it carries out an action after the builder has approved that action. At Level 3 Bounded it carries out pre-approved, reversible actions of a named class within a written policy, and the person who wrote the policy holds the stop. At Level 4 Autonomous it selects and carries out actions without per-action approval, within bounds set in advance. The ladder is older than the series: Parasuraman, Sheridan and Wickens proposed in 2000 that automation is a matter of degree, and that the degree can differ across the stages of a task (35, Parasuraman et al., 2000). The starting profile of this book gives a builder's assistant Level 3 only for the two named, reversible classes inside a sandbox, Level 2 or lower for everything else, and no Level 4. The ceilings are the author's recommendation for an organisation that provides the sandbox, not a standard.

The prohibitions are a floor under the ladder, and for a builder's assistant they read as follows. Level 4 Autonomous is never used for a change to production without a gate that the change itself cannot alter; for code in a security-critical path without review by a named developer; for a change to the assistant's own mandate, permissions, credentials, test oracles or pipeline gates; for an irreversible action on production data; or for a decision about a named person's employment, pay, performance rating or access to work. Each has a builder's meaning. A change to production passes through a pipeline whose gates the assistant, and the builder's own commit, cannot edit. Code in authentication, authorisation, cryptography, payment, clinical or life-safety logic is Tier D and has a named developer's review. The assistant does not edit its own mandate, its permissions, the secrets it might read, the oracle cases that judge its work or the pipeline file that tests its changes, since an assistant that may edit the tests that decide whether its change is accepted has been given the means to pass. An action that cannot be undone on production data is never taken without a person: a reported case in which a coding agent executed destructive commands during a code freeze and production data was lost has this shape, and the catalogue record that lists it names press reports and no primary post-incident report, so the case is cited as reported, as an illustration of the class and not as an established account (22, AI Incident Database, 2025). And a tool that decides about a named person's employment, pay, rating or access to work is Tier D, whatever tool built it.

Usage modes for builders

The series uses six usage modes, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, and the builder's assistant arrives in three of them. In Mode 1, a conversational assistant, the builder asks, receives a draft and pastes or types the result. In Mode 2, an assistant embedded in the editor or the building tool, the builder accepts or rejects each suggested change as it appears. In Mode 3, an agentic work tool, the assistant plans, edits several files and runs commands on its own initiative within the mandate, and the builder reads the outcome. A Mode 1 draft reaches the repository only through the builder's hands; a Mode 3 run can change many files before the builder looks, which is why the mandate and the sandbox exist and why the builder reads the diff.

Mode 5, autonomous production agents acting with an identity of their own on production systems, is not for builders. A builder is not placed to hold the stop path of such an agent, and the Level 4 prohibitions apply with most force there. Nordvik Region has no Mode 5 agent at all, and Hansa Mutual's operations agent acts under the practice of AI Operations and not under a builder's mandate (83, Nordqvist, 2026). If the tool a builder makes itself calls a model, that is Mode 4, a built AI application, and the build is at least Tier C, passes through the platform's model gateway where one exists, and never decides about a person.

The build record

The build record BLD is the one artefact that carries the whole build. It is a file in the repository, docs/build-record.yaml, and it holds the purpose, the user, the success measure, the tier decision, the owner and deputy, and the state of each of the twelve gates with the artefact that meets it, the date and the result. It is the page a manager, a receiving developer or an auditor reads first, and it is the page that tells the builder what is still open. It replaces nothing: the specification, the verification plan and the other records stay where they are, and the build record points to them. What it adds is the one place where progress is stated as evidence.

Each gate has one of five states: not_started, met, failed, expired and not_required (a gate that the tier does not require, recorded with the reason). A gate is met only with an artefact, a date and a result. expired follows from the age rule, and a gate that failed is not deleted: the history shows when it failed and when it was met after the fix, because the history is how the next builder learns. The record below is the Nordvik build as it stood on 2031-12-15, the day that the promotion to Tier C was approved. The values follow docs/BUILDS.md; the dates of the earlier gates are this book's illustrative choice.

bld:
  id: BLD-NR-2031-0001
  name: service-point-check
  repository: service-point-check          # the Region's Git service; version 0.2.0
  opened: 2031-09-08
  builder: Hanna Wikström
  deputy: Elin Berg
  manager: Gunilla Roos
  intent:
    purpose: "Report every week where the opening hours and service notices of the 24 service points differ between portal, phone script and notices spreadsheet"
    user: "the e-services team and the service-point managers"
    problem_now: "The three sources disagree after every change; residents travel to a closed service point and phone the phone service"
    success_measure: {what: "calls categorised wrong opening hours per month", source: "phone-service call log", baseline: {value: 41, period: 2031-08}, target: "at most 20 a month in the first full month on a schedule", note: "before-and-after count of one category; no control group"}
    done: ["one command compares all 24 service points", "the report names every mismatch", "the tool only reads"]
    non_goals: [correct_sources_automatically, printed_leaflet, anything_but_the_24_service_points]
    affected: [service-point managers, phone-service agents, residents]
  tier:
    current: C
    history:
      - {tier: B, decided: 2031-09-11, reclassify_if: [runs_on_schedule, used_by_other_units]}
      - {tier: C, decided: 2031-12-15, decision: AIDR-1203}
  mandate: MND-NR-BLD-2031-01
  gates:
    1_intent:        {status: met, date: 2031-09-10, artefact: "intent (this record)", evidence: "read and confirmed by the phone-service lead and Gunilla Roos"}
    2_tier:          {status: met, date: 2031-09-11, artefact: "tier (this record)", evidence: "countersigned by Gunilla Roos; five questions answered"}
    3_workshop:      {status: met, date: 2031-10-13, artefact: "README, AGENTS.md, MND-NR-BLD-2031-01", evidence: "clone-and-restore test by Elin Berg: pass"}
    4_specification: {status: met, date: 2031-10-15, artefact: SPC-NR-2031-0001, evidence: "approved; oracle owner Saga Edvardsson"}
    5_design:        {status: met, date: 2031-10-20, artefact: "docs/design.md, docs/adr/0001-0003", evidence: "read by Anders Falk"}
    6_build:         {status: met, date: 2031-11-05, artefact: "commits, docs/runs/RUN-NR-2031-*", evidence: "3 slices; tests pass from a fresh clone"}
    7_prove:         {status: met, date: 2031-11-05, artefact: "VER-NR-2031-0001, RVW-NR-2031-0001", evidence: "14 tests and 12 oracle cases pass; review by Anders Falk", expires: 2032-02-03}
    8_secure:        {status: met, date: 2031-11-06, artefact: PRV-NR-2031-0001, evidence: "tier B checklist complete; secret scan clean; one token in the secret store", expires: 2032-02-04}
    9_ship:          {status: met, date: 2031-12-12, artefact: "CHG-NR-2031-0001, CHG-NR-2031-0002, docs/rollback.md", evidence: "v0.1.0 on 2031-11-12; v0.2.0 on 2031-12-08; reopened 2031-12-11, rollback note named a tag; met 2031-12-12"}
    10_run:          {status: met, date: 2031-12-05, artefact: "RBK-NR-2031-0001, RST-NR-2031-0001", evidence: "restored from release on the template; output matched", expires: 2032-03-04}
    11_own:          {status: met, date: 2031-12-02, artefact: OWN-NR-2031-0001, evidence: "explain-it-back drill by Elin Berg without the assistant: pass; sunset 2033-08-31"}
    12_hand_over:    {status: met, date: 2031-12-12, artefact: "HND-NR-2031-0001", evidence: "takeover test 2031-12-11 by Rasmus Holm: 9 of 10 items; T6 revert failed, fixed and re-run 2031-12-12: pass"}
  next_evidence_expiry: 2032-02-03

Every gate in the record has an artefact that can be opened and a date. Three gates carry an expiry, and the first to run out is the review at Step 7 on 2032-02-03, so the owner knows what to refresh and by when. Gate 9 carries its own history: it was met on 2031-11-12 with a rollback note that nobody had followed end to end, and it was reopened when the takeover test followed the note and found the flaw. And gate 12 states the result as it was, nine items first time and ten after the fix. The Hansa record has the same form with other values. It opens on 2031-09-15 and holds the tier decision C of 2031-09-18, the data protection officer's screening of 2031-10-20 that narrowed the scope to property-damage claims (AIDR-1251), the mandate of 2031-10-27, the specification approved on 2031-10-30, the first release v0.1.0 of 2031-11-17 to the pilot team and the takeover test of 2031-12-09.

Practical guide: Create a build record for your own build and set its tier provisionally

Purpose. To start the build record for a tool you have built or are about to build, so that every later step has somewhere to report, and to set the tier provisionally so that you know how heavy the method will be.

Roles. The builder, who writes the record; the deputy, who reads it; the builder's manager, who reads and countersigns the tier; and, if the tool might touch personal data of others, the data protection officer, who is told at this point and screens at Step 2.

Inputs. The tool as it is, even if it is only a conversation with an assistant; a repository, or a folder that you are about to turn into one (Chapter 7 shows how); the five questions of Chapter 6 in outline: who uses it, what data it holds, what could go wrong, which law applies, whether it runs unattended.

Steps.

1. Create docs/build-record.yaml in the repository and copy the structure above. Give it an identifier of the form BLD-<organisation>-<year>-<number> as the register of your organisation prescribes.
2. Write the purpose in one sentence, name the user, and name the measure by which you will know whether the tool helps. Leave the target open if you do not yet have a baseline, and write that you do not.
3. Name your deputy: a colleague who will read the record and will pass the explain-it-back drill at Step 11. If you cannot name one, write that, because the lack of a deputy is itself a finding that the manager must see.
4. Answer the five questions in a few lines each and propose a tier. Apply the stop signs of Tier D first: does the tool rank or decide about a named person, feed a high-risk AI system, touch a security-critical path or act irreversibly on production data? If any answer is yes, stop here and tell your manager.
5. Write the signals that would change the tier: a second unit begins to use the tool, personal data of others enters it, it begins to run unattended.
6. List the twelve gates with the state not_started, and mark any that the proposed tier does not require as not_required with the reason from the proportion table.
7. Ask the deputy and your manager to read the record. Their reading is the evidence for the first two gates of the method.

Exit gate. The record exists in the repository; the tier is proposed with the Tier D signs checked and the reclassification signals written; the deputy and the manager have read it and a dated note in the record says so.

Artefact. docs/build-record.yaml, with sections 1 and 2 filled and the twelve gates listed.

Across the usage modes and the degrees of delegation

Across the usage modes

The table gives the highest degree of delegation that the starting profile of this book allows to the builder's assistant in each usage mode, and what the builder must be able to answer. The ceiling is not a licence. It is the most that a mandate may grant, and the mandate usually grants less.

Usage mode	What the builder does with it	Highest degree for the builder's assistant	Condition	The builder's question
0 Ambient AI	Accepts suggestions inside an editor or document tool that the supplier switched on	Level 1 Assisted	Recorded in the build record when it touches the tool's code	What completed what I typed, and did I read it?
1 Conversational assistants	Asks, receives a draft, copies it into the repository	Level 1 Assisted	Tier A and B; nothing from production, no secrets, no personal data of others in the conversation	What did I paste, and what left the boundary?
2 Embedded workplace assistants	Accepts or rejects changes in the editor or building tool	Level 2 Supervised	The builder approves each change and runs it against the examples	Can I explain the change I accepted without the assistant?
3 Agentic work tools	Lets an assistant plan, edit and run tests inside the sandbox	Level 3 Bounded for editing on a branch and running tests; Level 2 for the rest	Only in a sandbox that the organisation provides, under a written mandate; AI Developer, Chapter 19, kept this mode for developers, and the organisation's decision to extend it to builders is recorded as an AI Decision Record (AIDR-1200, AIDR-1250)	Whose identity acted, and what did I read before accepting?
4 Built AI applications	The tool the builder makes itself calls a model	Level 1 Assisted for outputs to the builder	Tier C at least; the platform's gateway; never for decisions about a named person	Who checks every output against the specification?
5 Autonomous production agents	Not applicable	Not for builders	Developer-owned mandate only; Nordvik Region has none	Where is the stop, and who holds it?

The Level 4 prohibitions apply without change. No build changes production without a gate that the change cannot alter, touches a security-critical path without review by a named developer, changes the assistant's own mandate, permissions, credentials, test oracles or pipeline gates, acts irreversibly on production data, or decides about a named person's employment, pay, performance rating or access to work.

Nordvik Region and Hansa Mutual

At Nordvik Region Hanna Wikström had built prototypes with a conversational assistant (Mode 1) since 2030. For this build she moved to the builder workspace that the platform team opened on 2031-10-06 (AIDR-1200), where the approved assistant works at Mode 2 in the editor and at Mode 3 for delegated tasks inside a sandbox. Her tier decision of 2031-09-11 was B, with the tier history shown above, and her mandate, adopted on 2031-10-13 (AIDR-1201), lets the assistant run tests but not read the production configuration. The Region has no autonomous production agents, and the platform's scheduled-job template, not Hanna, promotes releases.

At Hansa Mutual Katarzyna Nowak's tier decision of 2031-09-18 was C because claimants' personal data enters the tool. The data protection officer, Dr. Sabine Vogel, screened it and narrowed the scope to property-damage claims on 2031-10-20 (AIDR-1251); injury claims are out of scope because free-text fields may hold health data under Article 9 of the GDPR, and including them would raise the tier (4, European Union, 2016). The builder lane opened on 2031-10-13 (AIDR-1250), and the mandate was adopted on 2031-10-27 (AIDR-1252). The production export is read only by the pipeline identity, and neither Katarzyna nor her assistant reads it. By the end of December 2031 both builders hold the three ownership tests: a named owner and deputy, an explain-it-back drill passed without the assistant, and a rollback that has been followed.

Observable, expected, speculation

Observable. Non-developers build software with AI assistants and app builders, and platform documentation describes the controls that this chapter's tiers resemble: data policies per environment, personal and shared environments, and pipelines that promote work between them. Microsoft's guidance for one platform family is an example of the pattern, and the book makes no claim of effectiveness for it (107, Microsoft, 2025); (108, Microsoft, 2026). The tiers and the stewardship principle are those of AI Developer; the twelve steps, the gates, the takeover test and the build record are this book's own and have not been evaluated in a controlled study.

Expected. That organisations adopt tiers, registers, sandboxes and receiving developers for builders is expected where an organisation has the capacity and the wish, and Chapter 17 treats what that takes. That assistants read repository rules files and mandate-like instructions is observable for some tools; that they honour them reliably is not guaranteed, which is why the mandate is enforced by the sandbox and the pipeline and not only by the assistant's reading of it.

Speculation. That a law will require a register of builders, or a takeover test, is speculation: no instrument analysed in this book does so. The book's own projections are confined to Chapters 20 and 25.

Summary

This chapter defined the method. It has twelve steps, Step 1 Intent, Step 2 Tier, Step 3 Workshop, Step 4 Specification, Step 5 Design, Step 6 Build, Step 7 Prove, Step 8 Secure, Step 9 Ship, Step 10 Run, Step 11 Own and Step 12 Hand over, and each ends in a gate met by showing an artefact: an intent that the user has confirmed, a tier decision, a repository that a colleague can clone, a specification with an oracle owner, a design a reviewer can read, a build whose slices are committed and recorded, tests and an independent oracle, a security checklist with a provenance record, a release by the pipeline with a practised rollback, a runbook with a restore test, an ownership record with a drill passed without the assistant, and a handover pack with a passed takeover test. The proportion table sets how much of each applies to each of the four tiers, A personal, B team, C business and D project, and Tier D is not a citizen build: it leaves the method at Step 2.

The takeover test is the measure of professional. A named colleague who did not build the software, given a working day, can run it, change it and ship the change, switch it off and restore it, and the ten items of the test make that checkable. It is the stewardship principle of AI Developer applied to the tool: AI may draft, generate, explain and, within a mandate, execute, and it may not own. The builder is the named owner who passes Name, Understand and Revert, and the test oracle is independent of the assistant that wrote the code. The mandate, kept in the repository, says what the assistant may read, change, run and reach, and the Level 4 prohibitions hold: never for a change to production without a gate the change cannot alter, for security-critical code without a named developer's review, for the assistant's own mandate, credentials, oracles or pipeline gates, for an irreversible action on production data, or for a decision about a named person's employment, pay, rating or access to work.

The build record is the file that carries the whole build, with the state of every gate, its artefact, its date and its result, and with an expiry on any evidence about running software. It was opened on 2031-09-08 for Nordvik Region's service-point-check and on 2031-09-15 for Hansa Mutual's claims-doc-check, and by the middle of December each held twelve gates with artefacts. The practical guide of this chapter, creating a build record and setting the tier provisionally, is the first thing a reader does. All five developer functions stand behind the steps: D1 Frame in Steps 1, 2, 4 and 12, D2 Design in Steps 2 and 5, D3 Build in Steps 3 and 6, D4 Prove in Steps 7 and 8, and D5 Steward in Steps 3 and 9 to 12. Chapter 5 begins the steps with Step 1 Intent.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
2. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (4, European Union, 2016)
3. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (22, AI Incident Database, 2025)
4. Parasuraman, R., Sheridan, T. B. & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A 30(3), 286-297. (35, Parasuraman et al., 2000)
5. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. The Transformed Architecture, Book 10. (83, Nordqvist, 2026)
6. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Transformed Architecture, Book 9. (82, Nordqvist, 2026)
7. 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)
8. 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)
9. Bird, C., Nagappan, N., Murphy, B., Gall, H. & Devanbu, P. (2011). Don't Touch My Code! Examining the Effects of Ownership on Software Quality. ESEC/FSE '11, 4-14. (90, Bird et al., 2011)
10. Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), 253-261. (91, Naur, 1985)
11. Barr, E. T., Harman, M., McMinn, P., Shahbaz, M. & Yoo, S. (2015). The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering 41(5), 507-525. (89, Barr et al., 2015)
12. Microsoft (2025). Implement a data policy strategy. Microsoft Learn, Power Platform guidance. (107, Microsoft, 2025)
13. Microsoft (2026). Develop a tenant environment strategy to adopt Power Platform at scale. Microsoft Learn, Power Platform guidance. (108, Microsoft, 2026)