Glossary

This glossary defines the vocabulary of AI Developer, from the five developer functions, the classes of development work and the degrees of delegation to the artefacts, roles, practices, regulations and frameworks that the chapters use. Each entry gives the book's own usage in one to three sentences and names the chapter that owns the term, where it is introduced or defined. Where a term is used in a sense the chapters do not support, it is left out rather than defined. 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 (OWN-*, RVW-*) are sorted by their letters. An identifier such as DLG-* names a pattern: the wildcard stands for the number the organisation assigns to each record, and the book's examples use NR for Nordvik Region and HM for Hansa Mutual. AI Decision Records run from AIDR-1100 to AIDR-1199 in this book: Nordvik Region AIDR-1100 to AIDR-1149 and Hansa Mutual AIDR-1150 to AIDR-1199.

Levels, modes and work classes are defined in sets, so read an entry for one of them together with the entries it refers to. The book sets ceilings and not single values: where an entry gives a default, a delegation profile may set a lower level, and the lowest ceiling that applies governs. Legal entries follow the instrument and attribute each statement to its article as the chapters cite it; they describe organisational and architectural implications and are not legal advice. The labels observable, expected and speculation are defined below and mark every statement about the future. The functions D1 to D5 of this book are not the operations functions O1 to O5 of AI Operations or the leadership functions L1 to L5 of AI Leader.

A

Acceptance criteria. The testable statements that say when a piece of work has met the need, written before the build and kept in the specification record SPC-*. They are what an independent test oracle is written from (Chapter 5).

Acceptance rate. The share of an assistant's suggestions that developers accept. It measures use, not productivity, and the book treats it as a measure that misleads when used as a target (Chapters 3, 15 and 20).

Acceptance-rate dashboard. The anti-pattern in which a programme reports the share of AI suggestions accepted, or of lines that are AI-assisted, as evidence of value. It fails the Understand test, because the number counts use and says nothing of delivery (Chapter 30).

Adoption and value record (AVR-*). The versioned record that states an adoption or value claim with its quoted value, basis, owner, independent evidence owner, plan, expiry and the decision it supports. AVR-NR-2030-01 and AVR-HM-2030-01 are the examples (Chapter 20).

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 1 and 8).

Agent run record (RUN-*). The record of one run of a coding agent: the mandate under which it ran, the identity and scope of the run, what it read and changed, the commands it executed and the checks and approvals that followed. It is written outside the agent. RUN-NR-2030-0019 is the example (Chapter 8).

AI Act. Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744. The book uses its terms exactly (provider, deployer, high-risk AI system, general-purpose AI model, systemic risk) and reads Articles 3, 4, 14, 25, 26, 50 and 53 for the development organisation (Chapters 4 and 24).

AI bill of materials. See Bill of materials.

AI Decision Record (AIDR). The record of a decision about an AI capability or about the delegation of a class of work. It is numbered AIDR-1100 to AIDR-1199 in this book, Nordvik Region AIDR-1100 to AIDR-1149 and Hansa Mutual AIDR-1150 to AIDR-1199 (Chapter 4).

AI gateway. The platform service through which a coding assistant or agent reaches models and, where configured, tools, so that identity, logging, cost and the approved list of tools are set in one place and outside the agent. At Hansa Mutual the gateway is called Hansa Forge (Chapters 10 and 16).

AI literacy. The measures that providers and deployers take under Article 4 of the AI Act, as replaced by the Digital Omnibus on AI, to support the AI literacy of staff and others who operate AI systems on their behalf. The Article does not require a guaranteed level for any individual; in this book consultants and nearshore developers using the tools are inside its reach (Chapters 24 and 27).

AI-off practice. Time in which a developer works without the assistant, as deliberate practice and as a check on the developer's own calibration, for example an AI-off day each week in an apprenticeship plan or a practice plan (Chapters 13 and 28).

Ambient AI. See Mode 0 Ambient AI.

Anti-pattern. A recurring failure of development with AI in which every step looks reasonable. The book catalogues nine: the acceptance-rate dashboard, the unowned agent, the generated test that proves nothing, the junior hole, the review rubber stamp, the secret in the prompt, the vibe-coded production system, the trusted name and the open pipeline (Chapter 30).

Apprenticeship plan (APR-*). The record of the designed route by which a junior developer becomes an experienced one when AI performs many of the entry tasks: attempt first, review first, AI-off practice, an owned small change with a revert drill, a second assessor and a review date. APR-NR-2030-01 and APR-HM-2030-01 are the examples (Chapter 13).

Apprenticeship problem. The risk that when AI takes over the entry tasks through which novices became experienced, the route to seniority narrows, so that an organisation has too few seniors later. The book's remedy is to rebuild the route on purpose, not to assume it (Chapters 13 and 29).

Architectural drift. The gradual divergence of the code from the design intended for it, older than AI. The book asks whether generation changes its rate or kind, finds the evidence suggestive and not settled, and treats drift as a finding to be measured against conformance rules (Chapter 6).

Architecture as Code. The companion discipline of the series: architecture, policy and tests kept as versioned, executable artefacts. It is also the title of Book 1 (Chapter 1).

Architecture Decision Record (ADR). A short, numbered record of a design decision kept beside the code, introduced in Architecture as Code (Chapter 4). In this book it also records what took part in the decision, what the tool contributed, what the human added or rejected and who decided, as in ADR-NR-0031 (Chapter 6).

Argued. The weakest of the four grades of evidence: reasoning from mechanism with no measurement behind the specific claim, only as strong as its premises, which the chapter states. See Measured, Surveyed and Vendor (Chapter 3).

Asserted. The state of an adoption or value claim that rests on a statement and not on a measurement, as in the field value: asserted of AVR-NR-2030-01 (Chapter 20).

Attempt first. The apprenticeship rule that a junior developer makes an honest attempt at a task, and records it, before consulting the assistant, because learning needs the attempt (Chapter 13).

Automation bias. The tendency to over-rely on the output of an automated system and to under-check it. The book takes it as the reason a design must make the reviewer engage before accepting, and as the reason an AI comment never counts as a human approval (Chapters 4, 9 and 21).

