Glossary

This glossary defines the vocabulary of Vibe to Dev: the twelve steps, the four tiers, the gate and the artefact, the takeover test, the stewardship tests and the independent oracle, the builder's mandate and the usage modes and degrees of delegation, the records that the steps produce, and the plain-language terms of software work that the chapters define on first use for a reader who is not a developer. Each entry gives the book's own meaning in one to three sentences and names the chapter that owns the term, where it is defined or first used in that sense. A term that the chapters use without defining is left out. Terms that earlier volumes of the series defined are repeated briefly, with the volume named, so that the reader is not left with a gap.

How to use this glossary

Entries are in alphabetical order. Identifiers in code formatting (BLD-*, HND-*) are sorted by their letters. An identifier such as OWN-* names a pattern: the wildcard stands for the number that the organisation assigns to each record, and the book's examples use NR for Nordvik Region and HM for Hansa Mutual (for example OWN-NR-2031-0001). AI Decision Records run from AIDR-1200 to AIDR-1299 in this book: Nordvik Region AIDR-1200 to AIDR-1249 and Hansa Mutual AIDR-1250 to AIDR-1299; the range AIDR-1100 to AIDR-1199 belongs to AI Developer. The five developer functions D1 to D5 are those of AI Developer, not the operations functions O1 to O5 of AI Operations or the leadership functions L1 to L5 of AI Leader. The legal entries attribute each statement to the instrument and article as the chapters cite it, and describe organisational implications; they are not legal advice. The labels observable, expected and speculation are defined below and mark every statement about the future.

A

Acceptance example. A rule of the specification written as an example in the form given, when, then, with exact values, so that it can be turned into a test (Chapter 8).

Accountable. The role, normally the unit head, who stands behind the owner and the deputy of a tool and appoints a new owner when the post changes hands (Chapter 15).

Across the usage modes. The subsection, normally a compact table, in which a narrative chapter says how its subject differs across the six usage modes. A variant is Across the degrees of delegation (Chapter 4).

Agent. A system in which a model directs its own sequence of tool calls towards a goal. In this book an agent drafts, proposes or executes within a mandate; it does not intend, understand or decide (Chapters 2 and 4).

AGENTS.md. The project rules file in the repository: the instructions the assistant reads at the start of every session. It restates the mandate in plain sentences, never overrides it and is not edited by the assistant (Chapter 7).

AI Act. Regulation (EU) 2024/1689, as amended. The book uses its terms exactly (provider, deployer, high-risk AI system, general-purpose AI model, systemic risk) and, for builders, reads Article 4 (AI literacy), Article 50 and the high-risk screening as Chapter 19 cites them (Chapters 6 and 19).

AI Decision Record (AIDR). The record of a decision about an AI capability or about the delegation of a class of work. In this book they are numbered AIDR-1200 to AIDR-1299, for example AIDR-1200 (builder workspace, Nordvik Region), AIDR-1203 (promotion of service-point-check to Tier C), AIDR-1250 (builder lane, Hansa Mutual) and AIDR-1251 (data protection screening) (Chapter 4).

AI-off block. A fixed period in a builder's learning plan in which the builder works without the assistant, to practise and to check their own calibration; two hours a fortnight in the examples (Chapter 21).

Algorithm register. A public register of algorithmic systems, discussed for the public authority in AI Governance, Chapter 17. A builder's tool that only reports does not enter it, because it concerns systems that support decisions about persons (Chapter 18).

Ambient AI. See Mode 0 Ambient AI.

Anti-pattern. A practice that looks reasonable at the time and reliably leads to a failure. The book catalogues eleven: the open data store, the secret in the folder, the trusted name, the release by hand, the rollback nobody tried, the assistant's own tests, the tool that grew, the one person who knows, the claim without a measure, the one place for everything and the assistant with the keys. Each is placed on the step whose gate prevents it (Chapter 22).

Approved assistant. The AI assistant that the organisation has selected for builders, used at Mode 2 and Mode 3 inside a sandbox and under a written mandate. No product is named in the book (Chapter 17).

Architecture Decision Record (ADR). A short, numbered record of a design decision kept beside the code: context, decision, consequences, and in this book what the assistant proposed and what the builder rejected. Introduced in Architecture as Code (Chapter 4); used at Step 5 Design (Chapter 9).

