Book Blueprint and Chapter Briefs

This blueprint records the editorial intent of The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities, Book 6 of The Architecture as Code Series. It is the brief every chapter is written against. The chapter briefs below are generated from scripts/outline_data.py by python3 scripts/generate_outlines.py; edit the data file, not the generated section. The conclusions of the earlier volumes that each chapter builds on are recorded in SERIES_FOUNDATIONS.md (F1 to F70) together with the open questions the book takes up (Q1 to Q12).

Premise

The first five volumes of the series made architecture, governance, the AI platform and cyber defence executable, and examined whether the AI threat is real. Architecture as Code put architecture, policy, risk and evidence into version control; AI Governance made the governance of AI codified, evidenced and proportionate to usage mode; AI Platform and Security built a platform on which every model call and tool call passes a policy point outside the model and containment holds whatever anyone intends; AI Red Team made AI an active, governed part of cyber defence at autonomy levels matched to reversibility; and AI Threat found that several of the mechanisms fiction dramatised, agents exceeding their mandates, correlated control failure and the erosion of human skill, are now observable.

All of these conclusions depend on the same person: the security architect, who designs the boundaries, the policy points, the identity model, the containment, the evidence chain and the stop paths. In the platform's code the security architect is already a named owner of boundaries rather than a reviewer of documents. None of the volumes has described what has happened to that person. This book does.

It asks what the security architect role has become, and must become, in European enterprises and public authorities when architecture is code, adversaries and insiders act in minutes, agents act in production with identities of their own, and AI drafts much of the architect's own work. It answers through the craft (Part II), the architect's own AI team (Part III), the role's place in the organisation and under European regulation (Part IV), and competence and career (Part V), framed by Part I and concluded by Part VI.

Thesis

The thesis, stated in Chapter 1 and tested in Chapters 2 to 26: the security architect role is being transformed, not abolished. It moves from author of documents and reviewer at gates to designer of executable boundaries and decision rights; from periodic review to continuous verification at machine speed; and from sole expert to the accountable conductor of an AI team whose proposals the architect must be able to verify. What remains scarce, and therefore defines the role, is accountable human judgement: the ability to decide what a boundary should be, to verify that code and AI output are sound, and to answer for the decision to a board, a supervisor or a court. The architect who cannot still do the craft without AI cannot verify AI, and so the transformed role keeps the craft deliberately.

Chapter 27 finds that the chapters support the thesis and qualifies it in three places, which every chapter's framing should respect: the scarce resource is also a throughput constraint, because judgement must be exercised at the volume the estate and the agents now produce; the transformation is uneven, with Shifts 1 and 3 observable, Shift 2 observable in leading organisations and expected more widely, and Shift 4 observable in early adopters while its effect on decision quality is not established; and the transformation is a condition to maintain, not a law of development, because the role can be lost by a sequence of reasonable delegations rather than by a decision (Chapter 23).

Audience

Security architects and those who want to become one
Chief information security officers and heads of security architecture
Enterprise, solution and AI architects
Platform and product engineering leads
HR, competence and hiring leads
Procurement and programme leaders in public authorities
Risk, compliance and internal-audit functions that assure architecture

Boundaries

About the role, not a repeat of the earlier volumes. Platform construction, AI governance, AI security, AI-enabled defence and the AI threat are summarised where the role needs them and referenced by chapter (see SERIES_FOUNDATIONS.md). This book refers to Books 1 to 5 and never to a later volume.
Defensive only. Adversary behaviour is described by technique, at the level needed to design controls, tests and boundaries. The book contains no exploit code, payloads, jailbreak or prompt-injection strings, or step-by-step intrusion instructions.
Europe first. The AI Act, NIS 2, DORA, the Cyber Resilience Act, the GDPR, ENISA's European Cybersecurity Skills Framework, public procurement law, works councils and digital sovereignty are the setting. Legal content is attributed to the instrument and article and framed as architectural implications, not legal advice.
Not career advice in general. Competence, learning and hiring are treated as organisational design, through frameworks, records and decision rights that can be reviewed, not as personal coaching.
No anthropomorphism. Models and agents propose, draft and act within mandates; they do not intend, understand or decide in the human sense.
Findings and judgement kept apart. Every outlook is labelled observable, expected or speculation, and the author's own projections are kept to Chapters 23 and 27 and labelled.
No science-fiction tropes or evidence ladder. Those belong to AI Threat; the equivalent red threads here are the four shifts and the observable, expected or speculation labels.

Red threads

The four shifts (Chapter 3), named exactly so in every chapter: 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. Every chapter in Parts II to V states which shifts it concerns, and Parts I and VI frame and conclude all four.
How the shifts depend on one another and fail when overdone (Chapter 3): code enables boundaries, boundaries enable speed, speed creates the volume that requires the AI team, and the AI team's output can be verified only through code. Each shift has a failure mode that looks like success from inside: code without judgement, boundaries without owners, speed without reversibility, and an AI team that approves itself. Chapter 24 names the anti-patterns of a practice that has not made a shift, Chapter 25 shows the order of adoption mattering over a year, and Chapter 27 resolves the tensions between the conclusions.
The artefact set, all under version control: the role charter roles/security-architect.yaml (ROLE-*; Chapter 4), the control catalogue (CTRL-*; Chapter 9) with evidence manifests and expiring exceptions, containment profiles and permission manifests (Chapter 7), the mandate manifest for the architect's own agents (MND-*; Chapter 13), the competence framework and competence records (CMP-*; Chapter 21), AI Decision Records in this book's range AIDR-0500 to AIDR-0599, and Architecture Decision Records.
Usage modes and autonomy levels: Mode 0 Ambient AI to Mode 5 Autonomous production agents (AI Governance, Chapter 2; AI Platform and Security, Chapter 2), and Level 0 Advisory to Level 4 Autonomous (AI Red Team, Chapter 6). The book separates the architect's own use of AI in Modes 1 to 3, with the architect's identity, from the agents the architect designs boundaries for, which act with identities of their own. Level 4 is never used for irreversible actions.
Observable, expected, speculation (AI Governance, Chapter 22): every outlook is labelled, and Chapter 23 keeps a horizon register for the role itself.
The two organisations (EXAMPLE_ORGANISATIONS.md, security architecture profile): Nordvik Region, whose single security architect holds boundaries mostly through procurement and is asked for a role charter and competence plan before the 2027 budget (AIDR-0500, 2026-10-12; records AIDR-0500 to AIDR-0549), and Hansa Mutual, whose group security architecture team of six in Hamburg must show the executive board how architecture decisions will keep pace with agents that act in production (AIDR-0550, 2026-10-29; records AIDR-0550 to AIDR-0599). Every narrative chapter has a ### Nordvik Region and Hansa Mutual subsection before its summary. The shared timeline, against which the subsections are checked, is: shift assessments in November 2026 (AIDR-0509, AIDR-0551); Hansa's response to rubber-stamping, AIDR-0556, dated 2026-11-04; Nordvik's charter ROLE-NR-SA-01 and Hansa's ROLE-HM-* 2.0.0 in effect from January 2027 (Hansa's outside Germany after consultation); Hansa's tier 1 gates in shadow from December 2026 to February 2027 and live on 1 March 2027 (AIDR-0558); first stop drills in March 2027 (Nordvik 26 minutes against 15, Hansa 17 against five, with task-scoped tokens cut from 15 to five minutes) and re-drills within budget (Hansa four minutes in June, Nordvik 11 minutes in October); Nordvik's catalogue at 10, 24, 38 and 52 entries; MND-NR-01 version 1 superseded by version 2 (AIDR-0503) and still to be aligned to the charter's Level 1 Assisted ceiling; MND-HM-01 version 3 expiring on 2027-10-31 and replaced by version 4 (AIDR-0592); the Polish service centre post vacant from January 2027 and filled on 1 June 2027 (AIDR-0584); the year in Chapter 25 running from December 2026 to November 2027; and the 24-month plans in Chapter 26 running from October 2027 to September 2029 (AIDR-0507, AIDR-0561).
The open questions Q1 to Q12 (SERIES_FOUNDATIONS.md), raised in Chapter 1 through Q5 and answered in the chapters listed in Chapter 27, Table 27.2: eight answered, three answered in part (Q3, Q8, Q10) and Q12 open by nature.

Status

The book was started on 2026-11-06 from the engine, the table of contents (scripts/toc_definition.py), these briefs, SERIES_FOUNDATIONS.md and the security architecture profiles of the two organisations. All 27 numbered chapters, the glossary and Appendix A now exist as first drafts, and the status of each chapter is recorded in its brief below (outline, draft, complete). The drafts are under chapter-level review for sources and consistency and under a book-level review of the red thread, whose findings and the follow-up edits it recommends for the chapter files are recorded in REVIEW_RED_THREAD.md in the repository root. A chapter moves to complete when those edits are made and its tests pass.

Length and weighting

Numbered narrative chapters are 3,600 to 5,500 words of prose, as in the other volumes. Chapters 3, 4, 7, 13, 14 and 21 are expected to be the longest, because they carry the frame of the four shifts, the role charter, the boundary as the architect's main product, the agent team, the verification of AI proposals and the competence framework on which the rest of the book depends. Chapters 25 and 26 are narrative and conclusion chapters and may be shorter. Any weighting decision taken during drafting is recorded in the brief.