Autonomy budget. The limit on how much autonomous action an organisation allows, set by reversibility and blast radius, from AI Operations (Chapter 4). In this book its development counterpart is the change volume per owner (Chapter 11).

B

Betriebsrat, BetrVG. The German works council and the Works Constitution Act (Betriebsverfassungsgesetz). The book reads §87(1) no. 6 on co-determination for technical equipment that can monitor behaviour or performance and §90 on information and consultation about planned AI use in work procedures (Chapter 22).

Bill of materials. The inventory of the components, dependencies and, where recorded, models that a piece of software contains, with names, versions, sources and hashes. In the provenance record it is the basis for the Cyber Resilience Act duties and for stopping a component from outside the pipeline (Chapters 10 and 24).

Blameless review. A post-incident review that asks what the system allowed and not who erred. In this book it is combined with the Name test: the review is blameless and the owner is named (Chapter 23).

Blast radius. How many users, how much money and how much of the estate a change reaches. It is one of the five answers that set a delegation ceiling (Chapter 4).

C

Canary, ring. Stages of progressive delivery in which a change reaches a small share of traffic or a small group of users first. The ring sequence is a property of the release path and not of the change (Chapter 11).

Change fail rate. The share of deployments needing immediate intervention such as a rollback or a hotfix, one of the delivery metrics of the DevOps Research and Assessment (DORA) programme (Chapter 11).

Change lead time. The time from commit to production, one of the delivery metrics of the DevOps Research and Assessment (DORA) programme (Chapter 11).

Change record (CHG-*). The record of a change to a service, from AI Operations, on which the developer, who owns the change as software, hands over to the operator, who owns it as an event. In this book it carries a generator-independent gate and the revert path. CHG-NR-2030-0212 and CHG-HM-2030-0412 are examples (Chapter 11).

Change volume per owner. The number and size of changes a team can understand and run. It is treated as a budget: a team that raises its output without adding review and on-call capacity has spent a budget it does not have (Chapter 11).

Characterisation test. A test that records the observed behaviour of an existing system, typically from recorded production inputs and outputs, so that a migration can be checked against the old behaviour. It is written or captured by someone other than the tool that produces the translation (Chapters 4 and 12).

Circular verification. The failure in which one assistant drafts the requirements, the same or another generates the code and a third writes the tests, so that the loop is closed by machines alone and nothing in it has touched the user's need (Chapter 5).

Citizen developer. An employee outside the development organisation who builds software for work with a spreadsheet, a form or workflow builder, a low-code platform or a natural-language app builder. The research literature calls the wider group end-user programmers (Chapter 19).

Claim with evidence. A statement about productivity, quality, security, competence or readiness that carries its scope, method, date and result, and an expiry. A statement without these is not a claim the book accepts (Chapters 4 and 20).

Class of development work. One of the ten classes in which the book sets delegation: specify, design, generate, refactor, test, review, deploy, operate, document and migrate. A change can belong to more than one class, and the stricter ceiling governs (Chapter 4).

Co-determination. The strongest of four degrees of employee participation: the employer may not act without agreement or a substitute decision by a conciliation body or a court. The others are information, consultation and negotiation (Chapter 22).

Code-ownership record (OWN-*). The record that names the owner and a deputy of a module or repository, what it is and does, where its tests and decisions are, how it is reverted, when it is next reviewed and under what conditions it is retired, with the dates on which the owner last explained it without the tool and last tested the revert path. OWN-NR-2030-04 and OWN-HM-2030-07 are examples (Chapter 12).

Coding agent. An agent that plans, edits many files, runs commands and opens pull requests in a repository under a mandate (Chapter 8).

Coding-assistant usage profile. A short record of one assistant's usage mode, the work classes in which it may be used, acceptance criteria and a measurement plan. It narrows the delegation profile and never widens it. NR-DEV-001 is the worked example (Chapter 7).

Coding-tool system identifiers. NR-DEV-001 is Nordvik Region's pilot of an IDE assistant on a self-hosted open-weight model. HM-DEV-001 is Hansa Mutual's licensed IDE assistant, HM-DEV-002 its test-drafting assistant and HM-DEV-003 its planned legacy-code explainer, which stays at Level 0 Advisory in its pilot (Chapters 7 and 9).

Cognitive offloading. Handing a mental task to a tool. The book reports what studies measured about offloading, skill and overreliance with coding assistants and what is not established, and keeps the two apart (Chapter 28).

Competence groups. The six groups of the competence profile, the book's own proposal: frame and specify, design and system thinking, read, review and verify, delegate and bound, steward, and AI literacy for the role. Four levels are used: Foundation, Practitioner, Advanced and Expert (Chapter 27).

Competence record (CMP-*). The record that states a developer's competence as a claim: the competence groups, the level reached, the kind of evidence, its date and expiry, the assessor and the development plan. It separates assisted from unaided performance and is personal data. CMP-NR-2030-DEV-01 is the example (Chapter 27).

Complacency. Reduced vigilance towards an automated system that has usually been right. See Automation bias (Chapters 14 and 28).

Consultation. A dialogue between employer and employee representatives before the employer decides. See Co-determination (Chapter 22).

Consultation file. The document set handed to employee representatives for a coding tool: purpose and usage mode, tool and contract, delegation profile, mandate manifest, a telemetry description, data flows, the data protection impact assessment where there is one, and the way the tool changes over time (Chapter 22).

Conway's law. The observation that a system's design mirrors the communication paths of the organisation that builds it. The book uses it to explain why team boundaries and ownership matter more than the tool (Chapters 2, 6 and 16).

CRA clock. The reporting clock of Article 14 of the Cyber Resilience Act, which starts when a manufacturer becomes aware of an actively exploited vulnerability or a severe incident: an early warning within 24 hours, a notification within 72 hours and a final report later (Chapter 24).

Criteria sheet. The weighted list of criteria that a procurement officer puts into the tender documents for an AI coding tool and a developer can check against a repository, such as fit on the buyer's own stacks, life-cycle cost, security and secure development, exit and evidence. NR-2030-041 is the worked example (Chapter 18).