Architecture as Code. The companion discipline of the series, in which architecture, policy and tests are kept as versioned, executable artefacts, and the title of Book 1.

Artefact. A file or record, kept in the repository where possible, that shows that a gate is passed. A step is finished by showing its artefact, never by assertion (Chapters 1 and 4).

Assistant. The AI system that suggests, generates, drafts, explains or, within a mandate, executes. It does not own, and it is not the only judge of its own work (Chapter 4).

Attempt first. The learning rule that a builder makes an honest attempt at a task, and records it, before asking the assistant (Chapter 21).

Automated test. A small program that runs another program on a fixed input and compares the result with the expected result. A set of them is a test suite (Chapter 11).

B

Backup. A copy of the state of a tool kept so that it can be restored. A backup that has not been restored is a hope (Chapter 14).

Baseline. The value of the success measure before the software exists, without which no change can be shown (Chapter 5).

BLD-* (build record). The one file that carries a build from its first sentence to its handover: the intent, the tier decision and the twelve gates, each with its artefact, date and evidence. BLD-NR-2031-0001 and BLD-HM-2031-0001 are the examples (Chapters 4 and 5).

BLP-* (builder learning plan). The plan that decides the next thing a builder learns and the tier of build the builder may own, with a coach, a second assessor, an AI-off block and the statement that it is not used for pay, rating or discipline. BLP-NR-2031-01 and BLP-HM-2031-01 are the examples (Chapter 21).

Boring technology. Technology whose failure modes are already known, chosen at Step 5 Design so that the builder's attention stays on the problem and a developer can maintain the result (Chapter 9).

Branch. A separate line of work in the repository, so that a change can be made, read and discarded without touching main. The assistant works only on a branch named assistant/<topic> (Chapter 7).

Build. The software that a builder makes, from its intent to its handover, followed through the twelve steps. Also the name of Step 6 (Chapter 4).

Build record. See BLD-*.

Builder. A person who is not a developer and who builds software, with or without a low-code platform or an AI assistant, to do their own work or their team's work better. The word is lower case in prose and is not a rank (Chapter 1).

Builder lane. The organisation's provision for builders at Hansa Mutual (AIDR-1250): the approved assistant, synthetic claim exports, the group pipeline and a named receiving developer, inside the claims analytics workspace. At Nordvik Region the same provision is the builder workspace (Chapter 17).

Builder workspace. The place where builders work: an environment, set up by the platform team, in which the approved assistant, the repository service, the synthetic data and the secret store are available together and production is not (Chapter 17).

C

Change record (CHG-*). The record of a release: what was released, through which gate, by whom, who reviewed it, how it is undone and who may undo it. From AI Operations; used at Step 9 Ship (Chapter 13).

Change task. The small, specified change that the oracle owner chooses, and keeps from the builder, for item T4 of the takeover test (Chapter 16).

Changelog. A plain file in the repository that says, for each version, what changed and why (Chapter 13).

Citizen developer. A common name for a builder. The book uses builder, and notes that a programme that calls builders citizen developers can be read as a way to obtain software without a development budget, a reading for which it found no study (Chapter 20).

Claims with evidence. The rule that no chapter says that software is secure, tested, backed up or ready without saying what was checked, by whom, when and with what result; evidence expires (Chapters 1 and 4).

Clone-and-restore test. The gate of Step 3 Workshop: the deputy clones the repository on another machine and, from the README alone, runs the tests and the tool on synthetic data (Chapter 7).

Commit. A recorded, named change in the repository's history. The builder reads the diff and commits in their own name (Chapters 4 and 7).

CMP-* (competence record). The record of what a person has shown, with assisted and unaided entries kept apart, an assessor outside the line, a validity period and limits on who may read it. CMP-NR-2031-01 is the example (Chapter 21).

Cognitive offloading. The use of an external tool to reduce the mental effort a task needs. It becomes a problem when the effort offloaded was the effort that built the ability the person later needs (Chapter 21).

Controller. The organisation that decides why and how personal data is processed. A builder is never the controller; the organisation is (Chapter 6).