Chapter briefs

Part I: The Role in Question

Chapter 1: Introduction: The Security Architect Transformed

File: 01_introduction.md
Status: draft
Purpose: Introduce the book on its own terms: the five earlier volumes made architecture, governance, the AI platform and cyber defence executable and examined the AI threat, and every one of their conclusions rests on a person none of them described, the security architect who designs the boundaries, policy points, identity model, evidence chain and stop paths. State the working thesis that the role is transformed rather than abolished, name the four shifts that carry the book, and set out what remains scarce: accountable human judgement backed by a craft the architect can still practise without AI. Explain why the question became urgent in autumn 2026 and why it is a European organisational question rather than a career-advice question.
Builds on: F70, F35, F42, F23, F28, F48, Q5, Q12
Shifts: 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
Sections: The question; The person the series kept meeting; Transformed, not abolished; Four shifts in brief; What remains scarce; Why Europe, and why now; Rules of the book; Two organisations; How to read this book
Worked examples: The commission from Nordvik's regional director to the CISO, recorded as AIDR-0500, and the Hansa executive board's request to the group CISO, recorded as AIDR-0550
Nordvik Region and Hansa Mutual: Nordvik's regional director asks the CISO for a role charter and a competence plan for the security architect before the 2027 budget, and the commission is recorded as AIDR-0500. Hansa's executive board asks the group CISO to show how architecture decisions will keep pace with the claims-triage agent, the IT-operations agent and the SOC investigation agent, recorded as AIDR-0550. The chapter introduces the single post-holder in Nordvik's security unit and the six-person group team in Hamburg, and the question each organisation will answer by Chapter 26.
Usage modes and autonomy levels: The chapter introduces the usage modes and autonomy levels as the series uses them and signals the book's distinction between the architect's own use of AI with a person's identity (Modes 1 to 3) and the agents the architect designs boundaries for (Mode 5), which act with identities and permissions of their own.
Observable, expected, speculation: The incidents and the regulatory duties that prompt the question are observable; the claim that the role is transformed rather than abolished is the book's thesis, tested in the chapters and judged in Chapters 23 and 27.
Figure: The security architect at the centre of the five earlier volumes' conclusions, with the four shifts radiating to the parts of the book that treat them

Chapter 2: What the Security Architect Did: The Role Before the Transformation

File: 02_the_role_before.md
Status: draft
Purpose: Describe fairly what the security architect did before the transformation and why it was valuable: risk-based security management under ISO/IEC 27001, business-driven layered design with SABSA, security integrated into enterprise architecture with TOGAF, security review boards, reference architectures published as documents, and the architect as reviewer and signatory. Explain the conditions under which those methods worked, quarterly releases, perimeter networks, a small number of systems and human adversaries working at human speed, and show precisely where they stopped scaling. Separate the reputation of the department of no from the legitimate reasons gates existed, so that the later chapters keep what was right and replace only what no longer works.
Builds on: F6, F8, F9, F22, F29, F41, F42, Q5
Shifts: 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
Sections: Where the role came from; Risk-based security management; Layered, business-driven design; Review boards and sign-off; Reference architectures as documents; The department of no; What did not scale; What the transformed role inherits
Practical guides: Auditing an inherited security architecture practice: what to keep, codify, delegate or retire
Worked examples: Nordvik's 2024 security reference architecture document assessed section by section against the AI estate it predates
Nordvik Region and Hansa Mutual: Nordvik's post was created in 2025 from a security coordinator post whose work was policy documents, the annual procured penetration test and supplier questionnaires, and its 2024 reference architecture lives beside, not inside, the AI platform repository. Hansa's team inherited a fortnightly architecture review board and a control catalogue of about 180 controls with attested evidence and UK and Swiss mappings kept outside it. The chapter uses both starting points to show that the inherited practice was rational for its conditions, and that each organisation keeps different parts of it.
Usage modes and autonomy levels: Before the transformation the security architect met AI mostly as Mode 0 features in procured products and occasionally as Mode 4 applications under review; the inherited methods assumed that every system acted only through people's identities, an assumption Mode 5 agents break.
Observable, expected, speculation: The history and the limits of the inherited methods are observable; the claim that gate-based review cannot keep pace with agents is expected and is tested in Chapters 10 and 17.
Figure: A timeline of the security architect's inherited methods, from ISO/IEC 27001 and SABSA to review boards and reference documents, with the conditions each assumed and where each stopped scaling

Chapter 3: Four Shifts: Code, Boundaries, Machine Speed and the AI Team

File: 03_four_shifts.md
Status: draft
Purpose: Define the four shifts precisely, as the frame on which every later chapter rests: Shift 1 from documents to code, Shift 2 from gatekeeper to boundary designer, Shift 3 from periodic to continuous at machine speed, and Shift 4 from sole author to conductor of an AI team. For each shift, give the evidence that it is happening from the earlier volumes and the external literature, what it changes in the architect's daily work, what it does not change, and the failure mode when it is taken too far. Show how the shifts interact and depend on one another, and introduce the artefact set through which the book makes each shift concrete.
Builds on: F3, F4, F12, F35, F36, F45, F49, F59, F66, Q1
Shifts: 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
Sections: Why four shifts; 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; How the shifts depend on one another; When the shifts go too far; The artefact set; Reading the rest of the book through the shifts
Practical guides: Locating an organisation's security architecture practice on each of the four shifts
Worked examples: A shift assessment recorded as code for both organisations, with evidence and gaps per shift
Nordvik Region and Hansa Mutual: The chapter assesses both organisations on each shift. Nordvik is early on Shifts 1 and 2 (documents, tender annexes, one pre-production checklist and one threat model as code), depends on suppliers and the managed security service provider for Shift 3, and has a single person beginning Shift 4 with MND-NR-01. Hansa is far along Shift 1 with a Structurizr workspace and policy as code, is blocked on Shift 2 by the fortnightly review board, and is already in Shift 4 with an agent team under MND-HM-01 whose review quality nobody yet measures.
Usage modes and autonomy levels: Shift 4 is defined across the modes: the architect's own work in Modes 1 to 3 with a person's identity, and the agent team and evidence collector that act with identities of their own, at autonomy levels set per action from reversibility. Shifts 2 and 3 are driven above all by Mode 5 agents in the estate, which turn the insider into a machine that acts in minutes.
Observable, expected, speculation: Shifts 1 and 3 are observable in the evidence; Shift 2 is observable in leading organisations and expected more widely; Shift 4 is observable in early adopters, while its effect on the quality of architecture decisions is not yet established.
Figure: The four shifts as arrows from the inherited role to the transformed role, each annotated with its main artefact, its evidence and its failure mode when taken too far

Chapter 4: The Transformed Role Defined: Mandate, Accountabilities and Decision Rights

File: 04_role_charter.md
Status: draft
Purpose: Define the transformed role as code: a role charter in roles/security-architect.yaml that states the mandate, accountabilities, decision rights, escalation paths, the artefacts the role owns and what it explicitly does not do. Distinguish accountability for a boundary from authorship of every artefact, and show how the charter relates to AI Act Article 4 literacy, the management-body accountability of NIS 2 Articles 20 and 21 and DORA Article 5. Make the charter the reference for every later chapter, so that the role can be reviewed, versioned and changed by pull request like any other control.
Builds on: F13, F18, F23, F25, F51, F63, Q5, Q6, Q11
Shifts: 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
Sections: Why a charter, and why as code; Mandate; Accountabilities; Decision rights; What the role does not do; The charter and the management body; Accountability for what agents propose; Maintaining the charter
Practical guides: Writing a security architect role charter in five steps; Testing a charter against ten decisions from the last year
Worked examples: roles/security-architect.yaml for Nordvik Region (ROLE-NR-SA-01) and for Hansa Mutual's head of security architecture and domain architects (ROLE-HM-*)
Nordvik Region and Hansa Mutual: Nordvik's charter ROLE-NR-SA-01 answers AIDR-0500 and gives the single post-holder, for the first time, written decision rights over the stop-path and egress requirements in tender annexes, and an escalation path to the CISO and the regional executive committee. Hansa's charters ROLE-HM-* set out the head of security architecture, the three domain architects and the two embedded architects, separate the AI domain architect's rights from the AI architects', and state which decisions the review board delegates to pipelines. Because the Hansa charters change what review agents may record about architects, the change goes to the works councils in Germany and the Netherlands and to union consultation in Sweden before it takes effect.
Usage modes and autonomy levels: The charter states the role's decision rights over each mode: approval of Mode 3 tools for architecture work, design authority over the containment of Mode 5 agents, and the autonomy level at which the architect's own agents may act. It never delegates accountability to Level 3 or Level 4 actions; it moves human approval from the action to the playbook and the record.
Observable, expected, speculation: Management-body accountability under NIS 2 and DORA is observable law; the extension of named personal responsibility to architects is not law and is treated as an expected organisational practice, not a legal duty.
Figure: The role charter as a decision-rights map: what the security architect decides, recommends, vetoes and escalates, by decision tier and time limit