Cyber Resilience Act (CRA). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. It applies from 11 December 2027, and its Article 14 reporting duty applies from 11 September 2026. The book reads it for manufacturers, importers and open-source software stewards, and for the question whether a given piece of software is a product made available on the market (Chapter 24).

D

D1 Frame. The developer function of understanding the problem and fixing intent: requirements, acceptance criteria, the specification and traceability from need to check. It ends where a choice of structure begins (Chapters 4 and 5).

D2 Design. The developer function of choosing the constraints within which software is built: architecture, interfaces, data, security by design, the choice between options and the record of why. It ends where the enterprise architect's work begins (Chapters 4 and 6).

D3 Build. The developer function of producing software and directing its making: writing code, directing assistants and agents, refactoring, migrating and giving a tool the context it needs. AI takes part here more than anywhere in the loop (Chapters 4, 7 and 8).

D4 Prove. The developer function of showing that software is right: code review, tests of every kind, static and dynamic analysis, secure-code and supply-chain checks, and the independence of those checks from the thing they check. Its output is evidence with scope and age (Chapters 4, 9 and 10).

D5 Steward. The developer function of owning software over time: release, operation, maintenance, the ownership record, documentation, incident response for what the developer built and the authority to stop, roll back or fix a change. The stewardship principle is its definition of done (Chapters 4, 11 and 12).

Dark week. A planned week in which the tools are switched off at the gateway and the ambient completion is disabled by the IDE policy, so that owners can show that they explain and revert their changes without the assistant. Nordvik Region ran one in the integration and data team and on the platform side from 16 to 20 June (Chapter 31).

Decision rights register (DRR-*). The register of who decides what, from AI Leader. In this book its legal annex, DRR-NR-001-LEG and DRR-HM-001-LEG, gains a developer section, the duty register (Chapter 24).

Degrees of delegation. The series' autonomy levels per class of work: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous. They are defined in the entries beginning "Level". The level belongs to a work class in a context, not to a tool; the lowest of five answers governs; lowering is immediate and raising is a decision (Chapter 4).

Delegation ladder. The five rungs of the autonomy scale, Level 0 Advisory to Level 4 Autonomous, applied per class of development work. See Degrees of delegation (Chapter 4).

Delegation profile (DLG-*). The artefact that states, per class of development work, the highest degree of delegation, who answers, the evidence for the level, the stop path and the review date. A work class not listed is undelegated. DLG-NR-DEV-01 and DLG-HM-DEV-01 are the book's profiles, each at or below the recommended ceilings (Chapter 4).

Deliberate practice. Practice aimed at a specific skill with feedback, as distinct from mere repetition. The book uses it for AI-off sessions, code reading and kata in the developer's practice plan (Chapters 13 and 28).

Deploy (work class). Releasing a change to an environment. The recommended ceiling is Level 1 Assisted for production and Level 2 for non-production; the gate cannot be altered by the change (Chapter 4).

Deployer. In the AI Act, a natural or legal person that uses an AI system under its authority. A development organisation is a deployer of the coding tools it uses and, if it builds an AI system for its own staff, also its provider (Chapter 24).

Deployment frequency. How often a service is deployed to production, one of the delivery metrics of the DevOps Research and Assessment (DORA) programme (Chapter 11).

Deployment rework rate. The share of deployments that are unplanned and result from a production incident, one of the delivery metrics of the DevOps Research and Assessment (DORA) programme (Chapter 11).

Design (work class). Options, interfaces, the ADR and the data model, in D2. The recommended ceiling is Level 1 Assisted (Chapters 4 and 6).

Developer. The person who frames, designs, builds, proves and stewards software, whatever the title. A junior developer, a staff engineer, a tech lead and a platform engineer perform all five functions in different proportions (Chapter 4).

DevEx. The developer experience framework of Noda, Storey, Forsgren and Greiler, which names three dimensions: feedback loops, cognitive load and flow state. It belongs with SPACE to the experience family of measures (Chapter 20).

DevOps Research and Assessment (DORA) programme. The research programme, run by Google Cloud, that publishes software delivery metrics and annual reports. It is not the regulation of the same abbreviation. See DORA (regulation) and Four key metrics (Chapters 2, 11 and 20).

Digital Omnibus on AI. Regulation (EU) 2026/1744, which amended the AI Act, among other things by replacing Article 4 and changing the dates of application of the high-risk requirements. The book reads the amended text (Chapter 24).

Document (work class). Comments, guides, decision records and release notes. The recommended ceiling is Level 2 Supervised, and the author answers for the text (Chapter 4).

DORA (regulation). Regulation (EU) 2022/2554, the Digital Operational Resilience Act. For developers the book reads Article 9(4)(e) on ICT change management, Articles 28 and 30 on third parties and Commission Delegated Regulation (EU) 2024/1774, Articles 16 and 17, on testing, source-code integrity, independence of approvers and fall-back procedures (Chapter 24).

Duty register. The developer section of the legal annex to the decision rights register: for each duty the instrument and article, scope, addressee, holder and deputy, the artefact that answers it, the maximum age of the evidence and the ceiling for AI. Its entries expire and are re-verified (Chapter 24).

E

e-CF, SFIA. Competence frameworks used as vocabulary for developer posts: the European e-Competence Framework (EN 16234-1) and SFIA 9. The book's competence groups and levels are its own and are not an official equivalence to either (Chapter 27).

Employee representatives. The bodies that represent employees: in the book the German Betriebsrat and Konzernbetriebsrat, the Swedish trade unions under MBL, the Dutch ondernemingsraad under the WOR and the European Works Council. What a body is entitled to differs by country (Chapter 22).

Error budget. The allowance of unreliability that a service may spend, held by site reliability engineering. In this book the budget lowers the degree of delegation for AI-originated change when it is spent, as in the error-budget rule for SVC-HM-005 (Chapter 16).

European Works Council. The body for information and consultation on transnational matters in a Community-scale group (Directive 2009/38/EC), relevant to Hansa Mutual's group-wide tooling (Chapter 22).