Cost limit. A monthly limit on what a build or the builder's assistant may spend, with an alert, set at Step 10 Run (Chapter 14).

Crossing signal. A sign that a Tier B build has become Tier C: used by a second unit, running unattended, holding personal data of people outside the team, or calling a model at run time. A crossing signal makes the build Tier C; a Tier D sign ends the citizen build (Chapter 6).

D

D1 Frame, D2 Design, D3 Build, D4 Prove, D5 Steward. The five developer functions of AI Developer, Chapter 4, which are the professional practice behind the steps. Step 1 is D1; Step 2 is D1 and D2; Steps 3 and 6 are D3 (Step 3 also D5); Step 4 is D1; Step 5 is D2; Steps 7 and 8 are D4; Steps 9 to 11 are D5; Step 12 is D5 and D1 (Chapter 4).

Data protection impact assessment (DPIA). A written assessment of the risks of a kind of personal data processing, required before it begins when the processing is likely to result in a high risk. GDPR Article 35(1) (Chapter 6).

Data protection officer. The person an organisation designates to advise on data protection and to monitor compliance. Where a build touches personal data of others, the officer screens it at Step 2 Tier (Chapter 6).

Debate. The staged discussion of Chapter 20 in four steps: the case for concern, the case for calm, where the positions meet and what can be done, before a verdict (Chapter 20).

Dependency. A package of code written by others that the tool uses, installed by name from a registry. Listed in requirements.txt in a Python project (Chapter 12).

Dependency policy. The file that lists the packages allowed in requirements.txt, each with its purpose and who checked it, and that the pipeline checks (Chapter 12).

Deployer. The AI Act's term for a body that uses an AI system under its authority (Article 3(4)). The contrasting term is provider, a body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name (Article 3(3) and 3(11)) (Chapter 19).

Deputy. The second named person who can do what the owner does when the owner is absent or has left. The deputy runs the clone-and-restore test and passes the explain-it-back drill (Chapter 15).

Developer. A person whose profession is to design, build, prove and look after software (Chapter 1).

Diff. The set of changes that the assistant made in a slice, which the builder reads before committing: which files changed, how large the change is, what was removed and what it reaches (Chapter 10).

DORA. Regulation (EU) 2022/2554, the Digital Operational Resilience Act. Not to be confused with the DevOps Research and Assessment (DORA) programme, written out in full and thereafter called "the four key metrics" (Chapter 19).

DSG-* (one-page design). The record that a developer or architect can read in ten minutes: stack, data, access, accessibility, cost and exit. DSG-NR-2031-0001 is the example (Chapter 9).

E

Environment. A place where software runs: a development or test environment, where mistakes cost nothing, and production, where real users and real data are (Chapters 7 and 13).

Environment variable. A setting that the platform gives a program when it starts, used for paths and secrets so that none is written in a file (Chapter 7).

Evidence age. The rule that every claim carries a date and an expiry. At Tier C, evidence about a running tool is valid for 90 days or until the next change of code, dependency, rules or assistant, whichever comes first (Chapters 4 and 16).

Exit gate. See Gate.

Expected. One of the three labels of AI Governance, Chapter 22: a statement about the future that rests on evidence and a stated mechanism, but has not happened. See Observable and Speculation (Chapter 1).

Explain-it-back drill. The test of Step 11 Own: the deputy explains the tool, without the assistant, to the owner or a reviewer, and the gaps found are written into the README or the runbook (Chapter 15).

F

Failure case. A situation in the specification in which the tool must behave in a stated way when something is wrong, such as a malformed input; every rule has at least one (Chapter 8).

Failure patterns (six). The six ways in which vibe-coded software commonly fails: a secret in the prompt or the code, a public data store, no history, no backup, tests that prove nothing and a tool nobody can maintain (Chapter 2).

Financial entity. An entity within the scope of DORA, such as an insurer. Hansa Mutual is one (Chapters 6 and 19).

G

Gap. In the takeover test, a question that the receiver has to ask the owner. Every gap is written down and becomes a change to the handover pack (Chapter 16).

Gap map. The table in Chapter 3 that sets the twelve disciplines of a developer against what vibe coding usually has instead, and the score (present, partly, absent) with which a builder rates a build (Chapter 3).