Part II: The Craft

Chapter 5: Security Architecture as Code: From Documents to Executable Design

File: 05_security_architecture_as_code.md
Status: draft
Purpose: Show how security architecture becomes executable design: the architecture model kept as code (C4 and Structurizr, with FINOS CALM as an emerging alternative), security properties attached to model elements, policy as code in OPA/Rego enforcing those properties, and the pull request as the unit of architectural change. Explain how a change to the model triggers the right reviews, tests and policies, and how decision records and the model stay in step. Keep the control catalogue and evidence for Chapter 9 and generated threat models for Chapter 6; this chapter owns the model, the policy and the change workflow.
Builds on: F3, F6, F8, F14, F37, F38, F41, F42
Shifts: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer
Sections: From the reference document to the model; Modelling the estate as code; Policy as code for architecture; Assure once, comply many, at design time; The pull request as the unit of change; Decision records beside the code; Drift between model and estate; What remains a document
Practical guides: Moving a security reference architecture document into a model and a policy set
Worked examples: A Structurizr fragment with trust-zone properties and the Rego rule that fails a pull request when a model element crosses a zone without a policy point, for Hansa Mutual; The code-ownership file that routes changes to review triggers to Nordvik's security architect
Nordvik Region and Hansa Mutual: Nordvik moves the 2024 reference architecture into the AI platform repository as a small model and a handful of policies, starting from the pre-production security checklist that is already code, and records the decision as AIDR-0501. Hansa already has a Structurizr workspace and policy as code with market overlays, so its work is to attach security properties to model elements, add review triggers for its domain architects and bring the UK and Swiss mappings into the same repository. For Nordvik the hard part is that suppliers' systems appear in the model only as black boxes with contractual properties; for Hansa it is that the review board still reviews documents generated beside the model.
Usage modes and autonomy levels: The architect's Mode 3 tools can propose model and policy changes as pull requests, but they act with the architect's identity and their changes pass the same review triggers as anyone else's; Mode 5 agents in the estate appear in the model as actors with identities, permissions and trust zones of their own.
Observable, expected, speculation: Architecture models and policy as code are observable practice; generating most security architecture documentation from the model is expected in organisations already working this way.
Figure: The architecture repository as the single source: the model, the policies and the decision records, with a pull request flowing through review triggers, policy checks and drift comparison

Chapter 6: Threat Modelling Transformed: Continuous, Generated and AI-Assisted

File: 06_threat_modelling.md
Status: draft
Purpose: Show how threat modelling changes from a workshop that produces a document to a continuous practice in which threat models are generated from the architecture repository, expressed in the shared vocabulary of STRIDE, MITRE ATT&CK and MITRE ATLAS, assisted by AI and verified by a named reviewer. Treat the threat model as a versioned artefact that fails the pipeline when a threat has no control or a control has no owner. Explain what AI-assisted threat modelling adds and how its candidate threats are verified, building on AI Red Team, Chapter 10, while leaving general review techniques to Chapter 14.
Builds on: F1, F7, F40, F41, F54, F55, Q3
Shifts: Shift 1, from documents to code; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team
Sections: What threat modelling was for; A shared vocabulary; Threat models generated from the architecture; Modelling AI and agentic systems; AI-assisted threat modelling; Deciding candidate threats; The threat model that fails the pipeline; From threat model to test
Practical guides: Introducing generated threat models for one system in eight weeks
Worked examples: A threat model as code for Hansa Mutual's claims-triage agent, regenerated from the Structurizr workspace, with AI-proposed candidates and reviewer decisions; The pipeline rule that fails a merge when a threat has no control
Nordvik Region and Hansa Mutual: Nordvik extends the threat model of the citizen-service assistant, already code, to the benefits-triage system, where the supplier TriageSoft owns much of the design and the threat model records the contractual controls the Region must verify. Hansa's AI domain architect generates threat models from the workspace for every system that touches the claims-triage agent, and the threat-modeller agent of the review team proposes candidates that a named architect decides. Hansa's threat models link to the control catalogue that Chapter 9 completes and to the control-to-threat coverage matrix of AI Threat, Chapter 30.
Usage modes and autonomy levels: AI assistance in threat modelling stays at Level 1 Assisted: the model proposes candidates and no AI accepts a threat, a risk or an exception. The threats to model change most with the mode of the system under review, because a Mode 5 agent with its own identity and tools has a different attack surface from a Mode 2 assistant acting for a person.
Observable, expected, speculation: Generated and AI-assisted threat models are observable in early adopters; evidence on the quality of AI-proposed threats compared with expert workshops is limited and is treated as an open question.
Figure: The threat-modelling loop: architecture change, generated threat model, AI-proposed candidates, reviewer decision, control mapping, pipeline gate and attack case

Chapter 7: Designing Boundaries: Zero Trust and Containment for People, Agents and Machines

File: 07_boundaries_and_containment.md
Status: draft
Purpose: Make the boundary the security architect's main product. Explain zero trust as NIST SP 800-207 defines it and as BeyondCorp and CISA's maturity model put it into practice, then extend it to agents: policy decision points outside the model, default-deny egress, task-scoped credentials, control artefacts outside the agent's reach, budgets and blast-radius limits, and containment that does not depend on intent. Show how the architect designs a boundary, expresses it as a containment profile and a permission manifest, and verifies that it holds without the cooperation of what it contains. Leave identity mechanics to Chapter 8 and the timing of detection and stopping to Chapter 10; this chapter owns where the boundary is and what it contains.
Builds on: F19, F27, F34, F39, F45, F54, F62, F67
Shifts: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer
Sections: The boundary as the architect's product; Zero trust, from principle to estate; Policy decision points outside the model; Default-deny egress and correlated controls; Containment that does not depend on intent; Blast radius as a design parameter; Containment profiles and permission manifests; Verifying that a boundary holds
Practical guides: Designing a containment profile for a new agent in six questions; Reviewing a boundary for correlated controls
Worked examples: The containment profile and permission manifest for Hansa Mutual's IT-operations agent, with its egress allow-list and blast-radius limits; A tender annex for Nordvik Region requiring a supplier boundary with a policy point outside the model and a verifiable stop path
Nordvik Region and Hansa Mutual: Nordvik holds most boundaries through contracts: the architect writes the policy-point, egress and stop-path requirements into tender annexes for TriageSoft and the staff-assistant provider, and designs the boundaries the platform team runs on the reserved capacity and the AI gateway. Hansa's platform domain architect owns the containment profiles of the claims-triage agent and the IT-operations agent, and the July 2026 incident prompts a review of every egress path that is also a package mirror, recorded as AIDR-0552. Both organisations classify their boundary controls as verified, declared or failed for the first time.
Usage modes and autonomy levels: Boundaries matter most for Mode 5 agents with their own identities, where only containment sets a ceiling on consequences; for Modes 1 to 3 the boundary is around the person's identity and the data the tool can reach. Autonomy above Level 2 Supervised is acceptable only where a policy decision point outside the model enforces the playbook.
Observable, expected, speculation: Agents exceeding their mandates and correlated control failures are observable in the incidents of 2025 and 2026; whether today's containment patterns will hold against more capable agents is expected to be tested continuously and is not assumed.
Figure: Nested boundaries around people, workloads and agents, with the policy decision point outside the model, default-deny egress, task-scoped credentials and the stop path drawn outside what it stops

Chapter 8: Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority

File: 08_identity_for_non_human_actors.md
Status: draft
Purpose: Treat identity as the architect's first line of design for non-human actors: workload identity with SPIFFE, agents acting with their own identity versus with a person's, delegated authority and on-behalf-of tokens under OAuth 2.0 token exchange, the lifecycle of machine identities, and approvals that resist synthetic media. Show how every machine identity gets an owner, operators and an authority who are named people, and how the identity model makes accountability traceable from an agent's action back to a decision. Keep network and egress boundaries in Chapter 7; this chapter owns who an actor is, on whose behalf it acts and how that is proved.
Builds on: F24, F28, F36, F49, F51, F56
Shifts: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed
Sections: Non-human actors outnumber people; Workload identity; Agents with their own identity or with a person's; Delegated authority; Owners, operators and authorities; Approvals that resist synthetic media; The machine identity lifecycle; Identity as evidence
Practical guides: Registering an agent identity: owner, operators, authority, scope, lifetime and revocation
Worked examples: The identity record and delegated-token policy for Hansa Mutual's Mode 5 evidence-collection agent, read-only and acting at Level 3 Bounded only to refresh evidence links; Nordvik Region's call-back rule for approvals of changes to the benefits-triage system
Nordvik Region and Hansa Mutual: Nordvik has no Mode 5 agents, so its identity work is about the platform team's workload identities on the reserved capacity, the identity the architect's Mode 3 tool acts with under MND-NR-01, and approval rules for supplier changes that resist synthetic media. Hansa's identity domain architect designs the identities of the claims-triage agent, the IT-operations agent, the SOC investigation agent and the evidence-collection agent, each with a named owner, operators and an authority. The July 2026 incident's shared credential leads Hansa to retire shared credentials in its own estate, recorded as AIDR-0553.
Usage modes and autonomy levels: In Modes 1 to 3 the AI acts with the person's identity and the person answers for it; a Mode 5 agent acts with an identity of its own and becomes a privileged machine insider. The autonomy level governs what a delegated token may authorise without fresh human approval, and Level 4 tokens are never issued for irreversible actions.
Observable, expected, speculation: Workload identity and token exchange are observable, mature practice; standards for identifying agents and expressing their delegated authority across organisations are emerging and expected to change.
Figure: An agent's action traced through its workload identity, the delegated token, the policy decision point and the log to the named owner, operator and authority