Evidence age. How old the evidence for a claim, a level or a competence is. Evidence expires: the defaults are 90 days for usage and for competences that decay with disuse and 180 days for value, the revert drill and the ownership explanation, and a record states its own expiry (Chapters 4, 20 and 27).

Evidence grades. The four grades in which the book grades every claim by who produced it and how: Measured, Surveyed, Vendor and Argued. They sit under the evidence ladder of AI Threat, Chapter 4 (Chapter 3).

Excessive agency. The OWASP category (LLM06 in the list the book cites) for an agent that has the power to install and run things. The book's control is to give an agent only the permissions its task needs, because what an agent can be made to do is what its permissions allow (Chapters 8 and 10).

Exit record. The record of a toolchain dependency with its exit route and a tested alternative, so that a coding assistant can be withdrawn without losing the ability to develop. In the financial entity's case it ties to the DORA register of information (Chapter 26).

Expected. One of the three outlook labels of AI Governance (Chapter 22): a statement about the future that rests on decided law, announced plans or a trend with evidence, and for which the book names what would change it. See Observable and Speculation.

Expired. The state of a claim whose clock has run out, such as the usage figure in AVR-NR-2030-01, older than the 90-day clock (Chapter 20).

F

Feature flag. A switch that separates deploying code from releasing a behaviour, so that a change can be withdrawn without a redeploy. It is part of progressive delivery and of the Revert test (Chapter 11).

Finding (FND-*). A recorded finding from a review or test, from the earlier volumes. FND-HM-2030-0012, the dependency whose name a model suggested and which did not exist, is the book's example (Chapters 10 and 30).

Flow. The state of absorbed, focused work that developers value. The book reports what is known about how assistants affect flow and craft, and what is not (Chapter 28).

Four key metrics. Change lead time, deployment frequency, failed deployment recovery time and change fail rate, as the series calls them (AI Operations, Chapter 20). The DevOps Research and Assessment (DORA) programme now names five, adding deployment rework rate. The book reads their limits: they do not measure value, review depth or the health of the people who build (Chapters 11 and 20).

G

Gate. A defined check that a change must pass to reach production: tests, approvals, a deployment policy, a change window. A gate must be defined and enforced outside the change and outside the agent (Chapters 4 and 11).

GDPR. Regulation (EU) 2016/679. The book reads Articles 25 and 32 for the repository (pseudonymised test data, data protection by design and default, security) and Article 22(1) on decisions based solely on automated processing (Chapters 4 and 24).

General-purpose AI model. In the AI Act, a model that displays significant generality and can competently perform a wide range of tasks, as the Act defines it. Providers owe documentation to downstream providers under Article 53; the book reads this for the coding tools (Chapter 24).

Generate (work class). New code from intent, in the editor or by an agent. The recommended ceiling is Level 2 Supervised outside security-critical paths and Level 1 inside them (Chapter 4).

Generated test that proves nothing. The anti-pattern in which an assistant writes both the change and its tests, the suite passes and the pass is reported as evidence. The tests share the generator's reading of the requirement (Chapters 9 and 30).

Golden path. The opinionated and supported way to build something, a default with a visible exit and not a prohibition. The platform team's golden path carries the AI tooling defaults (Chapter 16).

Goodhart's law. The observation that a measure which becomes a target ceases to be a good measure. It is why acceptance rate and similar figures must not be used as targets (Chapters 4, 11 and 20).

H

Hansa Mutual. The fictional mutual insurance group headquartered in Hamburg, with about 9,500 employees and several legal regimes. Its Group Application Development builds the software; its tools are the IDE assistant HM-DEV-001, the test-drafting assistant HM-DEV-002 and the planned legacy-code explainer HM-DEV-003 (Chapter 1; profile in EXAMPLE_ORGANISATIONS.md).

High-risk AI system. In the AI Act, a system classified under Article 6 and Annexes I and III. Annex III point 4 covers employment and workers management, point 5(a) eligibility for essential public assistance benefits. The dates of application of Chapter III, Sections 1 to 3 follow the Digital Omnibus on AI (Chapters 4 and 24).

Horizon register (HZN-*). The register of trends that bear on developer roles, each with a one-sentence statement, a label (observable, expected or speculation), the functions concerned, evidence and its age, a trigger that would change the label, the posture the organisation takes (commit, prepare or keep reversible), an owner and a review date. HZN-NR-2031-01 and HZN-HM-2031-01 are the examples (Chapter 29).

Human oversight. The assignment of oversight of a high-risk AI system to natural persons with competence, training, authority and support (AI Act Article 26(2)), which the system must allow to understand, interpret, override and interrupt it (Article 14(4)). The three tests of the stewardship principle echo these provisions (Chapters 4 and 27).

I

Incident record (INC-*). The record of an incident, from AI Operations. INC-NR-2030-0071 (the secret in the prompt), INC-HM-2029-0207 (the duplicated settlements) and INC-NR-2030-0094 are the book's examples (Chapters 2, 10 and 23).

Independence principle. From AI Purple (Chapters 4 and 15): where AI is on both sides of a check, what tests must be independent of what is tested. The book generalises it, with the observer principle and the answerability principle of AI Leader, to the stewardship principle and the independent test oracle (Chapter 4).

Independent test oracle. A test oracle, the means of deciding whether observed behaviour is correct, that does not come from the generator of the change. The corollary of the stewardship principle: tests, reviews and checks that an AI system wrote for its own output verify less than they appear to (Chapters 4 and 9).

Information (participation right). The first degree of employee participation: the employer hands over what representatives need to examine a subject, in good time (Chapter 22).

Intended purpose. In the AI Act (Article 3(12)), the use for which a system is intended by its provider, including the specific context and conditions of use. The book reads a change to a general-purpose assistant's prompt, retrieval or tools as a possible change of intended purpose, to be gated before merge (Chapter 24).

Internal developer platform. The platform through which a platform team offers golden paths, pipelines and the AI gateway to development teams (Chapters 2 and 16).