Gate. The point at which a step is finished, passed by showing an artefact. Also called the exit gate of the step. A gate is met by an artefact that a second person can read, not by feeling ready (Chapters 1 and 4).

Golden path. The opinionated and supported way to build something; engineers may leave it, with less support. In the book it is the template with the steps built in (Chapter 17).

H

Handover pack (HND-*). The record in docs/handover.yaml that is a map to the documents that exist plus the facts only it states: what the tool never does, who the people are, how to run, change, ship, revert, switch off and restore it, and the known risks. HND-NR-2031-0001 and HND-HM-2031-0001 are the examples (Chapters 15 and 16).

High-risk AI system. The AI Act's term for an AI system that the Act places in a class with heavier duties. A build that is or feeds one is Tier D (Chapters 6 and 19).

I

Incident. An event that interrupts or degrades the tool or exposes data it should not (Chapter 14).

Incident record (INC-*). The record of an incident, from AI Operations. In the first hour: stop the bleeding, restore service and preserve the evidence (Chapter 14).

Independent oracle. The cases that judge a tool, written and owned by someone who is neither the builder nor the assistant, kept where the assistant cannot edit them. The corollary of the stewardship principle: the test oracle must be independent of the generator (Chapters 4 and 11).

Intent. The one-page statement of what is being built, for whom, what is wrong today, how success will be known, what finished looks like, what the build will not do and who else is affected. Also the name of Step 1 (Chapter 5).

L

Lane. See Builder lane.

Least privilege. The rule that each person, program and key can do what its job needs and nothing more (Chapter 12).

Level 0 Advisory. The lowest degree of delegation: the assistant explains and lists, and a person reads (Chapter 4).

Level 1 Assisted. The assistant drafts; the builder reads and decides, for example the commit message and the change in a commit (Chapter 4).

Level 2 Supervised. The assistant acts and the builder approves each change and runs it against the examples (Chapter 4).

Level 3 Bounded. The assistant acts within a stated boundary without approval per action, for example reading the repository, editing on a branch and running tests in the sandbox (Chapter 4).

Level 4 Autonomous. The highest degree of delegation. For a builder's assistant it is never used: not for a change to production without a gate that the change itself cannot alter, not for code in a security-critical path without review by a named developer, not for a change to the assistant's own mandate, permissions, credentials, test oracles or pipeline gates, not for an irreversible action on production data and not for a decision about a named person's employment, pay, performance rating or access to work (Chapter 4).

Linter. A static check that reports suspicious constructions and style problems (Chapter 11).

Log. The running record that a program writes about what it does. In Tier C builds that touch personal data it holds identifiers and counts and nothing else (Chapters 12 and 14).

M

Mandate (MND-*). The written statement of what the assistant may read, edit, run and reach, who owns it, who can stop it and what is recorded, kept in the repository. MND-NR-BLD-2031-01 and MND-HM-BLD-2031-01 are the examples. The assistant never approves or edits its own mandate (Chapters 4 and 7).

Minimising data. The rule that the software holds the data it needs for its purpose and no more, for no longer than necessary (Chapter 12).

Mode 0 Ambient AI. The usage mode in which suggestions appear inside an editor or document tool that the supplier switched on (Chapter 4).

Mode 1 Conversational assistants. The usage mode in which the builder asks, receives a draft and copies it into the repository (Chapter 4).

Mode 2 Embedded workplace assistants. The usage mode in which the builder accepts or rejects changes inside the editor or building tool (Chapter 4).

Mode 3 Agentic work tools. The usage mode in which an assistant plans, edits and runs tests inside a sandbox under a written mandate (Chapter 4).

Mode 4 Built AI applications. The usage mode in which the tool the builder makes itself calls a model; Tier C at least, through the platform's gateway, never for decisions about a named person (Chapter 4).

Mode 5 Autonomous production agents. The usage mode in which an agent acts in production on its own. Not for builders (Chapter 4).

N

Name. The first test of the stewardship principle: a named person owns the software. Tested by the ownership record and by the receiver finding the owner, the deputy and the accountable role in the pack (Chapters 4 and 15).

Never-do list. The list in the specification of what the tool must never do, such as write to a source system, send a message or read a free-text field (Chapter 8).