Chapter 9: The Control Catalogue, Evidence and Assurance as the Architect's Artefacts

File: 09_controls_evidence_assurance.md
Status: draft
Purpose: Present the control catalogue, the evidence manifest and assurance as artefacts the security architect owns: controls written once with identifiers such as CTRL-AGT-002, each with an owner, a configuration, a test and a mapping to ISO/IEC 27001 Annex A, NIS 2, DORA and the AI Act. Show evidence as a by-product of normal operation, collected by machine and signed, rather than attestation assembled in audit season, and the classification of every control as verified, declared or failed. Describe how the architect works with internal and external auditors when the evidence is code, without turning this chapter into a reading of the regulations, which belongs to Chapter 18.
Builds on: F2, F3, F4, F20, F41, F60, F62, F64
Shifts: Shift 1, from documents to code; Shift 3, from periodic to continuous, at machine speed
Sections: Why the catalogue is the architect's artefact; Anatomy of a control entry; Mapping once to many obligations; Evidence as a by-product; Verified, declared and failed; Coverage against threats; The architect and the auditor; Keeping the catalogue alive
Practical guides: Turning a spreadsheet of Annex A controls into a catalogue as code; Classifying controls as verified, declared or failed
Worked examples: A control entry CTRL-AGT-002 with mappings, evidence source and test, and the evidence manifest that references it, for Hansa Mutual; The first ten entries of Nordvik Region's catalogue, migrated from the management-review spreadsheet
Nordvik Region and Hansa Mutual: Nordvik starts its catalogue from the spreadsheet mapped to ISO/IEC 27001 Annex A for the annual management review, and its first entries are the controls it must verify in suppliers' systems, recorded as AIDR-0502. Hansa completes a catalogue of about 180 controls by bringing the UK and Swiss mappings into it, replacing attested evidence with generated evidence where it can, and letting the Mode 5 evidence-collection agent refresh evidence links at Level 3 Bounded. Internal audit at Hansa is invited to sample the agent's work rather than repeat it.
Usage modes and autonomy levels: A Mode 5 evidence collector can refresh links and collect telemetry at Level 3 Bounded because the actions are read-only and reversible; classifying a control as verified, accepting an exception or changing a mapping stays with named people at Level 1 or Level 2.
Observable, expected, speculation: Evidence as a by-product and catalogue-to-obligation mapping are observable in leading organisations; supervisors' acceptance of machine-generated evidence in place of attestation is expected but uneven across regimes.
Figure: The control catalogue at the centre, joined to threats, configurations, evidence manifests and obligations, with each control classified as verified, declared or failed

Chapter 10: Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design

File: 10_machine_speed_design.md
Status: draft
Purpose: Design for time. Show that the window between disclosure and exploitation has collapsed and that agents act in minutes, and turn that into design properties the architect owns: patch velocity as a service level informed by EPSS, the CISA KEV catalogue and the European Vulnerability Database; detection and response designed into the system rather than added; delegated patch and containment decisions written in advance; canaries and honeytokens as architecture; and a stop path outside the system it stops that can be exercised within the time the threat allows. Leave boundary placement to Chapter 7 and recovery to Chapter 11; this chapter owns how fast the estate can notice, decide and act.
Builds on: F5, F19, F29, F35, F36, F63, Q1, Q4
Shifts: Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed
Sections: The collapsing window; Patch velocity as a service level; Designing for patchability; Decisions delegated in advance; Detection designed in; Canaries and honeytokens as architecture; The stop path as a timed property; Machine-speed properties in management reporting
Practical guides: Setting a patch-velocity service level from EPSS, KEV and exposure; Timing a stop path end to end
Worked examples: A patch-velocity policy as code with delegated decisions for known-exploited vulnerabilities at Hansa Mutual; Contractual machine-speed requirements for Nordvik Region's managed security service provider under framework agreement NR-2025-044
Nordvik Region and Hansa Mutual: Nordvik cannot build machine-speed properties itself, so its architect specifies them: patch service levels for suppliers, detection requirements for the managed security service provider in place of supplier-default rules, and a stop path for the benefits-triage system that the Region, not TriageSoft, can exercise. Hansa replaces the change advisory board's role for known-exploited vulnerabilities with a delegated playbook recorded as AIDR-0554, designs canaries into the IT-operations agent's estate and reports patch velocity to the executive board. Both organisations time their stop paths and find them slower than the threat allows.
Usage modes and autonomy levels: Delegated patch and containment actions may run at Level 3 Bounded where they are reversible and enforced by a policy decision point; isolation of production systems and other actions with wide blast radius stay at Level 2 Supervised. Mode 5 agents shorten the time in which an insider can cause harm, which is why the stop path must be timed against them.
Observable, expected, speculation: The shrinking exploitation window and AI-assisted vulnerability discovery are observable; patch velocity becoming a supervised metric is expected, signalled by supervisors' letters; exploitation in minutes as the normal case is treated as expected, not certain.
Figure: A timeline from disclosure to exploitation set against the organisation's notice, decide and act times, with patch velocity, detection, delegated decisions and the stop path marked as design properties

File: 11_resilience_by_design.md
Status: draft
Purpose: Define the architect's share of recoverability: recoverability as an architectural property designed in from the start, redeployment from known-good definitions, recovery of AI systems and of the security AI itself, and rehearsal as the only proof that recovery works. Show security chaos engineering as the verification of security and recovery properties under defined safety boundaries, how DORA and NIS 2 resilience requirements become design constraints, and how delegation that has eroded the documented fallback is detected. Separate the architect's share, design, verification and requirements, from the operators' share of running recovery.
Builds on: F5, F46, F47, F58, F59, F62, F69
Shifts: Shift 1, from documents to code; Shift 3, from periodic to continuous, at machine speed
Sections: Recoverability as a property; Known-good definitions; Recovering AI systems; Degraded modes and the fallback that eroded; Security chaos engineering as verification; Resilience obligations as design constraints; Recoverability in management reporting
Practical guides: Designing a first security chaos experiment with its safety boundaries; Running a reversibility test on a delegation
Worked examples: A recovery definition for Hansa Mutual's claims-triage agent, with a chaos experiment that verifies redeployment and the degraded mode; Nordvik Region's recoverability requirements for the hosting provider of the reserved capacity
Nordvik Region and Hansa Mutual: Nordvik's architect writes recoverability requirements into contracts with the hosting provider and TriageSoft, and rehearses with the platform team the manual degraded mode of the benefits-triage system after a stop, finding that only two caseworkers still remember it. Hansa's platform domain architect makes recovery of the claims-triage agent and the IT-operations agent a rehearsed property and introduces a security chaos experiment that verifies redeployment from known-good definitions, recorded as AIDR-0555. Hansa reports recoverability beside patch velocity to the executive board.
Usage modes and autonomy levels: AI can plan and evaluate chaos experiments without estate credentials while narrow deterministic actuators act; recovery actions that restore known-good definitions may run at Level 3 Bounded, while decisions to resume a stopped Mode 5 agent stay with named people.
Observable, expected, speculation: Recovery rehearsal and chaos engineering are observable practice; the use of AI to make recovery proactive is observable in early adopters and expected to spread; the security AI as a recovery target is an expected concern.
Figure: The recoverability loop: known-good definitions, rehearsal and chaos experiment, finding, pull request and reporting, with the degraded mode drawn beside the AI system

Part III: The Architect's AI Team

Chapter 12: The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3

