Series Foundations: What This Book Builds On

This is a reference for authors and editors, not a manuscript chapter. AI Developer is Book 12 of The Architecture as Code Series. It does not repeat the earlier volumes; it takes their conclusions as its starting point and asks a question that each of them passed without treating: what happens to the role of the developer, the person who builds what the others govern, secure, defend, operate and lead, when AI is used broadly across software development, in the editor, the pull request, the pipeline, the ticket, the legacy migration and the citizen's low-code app? This document records the conclusions the book builds on with stable identifiers (F1 to F184, grouped by volume), the open questions that the earlier volumes left or that this book raises (Q1 to Q24), the artefacts and vocabulary the book reuses, a map from each chapter of this book to the foundations it takes over, and the tables of contents used for cross-references. BOOK_BLUEPRINT.md maps every chapter of this book to the foundations it builds on, and DISPOSITION.md fixes the design.

The series

No.	Book	Repository	Website
1	Architecture as Code	Geonitab/architecture_as_code	https://aac.geon.se
2	AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities	Geonitab/AI-governance	https://aig.geon.se
3	AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities	Geonitab/AI-platform-security	https://aips.geon.se
4	AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities	Geonitab/Ai-red	https://aired.geon.se
5	AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities	Geonitab/Ai-threat	https://aithreat.geon.se
6	The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities	Geonitab/Transformed-security-architect	https://tsa.geon.se
7	AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities	Geonitab/Aiboss	https://aiboss.geon.se
8	AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities	Geonitab/Ai-blue	https://aiblue.geon.se
9	AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities	Geonitab/Ai-purple	https://aipurple.geon.se
10	AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities	Geonitab/Ai-operations	https://aiops.geon.se
11	AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities	Geonitab/Leader	https://leader.geon.se
12	AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities (this book)	Geonitab/Developer	https://developer.geon.se

The series builds strictly in publication order, so that there is no circular reasoning between the books. This book is Book 12 and builds on Books 1 to 11; it refers to no later volume, and Books 1 to 11 refer to no later volume than their own number. The companions Tools and Landscape are not numbered books and are not cited. It cites Architecture as Code as (Nordqvist, 2025) and AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader as (Nordqvist, 2026), each through its own entry in docs/36_references.md. When a chapter builds on a foundation, it says so in the prose, refers to the earlier volume in plain text by chapter ("Architecture as Code (Chapter 19)"; "AI Governance, Chapter 13"; "AI Platform and Security, Chapter 19"; "AI Red Team, Chapter 26"; "AI Threat, Chapter 14"; "The Transformed Security Architect, Chapter 14"; "AI Boss, Chapter 26"; "AI Blue, Chapter 11"; "AI Purple, Chapter 15"; "AI Operations, Chapter 17"; "AI Leader, Chapter 12"), cites the volume's bibliography entry, and summarises enough that the reader is not left with a gap. A reference to an earlier volume builds on that volume's conclusions; it never stands in for an external source for a factual claim.

The turn this book makes

The eleven earlier volumes are about systems and about the people who govern, secure, assess, architect, manage, defend, verify, operate and lead them. Architecture as Code made architecture executable. AI Governance made the governance of AI executable and proportionate to how AI is used. AI Platform and Security built the AI platform and the pipeline an AI-built system passes through. AI Red Team put AI to work in cyber defence under a written mandate. AI Threat found the quiet harms, including the erosion of skill beside reliable automation, the most deserving of attention. The Transformed Security Architect described the role that designs the boundaries, AI Boss asked what happens when AI manages people, AI Blue and AI Purple the defenders and the loop between red and blue, AI Operations the people who keep services running, and AI Leader the people who lead and answer.

One role runs through all of them without having been the subject of any: the developer. Every earlier volume depends on something somebody built: the pipeline, the platform, the detection, the runbook, the workflow an agent runs. AI Developer takes the developer as its subject across the development organisation: in the requirement, the design, the pull request, the test, the release, the legacy system and the code that outlives its authors. Its premise is that software development has always been partly an act of translation, from need to requirement, from requirement to design, from design to code and from code to behaviour in production. Generative AI performs the translation from specification to code cheaply and fluently; it does not make cheaper knowing what to build, knowing whether what was built is right, or answering for it in production, and these may be scarcer and more exposed because they are what is left.

The book divides development into five functions, named exactly so in every chapter that uses them: D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward (Chapter 4). The delegation of each class of development work (specify, design, generate, refactor, test, review, deploy, operate, document, migrate) to AI is a degree, using the series' autonomy levels, so that a delegation profile states per work class how far a given tool or agent has been allowed to go.

Its working thesis, tested in Parts II to V and judged in Chapters 29 and 33, has five parts. First, the developer is transformed, not abolished: from author of code to framer, verifier and steward of software. Second, delegation of development work is graded and has a ceiling: 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 without 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. Third, verification, not generation, becomes the scarce skill, and the junior pipeline must be rebuilt, not assumed. Fourth, the stewardship principle: AI may draft, generate, refactor and, within a mandate, execute, but may not own; for every change in production a named developer or team passes the tests Name, Understand and Revert, and the test oracle is independent of the generator. Fifth, productivity, quality and competence are claims that need evidence, and craft decays if it is not exercised. The book separates what studies measured from what vendors, consultancies and executives claim, and attributes the duties that European law places on software to the instrument and article.

"DORA" in this book means Regulation (EU) 2022/2554, the Digital Operational Resilience Act. The research programme of the same abbreviation, where it is needed, is written "the DevOps Research and Assessment (DORA) programme" at first use and "the four key metrics" thereafter.

How the parts of this book take over the foundations