Non-goal. Something a reader might reasonably expect the software to do and that it deliberately will not (Chapter 5).

O

Observable. One of the three labels of AI Governance, Chapter 22: a statement about the future that rests on something already seen. See Expected and Speculation (Chapter 1).

Oracle. The source of the expected result of a test. See Independent oracle (Chapter 11).

Oracle owner. The person who writes and owns the oracle cases; neither the builder nor the assistant. Saga Edvardsson at Nordvik Region; Marek Zieliński, with a quality sample from the head of claims operations' office, at Hansa Mutual (Chapters 8 and 11).

Out of scope. What the tool does not cover, written down so that a reader does not assume it does; at Hansa Mutual, injury claims (motor_injury), whose free text may hold health data (Chapters 6 and 8).

OWN-* (code-ownership record). The record of the owner, the deputy, the accountable role, the documents, the update routine, the review cycle, what happens when the owner leaves and the sunset date. OWN-NR-2031-0001 and OWN-HM-2031-0001 are the examples (Chapter 15).

Owner. The person who answers for the tool: who is called when it fails and who decides about changes. A named person, not a department (Chapter 15).

P

Package hallucination. The case in which an assistant names a package that does not exist, which an attacker can then register; a reason for the dependency policy (Chapter 12).

Personal data. Any information relating to an identified or identifiable natural person (GDPR Article 4(1)). Claim identifiers that are linkable to claimants are personal data, which is why claims-doc-check is Tier C (Chapter 6).

Pipeline. A fixed, automated sequence of steps that takes a change from the repository to the environment where it runs; in the book test, scan and deploy. It is the only way to production (Chapter 13).

Pipeline identity. The automated account that performs a promotion. Never a person and never the assistant (Chapters 13 and 16).

Practical guide. The form of a step chapter's central section: Purpose, Roles, Inputs, Steps and Resulting artefact, ending in the exit gate (Chapter 4).

Pre-release. A tag such as v0.1.0-rc.1 that marks a version that is built and rehearsed but not yet offered to users (Chapter 13).

Promotion. In Step 9, moving a version from one environment to the next. Between tiers, the decision, on criteria kept as data, that a build has outgrown its tier. The builder never promotes their own tool (Chapters 13 and 16).

Prompt. The instruction that a builder gives an assistant. Ordinary prompts for each step are in Appendix B. Prompts are working material, kept for a stated time and then removed at Nordvik Region (Chapters 5 and 18).

Prompt injection. The case in which text that arrives as data and reads like an instruction is followed by a model. It applies when the builder's tool itself calls a model; described by class and never by strings (Chapter 12).

PRV-* (provenance record). The record of what produced the build (assistant, mandate, runs), what it depends on, whether a secret or personal data is in the repository or the logs, what was not checked and until when it holds. PRV-NR-2031-0001 and PRV-HM-2031-0001 are the examples (Chapter 12).

Provider. The AI Act's term for a body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name, which includes supply for own use. A tool that calls a model at run time makes its organisation both provider and deployer; a tool of ordinary code is not an AI system (Chapter 19).

Public authority. A body governed by public law, whose accountability for a tool built in-house, duties on records and public access, and accessibility duties the book treats at Nordvik Region (Chapter 18).

R

RBK-* (runbook manifest). The record that lets a colleague watch, stop, restore and call for help for a tool, with the first hour of a failure and the manual fallback. RBK-NR-2031-0001 and RBK-HM-2031-0001 are the examples. From AI Operations; used at Step 10 Run (Chapter 14).

README. The file that explains what the tool is for, what it never does, how to run it, how it works, how to change it and ship the change, how to switch it off, revert and restore it, whom to call and when it ends. It must pass the run on a clean copy (Chapter 15).

Receiving developer. The developer who receives a builder's tool, reviews it, runs the takeover test and coaches the builder: Rasmus Holm at Nordvik Region, Tomasz Wrona at Hansa Mutual (Chapters 7 and 17).

Reclassification. The change of a build's tier when a signal named in the tier decision occurs (Chapter 6).

Register. The organisation's list of what builders have made: one entry per tool, with owner, deputy, tier, data classes, receiving developer, evidence dates and sunset, kept in version control. BREG-NR is Nordvik Region's (Chapter 17).