Irreversible-data prohibition. The fourth Level 4 prohibition: an action that cannot be undone on production data is never Level 4 (Chapter 4).

J

J-curve (productivity). The pattern in which productivity falls before it rises while an organisation adapts to a new technology. The book uses it as a reason not to judge an adoption programme on its first months (Chapter 20).

Junior hole. The anti-pattern in which an organisation lets the assistant do the tasks that taught juniors and takes fewer juniors, so that it has too few seniors later (Chapters 13 and 30).

K

KBV. Konzernbetriebsvereinbarung, a group works agreement in Germany. KBV-IT-2024-DEV-01 is the developer-tooling annex of Hansa Mutual's group agreement on IT systems (Chapter 22).

L

LDR-*. See Leadership decision record.

Leadership decision record (LDR-*). The record of a leadership decision, from AI Leader. Developer-tooling decisions that bind a named matter use the same shape (Chapter 4).

Lethal trifecta. The combination named by Simon Willison of access to private data, exposure to untrusted content and the ability to communicate externally. It is the background of the rule of two (Chapter 8).

Level 0 Advisory. The AI system suggests, answers a question or explains code; the developer writes, decides and commits (Chapter 4).

Level 1 Assisted. The AI system drafts the code, test, document or option set; the developer reads, edits and commits in the developer's own name (Chapter 4).

Level 2 Supervised. The AI system executes after explicit approval of each action, for example opening a pull request or running a command; the developer approves each action (Chapter 4).

Level 3 Bounded. The AI system executes pre-approved, reversible actions of a named class within a codified policy, enforced outside the model; the authority that approved the policy holds the stop. Without a written policy enforced outside the model and a stop held by a named person, it is Level 4 under another name (Chapters 1 and 4).

Level 4 Autonomous. The AI system selects and executes actions without per-action approval, within bounds set in advance; the authority that set the bounds checks by sampling. It has no default home in the ten work classes (Chapter 4).

Level 4 prohibitions. 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 or safety-critical path (authentication, authorisation, cryptography, payment, clinical or life-safety logic) without human review by a named developer; for a change to the agent's own mandate, permissions, credentials, test oracles, review rules 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 (Chapter 4).

Licence contamination. The entry of code under licence terms that the receiving codebase cannot meet, for example copyleft obligations, through generated code or a suggested dependency. Detection and policy are part of the licence policy LIC-* (Chapters 10 and 26).

Licence policy (LIC-*). The policy that sets which licences may enter a codebase and who answers for exceptions. LIC-HM-DEV-01 is Hansa Mutual's example (Chapter 26).

Low-code platform. A platform that provides visual building blocks, connectors to data and a hosting environment so that an application can be assembled with little or no hand-written code. See Citizen developer (Chapter 19).

M

Mandate manifest (MND-*). The written, versioned statement of what an agent may do, with what, on what, for how long and at what cost, and who can stop it. It is subordinate to the delegation profile: a mandate may lower a level for one agent and never raise it. MND-NR-DEV-* and MND-HM-DEV-* are the book's families; MND-HM-DEV-01 (patch-level dependency updates) and MND-HM-DEV-02 (the agent pilot) are examples (Chapter 8).

MBA-*. See Negotiation record.

MBL. The Swedish Co-determination in the Workplace Act (Medbestämmandelagen). The book reads §11, the duty to negotiate before an important change, and §12, negotiation at the union's request, and uses MBL-NR-IT-2027-01 as the Region's framework agreement (Chapter 22).

Measured. The strongest of the four grades of evidence: a study with a stated sample and method, official text or a primary report. It applies to the sample, task and tool version tested (Chapter 3).

Migrate (work class). Moving code between languages, platforms or versions. The recommended ceiling is Level 1 Assisted, with characterisation tests written by someone else (Chapters 4 and 12).

Mode 0 Ambient AI. AI that people meet without having chosen it, such as completion switched on by an update. The usage mode is where an organisation's profile is most often wrong (Chapters 1 and 7).

Mode 1 Conversational assistants. A general-purpose chat interface; the person brings the context and takes the output away (Chapters 1 and 7).

Mode 2 Embedded workplace assistants. An assistant that works inside the developer's tools with the developer's permissions, such as an IDE assistant (Chapters 1 and 7).

Mode 3 Agentic work tools. A model in a loop with tools; a person delegates and reviews. An agent that reads a repository, proposes a change, runs tests and opens a pull request is the example (Chapters 1, 7 and 8).

Mode 4 Built AI applications. A model integrated in the organisation's own system, with its own lifecycle, such as a test-drafting assistant (Chapters 1 and 7).

Mode 5 Autonomous production agents. An agent that acts on business systems without a person approving each step. None writes or merges code in the two organisations (Chapters 1, 7 and 8).

Moral crumple zone. Elish's term for the human actor who bears responsibility for the failure of an automated system over which that person had limited control. An organisation that names a junior as approver of agent-opened pull requests without time, sources or authority to refuse has built one (Chapters 4 and 12).

Mutation testing. Measuring the strength of a test suite by making small deliberate changes to the code, called mutants, and counting those that no test fails. A live mutant marks a behaviour the suite does not pin down (Chapter 9).

N

Name (test). The first test of the stewardship principle: the owner is identifiable in the code-ownership record to colleagues, operators and auditors, by name or by a named team with a reachable lead (Chapter 4).

Natural-language app builder. A tool that generates an application, and often its database and hosting, from a description in ordinary language (Chapter 19).

Negotiation. The third degree of employee participation: the employer must seek agreement but may decide when none is reached (Chapter 22).

Negotiation record (MBA-*). The record of a negotiation with employee representatives at Nordvik Region. MBA-NR-2030-03 concerns developer tooling and telemetry (Chapter 22).

NIS 2. Directive (EU) 2022/2555. The book reads Article 21(2)(d) and (e) and 21(3) on supply chain security and on security in acquisition, development and maintenance, including vulnerability handling, and the Swedish Cybersäkerhetslag (Chapters 3 and 24).