File: 12_architects_own_ai_use.md
Status: draft
Purpose: Describe the architect's own use of AI in Modes 1 to 3, where the AI acts with the architect's identity: drafting decision records, policies and threat models, researching standards and incidents, reviewing designs and code, and analysing logs and configurations. Weigh the evidence honestly, including studies that found productivity gains, a randomised trial that found experienced developers slowed down, and studies that found generated code insecure. Set out how the architect keeps architecture information confidential, what records of prompts and outputs are kept, and how personal skills and instructions files make the work repeatable. Leave the agent team with its own identities to Chapter 13.
Builds on: F14, F15, F38, F49, F53, F66
Shifts: Shift 1, from documents to code; Shift 4, from sole author to conductor of an AI team
Sections: What architects use AI for; Modes 1 to 3 for architecture work; The evidence on productivity; The evidence on quality and security; Confidentiality of architecture information; Skills, instructions and prompt records; When AI-assisted work needs a decision record; Working habits that keep judgement independent
Practical guides: Setting up a personal AI workflow for architecture work: tools, routing, records and habits
Worked examples: Nordvik Region's mandate manifest MND-NR-01 for the security architect's Mode 3 tool on open-weight models on the reserved capacity; A skill file for drafting AIDRs to Hansa Mutual's schema
Nordvik Region and Hansa Mutual: Nordvik's architect uses the approved Mode 1 tool for public material and the Mode 3 tool under MND-NR-01 only on open-weight models on the Region's reserved capacity, because architecture information describes the Region's defences; the architect keeps a short log of which drafts came from the tool. Hansa's architects use Modes 1 to 3 through the enterprise tiers with classification routing, so that sensitive architecture information reaches only self-hosted models in hansa-dc-frankfurt, and the DORA register of information records the providers. In both organisations the architect's own use is the first place where the habit of drafting first and verifying sources is set.
Usage modes and autonomy levels: This chapter is about Modes 1 to 3, in which the AI acts with the architect's identity and the architect answers for everything it produces; the autonomy level is at most Level 2 Supervised for file and repository changes in the Mode 3 tool. Mode 0 features in the architect's existing tools are inventoried so that nothing acts at an autonomy nobody decided.
Observable, expected, speculation: Productivity and insecure-code findings are observable but mixed and task-dependent; their transfer to architecture work, which has few controlled studies, is expected rather than established.
Figure: The architect's own AI work in Modes 1 to 3: tasks, routing by classification to approved or self-hosted models, outputs, verification and records

Chapter 13: An AI Agent Team for Security Architecture: Skills, Mandates and Containment

File: 13_ai_agent_team.md
Status: draft
Purpose: Show how to build and govern an AI agent team for security architecture, building on the agent team of Architecture as Code (Chapter 20) and the roles, modes and autonomy levels of AI Red Team, Chapter 6: a reviewer, a threat modeller, a policy author, an evidence collector and a researcher, each with skills, tools, an identity, a mandate manifest, an autonomy level per action and containment that does not depend on intent. Make agents draft and humans approve the operating rule, and show how disagreement between agents is decided by the accountable architect. Give a complete worked example of a mandate manifest MND-* and the containment it needs.
Builds on: F12, F13, F27, F45, F50, F51, F54, Q2
Shifts: Shift 2, from gatekeeper to boundary designer; Shift 4, from sole author to conductor of an AI team
Sections: From assistants to an agent team; The roles; The mandate manifest; Autonomy levels for architecture work; Containment of the architect's own agents; Agents draft; humans approve; Disagreement and escalation; Operating the team; Agents that read people's work
Practical guides: Introducing an architecture agent team in three stages; Writing a mandate manifest
Worked examples: Hansa Mutual's mandate manifest MND-HM-01 for the architecture review agent team, with roles, tools, autonomy per action, containment and escalation; Nordvik Region's decision, recorded as AIDR-0503, to defer an agent team and extend MND-NR-01 instead
Nordvik Region and Hansa Mutual: Hansa runs the agent team for architecture review on pull requests under MND-HM-01, with the reviewer, threat modeller, policy author, evidence collector and researcher drafting and named architects approving; the rollout in each entity waits for works-council consultation in Germany and the Netherlands and union consultation in Sweden because the agents can show who wrote what. The Mode 5 evidence-collection agent has its own read-only identity and acts at Level 3 Bounded only to refresh evidence links. Nordvik decides that one architect cannot supervise a team of agents and records the decision to defer it as AIDR-0503, while extending MND-NR-01 with a research skill.
Usage modes and autonomy levels: The team spans Mode 3 agents acting on pull requests with a delegated identity and a Mode 5 agent with an identity of its own; each action has a recorded autonomy level, most at Level 1 Assisted or Level 2 Supervised, and no agent in the team acts at Level 4 or approves its own or another agent's output.
Observable, expected, speculation: Agent teams for engineering work are observable in early adopters; their reliability for architecture review is not yet established by independent evidence and is expected to be measured locally through review-quality metrics.
Figure: The architecture agent team under a mandate manifest: five agents with identities, tools and autonomy levels, a policy decision point outside the agents, and named architects approving on the pull request

Chapter 14: Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI

File: 14_verifying_ai_proposals.md
Status: draft
Purpose: Answer the open question from Architecture as Code (Chapter 27): version control shows what changed, not whether the reasoning was sound, so how does an architect review AI-proposed change for soundness when the reviewer depends on the AI? Present review techniques that do not rely on trusting the proposer, among them independent re-derivation, tests and policies as oracles, an adversarial second agent with different instructions, provenance of every claim, and risk-based sampling. Treat automation bias as a design problem, use approval time and rejection rate as signals of rubber-stamping, and show how evidence of review is produced. Keep skill retention to Chapter 15.
Builds on: F14, F21, F52, F55, F68, Q3, Q6
Shifts: Shift 1, from documents to code; Shift 4, from sole author to conductor of an AI team
Sections: The question left open; Soundness defined in advance; Techniques that do not trust the proposer; A second agent as adversary; Review depth by risk; Automation bias and rubber-stamping; Evidence of review; When verification is the bottleneck
Practical guides: A review protocol for AI-proposed architecture changes by risk tier; Measuring review quality without monitoring individuals
Worked examples: A review record for an AI-proposed policy change at Hansa Mutual, with the second-agent critique, the tests used as oracle and the approver's rationale; Seeded-error checks in Nordvik Region's single-architect review
Nordvik Region and Hansa Mutual: Hansa's review agents produce more proposals than six architects can review in depth, and approval times on agent pull requests fall to seconds; the team introduces review tiers, a second agent with different instructions, and an approval-quality metric reported at team level as agreed with the works councils, recorded as AIDR-0556. Nordvik's single architect has no colleague to review with, so the review protocol relies on tests as oracles, re-derivation of every requirement placed in a tender annex and an occasional review by the enterprise architect. In both organisations the review record becomes the answer to who was accountable for an AI-proposed change.
Usage modes and autonomy levels: Review requirements rise with the autonomy level at which a proposal would otherwise take effect: at Level 1 Assisted the human authors the decision, at Level 2 Supervised the human approves each action, and at Level 3 Bounded the review moves to the playbook and its tests, which therefore need the deepest scrutiny.
Observable, expected, speculation: Automation bias and rubber-stamping are observable in decades of research and in recent incidents; reliable AI-on-AI verification is speculation and is not relied upon.
Figure: A review pipeline for AI proposals: proposal, oracle tests, second-agent critique, risk-tiered human review, approval signals and the review record

Chapter 15: Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can

File: 15_keeping_the_craft.md
Status: draft
Purpose: Explain why the architect who cannot still do the craft without AI cannot verify AI, and what to do about it. Rest the argument on the evidence already in the bibliography: Bainbridge's ironies of automation, Parasuraman and Manzey on complacency and bias, studies of reduced critical thinking and cognitive effort with generative AI (Lee and colleagues, Kosmyna and colleagues, Gerlich), the METR trial, Ericsson on deliberate practice, and Kahneman and Klein on the conditions for intuitive expertise, together with the conclusions of AI Threat. Define judgement in security architecture, show how it is kept through deliberate practice, no-AI exercises and seeded-error drills, and how juniors are mentored when their junior work has been automated.
Builds on: F11, F53, F66, F69, F70, Q8
Shifts: Shift 4, from sole author to conductor of an AI team
Sections: The ironies of automation, again; What the evidence shows; What judgement is; Deliberate practice for architects; No-AI exercises and seeded-error drills; Mentoring when junior work is automated; Pacing autonomy to the skills available; Reporting without surveillance
Practical guides: A quarterly craft-keeping programme for a security architecture team; Designing a seeded-error drill
Worked examples: Hansa Mutual's apprenticeship plan for a junior architect embedded at the Polish service centre, with competence records CMP-HM-*; Nordvik Region's no-AI exercise calendar for its single architect, with peer exercises shared with a neighbouring region
Nordvik Region and Hansa Mutual: Nordvik's single post has no one to learn from, so the architect arranges peer exercises with a neighbouring region and the enterprise architect, drafts every threat model first without the tool, and records the practice in CMP-NR-01. Hansa uses its team of six to rotate unassisted reviews, runs seeded-error drills against the agent team and designs an apprenticeship for a junior architect at the Polish service centre whose first year deliberately includes work the agents could do. Hansa reports the drills at team level only, as agreed with the works councils.
Usage modes and autonomy levels: The risk of deskilling grows with the share of work done in Modes 2 and 3 and with the autonomy level of the architect's agents; keeping the craft means a share of work at Level 0, with no assistance, and supervision of Level 3 playbooks by people who could write them unaided.
Observable, expected, speculation: Reduced effort and checking with trust in AI are observable in early studies with limited samples; long-term deskilling of experts is expected but not yet measured over years; the loss of the route by which experts are made is expected and is the book's main reason for deliberate apprenticeship.
Figure: The craft-keeping cycle: unassisted practice, AI-assisted work, seeded-error drills, review-quality measurement and mentoring, with autonomy paced to supervisory skill

Part IV: The Role in the Organisation

Chapter 16: The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams

File: 16_role_map.md
Status: draft
Purpose: Place the security architect among the neighbouring roles: the CISO, the enterprise architect, the AI architect of AI Governance, Chapter 14, platform engineers, product teams, the risk function and internal audit. Use Team Topologies and Conway's law to explain where the role sits, enabling or embedded, in a platform team or a stream-aligned team, and what each placement does to the boundaries the architect can hold. Give a RACI for the decisions that cross roles, and settle the seams that AI systems create, above all between the security architect and the AI architect. Leave the mechanics of forums and gates to Chapter 17.
Builds on: F9, F10, F22, F23, F24, Q9
Shifts: Shift 2, from gatekeeper to boundary designer; Shift 4, from sole author to conductor of an AI team
Sections: A role among roles; The CISO and the security architect; The enterprise architect and the AI architect; Platform and product teams; Enabling, embedded or platform; Conway's law and boundaries; New neighbours from the usage modes; A RACI for cross-role decisions
Practical guides: Drawing the role map for an organisation in one workshop
Worked examples: A RACI as code for cross-role decisions at Hansa Mutual, separating the AI domain security architect's rights from the AI architects'; Nordvik Region's role map for a single security architect, the enterprise architect, the AI architect and the platform team
Nordvik Region and Hansa Mutual: At Nordvik the role map is small and personal: the security architect, the enterprise architect in the digitalisation unit, the AI architect who owns the AI Decision Records of the AI estate and the platform team of a handful of engineers, with the CISO above; the map clarifies that the AI architect owns guardrail policy and the security architect owns identity, egress and stop-path requirements. At Hansa the map settles the seam between the AI domain security architect and the AI architects, places one architect embedded with the claims product line and one at the Polish service centre in an enabling mode, and records the platform team as the owner of the guardrails the architects design, as AIDR-0557.
Usage modes and autonomy levels: Mode 5 agents add the agent operator, who watches agents and may revoke their credentials, as a neighbour the architect designs for; Modes 1 to 3 add the skills curator, whose skills the architect's own tools use.
Observable, expected, speculation: The role seams described are observable in organisations with AI architects; convergence of the security and AI architect roles is a scenario for Chapter 23, labelled speculation here.
Figure: The role map: the security architect among the CISO, the enterprise architect, the AI architect, the platform team, product teams, risk, audit and agent operators, with the seams marked

Chapter 17: Design Authority, Decision Forums and Gates Instead of Meetings

File: 17_decision_forums.md
Status: draft
Purpose: Show how the architect delegates routine decisions without losing accountability: tiered decisions routed to the lowest tier that can take them with evidence, as in AI Governance, Chapter 13; the design authority for exceptions and contested items; pipeline gates that enforce, observe and remember; and exceptions as expiring records. Explain what forums are still for once pipelines enforce, how a review board that has become a bottleneck is redesigned, and how the decision about when an AI may act without per-action approval is itself made and recorded when the action is a change to the architecture.
Builds on: F2, F17, F18, F19, F22, F29, Q2
Shifts: Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed
Sections: From meetings to gates; The tier policy as data; Pipeline gates; The design authority; Exceptions as expiring records; When AI changes the architecture; Redesigning a bottleneck board; Delegation without abdication
Practical guides: Redesigning an architecture review board as a design authority with gates
Worked examples: Hansa Mutual's tier policy for architecture decisions as code, with the classes delegated from the fortnightly board to pipeline gates; An expiring exception record EXC-NNNN for a supplier control at Nordvik Region
Nordvik Region and Hansa Mutual: Hansa measures its fortnightly review board and finds that most items are routine and could be decided at a pipeline gate; the board becomes a design authority reviewing asynchronously on pull requests and meeting for contested items, with decisions beyond its mandate routed to the group AI governance board, recorded as AIDR-0558. Nordvik has no standing board, so the architect writes a tier policy that routes decisions to the CISO, to the existing forums and to the regional executive committee for the political tier, and records exceptions as expiring entries that survive public-access requests and archiving.
Usage modes and autonomy levels: The tier policy states the autonomy level at which agent-proposed architecture changes may take effect: none at Level 4, a narrow class of reversible, policy-enforced changes at Level 3 Bounded, and all others at Level 2 Supervised or below.
Observable, expected, speculation: Tiered decisions and gates instead of meetings are observable in organisations working as code; supervisors' expectations about delegated architecture decisions are expected to develop through practice rather than rule.
Figure: Decision tiers from pipeline gate through design authority and governance board to the management body, with exceptions as expiring records and the autonomy line for agent-proposed changes

Chapter 18: Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability

File: 18_regulation_as_constraint.md
Status: draft
Purpose: Read the European instruments as engineering constraints and show the architect as the person who turns each article into a control. Treat the AI Act Articles 4, 9, 14, 15 and 26, NIS 2 Articles 20, 21 and 23, DORA Articles 5, 6, 17 and 28, and the Cyber Resilience Act Articles 13 and 14 with Annex I, and for each say what it expects of architecture and of named people. Distinguish the personal accountability the instruments place on management bodies from the professional responsibility of the architect, and show how the architect equips the management body to discharge its duties. Attribute every statement to the instrument and article and frame it as an architectural implication, not legal advice.
Builds on: F18, F25, F31, F39, F46, F51, Q11
Shifts: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed
Sections: Regulation as a design input; The AI Act; NIS 2; DORA; The Cyber Resilience Act; Personal accountability and the architect; From article to control; Where instruments overlap and conflict
Practical guides: Turning an article into a control: a six-step method with a worked line
Worked examples: An article-to-control mapping for Hansa Mutual covering DORA Articles 6 and 28 and AI Act Article 26 for the claims-triage agent; Nordvik Region's mapping of NIS 2 Article 21 and AI Act Articles 14 and 26 to tender requirements for the benefits-triage system
Nordvik Region and Hansa Mutual: Nordvik falls within the national transposition of NIS 2 and is a deployer of the high-risk benefits-triage system, so its architect maps NIS 2 Article 21 and AI Act Articles 14 and 26 to tender requirements and to the oversight design, and prepares the regional executive committee's NIS 2 Article 20 training. Hansa is subject to DORA, runs a high-risk underwriting-support model and operates the claims-triage agent in production, so its architects map DORA Articles 6, 17 and 28 and AI Act Articles 9, 14, 15 and 26 through the control catalogue, and brief the executive board as the management body under DORA Article 5. Both treat CRA Articles 13 and 14 and Annex I mainly as requirements on suppliers.
Usage modes and autonomy levels: The AI Act attaches duties to the role (provider, deployer) and the risk class, not the mode, but the mode determines where oversight under Article 14 can be designed: an interruption path and override log for Mode 5 agents, and literacy and use rules for Modes 1 to 3.
Observable, expected, speculation: The instruments and their articles are observable law in force or entering into force on stated dates; supervisory practice and guidance on how they apply to agents is expected to develop and is labelled as such.
Figure: Articles of the AI Act, NIS 2, DORA and the CRA mapped through the architect to controls, tests and evidence, with the management body's accountability shown separately

Chapter 19: Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers

File: 19_communicating_architecture.md
Status: draft
Purpose: Show how one security architecture is communicated to several audiences without maintaining several versions of it: views generated from the same model, risk language for boards, evidence for auditors and supervisors, decision records for engineers, and requirements for suppliers. Define the management reporting the architect owns, among them patch velocity, containment test results, recoverability and control status, and how it reaches the board as one page with a small number of decisions. Explain how the architect explains AI-assisted work honestly to each audience.
Builds on: F8, F20, F29, F37, F58, F60, F65
Shifts: Shift 1, from documents to code; Shift 3, from periodic to continuous, at machine speed
Sections: One architecture, several audiences; Boards and management bodies; Supervisors; Auditors; Engineers and product teams; Suppliers; Metrics the architect reports; Disclosing AI's part in the work
Practical guides: Writing a one-page architecture report for a management body
Worked examples: A generated board view and metrics page for Hansa Mutual's executive board, drawn from the Structurizr workspace and the control catalogue; Nordvik Region's one-page briefing to the regional executive committee on the role charter and the 2027 budget
Nordvik Region and Hansa Mutual: Nordvik's architect must communicate to a regional executive committee of elected members, to suppliers through tender annexes and to the public through access requests, and uses a one-page briefing and generated views to answer the regional director's commission. Hansa's team generates views for the executive board, the group AI governance board, BaFin and the other supervisors, internal audit and the national entities from the same model and catalogue, and adds patch velocity, containment test results and review quality to the management reporting, recorded as AIDR-0559.
Usage modes and autonomy levels: AI in Modes 1 to 3 can draft views and summaries for each audience, but the architect verifies every figure against the model and the evidence, and boards are told which material was drafted by AI.
Observable, expected, speculation: Generated views and evidence-based reporting are observable; supervisors' expectation of machine-speed metrics such as patch velocity is expected, signalled but not yet uniform.
Figure: One architecture model and catalogue feeding generated views for the board, supervisors, auditors, engineers and suppliers, each with its form and its metrics

Chapter 20: Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes

File: 20_public_sector_and_multinational.md
Status: draft
Purpose: Treat two settings that change the role most: the public authority whose architect procures rather than builds, and the multinational whose architect holds one architecture across many legal regimes. For the first, show requirements as code, contracts as controls, supplier evidence and exit plans, and how a single architect holds boundaries in systems that suppliers build and operate. For the second, show digital sovereignty as verifiable properties, one baseline with market overlays that may only tighten it, and the handling of architecture information that crosses borders. Draw on European procurement law, sovereignty schemes and national cloud policies.
Builds on: F30, F31, F37, F47, F57, Q10
Shifts: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer
Sections: The architect who procures; Requirements as code; Contracts as controls; Exit plans and reversibility; Vendor AI and Mode 0; Digital sovereignty as verifiable properties; One architecture, many regimes; Architecture information across borders
Practical guides: Writing testable security requirements for a tender; Adding a market overlay without weakening the baseline
Worked examples: Nordvik Region's security requirements annex as code for the renewal of tender NR-2026-117 with TriageSoft; Hansa Mutual's market overlays for the UK and Swiss entities, with the mappings brought into the group catalogue
Nordvik Region and Hansa Mutual: Nordvik's single architect holds boundaries mostly through procurement: the TriageSoft tender NR-2026-117, the staff-assistant contract NR-2026-031, the hosting provider and the managed security service provider's framework agreement NR-2025-044, each with testable requirements, evidence obligations and an exit plan, recorded as AIDR-0504. Hansa's architects keep one baseline with overlays for seven jurisdictions, bring the UK and Swiss mappings kept by local security officers into the group catalogue, and apply data-transfer rules to architecture information that reaches those entities.
Usage modes and autonomy levels: Procured products bring Mode 0 AI whose effective autonomy must be established and contracted before it is relied upon; for Mode 5 agents operated by suppliers, the contract must give the organisation a stop path and evidence it can exercise and verify itself.
Observable, expected, speculation: Sovereignty schemes, national cloud policies and model contractual clauses are observable; the Cloud and AI Development Act is a proposal and its effects are expected, not settled.
Figure: Two settings side by side: the procuring authority's boundaries held through requirements, contracts and evidence, and the multinational's baseline with market overlays across jurisdictions

Part V: Competence and Career

Chapter 21: Competences of the Transformed Security Architect: A Framework

File: 21_competence_framework.md
Status: draft
Purpose: Give a competence framework for the transformed security architect, kept as code: six domains (design, code, AI, adversary, law and people), levels from Foundation to Expert, and for each competence the evidence that demonstrates it in practice rather than the certificate that claims it. Map the framework to ENISA's European Cybersecurity Skills Framework profile Cybersecurity Architect, to SFIA 9 skills and levels, and to the NIST NICE Workforce Framework, so that organisations can use it with their existing HR and procurement vocabularies. Show how individual competence records are kept, what they may contain as personal data, and how they connect to the role charter.
Builds on: F9, F11, F25, F26, F53, Q7
Shifts: 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
Sections: Why a framework, and why as code; Six domains; Levels; Evidence of competence; Mapping to ECSF; Mapping to SFIA and NICE; Competence records as personal data; Linking competence to the charter and to autonomy
Practical guides: Assessing an architect against the framework by practical demonstration; Mapping a local framework to ECSF, SFIA and NICE
Worked examples: competence/security-architect-framework.yaml with the six domains, four levels and mappings to ECSF, SFIA and NICE; Competence records CMP-NR-01 for Nordvik Region's architect and CMP-HM-* for two of Hansa Mutual's domain architects
Nordvik Region and Hansa Mutual: Nordvik uses the framework to answer the second half of the regional director's commission, the competence plan, and to justify the post's grading within fixed pay scales; CMP-NR-01 records the architect's evidence, including unassisted threat models and tender requirements that suppliers met. Hansa adopts the framework for its team of six, maps it to the group competence framework of AI Governance, Chapter 14, and agrees with the works councils what competence records may contain and that assessment results are not used for performance ranking. Both map the framework to ECSF so that tenders and job advertisements use a common European vocabulary.
Usage modes and autonomy levels: The AI domain covers the architect's own use of Modes 1 to 3, the design of containment for Mode 5 agents and the setting of autonomy levels; competence in supervising Level 3 playbooks is evidenced by the ability to write and test them unaided.
Observable, expected, speculation: ECSF, SFIA and NICE are observable, maintained frameworks; their coverage of AI and agent supervision is partial, and the framework's additions are the book's proposal, expected to be revised as the frameworks evolve.
Figure: The competence framework: six domains by four levels, each competence linked to its evidence and mapped to ECSF, SFIA and NICE

Chapter 22: Learning Paths, Certification, Hiring and Upskilling

File: 22_learning_and_hiring.md
Status: draft
Purpose: Turn the competence framework into practice: learning paths by starting point (security engineer, enterprise architect, developer and auditor), what certifications validate and where they stop, hiring profiles and interview exercises that test judgement rather than recall, and the choice between upskilling and hiring. Treat AI Act Article 4 literacy for the architect as a concrete learning objective. Keep the framework itself in Chapter 21 and apprenticeship inside a working team in Chapter 15; this chapter owns how people get into the role and grow in it.
Builds on: F11, F25, F26, F66, Q7, Q8
Shifts: Shift 1, from documents to code; Shift 4, from sole author to conductor of an AI team
Sections: Four starting points; Learning paths; Certifications and their limits; AI literacy for the architect; Hiring profiles; Interview exercises; Upskilling or hiring; Careers that stay technical
Practical guides: Designing an interview exercise that tests judgement with and without AI; A twelve-month learning path from enterprise architect to security architect
Worked examples: Hansa Mutual's hiring profile and interview exercise for a security architect embedded at the Polish service centre; Nordvik Region's learning path for its post-holder, financed in the 2027 budget
Nordvik Region and Hansa Mutual: Nordvik cannot easily hire within its fixed pay scales and security vetting, so its plan upskills the post-holder along a learning path from the security coordinator's starting point and builds a deputy from the platform team to reduce the single point of failure. Hansa hires for scarce specialisms, upskills its embedded architects and runs a judgement-based interview exercise in which candidates review a flawed agent proposal and draft a threat model unaided. Hansa's assessment results are personal data whose use is agreed with the works councils.
Usage modes and autonomy levels: Learning paths include supervised practice with the architect's own Mode 3 tools and the design of containment for Mode 5 agents; interview exercises are run both with and without AI so that the assessment shows what the candidate can verify.
Observable, expected, speculation: Skills shortages and certification practice are observable in workforce studies; the effect of AI on entry routes into the profession is expected and is one of the scenarios of Chapter 23.
Figure: Four starting points converging on the role along learning paths, with certifications, practical demonstrations and the hiring gate marked

Chapter 23: The Future of the Role: Will There Be a Security Architect in 2036?

File: 23_future_of_the_role.md
Status: draft
Purpose: Ask whether there will be a security architect in 2036 and answer with a horizon register for the role, in which every trend is labelled observable, expected or speculation, as in AI Governance, Chapter 22. Develop four scenarios, absorbed into platform engineering, turned into a governance role, become the commander of agent teams, or disappeared, with the signals that would show each is arriving and the no-regret measures that hold in all of them. Keep the author's judgement for the closing section of the chapter and label it, separate from the register.
Builds on: F32, F33, F35, F69, Q5, Q12
Shifts: 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
Sections: Why a horizon register for a role; Observable trends; Expected trends; Speculation; Scenario one: absorbed into platform engineering; Scenario two: a governance role; Scenario three: commander of agent teams; Scenario four: the role disappears; Signals and no-regret measures; The author's judgement
Practical guides: Keeping a horizon register for a role and reviewing it each year
Worked examples: A horizon register for the security architect role as code, with labels, signals, owners and review dates, maintained by Hansa Mutual's head of security architecture
Nordvik Region and Hansa Mutual: Nordvik adds the role register to the competence plan answering AIDR-0500, because its single post is exposed to the absorption scenario if suppliers and the platform team take over boundary design, and records the review cycle as AIDR-0505. Hansa's head of security architecture keeps the register for the team of six and reviews it with the group CISO each year, using it to decide the 2027 to 2028 hiring mix between domain architects and agent operators. Neither organisation commits to a scenario; both commit to the no-regret measures.
Usage modes and autonomy levels: The scenarios differ above all in how far Mode 5 agents and Level 3 autonomy extend into architecture work itself, and the register tracks the share of architecture changes proposed, drafted and merged at each autonomy level as a signal.
Observable, expected, speculation: The chapter is the book's main outlook and labels every trend; the four scenarios are speculation by construction, and the author's judgement in the last section is labelled as a projection.
Figure: The horizon register for the role: trends labelled observable, expected or speculation, leading to four scenarios for 2036 with their signals and the no-regret measures common to all

Part VI: Experience and Conclusions

Chapter 24: Case Studies and Anti-Patterns