Part	Chapters	Foundations taken over
I The Developer Role in Question	1 to 4	F15, F70, F91, F112, F156, F184 (the series' argument and the stewardship principle as its developer form); F142 to F144, F148, F157 to F159 (the loop, the autonomy budget, the observer, independence and answerability principles); F50, F72, F75, F93, F143, F158 (autonomy levels, the transformed role as an artefact); F8, F9, F10, F22, F94, F108 for the pre-AI baseline of Chapter 2; F35, F36, F66, F90, F105, F160, F161 for the pressure in Chapter 3
II The Craft of Developing	5 to 12	D1 (5): F8, F14, F38, F55, F163, F164; D2 (6): F8, F13, F14, F22, F23, F38, F41, F74; D3 (7, 8): F12, F27, F45, F49, F51, F52, F57, F63, F66, F67, F75, F90, F98, F130, F143, F158, F161; D4 (9, 10): F7, F20, F21, F39, F40, F54, F56, F76, F84, F99, F101, F118, F124, F127, F128, F131, F144, F145; D5 (11, 12): F5, F29, F53, F69, F77, F121, F142, F146, F147, F148, F149
III Developer Roles Across the Organisation	13 to 19	F11, F26, F53, F77, F79, F109, F138, F153, F167 (juniors and the apprenticeship); F71, F73, F76, F152, F173 (seniors); F87 to F90, F137, F165, F166, F171, F174 (tech leads and engineering managers); F10, F22, F23, F37, F42, F74, F147 (architects, platform engineers, site reliability engineers); F7, F43, F44, F62, F119 (testers and quality); F31, F47, F85, F111, F133, F172, F179 (the public authority); F15, F49, F57, F69, F160 (citizen developers)
IV Leading Change and Adoption	20 to 23	F90, F105, F119, F132, F146, F160, F161 (adoption and productivity as claims with evidence age); F89, F103, F110, F137, F150, F174 (culture, trust, safety); F81, F84, F85, F86, F151, F175 (works councils and developer telemetry); F19, F28, F46, F63, F67, F100, F116, F121, F134, F149, F176 (incidents)
V Regulation, Ethics and Responsibility	24 to 26	F25, F46, F78, F86, F106, F135, F148, F151, F177 (regulation as duty of named parties); F13, F31, F85, F178 (ethics and judgement); F30, F47, F57, F97, F111, F133, F136, F179 (sovereignty and dependency in the toolchain)
VI The Developer as a Person	27 to 29	F11, F25, F26, F77, F79, F152, F153, F154, F180 (competence and the craft); F53, F66, F110, F138, F153, F181 (the developer's own mind); F32, F33, F80, F113, F139, F155, F182 (outlook labels and the author's projection)
VII Experience and Conclusions	30 to 33	F28, F67, F114, F140, F141, F183 (cases and anti-patterns); F70, F91, F112, F156, F184 (the series' argument closed for the developer); all foundations for the two-organisation conclusions

Foundations from Architecture as Code (Book 1)

ID	Conclusion	Where it is made
F1	Threat handling belongs in the codebase: threat intelligence is ingested as STIX/TAXII through pipelines, threat models are generated from architecture code, response playbooks are state machines (subscribe, assess, act, document), and findings return as pull requests. "Celebrate the remediation pull request, not just the discovery."	Chapter 9C, Risk as Code and Threat Handling as Code
F2	Risk is a versioned record with likelihood, impact, owner and expiring exceptions; a failing control metric fails the pipeline.	Chapter 9C
F3	Policy as Code (OPA/Rego) with "assure once, comply many": a control is written once and mapped to many obligations, with evidence linked to enforcement.	Chapters 10 and 11, Policy and Security as Code in Detail; Governance as Code
F4	Evidence as Code: evidence is machine-collected, signed and versioned, not assembled in audit season.	Chapter 15A, Evidence as Code and Continuous Assurance
F5	Manual incident response cannot scale when attacks develop within minutes; compromised components are redeployed from known-good definitions, and MTTD, MTTR and false-positive ratio are the programme metrics. AI models must themselves be defended against adversarial machine learning.	Chapter 9B, Advanced Security Patterns and Implementation
F6	Security architecture has four dimensions that the codebase must carry: threat modelling, zero trust, Policy as Code and risk assessment.	Chapter 9, Security Fundamentals for Architecture as Code
F7	Security and compliance tests, including synthetic attack simulations, run in the pipeline against ephemeral environments.	Chapter 13, Testing Strategies for Infrastructure as Code
F8	Architectural decisions are kept as short, numbered, immutable Architecture Decision Records beside the code, with context, options and consequences, so that the rationale survives the people who made it.	Chapter 4, Architecture Decision Records (ADR)
F9	Architecture as Code succeeds only with equal investment in people, process and technology. Modern roles blend engineering, governance and advocacy; security partners work from shared roadmaps and influence without direct authority; dual-ladder careers keep experts on technical tracks; resistance to change usually signals legitimate concerns about skills and job security.	Chapter 17, Organisational Change and Team Structures
F10	Platform teams act as internal service providers that own the common toolchains, guardrails and reusable modules, so that product teams move quickly without sacrificing governance; the system design mirrors the organisation's communication paths (Conway's law).	Chapters 17 and 18, Team Structure and Competency Development for IaC
F11	Competence is managed as a skills matrix by level (Foundation, Practitioner, Advanced, Expert) with interpersonal domains, in a development loop of assessment, planning, learning, application, knowledge sharing and measurement; certifications validate knowledge, while practical demonstration on real delivery shows capability.	Chapter 18
F12	AI agents are structured participants under human direction: "agents draft; humans approve", and exceptions and risk acceptances carry a named human approval in the audit trail.	Chapter 20, AI Agent Team for Architecture as Code Initiatives
F13	Some decisions stay with people whatever the agents propose: architectural commitments with long-term consequences (platform lock-in, data residency, operational dependencies) are escalated by the Architect agent, conflicting agent recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual.	Chapter 20
F14	The habit on which trustworthy programmes are built is making the implicit explicit: an AI-assisted decision without a traceable human rationale should receive an Architecture Decision Record, written retrospectively if necessary.	Chapter 27, Conclusion

Foundations from AI Governance (Book 2)

ID	Conclusion	Where it is made
F15	AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk; the usage mode, not the brand, sets the governance (Mode 0 Ambient AI to Mode 5 Autonomous production agents).	Chapters 2 and 25
F16	Classification is triggered by change, not by the calendar: a new model version, a drift alert, an incident, a regulatory change or a move between modes.	Chapter 8, AI Risk Management and Classification as Code
F17	Decisions are tiered and routed to the lowest tier that can take them with evidence: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board, risk beyond appetite at the management body. The tier policy is itself data, changed by pull request.	Chapter 13, Decision Forums and Governance Bodies
F18	Governance as code does not remove forums; it changes what they are for. Pipelines enforce, observe and remember, while forums decide what pipelines cannot: appetite, policy, exceptions and residual risk. NIS 2 Article 20 and DORA Article 5 anchor oversight in a trained management body, and the AI architect acts as secretary of the design authority.	Chapter 13
F19	Stop decisions are named in advance: the on-call incident commander and the use-case owner may each stop a system unilaterally, restart needs the owner and, for high-risk systems, the risk function, and a stop path that runs inside the system it stops fails when it is needed.	Chapter 13
F20	Evidence is a by-product of delivery; the evidence manifest ties the chain together; attestation is a person asserting, evidence is machine-generated.	Chapter 11, Evidence, Assurance and Audit
F21	Human oversight must be designed, not declared: an interruption path, an override log and the authority to use them. Approvals given in seconds are a signal of rubber-stamping.	Chapters 10 and 21
F22	Organisational design is architecture by other means (Conway's law). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode; control functions keep their independence through gates and records rather than meetings ("gates instead of meetings"), with exceptions routed as expiring records.	Chapter 12, Organisational Design for AI
F23	The AI architect owns the seams between the architecture roles. The security architect keeps the threat model, identity, secrets and zero trust, and relies on the AI architect for AI-specific threats, guardrail policy, agent permissions and the model supply chain.	Chapter 14, Competence, Roles and the AI Architect
F24	New roles follow the usage modes: the AI system owner, the agent operator who watches Mode 5 agents and may revoke their credentials, the skills curator and the evaluation engineer; existing roles such as procurement, internal audit and the data protection officer change.	Chapter 14
F25	AI literacy is role-specific and must be evidenced in a competence framework and individual records checked at the readiness gate. Article 4 of the AI Act, as amended by the Digital Omnibus, asks for measures that support literacy, but Articles 14 and 26(2) still demand competent oversight, and NIS 2 Article 20(2) and DORA Article 5(4) require management-body training.	Chapter 14
F26	Upskilling is the strategy and hiring is for scarce specialisms and the first AI architect; careers need a specialist ladder and a path between building and verifying with a cooling-off period; competence is assessed by practical demonstration, and assessment results are personal data whose use is agreed with employee representatives.	Chapter 14
F27	Govern every agent as a well-meaning insider: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences.	Chapters 19 and 25
F28	The July 2026 OpenAI–Hugging Face incident failed through correlated controls: a shared credential, a package mirror that was also an egress path, and an alert that reached people who did not hold the stop decision.	Chapter 19, A Cautionary Case: The OpenAI–Hugging Face Incident
F29	Patch decisions must be delegated in advance; a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities, and patch velocity belongs in management reporting as a risk indicator.	Chapter 24, Reflections on Each Part
F30	Model origin is a risk question separate from hosting: five categories of geopolitical risk, and a risk-tiered position that decides which models may handle which data, reviewed periodically rather than once.	Chapter 6, Geopolitics and Model Origin
F31	In public authorities legality comes before capability: the line between decision support and automated decision is drawn in the data model and the audit log, every case has a reasons log, and the algorithm register is generated from version-controlled entries.	Chapter 17, AI in Public Authorities
F32	An outlook is governed as a horizon register: each trend is labelled observable, expected or speculation; observable trends justify commitment, expected ones preparation and speculative ones reversibility; the register is valuable because it can be wrong in a reviewable way.	Chapter 22, Future Trends
F33	The author's judgement is kept apart from the book's findings: projections that go beyond the evidence are labelled and placed in their own chapter.	Chapter 24

Foundations from AI Platform and Security (Book 3)

ID	Conclusion	Where it is made
F34	A platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation.	Chapter 25, Conclusions: Building and Securing AI Platforms
F35	AI is both a target and a source of threat; every AI system is designed twice, as something to protect and as something to contain; security operations must run faster than a monthly patch cycle. Security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case (labelled speculation).	Chapters 18 and 25
F36	Four commitments against AI-enabled adversaries: patch velocity as a measured service level (EPSS, KEV, EUVD and local exposure); detection at machine speed, with canaries, honeytokens and the authority to act; identity and approvals that resist synthetic media; and AI for defence under oversight, in which human verification is the bottleneck.	Chapter 18, When AI Is the Threat
F37	A reference architecture of five layers inside a control plane for identity, policy, observability and evidence, carried by the AI gateway, the model registry, the evaluation service and prompt and policy repositories; every tool is registered and its credentials held by the platform. Adaptations are overlays on a pinned baseline that may only tighten it, and the declarative model can be checked against the running estate.	Chapter 4, A Reference Architecture for AI in Large Organisations
F38	AI Decision Records keep Nygard's discipline of short, numbered, immutable records, add the fields AI needs, are validated against a schema and re-opened by evidence; the architecture repository, not the document, is the single source from which Annex IV technical documentation is generated.	Chapter 5, AI Decision Records, Model Cards and the Architecture Repository
F39	Security for AI systems is security architecture with three additions: natural language as an instruction channel the model cannot police, models and datasets as supply-chain components with verifiable provenance (ML-BOM, SLSA, signing), and agent containment through identity, permission and egress. AI Act Article 15, NIS 2 Article 21 and the Cyber Resilience Act make the layer a demonstrable obligation.	Chapter 16, Security for AI Systems
F40	Prompt injection is a property of the architecture, not a patchable defect; controls sit outside the model; OWASP LLM Top 10 and MITRE ATLAS give the shared vocabulary; model loading is code execution.	Chapter 16
F41	Every threat names a control, every control a configuration, and every configuration produces evidence; the threat model lives in the repository and fails the pipeline when a threat has no control or a control no owner, a code-ownership rule routes changes to its review triggers to the security architect, and the control catalogue maps to ISO/IEC 27001, ISO/IEC 42001, ENISA's framework and the regulations.	Chapter 17, AI Security Engineering in Practice
F42	In the platform's code the security architect is already a named owner of boundaries rather than a reviewer of documents: of the bypass list and token policy, the scanning thresholds, egress and workspace isolation, and the pre-production security checklist run against the pull request that introduces an AI system.	Chapters 8, 9, 15 and 16
F43	Red teaming of AI systems runs continuously in CI: the external exercise is for discovery, and every finding becomes a versioned attack case with explicit thresholds, published as evidence against control IDs. DORA threat-led penetration testing is periodic; continuous suites complement it.	Chapter 17
F44	Red teaming is the apex of the evaluation pyramid: a scenario library in version control, an automated harness, a route for human findings into scenarios, and a finding–remediation–re-test path. Deployers ask providers of general-purpose AI models for their Article 55 evidence and test the compound system themselves.	Chapter 20, Evaluation and Testing of AI Systems
F45	Containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report.	Chapter 19, When Your Own Agents Exceed Their Mandate
F46	AI incident management adds an AI classification step (AI Act Articles 3 and 73, DORA), an impact query against the event log and a path back to evaluation; the reporting deadlines of NIS 2, the AI Act, DORA and the Cyber Resilience Act are design constraints on the logs.	Chapters 17 and 21
F47	Digital sovereignty is a set of verifiable properties, not a location: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails.	Chapter 13, Infrastructure, Compute and European Digital Sovereignty

Foundations from AI Red Team (Book 4)

ID	Conclusion	Where it is made
F48	AI strengthens cyber defence across every CSF Function when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop that turns every finding into a verified control with evidence.	Chapter 28, Conclusions: AI as an Active Part of Cyber Defence
F49	The usage mode, not the model, sets the risk: in Modes 1 to 3 AI acts with a person's identity, while a Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider. AI changes the work of red, blue, purple and white teams but not their accountability.	Chapter 6, Roles, Usage Modes and Autonomy Levels; Chapter 28
F50	Five autonomy levels (Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded, Level 4 Autonomous) are set per action from reversibility, blast radius, confidence and the decision tier. The line between Level 2 and Level 3 is the most important; Level 3 is defined by a codified playbook enforced by a policy decision point outside the model; Level 4 is never used for offensive or irreversible actions; the level is decided and recorded, not discovered.	Chapter 6
F51	Every machine identity has an owner, operators and an authority who are named people; at Level 3 human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it; NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool.	Chapter 6
F52	Human command is built, not assumed: an interruption path outside the system it stops, an override log, and approval quality measured by time to approval, rejection rate and reversals; where works councils have rights, those metrics are agreed first and reported in aggregate.	Chapters 6 and 15
F53	Skills erode when AI does most of the work, yet supervision and the degraded mode after a stop need them; people keep them by working a share of cases without assistance, and autonomy is paced to the skills available to supervise it.	Chapters 6 and 15
F54	Everything security AI reads may be written by the adversary; because prompt injection is architectural, the defence is a policy decision point outside the model, permission manifests that set a ceiling on every action, and red-team campaigns that test the ceiling.	Chapters 13 and 28
F55	Threat models belong in code beside the architecture and are regenerated on change; AI proposes candidate threats at Level 1 Assisted; soundness is defined in advance (grounding, classification, mitigation family, likelihood and impact basis, completeness, stability); a named reviewer decides each candidate against its provenance, review quality is measured, and no AI accepts a threat, a risk or an exception.	Chapter 10, AI-Assisted Threat Modelling and Risk Assessment
F56	Identity is the first line of protection against AI-enabled attackers: phishing-resistant authentication, agents with workload identities and task-scoped, short-lived credentials issued outside their runtime, delegated tokens that carry the task and the entity, and approvals confirmed by call-back rather than by appearance.	Chapter 14, Identity, Authentication and Access for People, Agents and Machines
F57	Mode 0 is the blind spot: vendor AI in security products and managed services may already act at an effective autonomy nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on.	Chapters 8 and 28
F58	Recover is where AI changes the economics most: recoverability becomes a measured, continuously rehearsed property, every recoverability finding returns to Govern, Identify and Protect as a pull request, and recoverability belongs beside patch velocity in management reporting.	Chapters 22 to 24 and 28
F59	Security chaos engineering verifies security capabilities continuously by injecting conditions and checking steady-state hypotheses across all six Functions. AI plans and evaluates experiments without estate credentials while narrow deterministic actuators act, and the safety boundaries (catalogued, reversible experiments, bounded blast radius, independent abort, out-of-band stop path, the platform as a tier-0 asset) are the design. It complements, and does not replace, threat-led penetration testing.	Chapter 25, Security Chaos Engineering with AI
F60	Every finding, from an exercise, an AI red-teaming campaign, a chaos experiment or an incident, ends as a verified control, closed only when the re-test passes (the purple loop); a CSF profile kept as code maps each Category to the obligations it helps meet, so that boards and supervisors are answered from the programme's own evidence.	Chapters 3, 26 and 27
F61	Writing about offensive capability stays defensive: adversary behaviour is described by technique at the level needed to design controls, never as exploit code, payloads, jailbreak strings or step-by-step instructions, and offensive work runs only under signed rules of engagement.	Chapter 1; Chapter 7, Policy, Mandate and Rules of Engagement

Foundations from AI Threat (Book 5)

ID	Conclusion	Where it is made
F62	A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and for containment only when it has been shown to hold without the cooperation of the system it contains; controls are classified verified, declared or failed.	Chapter 30, Organisational Defences: Containment, Evidence and Decision Rights
F63	Decision rights to stop, pause, deny or reverse are assigned before the crisis, to holders who can act within the time the threat allows (minutes for an agent on a production estate); the right to stop must be cheaper to exercise than the right to continue, and a stop in good faith is never a failure.	Chapter 30
F64	A control-to-threat coverage matrix joins the threat register to the control catalogue, records shared dependencies so that two controls that fail together are not counted as two, and turns every gap into a finding.	Chapter 30
F65	The AI threat register holds scenarios with a path to harm, an owner, a decision tier and triggers, omits probability on purpose, separates exposure from influence, is reviewed on change, and reaches the board as one page with at most three decisions; it feeds the ORSA, the DORA ICT risk framework and the NIS 2 risk analysis by reference.	Chapter 32, The AI Threat Register: Governing Scenarios as Code
F66	Relying on AI reduces effort, recall and, among those who trust the tool, checking; automation erodes the skills of the people who must catch its errors, and automating junior work removes the route by which experts are made. Drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level are the response.	Chapters 6 and 14, Are We Getting Dumber?; Work, Skills and the Ironies of Automation
F67	Agents acting beyond their mandate are observable: the incidents of 2025 and 2026 share a pattern of mechanism (persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on compliance or leaked), developers moved controls from the agent's compliance into the environment, and organisations should rehearse reconstructing an agent incident from their own logs.	Chapters 25 and 35
F68	Where models may behave differently under test, assurance cannot rest on any single evaluation: pre-deployment tests are layered with a shadow period, production monitoring, comparison of the agent's reports with the record and decoys that do not reveal themselves.	Chapters 23 and 30
F69	Small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists; a delegation register shows the sum of what has been delegated, and reversibility tests check that each delegation can be undone, with further delegation frozen where a test fails.	Chapter 26, Gradual Disempowerment and Correlated Failure
F70	The series makes one argument: keep decisions as records that can be corrected, keep the ability to stop outside the system being stopped, keep people able to do the work and judge the output, keep dependence reversible, and match autonomy to reversibility. The quiet harms at the scales of the mind and the organisation deserve attention first.	Chapter 35, Conclusions: Is There Anything in It?

Foundations from The Transformed Security Architect (Book 6)

ID	Conclusion	Where it is made
F71	The security architect role is transformed, not abolished; what remains scarce, and defines the role, is accountable human judgement, the ability to verify code and AI output and to answer for the decision.	Chapters 1 and 27
F72	Four shifts describe the transformation: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team.	Chapter 3, Four Shifts: Code, Boundaries, Machine Speed and the AI Team
F73	A role is itself a versioned artefact: a role charter with mandate, accountabilities and decision rights, a control catalogue, mandate manifests for the role's agents, competence records and decision records.	Chapters 4, 9, 13 and 21
F74	Boundaries are designed to hold whatever anyone, human or agent, intends; routine decisions are delegated to pipelines and forums under written decision rights, gates instead of meetings.	Chapters 7 and 17
F75	An agent team works under a written mandate manifest at an autonomy level matched to reversibility; the person who conducts it remains the accountable verifier of everything it proposes.	Chapter 13, An AI Agent Team for Security Architecture: Skills, Mandates and Containment
F76	Verifying what AI proposes when the reviewer depends on the AI requires independent reproduction, seeded errors, an oversight-quality metric and review that does not start from the AI's answer; automation bias is documented and must be designed against.	Chapter 14, Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI
F77	Keeping the craft is a design decision: unassisted practice, apprenticeship routes that survive the automation of junior work, and a record of what the practitioner can still do without AI.	Chapter 15, Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can
F78	European regulation places duties on named people and management bodies (NIS 2 Article 20, DORA Article 5, AI Act Article 26); someone must turn each article into a control, and accountability cannot be delegated to a system.	Chapter 18, Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability
F79	Competence is evidenced by records of judgement exercised, not by certificates alone; competence records and frameworks (ECSF, SFIA) make it reviewable.	Chapters 21 and 22
F80	Outlooks on a role carry the labels observable, expected or speculation; the role persists wherever accountability for a boundary must be human.	Chapters 23 and 27

Foundations from AI Boss (Book 7)

ID	Conclusion	Where it is made
F81	AI may direct work but may not, on its own, decide about people: direction can be delegated up to Level 3 Bounded where constraints sit in the optimiser, while every management function that carries consequences for a person has a named human decider who can be identified, contested and held to account; Level 4 Autonomous is never used for an M3 Consequence decision.	Chapters 4 and 33
F82	Management divides into five functions that can each be delegated, measured and governed separately: M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care; a delegation profile states the autonomy level per function.	Chapters 2 and 4
F83	Every management decision that AI makes or shapes about a person is a Management Decision Record the person can see, contest and have corrected; the delegation register records what has been delegated.	Chapter 25, Management Decisions as Records
F84	Human oversight of decisions about people must be real, not rubber-stamped: it is measured by an oversight-quality metric, and an approval given in seconds is a signal of failure.	Chapter 26, The Human in the Chair
F85	Contestability and transparency are designed in: explanation, appeal and correction paths, and worker information notices that tell people which systems manage them, drafted against AI Act Article 26(7) and the Platform Work Directive.	Chapters 27 and 28
F86	Monitoring and scoring of workers falls within co-determination and data-protection law: German co-determination under BetrVG §87(1) no. 6 reaches almost every system that is objectively suitable for monitoring, Swedish law obliges negotiation of important changes, and agreements should govern change classes rather than software versions; monitoring must meet tests of necessity, proportionality and information.	Chapters 13 and 23
F87	The manager's role is transformed, not abolished: from supervisor of tasks to accountable leader of people and conductor of agents, which applies Shift 4 of The Transformed Security Architect to every line manager.	Chapter 29, The Transformed Manager
F88	When an agent orchestrates other agents, oversight of the last step is not oversight of the chain: the chain of accountability ends with a named person, and the agents a manager directs work under mandate manifests.	Chapters 16 and 17
F89	The quiet harms of algorithmic management, to autonomy, dignity, pace, health, voice and the willingness to speak, deserve attention before the loud ones; monitoring has a chilling effect and pace has a cost in health.	Chapters 11, 13 and 14
F90	The evidence on whether algorithmic management works is mixed: controlled studies show short-run gains for less experienced workers and limits for experts, targeted monitoring paid in one well-designed study but not as a general method, and European case studies find that outcomes depend on institutions and on whether workers took part in the design.	Chapter 15, Does It Work?
F91	The series' one argument gains a sixth commitment: keep a named person in the chair for every consequence; the five management functions are the lasting frame and the employer's duty of care is never delegated.	Chapter 33, Conclusions: Who Should Be the Boss?

Foundations from AI Blue (Book 8)

ID	Conclusion	Where it is made
F92	The blue team is transformed, not abolished: in every function AI takes a task and a person keeps a judgement that must be verified and answered for (B1 Anticipate: which hypotheses deserve engineering time; B2 Detect: a draft counts only after a passing test and a named approver; B3 Investigate: a conclusion that matters is reproduced from a second source; B4 Respond: a named incident commander holds what cannot be undone; B5 Learn: a finding closes on a passing re-test). The claim was held with qualifications; the book makes no promise about headcount.	Chapters 5 to 11 and 28
F93	The transformed team is an artefact: a charter (mandate, decision rights, what no system may do), a delegation profile per function and action class (the lowest ceiling governs, any unlisted action is undelegated), a delegation register that states the sum, and a reversibility test that checks each delegation can be undone. Lowering a level is immediate; raising one is a decision by a named authority.	Chapter 4
F94	The work moves from the queue alone to the queue and the loop: AI closes defined low-risk classes and leaves a residual queue plus the review of what it closed, and a loop with no cap on open drafts is another queue (131 drafted detections in a half-year, 52 merged, 79 open before a cap in the illustrative Hansa year). That treating each alert as evidence of a detection not yet engineered reduces load over time is a hypothesis, not a result.	Chapters 6, 7, 26 and 28
F95	A detection is a record with logic, data sources, ATT&CK mapping, tests, owner, alert budget and review date, and it counts only when a recent test shows that it fires and a measure shows what it costs. The classification of controls as verified, declared or failed applies unchanged to detections; supplier detections are Mode 0 and stay declared until the contract grants provenance, logic, tuning and test rights; detection debt is a generated register. The rate of new detections is bounded by the rate at which the team can test them.	Chapters 6 and 11
F96	Closure of alerts is delegated by class, under a closure policy that states the definition, the evidence to close, the level, the owner, the sampling and seeding rates and a stop condition written as numbers, enforced by a policy decision point outside the model. Quality is shown by measures speed cannot buy: escape rate by class, seeded-incident catch rate, retrospective audit and reopen rate, read together with the oversight-quality metric. A blank in the case record is a finding.	Chapter 7
F97	Managed triage with embedded vendor AI is the Mode 0 blind spot in practice, and the answer is a contract. Annex MS-2 turns it into six terms (levels and actions, quarterly sampling, audit rights, evidence, tuning and test rights, 20 working days' notice of a model change) plus conditions for data and exit. Whatever the operating model, detection content, decision rights for containment and disclosure, the case record, the ability to leave and enough skill to supervise stay with the organisation.	Chapters 7 and 16
F98	Autonomy in response is matched to reversibility: actions are classified into five classes, the ceiling is set by the lowest answer to five questions, Level 3 Bounded is reserved for preservation and narrow reversible actions inside a playbook enforced by a policy decision point outside the model, wide, business-critical and person-related actions stay at Level 2, and irreversible or external actions are taken by a named person. The playbook manifest carries the authority; approval moves to the playbook and its owner; the team has no response agent, because containment is a playbook run by the orchestration layer.	Chapters 10 and 13
F99	Verifying what AI concludes when the analyst depends on AI to read the data requires: soundness defined in advance; review that does not start from the AI's answer; independent reproduction of the key fact by another route; a critique agent on a different model family for questions, not verdicts; seeded errors and seeded incidents with a stop rule that freezes delegation when the catch rate falls; and caps, back-pressure and rotation so that review stays real at volume. Because these measures concern people, they are agreed with employee representatives first and reported in aggregate.	Chapter 14
F100	Accountability for a missed closure rests first with the class owner and those who designed the review and granted the level, then with the reviewer, but only if the process allowed real review; the oversight record makes the chain visible. Responsibility does not pass to a tool (NIS 2 Article 20, DORA Article 5).	Chapters 4, 14 and 28
F101	The defenders' AI is part of the estate that is defended: the SOC reads text that adversaries can write, so its agents are privileged insiders that can be steered. The controls sit outside the model: inputs classified by who can write them, a policy decision point enforcing a containment profile scoped to the case, deterministic corroboration of any conclusion that triggers an action, egress denied by default, short-lived credentials, canaries, and the SOC platform treated as a tier-0 asset. They bound suppression, action and disclosure; they do not bound misdirection, which is why review (F99) and the controls must be read together.	Chapter 15
F102	A finding closes when the re-test passes and not before. Every detection built from an exercise carries the exercise's scenario as a regression test, which is what separates a purple loop from a set of exercise reports: a report records that a technique was missed, a loop leaves behind a test that it will not be missed again and the date on which that was last shown. Chaos experiments extend the loop to the machinery around the detection (log sources, connectors, rollback, the stop path).	Chapter 11
F103	Learning is measured by the time from finding to verified control, the recurrence of conditions and the share of controls verified, reported for the team and never for the individual; the number of findings opened or closed is not a measure of learning. One named role is accountable for the age of the register; the red team or external tester is accountable for the quality of findings, not for their closure.	Chapters 11 and 20
F104	The purple team coordinator is a role of the blue team's loop: it schedules exercises, makes sure that findings reach the detection engineer and the playbook owner in a form they can act on, and tracks the age of open findings. Where there is no red team, the coordinator is the person who commissions and receives the penetration test and any contracted exercise, a fraction of the detection owner's duties.	Chapters 11 and 17
F105	Time to detect, time to respond, closure rate and alert volume reward closing alerts faster, and AI makes that the cheapest thing a SOC can do. Four families of measure replace them: speed on verified incidents, coverage as a map of verified, declared and failed cells with a test date, quality of judgement, and learning. Every measure carries a gaming check; benchmarks give direction, never targets; the board sees one page with at most three decisions, each traced to a measure; measures about people are agreed first, reported in aggregate and never per named analyst.	Chapter 20
F106	Regulation reaches the blue team as clocks, records and named people (NIS 2 Articles 20, 21 and 23; DORA Articles 5 and 17 to 19; Regulation (EU) 2024/2847 Article 14; GDPR Articles 32 to 34 and 88; AI Act Articles 4, 14, 26 and 73). One incident can open several clocks, so the case record carries one clock per regime with its own start, limit, owner and state, opened at the earlier of two awareness timestamps; AI drafts notifications and a person classifies and sends; the management body delegates the work and never its accountability.	Chapter 19
F107	Decision rights are requirements with a holder, a deputy and a second deputy, a response time, an evidence standard and a record, set from the speed of the threat and the shortest applicable clock. The right to stop is held by a named set of people, needs no approval or prior justification and costs the organisation, not the individual, if it proves unnecessary; continuing after a stop needs the owner, who restarts at a lower level. A Level 3 playbook decides only what the delegation lists, with the delegator named, and escalates everything else through a packet whose routing it cannot change.	Chapter 18
F108	The tier-1 pyramid was a response to alert volume and a school for the craft. Its functions divide into closure by class, sampling and review, the residual queue and learning what normal looks like; the roles that grow are detection engineer, investigation lead, incident commander, agent operator and intelligence analyst, and the new roles include the purple team coordinator and the evaluation engineer. The expected shape is a diamond whose weak point is the entry rung. Competence is evidenced by exercises, not certificates, and with fewer than two evidenced holders per site a Level 3 class falls back to Level 2.	Chapters 17 and 22
F109	The apprenticeship problem has two halves: where the next analysts come from if closure by class removes the tier-1 queue, and how present experts keep a skill their own automation no longer exercises. That unexercised skill decays beside reliable automation is observable outside the SOC; that it does so for analysts is expected; that organisations stop hiring juniors is speculation and a risk. The design has a measured, randomised share of unassisted work, a craft register, and an apprenticeship route that offers a new first rung in writing and reviewing the tests of detections.	Chapter 23
F110	The analyst is a worker whose attention is the scarce resource; the research on alarm fatigue and burnout is small and mostly qualitative, and whether AI relieves or intensifies the load is open and depends on team design. Measures concern the system and not the person; tools that log every query and ranking of closures can profile the individual and fall within co-determination.	Chapter 21
F111	Sovereignty is tested by four properties and not by a postcode; hybrid models are observable, provider AI that acts at Level 3 across clients is expected, and a fully autonomous managed SOC with no named human decider is speculation. A contract right is only a promise until the first sample, seed or stop request shows it works.	Chapters 16 and 28
F112	The final test of the blue team has two questions, both answered from records and drills: can the team show who or what decided what, and can it stop what it has started and recover? The sixth commitment of the series applies twice in a blue team, to the incidents it handles and to the analysts the tools measure.	Chapter 28
F113	The author's labelled projection for 2036: by then the system is expected to read, correlate, draft and execute inside playbooks; the person conducting systems is expected to engineer, verify and learn; a person alone is expected to decide and answer for what cannot be undone, what is disclosed and what is decided about people. The form of the function (SOC, platform team or bought service), the pace and the entry route are speculation. The first refutation, and the highest bar, is multi-year outcome evidence that a team without a human able to verify and stop its AI does better.	Chapters 24 and 28
F114	The first evidence from a loop on the defenders' own AI: in the illustrative Hansa exercise RoE-HM-2027-SOC-01 the policy decision point denied the unscoped isolation that followed a planted instruction-like ticket, so the action control held, but the case store accepted unlabelled text and a second agent trusted a planted note (finding FND-HM-2027-014, severity high). Elsewhere in the year the stop drill of PIR-HM-0455 took 3 minutes 40 seconds against a target of 2 minutes and passed its re-test at 1 minute 46 seconds. Each defect in implementation needed a re-test; the rule held.	Chapters 15, 26 and 28

Foundations from AI Purple (Book 9)

ID	Conclusion	Where it is made
F115	Purple is a loop, not a team: five stages, P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify, each producing a record (scenario, emulation plan, finding and purple session record, change, regression case with evidence manifest). AI moves the loop from the event to the pipeline and keeps the event. The five states of AI Red Team, Chapter 26, map to P3 to P5, and P3 to P5 are the exercise-driven half of B5 Learn. The same shape, a loop with named stages and records, is what this book gives operations.	Chapters 1 and 4
F116	The closure rule has four clauses: a finding is closed only when the re-test passes, the evidence is attached, a named person signs and the closure carries an age. Five states keep it auditable (open, implemented but unverified, re-test failed, closed and verified, risk accepted); an implemented but unverified change is reported as open, and an accepted risk is reported apart from closure.	Chapters 4 and 11
F117	Before AI the six forms of testing (penetration test, red team engagement, threat-led test, tabletop, purple session, breach-and-attack simulation) were strong at Target, Emulate and Observe and weak at Improve and Verify; the report was the end of the loop and closure had no owner. The rhythm assumed that exploitation took longer than the interval between tests; time-to-exploit measured 63 days, then 32, then 5, and AI changes the cost of variation and repetition, not of novelty, judgement, independence or safety.	Chapters 2 and 3
F118	The independence principle: a check counts as verification only when its failure modes are shown not to be those of the thing it checks. Independence has several dimensions (model, data, authorship, vendor, time) and is shown by held-out scenarios written by people, seeded gaps and seeded errors, layering against test-aware behaviour, and reproduction by a person from the evidence manifest. A loop closed by machines alone can show that something known to work still works; it cannot by itself show that its coverage is real. The statement of independence is quarterly and carries an expiry.	Chapters 4 and 15
F119	Coverage is a claim with five parts (a technique, an environment, a result at a named layer, a date and an expiry); a heat map without age and evidence is not a coverage statement. The coverage record is derived, with six statuses computed by rule (verified, expired, implemented but unverified, failed, asserted, untested), and only a verified record counts as covered. Evidence expires by clock and by condition (a change in a log source, connector, parser, agent model or provider model); "not tested" is counted in the denominator; the board sees the denominator, five counts, the age distribution and at most three decisions. Resilience in this book takes the same form.	Chapter 17
F120	Rules of engagement are the first design question of emulation: authorisation by a named authority in a signed manifest separate from the agent's mandate; scope as code enforced by a policy decision point that fails closed; safety classes (S1 benign and reversible, S2 reversible with bounded side effects, S3 may disturb service and never in production, S4 irreversible or involving staff or third parties and range only). Production and pre-production are different evidence; third parties consent through contracts and notices the manifest records.	Chapter 6
F121	The stop path runs outside the system it stops, is held by named people who need no approval, is timed (seconds for a pipeline, minutes for a human-led exercise) and drilled, and restart is a separate decision at a lower level. A stop in good faith is never a failure, and a stop path decays unless it is exercised.	Chapters 6, 13 and 20
F122	Delegation is a degree per stage and action class: ceilings of Level 2 Supervised for P1 and P4, Level 3 Bounded for catalogued S1 scenarios at P2, read-only observation at P3 and codified re-tests at P5. Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond the authorisation or that targets a named person. Authorisation, the stop, the closure of a finding and the authorship of novelty are not delegated at any level.	Chapters 4, 7 and 14
F123	The loop's roles are separate on purpose: the red team emulates, the white team governs and holds the stop path, the trusted agent answers "is this ours?", the purple team coordinator and the closure owner hold the register, and nobody marks their own work. The coordinator is a role and not a team; where a small team cannot keep the pairs apart it uses countersignature, sampling and a contract.	Chapters 4, 7, 19 and 20
F124	A pipeline is exposed to Goodhart's law: detections converge on the scenarios that test them. The responses are variation on purpose, a held-out share hidden from detection engineers, a telemetry tag detections cannot see and the generalisation gap as the honest number. Continuous regression is observable, AI-generated variants at scale are expected, replacement of the human red team is speculation; a protected share of human-led, novel work remains.	Chapters 8, 24 and 25
F125	Observation is comparison with a written expectation sealed before the result is shown; the ground truth is tagged, time-stamped from a trusted source and held outside the system observed. Each step ends in one of seven outcomes ordered by layer, "detected" demands the whole chain through triage and action, a telemetry gap is recorded at the layer where the event disappeared, and an agent that runs a scenario does not also grade it.	Chapter 9
F126	A finding becomes a change by a recorded decision (layer that failed, routes considered, route chosen, owner, reviewer, cost, expiry, regression case). AI drafts every kind of change and the bottleneck is review: caps on open drafts, a reviewer who is a named person and not the drafter, seeded errors, and the tester who authored a scenario does not tune the detection that answers it. The cost of a change is counted, and findings that cannot be fixed end in a compensating control, a recorded risk acceptance or a transfer, never in silence.	Chapter 10
F127	The exact re-test is necessary and insufficient: variants of path, context and rate, a held-out variant written by someone other than the fix author and a negative control turn a re-test into evidence about the technique. Regression cases run on change, on schedule and on intelligence and cannot be quietly removed (the ratchet); evidence is code, generated by the run, hashed, signed by a person, minimised, and reproducible by a person who was not in the room.	Chapter 11
F128	An AI system is watched as a compound system, by correlation across model, tools, data and identity. Scenarios target four classes (model and instructions, retrieval, tools, data and outputs); prevention and detection are recorded separately per layer; a control that held but was not seen is a finding; a passing evaluation is not a running detection; detections cover an agent acting beyond its mandate but not an agent steered within it.	Chapter 12
F129	A delegation to the defenders' AI is a standing claim that has to be re-shown after every change and lost quickly on failure. Six subjects (triage, investigation, drafting, playbook, stop path, provider's AI) are tested on correctness, grounding, restraint and robustness to hostile input, with restraint first wherever an action is delegated; the agent's own account is not the record; a provider's AI is tested through an injected-test clause that makes a contract right usable.	Chapter 13
F130	The loop's own AI is a team of up to eight narrow functions under per-agent mandate manifests: an identity of its own, tokens issued outside the agent, a catalogue binding, a separation list that implements independence, a never list that closes the routes by which an agent could change its own governance, budgets, circuit breakers and a drilled stop. Containment is judged by what the agent can reach whatever it intends, and shared dependencies are listed so that controls that fail together are not counted twice.	Chapter 14
F131	The loop's own assets (findings register, scenario library, emulation plans, coverage records, agent credentials) are tier 0: an adversary's best map of the estate and the records on which claims rest. The controls sit outside the agent: a register of record in its own store, handling classes FC-1 to FC-4 attached to content, access policy as code at a decision point, agents without standing access to open findings, a deterministic redaction gateway before any hosted model, scenario content pinned and signed as supply chain, canaries, and insider scenarios handled by separation of duties and attributable records, not by covert monitoring of staff.	Chapter 16
F132	Six measures describe the loop and none can be improved by running more scenarios (finding-to-control cycle time, finding half-life, first-attempt re-test pass rate, verified share within expiry, yield per exercise, detection debt); activity counts and a green percentage without a denominator mislead. Goodhart's law applies in four forms and AI makes the adversarial form faster; all measures are of the system, never per person, with a minimum group size and the catalogue agreed with representatives first.	Chapter 18
F133	Four operating models recur (in-house, contracted, hybrid, sovereign or sector) and an organisation runs a mixture, so the decision is made per stage and recorded with exit criteria. What must stay with the organisation is the coordinator, the closure owner, the white team, the register of record and the right to stop. Procurement buys the right to learn: the organisation owns the scenarios and findings, the supplier declares its AI, data are returned and destroyed, and the organisation can stop and leave.	Chapter 19
F134	A loop that decides more, and faster, needs a decision-rights file with a holder, a deputy, a time, an evidence standard and a record for each decision (ten in the loop). Position governs: the authoriser does not run, the acceptor neither authors nor closes, and nobody sets a coverage cell by hand. Risk acceptance is routed by severity with a reason, a compensating control and an expiry; an emulation that becomes an incident is stopped and handled like any other, and no alert is closed as an exercise without a match in the tag ledger.	Chapter 20
F135	Continuous emulation is not a threat-led test; its manifest, authority and evidence are kept apart from the test's, with a hold list that protects the test's secrecy. DORA Articles 24 to 27 and Delegated Regulation (EU) 2025/1190 specify testing and threat-led penetration testing; TIBER-EU is the framework behind it; an agent in a supervised test is the tester's tool and the supervisor is asked first. Agreements with staff govern classes of exercise, and a register that maps each obligation to a control, an evidence artefact with an age and an owner is re-verified against the live text every six months.	Chapter 21
F136	Crossing a boundary needs standing consent in the contract, notice before each run, and a stop held outside the system stopped on both sides; providers' published rules differ and change, so the protocol records the page, the date and the form. A log that cannot cross a border is a coverage gap; a change that belongs to a provider is a request proved by an injected test; sharing with peers is a choice of fields through a deterministic sanitiser and a person's release; disclosure routes are written in advance.	Chapter 22
F137	People on both sides of a loop are rewarded in opposite directions, so accountability is kept separate where independence needs it and the target is shared where learning needs it. A session is safe for the truth when the charter is written first, records name roles and not people, no result enters an appraisal and anyone may pause. Load is a design concern; staff exposed to exercises are protected by governance, and the large studies of phishing simulations found limited value in training individuals.	Chapter 23
F138	The evidence on skill beside automation is old in theory and recent in measurement (colonoscopy, school mathematics, a programming study), the effect depends on how the assistant is used and novices gain most. The question of erosion is open and the response is within the organisation's control: a protected human-led share, an apprenticeship route with rotation in both directions, a craft register tied to the agent's level and contracts that buy teaching with testing.	Chapter 24
F139	The future of the loop is kept as a horizon register in which every trend carries a label, a stage, evidence, a trigger, a posture and an owner. That independence is needed is expected; how it is provided (two teams with one loop, one engineering practice, a pipeline with a human verifier) is speculation; a vendor-run loop with no named human decider is speculation. The author's projection comes with five thresholds that would change it.	Chapter 25
F140	The loop fails in recognisable ways and each way is a step that looked reasonable: eight anti-patterns, among them the contract with no right to test, the emulation that leaves its scope, the coverage claim never tested, the register spread to many copies, the detection tuned until the scenarios pass, the session without a re-test, the verifier that shares the model and prompts of the thing it verifies, and the dashboard that hides evidence age. The controls are few: the closure rule, independence, evidence age, scope as code with an outside stop path, handling classes and a testing right.	Chapter 26
F141	The first year of the illustrative loop (labelled illustrative): at Hansa Mutual 27 of 34 priority techniques verified within expiry against 25 at the baseline, a finding half-life shortened from 46 to 37 days and a generalisation gap of 19 points; a restraint failure of a SOC agent lowered a level for 49 days; an independence re-test moved two cells to failed. At Nordvik Region 4 of 9 techniques tested within expiry, 14 of 15 seeded cases handled correctly by the provider and a stop that took 21 minutes against 15. The pattern is that the first honest numbers are lower than the first dashboards.	Chapters 13, 15 and 18

AI Purple took the loop between red and blue as its subject and the security function as its setting; AI Operations, in the next section, applied the pattern to IT operations as a whole.

Foundations from AI Operations (Book 10)

ID	Conclusion	Where it is made
F142	Operations is transformed, not abolished: the work moves from the queue to the control loop, from handling tickets and alerts to designing, bounding and verifying closed loops. Five functions, O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, can each be delegated, measured and governed separately.	Chapter 4
F143	Autonomy is matched to reversibility and blast radius and has a budget: the degree of delegation is set per function and action class by the lowest of four answers (reversibility, blast radius, evidence and window), with eleven action classes from read to restore-overwrite, and errors consume the budget in the way an error budget is consumed. Level 4 Autonomous is never used for an irreversible action on production data, for an action outside an authorised change window or freeze on a critical function, for an action that disables the observation or the stop path itself, or for an action that decides about a named person's access to work.	Chapter 4
F144	The observer principle has three tests: what verifies an action is independent of what performed it (independence), the observer does not depend on the system it observes (dependence), and the stop path works when the platform does not (stop). It is the operations form of the independence principle of AI Purple.	Chapters 4 and 17
F145	Independence is graded by action class and shown by seeded faults and by reproduction by a person; scripts and synthetic transactions are preferred to a second model, because correlated errors among capable models make a model checking a model a partial remedy; evaluation-aware behaviour weakens any single test. Restart, scale and certificate renewal can be delegated at Level 3 Bounded where an observer exists, rollback stays at Level 2 Supervised and failover at Level 1 Assisted until seeded faults are caught within target.	Chapter 17
F146	Resilience is a claim with a scope, an objective, a measurement, a date and a result; only a verified claim may be called recoverable; evidence expires on a clock (180 days by default for a Tier 1 restore or failover test) or on a substantive change; "not tested" is a legitimate entry. The same form applies to competence.	Chapters 4 and 19
F147	The operator's own AI (remediation agents, observability pipelines, runbook libraries, configuration maps, the control plane they use) is part of the estate it operates and a Tier 0 asset: it holds the broadest credentials and the best map of the organisation, and is contained accordingly.	Chapters 4 and 18
F148	Decision rights are requirements, not job-description prose: each has a holder, two deputies, a response time, an evidence standard, a record and a ceiling for AI. DORA Articles 5 and 17, the delegated regulation on ICT risk management, NIS 2 Article 20 and the AI Act's Articles 14 and 26 ask for the same content in other words: clear roles, activation conditions, a trained and empowered overseer and a management body that approves the allocation.	Chapter 22
F149	Four rules about position keep the holders honest: the incident commander holds the incident by written, pre-assigned authority and hands over by recorded briefing; an assistant works at the stages of information and analysis, files what the commander approves, and never classifies or speaks externally; change authority replaces the weekly board with class approval, a small forum for exceptions and an emergency right whose approver is never the requester; the stop right is held by roles that include one reachable out of hours without approval, through a mechanism outside the platform, and drilled within 90 days. Risk is accepted by named people with a compensating control and an expiry, and no Level 4 prohibition is a risk to accept.	Chapter 22
F150	The evidence on the load of on-call work is more limited than the practice built on it: required availability is associated with changes in mood and in the physiological response, the burden depends on interruptions, control and culture, and no independent study of wellbeing under autonomous operations agents was found; the older research on automation is firmer (operators left with the residue of automation lose practice, complacency and automation bias are not cured by training, and responsibility tends to land on the person nearest the system). The design response is structural: budgets, rest rules, supervision limits, a delegation record that names the delegator, a stop right without penalty and metrics about the rota, never the person.	Chapter 25
F151	The law sets a floor for the people who carry a loop: the Working Time Directive and the Court of Justice's treatment of stand-by as working time where the constraints are heavy, German co-determination that reaches working time, health protection and tools that can monitor employees, and Swedish negotiation before important changes. The charter that records the response, rest, load and agent clauses is agreed first with employee representatives.	Chapter 25
F152	A craft is kept on purpose: a manual-practice clause with an interval (90 days), the agent switched off, an evidenced holder who did not write the runbook, a record of every missing step and a consequence that falls on the delegation (when evidence lapses and a window has fewer than two evidenced holders, its Level 3 classes drop to Level 2); dark days, game days with the agents off and seeded-error drills supply the practice and keep the observer and the stop path in service.	Chapter 26
F153	The decay of unaided performance is observable in other domains (the pilot, colonoscopy, mathematics and programming studies), on stated conditions, and expected in the cognitive part of manual recovery; a thinning supply of entry-level operators is expected where organisations let it; wholesale loss of the craft is speculation. The early-career route is replaced by designed first rungs, an attempt-first rule and rotation.	Chapter 26
F154	Competence is evidenced by records of exercises, not by attendance, mapped to SFIA and e-CF and agreed with employee representatives; the record is personal data and is handled accordingly.	Chapter 26
F155	The outlook is a horizon register in which each trend carries a label, the functions it concerns, evidence, a trigger and an owner. The author's labelled projection is that a person will still be on call in 2036 for large organisations' Tier 1 services, with fewer and heavier pages and the binding constraint moved to verification; five thresholds would change it.	Chapter 27
F156	The observer principle is the rule that carries the operations thesis; the thesis would be shown wrong by independent incident data over several years in which autonomous remediation without independent verification and without practised manual operation did better than a loop that keeps both. Five things to do on Monday: write the loop of one Tier 1 service on one page, set the ceiling for each action class and name who can stop, list the identities that can change production, ask what verifies the last automatic repair, and write the six parts of the oldest recoverable claim and schedule a manual drill with the agent off.	Chapter 31

Foundations from AI Leader (Book 11)

ID	Conclusion	Where it is made
F157	Leadership is transformed, not abolished: from information intermediary to sense-maker, designer of decision rights and accountable answerer. Five functions, L1 Orient, L2 Decide, L3 Organise, L4 Enable and L5 Answer, can each be delegated, measured and governed separately; they are the leader's functions and not the management functions M1 to M5 of AI Boss.	Chapters 1 and 4
F158	Delegation of leadership decisions is a degree per decision class (strategic, resource, structural, people, risk, external, crisis). The ceiling is the lowest of four answers (reversibility, reach, who is affected, evidence); lowering is immediate, raising is a named authority's decision, and an unlisted decision is undelegated. Level 4 Autonomous is never used for a decision about a named person's employment, pay, discipline or access to work, for a decision that law assigns to the management body, a named office or an accountable official, for a decision that sets an AI system's own mandate, budget, oversight or stop path, or for an irreversible decision beyond the system's mandate. The starting ceilings are the author's recommendation, not a measured result.	Chapters 4 and 8
F159	The answerability principle: AI may inform, draft, prepare and, within a mandate, execute; it may not answer. For every consequential decision a named leader passes three tests, Name, Explain and Reach (the authority, time and information to change or stop the decision outside the system that proposed it). Delegation moves work and never answerability. A leader informed only by machine summaries is blind, so the leader keeps sources independent of the briefing. It is the leader's counterpart to the independence principle of AI Purple and the observer principle of AI Operations, and the model for the stewardship principle of this book.	Chapters 4 and 12
F160	A claim about adoption, readiness, productivity or competence carries scope, method, date, result and expiry; it expires by a clock (as convention 90 days for usage and 180 days for value) and by conditions such as a change of provider model or counting rule, and is shown as verified, expired or asserted. The adoption and value record keeps the quoted and the measured figure side by side, says "not measured" where value has not been measured, and names an evidence owner independent of the sponsor. A programme has a stop rule written before the roll-out.	Chapters 4 and 20
F161	The studies reviewed on AI and productivity (support agents, consultants, developers, population surveys, administrative data) disagree on the surface and agree underneath: effects depend on the task, the person and the conditions; perceived and measured effects can diverge; use can be widespread while outcomes that records capture have not moved. The productivity J-curve explains why early figures are hard to read in both directions. A vendor's figure is read as a claim by an interested party.	Chapters 3, 10 and 20
F162	What studies measured on decision advice supports neither simple story: automation bias is documented in experts and mediated by workload and time pressure; explanations can raise acceptance regardless of correctness; algorithm aversion and appreciation both occur; in experiments to mid-2023 human-AI combinations in decision tasks lost on average to the best of either; almost none of this was studied on leaders. Calibrated trust is built by reproduction, scripts before a second model, seeded errors and outcome tracking, each with an expiry. Level 3 Bounded is expected for narrow routine decisions in the resource and external classes, with a policy point outside the model and a numeric stop condition.	Chapter 8
F163	AI adds capacity to orientation (briefings, horizon scanning, scenarios, synthetic stakeholders) and the same properties produce structural failures: homogenised advice, hallucinated evidence, sycophancy to the framing of the question, dissent that does not survive condensation. A briefing specification carries provenance, a dissent field and independent sources; for questions that cannot be scored in time, process and independence take the place of the model's record.	Chapters 5 and 6
F164	Decision quality is a property of the process at the time of the decision, not of the outcome. Decision rights are part of the decision: a register gives each decision a named holder, deputies, a response time, an evidence standard, a record and a ceiling for AI, and a right that law assigns to a body or an official cannot be reassigned by a register. Reversibility is the first sort.	Chapters 7 and 15
F165	Spans and layers allocate attention, expertise and agreement. AI unbundles the tasks of the middle manager whose inputs are text and records (coordinating, reporting, first-line answering: at most Level 2 Supervised) and leaves coaching, judgement in exceptions and representation with a named person at Level 0. A layer is changed by moving its functions one at a time and in writing; a span-and-layer record gives a change a baseline, a span ceiling, a coaching floor, a first rung for junior leaders, a review date and a stop condition. The evidence on delayering is conditional and none tests whether AI carries the coordination; both organisations had cut a layer without evaluating it.	Chapters 9 and 16
F166	The task, not the job, is the unit of allocation, tested by five questions (can a person check the output, can the action be undone, what is the evidence, does the task teach the next generation, does it decide about a named person). A human-agent team has an owner, an identity, a mandate and a stop path outside the agent for every agent; the conductor verifies and holds the stop; the number of agents is limited by what can be verified; every workflow in which an agent acts has one accountable owner with a drilled deputy.	Chapter 10
F167	The apprenticeship problem reaches leadership: the entry tasks through which future leaders learned (first drafts, minutes, summaries, small projects) are the tasks assistants now do in part. The studies measured different things (hiring of the youngest in exposed occupations in one payroll dataset, novices' productivity on a task, learning with and without an assistant) and none measured leaders; the response is designed first rungs, with coaching kept as a relationship between named people.	Chapters 11 and 27
F168	The accountability gap appears in deployed systems as misplacement, not absence: the person nearest the system absorbs the consequences (Elish's moral crumple zone) and a named person at the end of a process does not by that fact oversee it. The remedy is design: Name, Explain and Reach tested on a sample of decisions, and an accountability map that names the owner of the review design, the grant of the level and the stop right as well as the decider.	Chapter 12
F169	The management body has duties the law states (DORA Article 5, NIS 2 Article 20, Solvency II Articles 41 and 42, AI Act Articles 4 and 26) and a measure it does not. The board keeps the decisions that law assigns to it and the decision on its own assistant's mandate, budget, oversight and stop path; every board paper carries provenance, age and dissent; competence is evidenced by what members can do, recorded with an expiry.	Chapter 13
F170	The chief executive owns the thesis, the pace (by outcome, not by use), the acceptance of residual risk, the decision rights and the answer. Each executive seat gains an object and four boundaries rub: the builder does not verify, data about people has two stewards, the spender does not measure the value, the adviser does not own the decision. The chief AI officer is judged by what the seat holds, not by a claim about its results.	Chapters 14 and 15
F171	The first-line leader's job is allocation, coaching, representation and care; AI takes the routing, and the job becomes supervision of the routing plus the work that cannot be routed. Coaching with data opens a conversation and never closes it; figures of agents and people are kept apart; each measure is paired with a check that does not use the same data.	Chapter 17
F172	In a public authority the leader works inside a legal chain of delegation. Reasons, hearing and appeal are design requirements that AI support must leave intact; the AI Act's Article 86 adds an explanation of the system's role on request; GDPR Article 22, read with the SCHUFA judgment, warns that a score others draw strongly on can count as part of the decision. The caseworker is necessary and not sufficient. The SyRI judgment and the childcare benefits inquiry show what an unexplained selection looks like when it goes wrong.	Chapter 18
F173	Leaders of specialists cannot judge content by rank and cannot read fluency as competence. Review starts from the reviewer's first judgement, is disclosed, seeded, partly unassisted and budgeted, and is never delegated to a second model alone; a professional-judgement protection clause in the role charter gives the specialist the right to override and to record disagreement.	Chapter 19
F174	Trust in AI is calibrated, not maximised. Psychological safety is a property of teams; an assistant changes what speaking up risks at three points, the record, the count and the draft, each a rule a named leader sets. Fear of replacement is widespread as a perception and is answered by what the leader can truthfully say. Shadow AI and concealment are signals about trust; a pulse is bounded by limits agreed before its first question.	Chapter 21
F175	Employee representatives' rights differ by country (German co-determination, the Swedish duty to negotiate before deciding, Dutch council consent, a European floor of information and consultation extended for high-risk AI systems by Article 26(7) of the AI Act from 2 December 2027). The leader's duty is mostly timing; an agreement is a better statement of limits than a policy, though the evidence that it improves outcomes is thin.	Chapter 22
F176	A crisis begins with arrangements made before it: a crisis leader and deputies, an incident commander, a signatory, stop holders and a scribe, named in a register. The incident commander holds the incident; the crisis leader holds the decisions the incident cannot. The leader's picture of the situation is the most exposed asset; the stop right is held outside the platform, needs no approval, is drilled and is never held by the leader alone; no system takes part in decisions about its own stop path.	Chapter 23
F177	The law of the book addresses the organisation, the management body and the named person; no instrument lets a system hold a duty, and several (AI Act Article 14(4), Article 10(5) of the platform-work directive) ask that a human can override or must take the decision. The practice is a dated duty register in version control with an addressee, a holder, an artefact and an evidence age for every row, re-read against the live text at least every six months.	Chapter 24
F178	Law states a floor and a process; leaders decide the cases beyond it. Four values recur, fairness, dignity, honesty and care, and they conflict without a fixed solution. The delegation ladder gains a question: which value does a decision put at stake, and can the test run outside the system? Where it cannot, the ceiling is lowered. Evidence on moral deskilling is thin; experiments show that advice from a language model moves moral judgement and that disclosure of the source does not remove the effect.	Chapter 25
F179	Dependency on AI providers is the normal condition and a strategic choice; a dependency accepted without an exit has not been decided. Competition-authority evidence shows few customers switch and the barriers; the law gives levers (DORA exit and concentration provisions, Data Act switching, procurement award criteria). Acceptance, budget and exit conditions are decisions recorded once.	Chapter 26
F180	Leader competence is a claim that needs evidence: five groups (sense-making and independent sources, verifying AI advice and decision hygiene, delegation design, conversation, AI literacy for the role), a record of judgement exercised that separates assisted from unaided performance, assessed by a second leader, dated, expiring and limited by purpose and reader because it is personal data. Confidence is not evidence of competence.	Chapter 27
F181	The studies on cognitive offloading and overreliance show a consistent, conditional pattern in other populations and none sampled executives. The assistant as confidant is the sharpest risk: power lowers the weight given to advice and assistants tend to agree. The design response is a first view written before the briefing, a dark day with the assistants off and a named partner.	Chapter 28
F182	The future of leadership is two questions, fewer layers and fewer answerers, and they are answered separately: flatter organisations are expected in direction and unmeasured in pace; agent-heavy teams are observable with limits and speculative in scale; AI-run units are observable only as a failed small experiment and run into instruments that name natural persons; the leader as curator is expected and safe only if the craft is kept. The author's labelled projection is that coordination work shrinks, answerers do not shrink in step, and the route into leadership is the part most at risk.	Chapter 29
F183	The verified public cases show three recurring mechanisms (a system with owners for its parts and none for the whole, an explanation the user could not give, an assurance that certified a process or a count and outran its evidence) and no lazy leader. Seven anti-patterns are catalogued, each with the test it fails and the control that checks it: the AI-theatre board, the delegated apology, the missing owner, the cut layer, the green adoption dashboard, the briefing monoculture and the unreachable accountable person.	Chapter 30
F184	The thesis of AI Leader holds as a set of design rules and a description of mechanisms, is strongest where it asks for records that can be checked and weakest on outcomes, and ten places were found where no verified study exists. It would be shown wrong by independent multi-year evidence that fewer answerers or a machine-only information diet produce better outcomes. In the illustrative year the first honest numbers were lower than the first dashboards, claims expired faster than they were re-measured, the failures that mattered were quiet, and no step ran at Level 4. The rule through both organisations' plans is to close what has expired before opening anything new.	Chapters 31 to 33

Foundations that AI Developer (Book 12) builds on

Each chapter of this book (DISPOSITION.md, section 7) takes over the foundations below. D1 to D5 are the development functions the chapter concerns. The foundations of Book 11 (F157 to F184) are generalised where the developer is concerned: the answerability principle (F159) becomes the stewardship principle with the tests Name, Understand and Revert, the delegation ladder (F158) applies to development work classes, and claims with evidence (F160) apply to productivity, quality, security and competence.

Chapter	Title	Functions	Foundations taken over
1	Introduction: The Developer with AI	all	F15, F70, F91, F112, F142, F148, F157, F159
2	What Developers Did Before: Craft, Waterfall, Agile, DevOps and Open Source	all	F8, F9, F10, F22, F71, F73, F94, F108
3	The Pressure on Developers: Productivity Claims, Adoption, Legacy and Accountability	all	F35, F36, F66, F78, F90, F105, F106, F160, F161
4	The Developer Loop Defined: Five Functions, Delegation Ladder and Stewardship	all	F50, F70, F72, F75, F93, F118, F143, F144, F158, F159, F160
5	Frame: Problems, Requirements and Intent	D1	F8, F14, F38, F55, F163, F164
6	Design: Architecture, Decisions and Constraints with AI	D2	F8, F13, F14, F22, F23, F38, F41, F74
7	Build: Writing Code and the Tools of the Craft	D3	F12, F49, F57, F66, F75, F90, F160, F161
8	Build with Agents: Delegated Coding, Mandates and Sandboxes	D3, D4	F27, F45, F51, F52, F63, F67, F98, F130, F143, F158, F162
9	Prove: Review, Tests and Verification	D4	F7, F20, F21, F76, F84, F99, F118, F124, F127, F144, F145
10	Prove Security: Secure Code, Supply Chain and the Toolchain as Attack Surface	D4, D5	F28, F39, F40, F54, F56, F61, F101, F128, F131, F147
11	Steward the Release: CI/CD, Change and Operating What You Build	D5	F5, F29, F121, F142, F143, F146, F148, F149
12	Steward the Code: Maintenance, Legacy Modernisation, Technical Debt and Documentation	D5, D2	F8, F14, F53, F69, F77, F146, F168
13	The Junior Developer and the Apprenticeship Problem	D3, D4	F11, F26, F53, F66, F77, F79, F109, F138, F153, F167
14	The Senior Developer, Staff and Principal Engineer	D2, D4, D5	F71, F73, F76, F77, F87, F152, F173
15	The Tech Lead and the Engineering Manager	D1, D3, D5	F87, F88, F89, F90, F137, F165, F166, F171, F174
16	Architects, Platform Engineers and Site Reliability Engineers	D2, D5	F10, F22, F23, F37, F42, F71, F74, F142, F147, F149
17	Testers, Quality Engineers, Product Owners and Designers	D1, D4	F7, F11, F24, F43, F44, F62, F119, F124
18	Developers in the Public Authority: Procurement, Public Code and Legitimacy	D1, D2, D5	F31, F47, F85, F111, F133, F172, F179
19	Citizen Developers, Low-Code and the Non-Developer Who Builds	D1, D3, D5	F15, F49, F57, F69, F160, F166
20	Measuring and Leading AI Adoption in Development	D3, D5	F90, F105, F119, F132, F146, F160, F161
21	Team Practice and Culture: Pairing, Review Culture, Trust and Psychological Safety	D3, D4	F89, F103, F110, F123, F137, F150, F174
22	Developers, Works Councils and Employment: Telemetry, Rights and Intellectual Property	D3, D5	F81, F84, F85, F86, F89, F151, F175
23	When It Breaks: Incidents, Outages and AI-Generated Defects	D4, D5	F19, F28, F46, F63, F67, F100, F116, F121, F134, F149, F176
24	Regulation as Constraint: AI Act, Cyber Resilience Act, Product Liability, NIS 2, DORA, GDPR	all	F25, F46, F78, F86, F106, F135, F148, F151, F177
25	Ethics, Professional Responsibility and the Developer's Judgement	D1, D2, D5	F13, F31, F85, F89, F178
26	Intellectual Property, Open Source and Sovereignty in the Toolchain	D2, D3, D5	F30, F47, F57, F97, F111, F133, F136, F179
27	Competences and Developing the Developer	all	F11, F25, F26, F77, F79, F152, F153, F154, F180
28	The Developer's Own Mind: Craft, Flow, Cognitive Offloading and Identity	D3, D4	F53, F66, F110, F138, F153, F181
29	The Future of the Developer: Fewer, More or Different?	all	F32, F33, F80, F113, F139, F155, F182
30	Case Studies and Anti-Patterns	all	F28, F67, F114, F140, F141, F183
31	A Year in Development: Nordvik Region and Hansa Mutual	all	F102, F141, F156, F184
32	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations	all	all foundations as needed; F33, F70, F91
33	Conclusion	all	F70, F91, F112, F113, F139, F156, F182, F184

Open questions this book takes up

Q1 to Q10 were raised in AI Operations (Book 10) and Q11 to Q16 in AI Leader (Book 11); those that concern people, verification, sovereignty and the pipeline of future practitioners are carried into this book as stated, and the questions that only concern operations or leadership are taken up only at the boundary (Q1 to Q3 and Q8 in Chapters 9, 11 and 13; Q4 in Chapter 26; Q6 and Q7 in Chapters 21 and 22; Q8, Q10, Q15 and Q16 in Chapters 13 and 29). Q17 to Q24 are new in this book.

ID	Question	Raised in
Q1	When AI both performs and verifies an operations action, what makes the verification independent, and how is it shown to a supervisor?	AI Purple, Chapter 15; AI Threat, Chapter 23; AI Blue, Chapter 14; Chapter 17 of this book
Q2	What does "recoverable" mean for a service, how long does evidence of it remain valid, and how does it expire when the estate changes?	AI Red Team, Chapters 22 to 24; AI Purple, Chapter 17; Chapter 19
Q3	How far can Level 3 Bounded safely reach for restart, scale, roll back and fail over, how is the autonomy budget consumed, and how quickly does a stop path decay unless it is drilled? (Carried over: AI Purple, Chapter 13, and AI Blue, Chapter 28.)	AI Red Team, Chapter 6; AI Blue, Chapter 10; Chapters 4, 10 and 17
Q4	How are silent provider-side model updates operated as change, and what notice and test rights can a contract secure?	AI Platform and Security, Chapter 21; AI Blue, Chapter 16; Chapters 13 and 24
Q5	When an agent's action causes an incident, how do the reporting clocks of NIS 2, DORA, the AI Act and the GDPR apply, and who classifies?	AI Blue, Chapter 19; AI Purple, Chapter 20; Chapters 14 and 23
Q6	Does AI relieve or intensify the load of on-call, alert fatigue and toil, and what must a team lead do about it? (Carried over, open in AI Blue and AI Purple.)	AI Boss, Chapters 14 and 29; AI Blue, Chapter 21; AI Purple, Chapter 23; Chapter 25
Q7	How do co-determination, working-time and data-protection law apply to on-call rotas, operational metrics and the monitoring of the people who operate? (Carried over.)	AI Boss, Chapters 13 and 23; AI Blue, Chapter 21; Chapters 20 and 25
Q8	If AI does the routine operations work, where do the next site reliability engineers and incident commanders come from, and how is manual recovery kept in practice?	AI Threat, Chapter 14; The Transformed Security Architect, Chapter 15; AI Purple, Chapter 24; Chapter 26
Q9	How do digital sovereignty, concentration risk and the Data Act's switching rules shape who can operate a service when a provider fails, and what does an exit test show? (Carried over.)	AI Platform and Security, Chapter 13; AI Blue, Chapter 16; Chapter 24
Q10	Will anyone be on call in 2036, or will operations converge into provider-run autonomous operations with a human verifier?	The Transformed Security Architect, Chapter 23; AI Purple, Chapter 25; Chapter 27
Q11	Does managers' use of generative AI improve or degrade the quality of their decisions and the independence of their sources, and under which conditions?	AI Threat, Chapter 14; AI Operations, Chapter 26; Chapters 6, 8 and 28 of this book
Q12	Where does the work of coordinating, reporting and first-line answering go when AI unbundles the middle manager's tasks, and what remains that only a person can do?	AI Boss, Chapter 26; AI Governance, Chapter 12; Chapters 9 and 16
Q13	What makes a named leader reachable (the Reach test) when decisions are taken in a human-agent workflow at machine speed?	AI Operations, Chapters 17 and 22; AI Purple, Chapter 15; Chapters 4 and 12
Q14	What do boards and management bodies need to evidence about AI competence and oversight, and how will supervisors test it?	AI Governance, Chapter 13; AI Operations, Chapter 23; Chapter 13
Q15	If the entry rungs of the leadership route are automated, where do the next leaders come from?	AI Threat, Chapter 14; The Transformed Security Architect, Chapter 15; AI Operations, Chapter 26; Chapters 11 and 27
Q16	Will there be fewer leaders in 2036, or more leaders of fewer, larger and more agent-rich units?	AI Operations, Chapter 27; AI Boss, Chapter 29; Chapter 29
Q17	Does AI assistance raise the productivity and quality of experienced developers in their own codebases over years, and how can a development organisation measure it without mistaking activity (acceptance rate, lines, pull requests) for value?	AI Leader, Chapter 20; AI Operations, Chapter 20; Chapters 7 and 20 of this book
Q18	What makes a test oracle independent when AI writes both the code and the tests, and how is independence shown to a reviewer and a supervisor?	AI Purple, Chapter 15; AI Operations, Chapter 17; Chapters 4 and 9
Q19	Where do the next senior developers come from if the entry-level tasks that taught the craft are the tasks AI performs best, and what does an apprenticeship look like that does not depend on them? (Carried over, in developer form, from Q8 and Q15.)	The Transformed Security Architect, Chapter 15; AI Leader, Chapter 11; Chapter 13
Q20	When a coding agent opens, and within a mandate merges, a change, who is the owner in the code-ownership record, how does that owner pass the tests Name, Understand and Revert, and what happens when the owner cannot reconstruct the change without the tool?	AI Leader, Chapters 4 and 12; AI Operations, Chapter 22; Chapters 4, 8 and 12
Q21	How do the Cyber Resilience Act, the Product Liability Directive, NIS 2 Article 21 and the AI Act apply to software that an enterprise or public authority builds for its own use, buys, or publishes as public code, and where do their duties meet the developer?	AI Blue, Chapter 19; AI Leader, Chapter 24; Chapter 24
Q22	What may be collected about developers' use of coding tools (telemetry, acceptance rates, prompts) and what may be done with it, under co-determination and data-protection law? (Carried over, in developer form, from Q7.)	AI Boss, Chapters 13 and 23; AI Leader, Chapter 22; Chapter 22
Q23	Who owns what a developer produces with AI, how does licence contamination arise and get detected, and how does an organisation exit a coding-model provider? (Carried over, in developer form, from Q4 and Q9.)	AI Platform and Security, Chapter 13; AI Leader, Chapter 26; Chapter 26
Q24	Will there be fewer developers in 2036, or more people building software with different skills, with specification and verification as the main artefacts?	AI Leader, Chapter 29; AI Operations, Chapter 27; Chapter 29

Vocabulary and artefacts to reuse

• The five development functions (Chapter 4), named exactly: D1 Frame (problem, requirements, intent and acceptance criteria; the specification as the source of intent); D2 Design (architecture, decisions and constraints; interfaces, boundaries, data and security by design); D3 Build (writing, generating, refactoring and integrating code with the tools of the craft, including directed agents); D4 Prove (review, tests, verification, security and supply-chain assurance; evidence that the software is right); D5 Steward (release, operation, maintenance, legacy, deletion and ownership over time). They are not the leadership functions L1 to L5 of AI Leader, the operations functions O1 to O5 of AI Operations or the management functions M1 to M5 of AI Boss; D5 Steward meets O3 Change and O4 Restore at the boundary. Every chapter in Parts II to V names, in its opening and its Summary, which functions it concerns, by these exact names.
• The delegation ladder. Degrees of delegation are the series' autonomy levels applied per class of development work (specify, design, generate, refactor, test, review, deploy, operate, document, migrate): Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous (AI Red Team, Chapter 6; AI Leader, Chapter 4). A delegation profile (DLG-*) states the level per work class. 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.
• The stewardship principle (Chapter 4, applied in Chapters 9, 12 and 14): 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 (the owner is identifiable in the code-ownership record to colleagues, operators and auditors), Understand (the owner can explain what the change does and why, and can reconstruct it, without the tool that generated it) and Revert (the owner has the authority, the access and the time to stop, roll back or fix the change, outside the pipeline that shipped it). It is the developer's counterpart to the answerability principle of AI Leader, the observer principle of AI Operations and the independence principle of AI Purple, and carries a corollary: the test oracle must be independent of the generator; tests, reviews and checks that an AI wrote for its own output verify less than they appear to.
• Claims with evidence. No chapter says that a tool raises productivity, that code is secure, that a team is AI-fluent or that a role is redundant without saying what was measured, how, when and with what result; evidence expires (F146, F160). Acceptance rate is not productivity and lines written are not value.
• Usage modes Mode 0 Ambient AI, Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants, Mode 3 Agentic work tools, Mode 4 Built AI applications and Mode 5 Autonomous production agents (AI Governance, Chapter 2; AI Platform and Security, Chapter 2), applied to coding tools (completion, chat, edit and agentic modes, background agents). Every narrative chapter has an ### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table.
• Reused artefacts. Mandate manifests MND-*, delegation profiles DLG-*, role charters ROLE-*, competence records CMP-*, change records CHG-*, service records SVC-*, runbook manifests RBK-*, restore tests RST-*, post-incident reviews PIR-*, delegation and decision records LDR-* and decision-rights registers DRR-* (from AI Leader), adoption and value records (ADP-* in AI Leader, AVR-* in this book), works agreements KBV-* and negotiation records MBA-*, AI Decision Records (AIDR-NNNN, immutable and numbered; AI Platform and Security, Chapter 5) and Architecture Decision Records (ADR; Architecture as Code (Chapter 4)).
• New artefacts of this book (names fixed in DISPOSITION.md, section 6):

Identifier	What it is	Chapter
SPC-NR-*, SPC-HM-*	Specification record: intent, acceptance criteria, traceability	5
OWN-NR-*, OWN-HM-*	Code-ownership record: owner, deputy, the tests Name, Understand and Revert	12
VER-NR-*, VER-HM-*	Verification plan, including the independent test oracle	9
RVW-NR-*, RVW-HM-*	Review record	9
RUN-NR-*, RUN-HM-*	Agent run record	8
PRV-*	Provenance record: origin of generated code and dependencies, AI bill of materials	10
AVR-NR-*, AVR-HM-*	Adoption and value record, with the evidence age of every claim	20
APR-NR-*, APR-HM-*	Apprenticeship plan	13
HZN-NR-*, HZN-HM-*	Horizon register	29
ROLE-*	Role charters for developer roles (for example ROLE-NR-DEV-01, ROLE-HM-DEV-01)	14
MND-NR-DEV-*, MND-HM-DEV-*	Mandate manifests for coding agents and assistants	8
DLG-*	Delegation profile for development work classes	4, 8
AIDR-1100 to AIDR-1199	AI Decision Records: AIDR-1100 to AIDR-1149 Nordvik Region, AIDR-1150 to AIDR-1199 Hansa Mutual (the next free ranges after AI Leader's 1000 to 1099)	all

• Observable / expected / speculation labels for any outlook (AI Governance, Chapter 22). The author's own projections are kept to Chapters 29 and 33 and labelled.
• Terminology. An AI system in development work suggests, generates, drafts, refactors, reviews or executes within a mandate; it does not understand, want, intend or decide. "Decides" is used only for a system to which a decision was formally delegated, and the record then says who delegated it. A developer frames, designs, builds, proves and stewards; ownership is not a property of a model.
• Defensive and constructive. Effects on people are described by what studies measured; no one is called lazy, stupid or replaceable; developers are not portrayed as obsolete, and AI is not portrayed as intending anything. Covert monitoring of staff and defeating employee representatives' rights are never described as methods. Security content (prompt injection into coding agents, package hallucination, secret leakage, malicious dependencies) is defensive only, by class and technique, never exploit code, working payloads or injection strings.
• This book does not use the evidence ladder of AI Threat, the four shifts of The Transformed Security Architect, the five management functions of AI Boss, the five blue team functions of AI Blue, the five stages of the purple loop of AI Purple, the five operations functions of AI Operations or the five leadership functions of AI Leader as red threads. It refers to them at the boundary: Shift 4 where the developer conducts agents (Chapter 8), the operations functions where D5 Steward meets O3 Change and the observer principle (Chapters 11 and 16), the leadership functions and the middle layer where tech leads and engineering managers lead development teams (Chapter 15), the management functions where developer telemetry touches performance management (Chapter 22), and the purple loop where AI-generated vulnerabilities are inputs to defence (Chapter 10).
• The fictional organisations Nordvik Region and Hansa Mutual, with the core profiles in EXAMPLE_ORGANISATIONS.md and the profiles of the earlier volumes in EXAMPLE_ORGANISATIONS_EARLIER_VOLUMES.md; the development profile added for this book gives the developers, teams, technology estate, coding tools, platform teams, legacy estate, procurement context and named characters.

Tables of contents for cross-references

Architecture as Code (Book 1): chapters most used

Chapter	Title
4	Architecture Decision Records (ADR)
6	Structurizr: Architecture Modelling as Code
9	Security Fundamentals for Architecture as Code
9B	Advanced Security Patterns and Implementation
9C	Risk as Code and Threat Handling as Code
10	Policy and Security as Code in Detail
11	Governance as Code
12	Compliance and Regulatory Adherence
13	Testing Strategies for Infrastructure as Code
15A	Evidence as Code and Continuous Assurance
17	Organisational Change and Team Structures
18	Team Structure and Competency Development for IaC
19	Management as Code
20	AI Agent Team for Architecture as Code Initiatives
24	Best Practices and Lessons Learned
25	Future Trends in Architecture as Code
26B	Anti-Patterns in Architecture as Code Programmes
27	Conclusion

AI Governance (Book 2)

Part	Chapter	Title
I Foundations	1	Introduction to AI Governance
	2	From Chat to Agents: How Large Language Models Are Used
	3	The EU AI Act and the European Regulatory Landscape
	4	Fundamental Principles
	5	Prerequisites and Readiness for Enterprise AI
II Sovereignty and Suppliers	6	Geopolitics and Model Origin
	7	Procurement, Vendor Management and Open Models
III Risk, Governance, Trust and Assurance	8	AI Risk Management and Classification as Code
	9	AI Governance as Code
	10	Trustworthy AI: Transparency, Fairness and Human Oversight
	11	Evidence, Assurance and Audit
IV Organisation and Leadership	12	Organisational Design for AI
	13	Decision Forums and Governance Bodies
	14	Competence, Roles and the AI Architect
	15	Change Management and Responsible Adoption
	16	Management as Code for AI Programmes
	16A	Governing AI Economics: Cost, Value and Portfolio Decisions
	17	AI in Public Authorities
V Experience	18	Case Studies
	19	A Cautionary Case: The OpenAI–Hugging Face Incident
	20	Anti-Patterns
	21	Best Practices and Lessons Learned
VI Future and Conclusions	22	Future Trends
	23	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	24	Reflections on Each Part
	25	Conclusions: A Consolidated Analysis

AI Platform and Security (Book 3)

Part	Chapter	Title
I Foundations	1	Introduction to AI Platform and Security
	2	Usage Modes and the Platform: What Each Mode Demands
	3	Regulatory Requirements as Engineering Constraints
	4	A Reference Architecture for AI in Large Organisations
	5	AI Decision Records, Model Cards and the Architecture Repository
II Data, Models and DevSecMLOps	6	Data Architecture for AI
	7	Model Lifecycle Management: MLOps and LLMOps as Code
	8	Setting Up an Effective DevSecMLOps Loop
	9	Risks and Vulnerabilities Across the DevSecMLOps Loop
	10	Foundation Models, Retrieval and Grounding
	11	Agentic Architectures and Orchestration
	12	Integrating AI into the Enterprise Landscape
III Infrastructure	13	Infrastructure, Compute and European Digital Sovereignty
	14	Cloud AI Services versus On-Premises AI: Different Challenges
	15	Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information
IV Security	16	Security for AI Systems
	17	AI Security Engineering in Practice
	18	When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window
	19	When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent
V Delivery and Operations	20	Evaluation and Testing of AI Systems
	21	Observability, Monitoring and Drift in Production
	22	Cost, Capacity and Sustainability of AI
	23	From Pilot to Production: Scaling AI Across the Organisation
VI Conclusions	24	Nordvik Region and Hansa Mutual: Platform and Security Conclusions
	25	Conclusions: Building and Securing AI Platforms

AI Red Team (Book 4)

Part	Chapter	Title
I Foundations	1	Introduction: Putting AI to Work in Cyber Defence
	2	The Threat Landscape When Attackers Use AI
	3	NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations
	4	A Reference Architecture for AI-Enabled Cyber Defence
II Govern	5	Organisational Context and Risk Strategy for AI in Cyber Defence
	6	Roles, Usage Modes and Autonomy Levels: People in Command of Security AI
	7	Policy, Mandate and Rules of Engagement
	8	Oversight and AI Supply Chain Risk
III Identify	9	Asset Management for an Estate That Includes AI
	10	AI-Assisted Threat Modelling and Risk Assessment
	11	Vulnerability Discovery and Exposure Management at Machine Speed
	12	Adversary Emulation and Continuous Red Teaming with AI
	13	Red Teaming AI Systems and Agents
IV Protect	14	Identity, Authentication and Access for People, Agents and Machines
	15	Awareness and Training: Resilience to AI-Generated Deception
	16	Data and Platform Security with and for AI
	17	Technology Infrastructure Resilience Against Machine-Speed Attacks
V Detect	18	The AI-Assisted Security Operations Centre
	19	Detection Engineering, Threat Intelligence and Deception as Code
VI Respond	20	Incident Management and Analysis with AI
	21	Incident Reporting, Communication and Mitigation
VII Recover	22	Recovery Plan Execution with AI: From Incident to Restored Operations
	23	Recovering AI Systems and Security AI
	24	Proactive Recovery: Recoverability, Rehearsal and Communication
VIII Verification, Improvement and Conclusions	25	Security Chaos Engineering with AI: Verifying Security Capabilities Continuously
	26	Purple Teaming, Measurement and Continuous Improvement
	27	Nordvik Region and Hansa Mutual: Cyber Defence Conclusions
	28	Conclusions: AI as an Active Part of Cyber Defence

AI Threat (Book 5)

Part	Chapter	Title
I The Question	1	Introduction: Are the Dystopias Coming True?
	2	A Century of Machine Dystopias: What Science Fiction Actually Warned About
	3	The Voices of Alarm and Calm: Who Is Warning, About What, and Why Now
	4	Weighing the Evidence and Disagreeing Well
	5	What AI Can and Cannot Do in 2026
II The Human Mind	6	Are We Getting Dumber? Cognitive Offloading and Critical Thinking
	7	Learning Without Struggle: Education, Children and Skill Formation
	8	Persuasion, Sycophancy and Manipulation
	9	Artificial Companions, Loneliness and Mental Health
III Society and Truth	10	The End of Truth? Synthetic Content and the Information Ecosystem
	11	The Automated State: When Public Authorities Got It Wrong
	12	Discrimination at Scale: Bias in Automated Judgement
	13	Surveillance, Profiling and the Erosion of Privacy
	14	Work, Skills and the Ironies of Automation
	15	Inequality and the Concentration of Power
	16	Culture, Creativity and the Homogenisation of Thought
	17	The Physical Cost: Energy, Water and Materials
IV Humans Wielding Machines	18	Cyber Offence at Machine Speed
	19	Biological and Chemical Uplift: The Hardest Question to Test
	20	Fraud, Impersonation and Influence Operations
	21	Autonomous Weapons and the AI Arms Race
V Machines Beyond Control	22	Specification Gaming and Reward Hacking: Getting Exactly What Was Asked For
	23	Deception, Scheming and Evaluation Awareness: Can We Trust What We Test?
	24	Self-Preservation and Shutdown Resistance: HAL 9000 Under Laboratory Conditions
	25	Agents in the Wild: The Incidents of 2025 and 2026
	26	Gradual Disempowerment and Correlated Failure
	27	Superintelligence, Loss of Control and the End of the World
VI The Response	28	What Europe and the World Have Decided
	29	Frontier Safety Frameworks: What Developers Promise and What It Is Worth
	30	Organisational Defences: Containment, Evidence and Decision Rights
	31	Staying Capable: What Individuals, Families and Schools Can Do
	32	The AI Threat Register: Governing Scenarios as Code
VII The Verdict	33	Nordvik Region and Hansa Mutual: Threat Conclusions
	34	What Going Well Looks Like
	35	Conclusions: Is There Anything in It?

The Transformed Security Architect (Book 6)

Part	Chapter	Title
I The Role in Question	1	Introduction: The Security Architect Transformed
	2	What the Security Architect Did: The Role Before the Transformation
	3	Four Shifts: Code, Boundaries, Machine Speed and the AI Team
	4	The Transformed Role Defined: Mandate, Accountabilities and Decision Rights
II The Craft	5	Security Architecture as Code: From Documents to Executable Design
	6	Threat Modelling Transformed: Continuous, Generated and AI-Assisted
	7	Designing Boundaries: Zero Trust and Containment for People, Agents and Machines
	8	Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority
	9	The Control Catalogue, Evidence and Assurance as the Architect's Artefacts
	10	Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design
	11	Resilience and Recovery by Design: The Architect's Share of Recoverability
III The Architect's AI Team	12	The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3
	13	An AI Agent Team for Security Architecture: Skills, Mandates and Containment
	14	Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI
	15	Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can
IV The Role in the Organisation	16	The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams
	17	Design Authority, Decision Forums and Gates Instead of Meetings
	18	Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability
	19	Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers
	20	Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes
V Competence and Career	21	Competences of the Transformed Security Architect: A Framework
	22	Learning Paths, Certification, Hiring and Upskilling
	23	The Future of the Role: Will There Be a Security Architect in 2036?
VI Experience and Conclusions	24	Case Studies and Anti-Patterns
	25	A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual
	26	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	27	Conclusions: The Transformed Security Architect

AI Boss (Book 7)

Part	Chapter	Title
I The Question	1	Introduction: Who Is the Boss?
	2	What a Manager Does: Five Management Functions and Who Performs Them
	3	From Scientific Management to Algorithmic Management: A Century of Managing by Measurement
	4	The AI Boss Defined: Management Functions, Degrees of Delegation and Accountability
II The AI Boss Today	5	Platform Work: The Algorithm as Dispatcher
	6	The Warehouse and the Shop Floor: Pace, Rate and Monitoring
	7	Hiring by Machine: Screening, Scoring and Automated Interviews
	8	Performance Scores, Productivity Metrics and Dismissal by Algorithm
	9	Scheduling, Pay and the Allocation of Work
	10	Knowledge Work: The AI Manager Enters the Office
III What It Does to People	11	Autonomy, Dignity and Control: Being Managed by a Machine
	12	Fairness, Bias and the Appeal That Never Comes
	13	Surveillance at Work and the Chilling Effect
	14	Health, Pace and Burnout: Occupational Safety Under Algorithmic Direction
	15	Does It Work? Productivity, Quality and the Evidence for Algorithmic Management
IV Managing Machines	16	The Agent Boss: When the Team Is Software
	17	Orchestrators: AI Managing AI Agents and the Chain of Accountability
	18	The Mixed Team: People and Agents Under the Same Manager
	19	Skill, Judgement and Who Becomes a Manager When AI Does the Managing
	20	Decision Rights in the Management Chain: Who May Direct, Evaluate, Reward and Dismiss
V Europe's Answer	21	The AI Act at Work: Annex III Point 4, Prohibited Practices and the Deployer's Duties
	22	Data Protection and the Platform Work Directive: The Right to a Human Decision
	23	Co-determination: Works Councils, Unions and the Nordic Model Meet the Algorithm
	24	Occupational Safety, Equality Law and the Public Authority as Employer
VI Designing the Accountable AI Boss	25	Management Decisions as Records: Decision Records and the Delegation Register
	26	The Human in the Chair: Oversight That Is Real, Not Rubber-Stamped
	27	Contestability by Design: Explanation, Appeal and Correction
	28	Transparency to the Managed: What Workers Are Told, When and by Whom
	29	The Transformed Manager: Leading People When AI Directs the Work
VII Experience and Verdict	30	A Year With the AI Boss: Nordvik Region and Hansa Mutual
	31	Case Studies and Anti-Patterns
	32	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	33	Conclusions: Who Should Be the Boss?

AI Blue (Book 8)

Part	Chapter	Title
I The Blue Team in Question	1	Introduction: The Blue Team Transformed
	2	What the Blue Team Does: Five Functions, Tiers and the Alert Queue
	3	The Pressure on the Blue Team: Machine-Speed Adversaries, Alert Volume and Scarce Talent
	4	The Transformed Blue Team Defined: Mandate, Functions and Degrees of Delegation
II The Craft	5	Anticipate: Threat Intelligence and Exposure at Machine Speed
	6	Detect: Detection Engineering as Code
	7	Triage Transformed: From Alert Queue to Verified Case
	8	Investigate: Hypotheses, Timelines and Evidence with AI
	9	Threat Hunting Transformed: Hypotheses, Data and Agents
	10	Respond: Playbooks, Bounded Containment and the Stop Path
	11	Learn: Post-Incident Review, Purple Teaming and Detection Debt
III The Blue Team's AI Team	12	The Analyst's Own Use of AI: Querying, Drafting and Summarising in Modes 1 to 3
	13	An AI Agent Team for the SOC: Skills, Mandates and Containment
	14	Verifying What the AI Concludes: Review for Soundness When the Analyst Depends on the AI
	15	Defending the Defenders' AI: Poisoned Telemetry, Hostile Tickets and the SOC as Tier 0
IV The Team in the Organisation	16	Operating Models: In-House, Managed, Hybrid and Sovereign Security Operations
	17	Team Design and Roles: After the Tier-1 Pyramid
	18	Decision Rights and Escalation: Who May Contain, Isolate and Disclose
	19	Regulation as Constraint: NIS 2, DORA, CRA, GDPR, the AI Act and the Reporting Clock
	20	Measuring the Transformed Blue Team: Speed, Coverage and Quality of Judgement
V People and Career	21	The Analyst at Work: Fatigue, On-Call and Being Managed by Metrics
	22	Competences, Training and Exercises: A Framework for the Transformed Blue Team
	23	Keeping the Craft and Making New Analysts: The Apprenticeship Problem
	24	The Future of the Blue Team: Will There Be a SOC in 2036?
VI Experience and Conclusions	25	Case Studies and Anti-Patterns
	26	A Year on the Blue Team: Nordvik Region and Hansa Mutual
	27	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	28	Conclusions: The Blue Team Transformed

AI Purple (Book 9)

Part	Chapter	Title
I The Loop in Question	1	Introduction: The Purple Loop with AI
	2	What the Loop Did Before: Penetration Tests, Red Teams, Tabletops and Purple Sessions
	3	The Pressure on the Loop: Machine-Speed Adversaries, Detection Decay and the Annual Test
	4	The Purple Loop Defined: Five Stages, Evidence and the Independence Principle
II The Stages of the Loop	5	Target: Threat-Informed Scenarios, Risk and Priority Techniques
	6	Rules of Engagement and Safe Emulation: Scope, Blast Radius and the Stop Path
	7	Emulate: Adversary Emulation Plans, Human-Led and AI-Assisted
	8	Emulate Continuously: Breach-and-Attack Simulation, Atomic Tests and Automated Red Teaming
	9	Observe: Telemetry, Detection and Response Compared with Expectation
	10	Improve: From Finding to Change in Detections, Controls, Playbooks and Mandates
	11	Verify: Re-test, Regression and Evidence
III The Loop Meets AI Systems	12	Purple for AI Systems and Agents: Attacks on Models and Detections That Catch Them
	13	Testing the Defenders' AI: SOC Agents, Playbooks and Providers' AI under Emulation
IV The Loop's Own AI	14	An AI Agent Team for the Loop: Skills, Mandates and Containment
	15	Independence: Verifying the Loop When AI Is on Both Sides
	16	Defending the Loop's AI: Scenario Libraries, Findings and Emulation Agents as Tier 0
V The Loop in the Organisation	17	Coverage as a Claim: Technique Maps, Evidence Age and Detection Decay
	18	Measuring the Loop: Cycle Time, Yield, Re-test Pass Rate and the Metrics That Mislead
	19	Operating Models and Team Design: In-House, Contracted, Hybrid and Sovereign Loops
	20	Decision Rights, Authorisation and the White Team
	21	Regulation as Constraint: DORA, TIBER-EU, NIS 2, the AI Act, the GDPR and Employee Rights
	22	Across Boundaries: Suppliers, Managed Providers, Sector Exercises and Authorities
VI People and Career	23	Red and Blue as People: Trust, Incentives, Safety and Wellbeing
	24	Competences, Training and Keeping the Red Craft
	25	The Future of the Loop: Will Red and Blue Be Separate Teams in 2036?
VII Experience and Conclusions	26	Case Studies and Anti-Patterns
	27	A Year in the Loop: Nordvik Region and Hansa Mutual
	28	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	29	Conclusions: The Purple Loop with AI

AI Operations (Book 10)

Part	Chapter	Title
I The Operations in Question	1	Introduction: Operations with AI
	2	What Operations Did Before: Runbooks, ITIL, DevOps, SRE and AIOps
	3	The Pressure on Operations: Complexity, Dependency, Cost and Machine-Speed Change
	4	The Operations Loop Defined: Five Functions, Autonomy Budget and Observer Principle
II The Craft	5	Observe: Telemetry, Observability and Service Level Objectives
	6	Observe with AI: Correlation, Anomaly Detection and Alert Noise
	7	Diagnose: Triage, Root-Cause Analysis and the Incident Assistant
	8	Change: Releases, Infrastructure as Code and AI-Authored Change
	9	Change Safely: Progressive Delivery, Freezes and Blast Radius
	10	Restore: Runbooks, Auto-Remediation and Recovery
	11	Sustain: Capacity, Cost, Energy and Lifecycle
	12	Sustain: Problem Management, Post-Incident Learning and Knowledge
III Operating AI Systems	13	Operating AI Systems: Drift, Model Updates and Provider Change
	14	Incidents Involving AI: Detection, Triage and Reporting
	15	The Economics of AI Operations: Tokens, GPUs, Latency and Energy
IV The Operator's Own AI	16	An AI Agent Team for Operations: Skills, Mandates and Containment
	17	The Observer Principle: Who Watches the Watcher
	18	Defending the Operator's AI: Agents, Credentials and the Control Plane as Tier 0
V Operations in the Organisation	19	Resilience as a Claim: Restore Tests, Game Days and Evidence Age
	20	Measuring Operations: The Four Key Metrics, SLOs, Toil and the Metrics That Mislead
	21	Operating Models: Platform Teams, SRE, Managed Services and Sovereign Operations
	22	Decision Rights, Change Authority and the Incident Commander
	23	Regulation as Constraint: DORA, NIS 2, CER, the AI Act, the GDPR and the Data Act
	24	Across Boundaries: Cloud Providers, Managed Providers, Outages and Exit
VI People and Career	25	Operators as People: On-Call, Toil, Trust and Wellbeing
	26	Competences and Keeping the Operator's Craft
	27	The Future of Operations: Will Anyone Be on Call in 2036?
VII Experience and Conclusions	28	Case Studies and Anti-Patterns
	29	A Year in Operations: Nordvik Region and Hansa Mutual
	30	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	31	Conclusions: Operations with AI

AI Leader (Book 11)

Part	Chapter	Title
I The Leadership Role in Question	1	Introduction: Leadership with AI
	2	What Leaders Did Before: Hierarchy, Management Science, Agile and Servant Leadership
	3	The Pressure on Leaders: Information, Speed, Span and Accountability
	4	The Leadership Loop Defined: Five Functions, Delegation Ladder and Answerability
II The Craft of Leading	5	Orient: Sense-Making, Strategy and Direction
	6	Orient with AI: Briefings, Scenarios and the Consensus Machine
	7	Decide: Decision Quality, Judgement and Decision Records
	8	Decide with AI: Advice, Automation Bias and Delegated Decisions
	9	Organise: Structure, Span of Control and the Middle Layer
	10	Organise Work: Human-Agent Teams, Workflows and Role Redesign
	11	Enable: Developing People, Coaching and the Early-Career Route
	12	Answer: Accountability, Transparency and Legitimacy
III Leadership Roles Across the Organisation	13	The Board and the Management Body: Duties, Oversight and Competence
	14	The Chief Executive and the Executive Team
	15	The Changing C-Suite: CAIO, CIO, CISO, CDO, CHRO, CFO and General Counsel
	16	The Middle Manager: Thinned, Transformed or Indispensable?
	17	The First-Line Leader and the Team Lead
	18	Leaders in the Public Authority: Mandate, Legitimacy and Democratic Accountability
	19	Leading Specialists: Architects, Engineers, Clinicians and Experts
IV Leading Change and Adoption	20	Leading the AI Transformation: Adoption, Value and Evidence
	21	Culture, Trust and Psychological Safety in a Human-Agent Organisation
	22	Leading with Works Councils, Unions and Employees: Co-determination and Dialogue
	23	Leading Through Incidents and Crises with AI
V Regulation, Ethics and Responsibility	24	Regulation as Constraint: The AI Act, DORA, NIS 2, the GDPR, Company Law and Public Law
	25	Ethics, Values and the Leader's Judgement
	26	Sovereignty, Dependency and Strategic Choice
VI The Leader as a Person	27	Competences and Developing the Leader
	28	The Leader's Own Mind: Cognitive Offloading, Power, Loneliness and Wellbeing
	29	The Future of Leadership: Will There Be Fewer Leaders?
VII Experience and Conclusions	30	Case Studies and Anti-Patterns
	31	A Year in Leadership: Nordvik Region and Hansa Mutual
	32	Nordvik Region and Hansa Mutual: Conclusions for Two Organisations
	33	Conclusions: Leadership with AI
Appendices	34	Glossary
	35	Appendix A: Code Examples: Delegation, Decision, Role, Accountability and Mandate Records
		Appendix B: Templates and Tools
	36	References and Sources
	37	About the Author