Regression. The breakage of behaviour that worked before (Chapter 11).

Release. One specific, named, finished version of the software, produced once by the pipeline and never altered afterwards (Chapter 13).

Release name. The name that a platform template accepts for a release, for example service-point-check-0.2.0-b3. The first Nordvik Region rollback note named the tag instead, and failed the Revert item of the takeover test (Chapters 13 and 16).

Repository. The folder, with its full history, in which the tool's files are kept under version control (Chapters 1 and 7).

Restore. The act of putting a backed-up tool back. A restore test rebuilds the tool from the repository and the configuration alone, with the assistant off, and records the minutes, the result and what was not tested (Chapter 14).

Restore-test record (RST-*). The record of a restore test. RST-NR-2031-0001 and RST-HM-2031-0001 are the examples. From AI Operations (Chapter 14).

Revert. The third test of the stewardship principle: the change can be undone and the tool switched off by a person other than the builder, from outside the thing being stopped. Tested at Step 9 and in the takeover test (Chapters 4 and 13).

Review. A person who did not write the change reads it and says whether they understand it. The review record RVW-* notes what was read, in what order, what was not checked and the outcome; an AI review comment is read after the person's reading and never counts as the approval (Chapter 11).

Rollback. Putting the previous release back in place. Not always possible: a change to data or to a contract with another system cannot be undone by redeploying code. The rollback note is rehearsed (Chapter 13).

Rung. One of the four stages of the learning path of Chapter 21: habits, reading, writing and debugging unaided, and owning (Chapter 21).

Run. To start the tool. Also the name of Step 10, and an item of the takeover test (Chapters 14 and 16).

Run record (RUN-*). The record of one session of the assistant: the mandate, the task, the files changed, the tests, what the builder read, what the assistant was refused. Written by the sandbox host, not by the assistant. RUN-NR-2031-0004 is the example (Chapter 10).

S

Sandbox. An environment without production reach, provided by the organisation, in which the assistant works at Mode 3 (Chapters 4 and 17).

Second assessor. The person outside the builder's line and not the coach who assesses unaided work; named in the learning plan (Chapter 21).

Secret. Any value that proves identity or grants access: a password, a token, a key, a certificate. Never in the repository, the conversation with the assistant or a log (Chapter 12).

Secret scan. A static check that reports secrets left in files, run before commit and in the pipeline (Chapter 12).

Secret store. The platform service that injects secrets into a job as environment variables at run time (Chapter 7).

Secure by default. The rule that the safe setting is the one that applies unless somebody changes it on purpose (Chapter 12).

Slice. A small, single change built in one turn: plan, tests, code, read the diff, commit, record (Chapter 10).

Specification record (SPC-*). The record of what correct means: need, rules, acceptance examples, failure cases, never-do list, oracle owner and approval. SPC-NR-2031-0001 and SPC-HM-2031-0001 are the examples (Chapter 8).

Speculation. One of the three labels of AI Governance, Chapter 22: a statement about the future for which there is no evidence yet, or only argument. See Observable and Expected (Chapter 1).

Static check. A program that reads source code without running it and reports problems it can recognise from the text: a linter, a type checker, a secret scanner (Chapter 11).

Step. One of the twelve parts of the method, each ending in a gate: 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, Step 12 Hand over (Chapter 4).

Stewardship principle. The principle of AI Developer, Chapter 4, that AI may draft, generate, refactor and, within a mandate, execute, but may not own: a named person passes the three tests Name, Understand and Revert. The book applies it to the builder (Chapter 4).

Stop path. The control the organisation holds alone: a way to switch a tool off that does not depend on the builder, the assistant or the tool itself, for example disabling the scheduled job or revoking the pipeline identity (Chapter 17).

Stop sign. A sign that ends a citizen build and makes it Tier D: it ranks or decides about a named person; it is or feeds a high-risk AI system; it touches a security-critical path; it acts irreversibly on production data (Chapter 6).

Success measure. A number or observable event that tells whether the software has helped, with its source, baseline and target (Chapter 5).

Summary. The closing section of each chapter, which names the steps and developer functions the chapter concerns (Chapter 1).