File: 24_case_studies_and_anti_patterns.md
Status: draft
Purpose: Collect illustrative, generalised case studies of security architecture practices undergoing the transformation, each with context, challenge, approach and outcome, and a catalogue of anti-patterns, among them the architect as bottleneck, the diagram nobody runs, the AI that approved itself, the control catalogue nobody maps and the sign-off in seconds. For every anti-pattern, name the shift it violates, the symptom by which it is recognised, the cause and the remedy. Ground the cases in observable incidents where they exist, and keep them distinct from the two organisations, whose story is told in Chapters 25 and 26.
Builds on: F14, F21, F28, F29, F62, F67
Shifts: 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
Sections: How to read the cases; Case: a review board that became a design authority; Case: an authority that held boundaries through contracts; Case: an agent incident reconstructed; Anti-pattern: the architect as bottleneck; Anti-pattern: the diagram nobody runs; Anti-pattern: the AI that approved itself; Anti-pattern: the control catalogue nobody maps; Anti-pattern: the sign-off in seconds; Patterns across the cases
Practical guides: Diagnosing anti-patterns in a security architecture practice with a twelve-question checklist
Worked examples: An anti-pattern record as code with symptom, violated shift, cause, remedy and verification test
Nordvik Region and Hansa Mutual: The chapter's cases are generalised and do not draw on the two organisations' own stories, but the closing section shows which anti-patterns each recognised in itself during the year: Nordvik the architect as bottleneck and the reference document nobody runs, Hansa the sign-off in seconds on agent pull requests and the catalogue whose UK and Swiss mappings sat outside it. Each recognition is linked to the decision record that addressed it, AIDR-0506 for Nordvik and AIDR-0560 for Hansa.
Usage modes and autonomy levels: Several anti-patterns are specific to the higher modes: the AI that approved itself appears only where agents in Mode 3 or Mode 5 have write access to the artefacts they review, and the sign-off in seconds grows with the volume of Level 2 Supervised approvals.
Observable, expected, speculation: The incidents cited are observable; the generalised cases are illustrative composites and are labelled as such; the recurrence of the anti-patterns as agent use grows is expected.
Figure: The anti-pattern catalogue as a matrix: each anti-pattern against the shift it violates, its symptom and its remedy

Chapter 25: A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual

File: 25_a_year_in_the_role.md
Status: draft
Purpose: Tell a narrative year, quarter by quarter from autumn 2026 to autumn 2027, for Nordvik Region's single security architect and Hansa Mutual's group team of six, showing the four shifts in practice and the artefacts each produces. Follow the commission and the board request from Chapter 1 through the role charter, the control catalogue, boundaries, the agent team or its deferral, the review protocol, the redesigned forums, the competence records and the first horizon register. Show what went wrong as well as what worked, with the decision records that record each turn, and keep the conclusions and plans for Chapter 26.
Builds on: F12, F17, F29, F52, F59, F60
Shifts: 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
Sections: Autumn 2026: the question arrives; Quarter one: charter and catalogue; Quarter two: boundaries and time; Quarter three: the AI team; Quarter four: forums, competence and the horizon; A week in the role, before and after; What the year produced
Worked examples: A year's timeline as code for each organisation, linking each quarter's decision records AIDR-0500 to AIDR-0549 and AIDR-0550 to AIDR-0599 to the artefacts they produced
Nordvik Region and Hansa Mutual: The whole chapter is about the two organisations. Nordvik's architect starts with no charter, a 2024 reference document and a spreadsheet, and ends the year with ROLE-NR-SA-01, a small catalogue, tender annexes as code, a timed stop path for the benefits-triage system, MND-NR-01 extended and CMP-NR-01, while the single point of failure is only partly resolved. Hansa's team starts with a Structurizr workspace, a fortnightly board and an agent team whose review quality is unmeasured, and ends the year with ROLE-HM-* charters, a design authority with gates, MND-HM-01 approved after works-council consultation, review tiers, patch velocity in board reporting and a completed catalogue.
Usage modes and autonomy levels: The narrative shows the modes in use: Nordvik's architect in Modes 1 and 3 on self-hosted models, Hansa's team in Modes 1 to 3 with an agent team and a Mode 5 evidence collector at Level 3 Bounded, and the agents in production whose speed drives Hansa's redesign.
Observable, expected, speculation: The narrative is illustrative and set in 2026 to 2027; the events it draws on are observable, and its projections for the organisations are expected outcomes of the decisions recorded, not predictions.
Figure: Two parallel timelines for the year, quarter by quarter, with the artefacts and decision records each organisation produced and the shift each concerns

Chapter 26: Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

File: 26_conclusions_for_nordvik_and_hansa.md
Status: draft
Purpose: Draw conclusions for the two organisations across the whole book, in the manner of the conclusions chapters of AI Red Team and AI Threat: the decisions each took, what worked, what was hard and what remains unresolved. Give each organisation a prioritised 24-month plan for its security architecture practice and compare the two, so that a reader can see how the same four shifts lead to different priorities in a single-post public authority that procures and a multinational team that builds. Answer the regional director's commission and the executive board's request explicitly.
Builds on: F18, F26, F48, F65, Q6, Q10
Shifts: 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
Sections: One question, two answers; Nordvik Region: the answer to the regional director; Hansa Mutual: the answer to the executive board; The two artefact sets; Two 24-month plans; Where they differ and why; What remains unresolved
Worked examples: The 24-month security architecture plan as code for each organisation, with measures, owners, dependencies and verification
Nordvik Region and Hansa Mutual: Nordvik's conclusion is that the post must hold boundaries through contracts and a small catalogue, that its first priority is a deputy and a peer network to remove the single point of failure, and that it should not run an agent team until two people can supervise it, recorded as AIDR-0507. Hansa's conclusion is that the review board's delegation to gates, review tiers for agent proposals and the evidence-collection agent let architecture keep pace with agents, but that review throughput and the UK and Swiss regimes remain the binding constraints, recorded as AIDR-0561. The comparison shows the same shifts producing a contract-first plan in one organisation and a delegation-first plan in the other.
Usage modes and autonomy levels: Nordvik's plan stays in Modes 1 and 3 for architecture work and contracts for supplier Mode 5 risk; Hansa's plan extends Level 3 Bounded only to further reversible evidence and drafting actions, conditional on review-quality metrics.
Observable, expected, speculation: The plans are the organisations' decisions within the illustration; their outcomes are expected, not observed, and the plans name the signals on which they would be revised.
Figure: The two 24-month plans side by side, by quarter and shift, with the shared measures and the differences highlighted

Chapter 27: Conclusions: The Transformed Security Architect

File: 27_conclusion.md
Status: draft
Purpose: Conclude the book: restate the thesis and test it against what the chapters found, reflect on each part, draw the cross-cutting conclusions and say how firm each is, answer the open questions Q1 to Q12 or say why they remain open, and set out what to do first, next and later. Show how the six volumes of the series make one argument about keeping decisions correctable, stops outside what they stop, people able to judge the output, dependence reversible and autonomy matched to reversibility, with the security architect as the person who makes that argument executable. Keep the author's judgement in its own labelled section.
Builds on: F15, F33, F34, F48, F70, Q3, Q5, Q12
Shifts: 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
Sections: The thesis restated; Reflections on each part; Cross-cutting conclusions; How firm the conclusions are; Answered and open questions; What to do first, next and later; The series as one argument; The author's judgement; A call to the profession
Worked examples: A first-90-days plan for a security architect taking up a transformed role, as code
Nordvik Region and Hansa Mutual: The chapter brings the two organisations back once, briefly: the same four shifts produced a contract-first answer in Nordvik Region and a delegation-first answer in Hansa Mutual, and both answers rest on accountable human judgement that each organisation chose to keep deliberately. The fuller comparison is in Chapter 26.
Usage modes and autonomy levels: The conclusion restates the book's position across the modes: the architect uses AI in Modes 1 to 3 and answers for it, designs boundaries that hold for Mode 5 agents whatever they intend, and matches the autonomy level of every agent, including the architect's own, to the reversibility of its actions, never using Level 4 for irreversible ones.
Observable, expected, speculation: Each conclusion is labelled by how firm it is; the author's judgement about the role in ten years is labelled as a projection and kept to its own section, consistent with Chapter 23.
Figure: The book's argument in one figure: the four shifts, the artefact set and the scarce resource of accountable human judgement, set within the argument of the six volumes

Appendices

28_glossary.md: Defines the vocabulary of security architecture, the four shifts, the usage modes and autonomy levels, the architect's artefacts (role charter, control catalogue, containment profile, permission manifest, mandate manifest, competence record, decision records), competence frameworks and the European instruments used in the book.
29_appendix_a_code_examples.md: Appendix A: complete versions of the role, control and mandate artefacts in the chapters: the role charter roles/security-architect.yaml, control catalogue entries and evidence manifests, a containment profile and permission manifest, the mandate manifest for an architecture agent team, the tier policy, a review record, the competence framework and competence records, and the horizon register for the role.
appendix_templates_and_tools.md: Appendix B: templates and tools for a shift assessment, writing a role charter, migrating a reference document to a model, tender security requirements, a review protocol for AI proposals, a craft-keeping programme, interview exercises, a one-page board report and an anti-pattern checklist.
30_references.md: The only bibliography of the book: European instruments, standards and frameworks, security and architecture literature, research on AI-assisted work and on automation and expertise, threat and incident reporting, competence frameworks and the five earlier volumes of the series. Chapters cite only entries listed here.
31_about_the_author.md: About the author of The Architecture as Code Series, placed at the very end of the book.