Nordvik Region. The fictional regional public authority of the series, in a Nordic member state, with about 6,000 employees. Its Applications and Integration unit and its platform team build software (Chapter 1; profile in EXAMPLE_ORGANISATIONS.md).

O

Observable. One of the three outlook labels: a statement about something that can be seen now and can be checked. See Expected and Speculation (Chapter 1).

Observer principle. From AI Operations (Chapters 4 and 17): what verifies an action must not share the failure modes of what performed it. See Independence principle.

Open pipeline. The anti-pattern in which a pipeline or release job can be altered by the thing it releases, or by a contributor who should not hold that power (Chapters 11 and 30).

Open-source software steward. In the Cyber Resilience Act (Article 3(14)), a legal person other than a manufacturer that systematically supports, on a sustained basis, the development of specific free and open-source products intended for commercial activities. The regime is light (Article 24) (Chapter 24).

Operate (work class). Running what was built: incidents, runbooks, support. The recommended ceiling is Level 1 Assisted, and Level 4 is never used on production data (Chapter 4).

Out of band execution. The property of a gate that runs on infrastructure the change cannot influence, with its secrets unavailable to the steps the change defines (Chapter 11).

OWN-*. See Code-ownership record.

Own-mandate prohibition. The third Level 4 prohibition: a system must not set, widen or loosen its own mandate, permissions, credentials, test oracle, review rules or pipeline gates. It protects the other four (Chapter 4).

P

Package hallucination. A coding assistant's suggestion of a dependency name that does not exist, which an adversary can register. The controls are a package proxy that serves only approved names, a human approval for each new dependency and a waiting period for new versions (Chapters 10 and 30).

Pair review. The practice in which two people read the diff of a change in a security-critical or payment path, one of them before seeing the tool's summary. Under DLG-HM-DEV-01 an AI review comment never counts as one of the two human approvals (Chapter 15).

People prohibition. The fifth Level 4 prohibition: no decision about a named person's employment, pay, performance rating or access to work. Telemetry from coding tools is not a basis for rating or paying a named developer (Chapters 4 and 22).

Policy decision point. The component outside the agent that decides whether an action is allowed, so that an agent cannot raise its own ceiling (Chapter 4).

Post-incident review (PIR-*). The review after an incident, from AI Operations. In this book it gains fields for AI involvement: what generated or changed the code, under which mandate and run record, who reviewed it and who is named (Chapter 23).

Practice agreement. A one-page written agreement of a team on how it works with an assistant: pairing, review, trust, speaking up and shadow AI. It may only be stricter than the delegation profile and gets no identifier family of its own (Chapter 21).

Practice plan. The developer's own plan for keeping skill in practice: AI-off sessions, code-reading time and what to keep by hand, agreed with the line and recorded as CMP-* (for example CMP-NR-2030-DEV-P01) (Chapter 28).

Product Liability Directive (PLD). Directive (EU) 2024/2853, which treats software as a product, applies to products placed on the market or put into service after 9 December 2026 and presumes defect in defined circumstances (Article 10(2)). The book concludes that a team's records are its evidence in both directions (Chapter 24).

Production-gate prohibition. The first Level 4 prohibition: no change to production without a gate that the change itself cannot alter (Chapters 4 and 11).

Professional-judgement clause. The part of a senior developer's role charter with six elements: the right to hold a change, the right to an explanation without the tool, the right to decline ownership, the right to record dissent, no use target in appraisal, and the right to unassisted work. A hold is time-boxed and is not a veto (Chapter 14).

Progressive delivery. Releasing a change in stages, with feature flags, canaries and rings, so that it can be observed and withdrawn (Chapter 11).

Promotion criteria. The conditions, kept as code, that a tool built by a citizen developer must meet to move from prototype to production: owner and deputy, data, access, tests, support and review (Chapter 19).

Prompt injection. A class of weakness in which text in content a model reads, such as issues, comments or documentation, is treated as an instruction. It is listed first in the OWASP Top 10 for LLM applications. The book describes the class and its controls and gives no injection strings (Chapters 8 and 10).

Provenance record (PRV-*). The record of the origin of a change: its subject, the origin of the code (whether an assistant or agent contributed, under which mandate and run record, with which model, hosted where, and the basis of the claim), the dependencies with the proxy's decision, licence and hash, the checks, the build, the people and a reference to the bill of materials. Where nothing recorded the origin, the field says "not asserted". PRV-HM-2030-0014 is the example (Chapter 10).

Provider. In the AI Act, 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)). An organisation that builds an AI system for its own staff is its provider as well as its deployer (Chapter 24).

Psychological safety. Edmondson's term for a team's shared belief that it is safe to take interpersonal risks. The book ties it to speaking up about defects in generated code and to the safety of juniors to ask (Chapter 21).

Public code. Software developed with public money and published for reuse under an open-source licence. A developer in a public authority owns the decisions on what to publish, under what licence and who maintains it (Chapter 18).

Q

Queue cap. The limit on open changes that a team will carry, so that when it is reached new generation waits. It sits with a review budget (Chapter 9).

R

RBK-*. See Runbook manifest.

Refactor (work class). Behaviour-preserving restructuring and dependency updates. The recommended ceiling is Level 2 Supervised, and Level 3 only for one named class whose checks the change cannot alter (Chapter 4).

Register (build-your-own-tool). The register in which tools built by citizen developers are entered by tier, with owner, data and review dates. It is found by asking and by service, not by monitoring individuals (Chapter 19).

Restore test (RST-*). The record of a test that a service can be restored, from AI Operations (Chapter 11).

Revert (test). The third test of the stewardship principle: the owner has the authority, the access and the time to stop, roll back or fix the change, outside the pipeline that shipped it (Chapters 4 and 11).

Revert drill. An exercise in which a developer reverts their own change in the test environment, outside the pipeline's helper, within an agreed time. It is evidence for the Revert test and expires after 180 days (Chapter 27).

Review (work class). Reading a change before it is merged. The recommended ceiling is Level 1 Assisted, and an AI comment never counts as a human approval (Chapters 4 and 9).