Sunset date. A date in the ownership record on which the tool ends unless the owner shows that it is still used and passes review; outcomes are renew, retire or hand over (Chapter 15).

Support path. A named contact and a rhythm for builders, such as a weekly office hour, and for each tool the route from the failure alert to the people who can act (Chapter 17).

Switch-off. Stopping the software from running without replacing it. For a first release the switch-off with the manual process is the way back (Chapter 13).

Synthetic data. Data that has the shape of the real data and none of the people, used in development; at Hansa Mutual, claim ids from SYN-0001 (Chapter 7).

T

Tag. A permanent label that the version control system attaches to one exact state of the repository, so that "version 0.2.0" always means the same files (Chapter 13).

Takeover test. The book's own measure of "professional": a named colleague who did not build the tool, given one working day, the repository and the handover pack, can find it, run it, explain it, change it, ship the change, switch it off, restore it and revert a change. The result is pass, pass with remarks or fail, and is recorded as TKT-* (Chapters 1, 4 and 16).

TKT-* (takeover-test record). The record of a takeover test with each item's result and time, every gap and the overall result. TKT-NR-2031-0001 and TKT-HM-2031-0001 are the examples (Chapter 16).

Test oracle. See Independent oracle.

Tier. The class of a build that sets how much of each step applies. Also the name of Step 2. The four tiers are those of AI Developer, Chapter 19 (Chapters 4 and 6).

Tier A personal. Used only by the maker; no personal data of others; no write access to shared systems (Chapter 4).

Tier B team. Used by colleagues in one unit; internal data only; no personal data of people outside the team (Chapter 4).

Tier C business. Personal data of citizens, customers or staff, money, a record of the organisation, more than one unit, or unattended running; needs a named owner and deputy, promotion gates and developer review (Chapter 4).

Tier D project. A build that ranks or decides about a named person, is or feeds a high-risk AI system, touches a security-critical path or acts irreversibly on production data. Not a citizen build: it goes to the development organisation (Chapters 4 and 6).

Tier decision. The written record of the five questions, their sources, the tier, the signals that would change it and the countersignature, section 2 of the build record (Chapter 6).

U

Understand. The second test of the stewardship principle: someone other than the assistant can explain how the software works and why, tested by the explain-it-back drill and the takeover test (Chapters 4 and 15).

Usage modes. The series' six modes of using AI, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, defined in AI Governance, Chapter 2. For builders, Modes 1 to 3 and, at Tier C, Mode 4 (Chapter 4).

V

Version. A number that names a release, written MAJOR.MINOR.PATCH (Semantic Versioning) (Chapter 13).

Version control. The system that records every change to the files of a tool, with who made it and when, so that any earlier state can be restored. The history is also why a secret committed once stays in it (Chapter 7).

Vibe coding. Building software by conversation with an AI assistant without reading or structuring the result: without reading, because the builder judges the result by whether it runs and looks right; without structuring, because nothing around the code exists (Chapter 2).

VER-* (verification plan). The plan that says how it is known that the build works: tests from the specification, the independent oracle and who wrote it, the first run, what is not covered and the validity date. VER-NR-2031-0001 and VER-HM-2031-0001 are the examples (Chapter 11).

W

Workshop. The place to work that can be trusted: repository, environments, secrets handling, synthetic data, the rules file and the mandate. Also the name of Step 3 (Chapter 7).

The two builds, their builders and organisations

claims-doc-check. The Hansa Mutual build: for motor property-damage claims it lists missing documents and drafts a request text for the handler to review and send. Builder Katarzyna Nowak, deputy Marek Zieliński, receiving developer Tomasz Wrona; Tier C from 2031-09-18 (Chapters 4 and 23).

Hansa Mutual. One of the two fictional organisations of the series, an insurer that is a financial entity under DORA (Chapter 1).

Nordvik Region. One of the two fictional organisations of the series, a public authority (Chapter 1).

service-point-check. The Nordvik Region build: it compares the opening hours and notices of 24 service points in three sources and reports mismatches weekly. Builder Hanna Wikström, deputy Elin Berg, receiving developer Rasmus Holm; Tier B from 2031-09-11, Tier C from 2031-12-15 (Chapters 4 and 23).

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)