Review budget. A named share of a senior's working time for review, changed only by a recorded decision. With the queue cap it makes the trade-off between generation and review visible (Chapters 9 and 14).

Review record (RVW-*). The record of a review: the verification plan it belongs to, the reviewers, the AI review comments counted as useful, wrong or noise, the checks run, what was not covered, whether the steward could restate the change without the tool, and the outcome. RVW-HM-2030-0412 is the example (Chapter 9).

Review rubber stamp. The anti-pattern in which a change is approved in seconds, or by the only other person who shares the author's blind spots (Chapter 30).

Role-boundary matrix. The artefact that records, per role, who frames, builds, proves and owns, so that the boundaries around intent and prototype can move while the boundaries around proof and ownership do not (Chapter 17).

Role charter (ROLE-*). The versioned statement of a role: tasks, decision rights, delegation ceilings, protections and review. The senior developer charter carries a professional-judgement clause. ROLE-NR-DEV-01 is the example; ROLE-*-TCL-*, ROLE-*-QA-* and ROLE-*-PLT-* cover tech leads, quality engineers and platform engineers (Chapters 2 and 14).

Role test. The five questions that precede any reading of an article as a duty, because one team can hold several roles at once: whether the organisation supplies software to others in the course of a commercial activity, whether it developed or changed the purpose of an AI system, whether processing of personal data is its own, whether it is an entity of a listed sector, and whether it publishes software that others integrate (Chapter 24).

Rule of two. A practitioner proposal by Meta that within one session an agent should satisfy no more than two of three properties: processes untrustworthy inputs; accesses sensitive systems or private data; changes state or communicates externally. It is not a tested standard (Chapter 8).

RUN-*. See Agent run record.

Runbook manifest (RBK-*). The record of a runbook, from AI Operations (Chapter 11).

S

Sandbox. An environment in which an agent or a citizen developer works with limited filesystem, process, network and secrets access, so that error and abuse stay contained (Chapters 8 and 19).

Secret in the prompt. The anti-pattern in which a credential or customer record is pasted into an assistant outside the boundary, or an agent is given a long-lived token. INC-NR-2030-0071 is the Region's fictional case (Chapters 10 and 30).

Security-critical prohibition. The second Level 4 prohibition: code in authentication, authorisation, cryptography, payment, clinical or life-safety logic is never Level 4 without human review by a named developer (Chapter 4).

Seeded defects. Known defects added to a sample of changes to measure how many each check catches. It is announced in advance, reported by check and team and never aimed at a named developer (Chapter 9).

Service record (SVC-*). The record of a service, from AI Operations. SVC-NR-002 (the citizen portal), SVC-NR-003 (the case-management system) and SVC-HM-001, -003, -004 and -005 (claims core, policy administration, settlement and customer portal) are used (Chapters 1 and 11).

Shadow AI. Use of AI tools outside the approved list. The book's approach is to make the approved path easier and the report safe, and not to rely on prohibition (Chapter 21).

Shadow IT. Software built or bought outside the IT organisation's knowledge. See Citizen developer (Chapter 19).

SLSA. Supply-chain Levels for Software Artifacts, the OpenSSF framework whose build track expresses levels of build integrity; at its third level runs are prevented from influencing one another and signing secrets are kept from user-defined steps (Chapters 10 and 11).

SPACE. The framework of Forsgren and colleagues which argues that developer productivity is multidimensional, covering satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow, so that no single metric stands for it (Chapter 20).

Spec-driven development. Working from a specification as the source of intent, from which tests and code are derived. The book treats the specification as code, kept under version control (Chapter 5).

Specification record (SPC-*). The record that states intent so that it can be tested: the need, requirements, acceptance criteria, what is out of scope, assumptions, open questions, how AI took part, recorded dissent, the tests and a review date, with an owner and an oracle owner. SPC-NR-2030-0001 and SPC-HM-2030-0031 are examples (Chapter 5).

Specify (work class). Acceptance criteria, user stories and the specification, in D1. The recommended ceiling is Level 1 Assisted (Chapters 4 and 5).

Speculation. One of the three outlook labels: a statement about the future for which there is no evidence beyond argument. The author's own projections are kept to Chapters 29 and 33 (Chapter 1).

Stewardship principle. 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, Name, Understand and Revert. Delegation moves work and never ownership (Chapter 4).

Stop path. The route by which an agent or a change is stopped or withdrawn, held by a named person and working outside the system or pipeline being stopped (Chapters 4, 8 and 10).

Sunset. The planned end of a tool built by a citizen developer, with an owner who must be named when the previous one leaves and a rule by which a tool without an owner becomes read-only, then archived, then deleted, on periods the register sets (Chapter 19).

Surveyed. The grade of evidence that rests on self-reported answers from a stated group of respondents. It describes what respondents report (Chapter 3).

Sycophancy. The tendency of a model to agree with the framing it is given. In framing, a model asked to clarify a request may confirm a wrong premise (Chapter 5).

Systemic risk. In the AI Act, a risk specific to the high-impact capabilities of general-purpose AI models. The exemption in Article 53(2) for open-source models does not apply to models with systemic risk (Chapter 24).

T

Technical debt. The accumulated cost of shortcuts in a codebase. The book reports what studies measured about churn, duplication and maintainability in assisted codebases, and treats the evidence as suggestive (Chapter 12).

Telemetry description. The part of a consultation file that states each field collected from a coding tool, the grain at which it is stored and reported, its retention and who may read it (Chapter 22).

Test (work class). Writing, running and triaging tests and the oracle. The recommended ceiling is Level 2 Supervised; the oracle is never written by the generator of the change (Chapters 4 and 9).

Test oracle. The means of deciding whether observed behaviour is correct. Barr and colleagues call the difficulty of obtaining one the oracle problem. See Independent test oracle (Chapters 4 and 9).

Text and data mining. In Directive (EU) 2019/790, Article 2(2) (21, European Union, 2019), any automated analytical technique aimed at analysing text and data in digital form to generate information such as patterns, trends and correlations. Articles 3 and 4 give exceptions; the book reads them for the training of coding models and for the AI Act's copyright provisions (Chapter 26).

Thesis scorecard. The record, kept as an AI Decision Record, that states for each part of the book's thesis and for each action of the closing chapter what is claimed, on what evidence, how old the evidence is and when it is next read. AIDR-1183 is Hansa Mutual's illustrative example (Chapter 33).

Tier 0. The class of assets with the broadest credentials, whose compromise reaches the rest of the estate. AI Operations, Chapter 18, placed the operator's own AI there; this book places the coding toolchain (editor, agent, gateway, package proxy, repository platform, build service, signing keys and release identities) there too (Chapter 10).

Tiers A to D. The four tiers of tools built by citizen developers, set by what can go wrong: A personal, B team, C business and D project. Tier D is not a citizen build: it ranks or decides about a named person, feeds a high-risk AI system, touches a security-critical path or acts irreversibly on production data (Chapter 19).

Trust calibration. Aligning how far a developer trusts an assistant with how far it has proved reliable for the task, measured and not assumed (Chapter 21).

Trusted name. The anti-pattern in which a dependency, extension or tool is accepted because its name is plausible or a trusted source suggested it (Chapter 30).

Twelve-month plan. The versioned plan with measures, owners and baselines that closes the book's year for each organisation, decided in AIDR-1132 (Nordvik Region) and AIDR-1182 (Hansa Mutual), with proposals for month 12 and the risks that would change it (Chapter 32).

U

Undelegated. The state of any class of work not listed in a delegation profile: no system may take part beyond Level 0 Advisory until a named authority has put it in the profile (Chapter 4).

Understand (test). The second test of the stewardship principle: the owner can explain what the change does and why, and can reconstruct it, without the tool that generated it (Chapter 4).

Unowned agent. The anti-pattern in which an agent runs against repositories, tracker or pipeline with an identity and permissions and nobody can say who owns it (Chapter 30).

Usage modes. The six modes of AI Governance, Chapter 2, from Mode 0 Ambient AI to Mode 5 Autonomous production agents. A mode says how a system reaches the developer; a degree says how much of the work is handed over (Chapters 1 and 7).

V

Values-to-engineering-rule mapping. The artefact that turns an organisation's value, such as fairness to customers or the public-service ethos, into a rule a developer meets at the point of work, a check independent of the generator, and evidence that expires. The worked examples are those of Nordvik Region and Hansa Mutual (Chapter 25).

Vendor (grade). The grade of evidence produced by a company that sells a tool or service in the area. It is read as a claim by an interested party (Chapter 3).

Verification plan (VER-*). The record of how a change will be shown to be right: the generator, whether the change is on a security or payment path, the specification it derives from, the independent oracle and who owns it, the mutation and static-analysis checks, the review, the steward and a date until which the evidence is valid. VER-HM-2030-0007 is the example (Chapter 9).

Vibe-coded production system. The anti-pattern in which software generated from a prompt, with no specification and no reviewer, becomes something people depend on (Chapters 19 and 30).

Vibe coding. A way of working in which the person describes what is wanted and often does not fully understand the result. It is not a tool; Merriam-Webster defines it as writing code "in a somewhat careless fashion, with AI assistance" (Chapter 7).

Volume problem. The arithmetic that when generation is cheap, review capacity bounds the merge rate, so the choice is between a visible cap and an invisible thinning of review (Chapter 9).

W

Whistle-blowing. The reporting of a breach of law or a danger to people through an internal, external or public channel. Directive (EU) 2019/1937 protects reporting persons (172, European Union, 2019) for breaches of Union law in listed areas; the book's reading is that the organisation makes a usable channel outside the development line before it is needed (Chapter 25).

Working agreement. The team agreement of a tech lead and a team on scope, review rules, work classes and ceilings, agents and mandates, data and secrets, metrics, rhythm and stop (Chapter 15).

Works agreement. An agreement between an employer and employee representatives about a system or practice at work, such as KBV-IT-2024-DEV-01. It follows the mandate and not the release of a tool (Chapter 22).

Works council. The body of employee representatives at a workplace or in a group, with rights that differ by country: in the book the German Betriebsrat and Konzernbetriebsrat, the Dutch ondernemingsraad under the Works Councils Act (WOR) and, in Sweden, union negotiation under MBL (Chapter 22).

Y

Year read-out. The ledger of claims for the year, each with a month, a record, a basis (recorded or derived) and a status (closed, closed with conditions, running or open). An entry without a closing record is an open item and not a result; the ledger is held by a partner outside the line. year/read-out-nordvik-2031-08.yaml is the illustrative example (Chapter 31).

"You build it, you run it." The DevOps principle that the team that builds a service also runs it. The book examines it when AI multiplies the number of changes, and ties it to the Revert test (Chapters 2 and 11).

Sources

The definitions restate the chapters named in each entry, which carry the evidence. The instruments and volumes the entries rely on directly are:

1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 (AI Act). (1, European Union, 2024)
2. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 (DORA); Directive (EU) 2022/2555 (NIS 2). (2, European Union, 2022), (3, European Union, 2022)
3. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (GDPR). (4, European Union, 2016)
4. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). (5, European Union, 2026)
5. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act); Directive (EU) 2024/2853 (Product Liability Directive). (242, European Union, 2024), (243, European Union, 2024)
6. European Commission (2024). Commission Delegated Regulation (EU) 2024/1774. (15, European Commission, 2024)
7. Nordqvist, G. (2025, 2026). Architecture as Code; AI Governance; AI Platform and Security; AI Red Team; AI Boss; AI Purple; AI Operations; AI Leader. (161, Nordqvist, 2025), (162, Nordqvist, 2026), (163, Nordqvist, 2026), (164, Nordqvist, 2026), (167, Nordqvist, 2026), (169, Nordqvist, 2026), (170, Nordqvist, 2026), (174, Nordqvist, 2026)
8. European Parliament and Council of the European Union (2019). Directive (EU) 2019/790 (copyright in the Digital Single Market); Directive (EU) 2019/1937 (reporting persons). (21, European Union, 2019), (172, European Union, 2019)