The Transformed Security Architect: teacher's guide

All courses / The Transformed Security Architect / Teacher's guide

How to use this guide

The guide holds everything a teacher needs to run the course on The Transformed Security Architect: the lecture of each module with a timed outline, the teaching plan of every lesson, the discussion questions, the exercises and the answers to the self-tests. The agendas of the three formats are on the course page; the slides are in the deck of the book.

Executive briefing (90 minutes): A briefing for the people who commission and fund the role. It frames the question, presents the four shifts and the role charter, shows what a management body should ask to see, from a timed stop path to control status in three counts, and ends with the decisions the two fictional organisations put to their governing bodies.
One-day seminar (1 day): A working day that takes one practice through the book's main artefacts. Participants assess their practice on the four shifts, draft decision rights, design a containment profile with a stop drill, classify controls, tier AI-proposed changes and decide which decisions leave the review board, ending with a diagnostic for anti-patterns and first steps.
Full course (8 weeks, with Part II and Part IV over two weeks each): The complete course: 27 lessons in six modules, one module per part of the book, each opened by a lecture on the argument of the part. Every lesson produces an artefact of the kind its chapter describes, and the artefacts accumulate into the capstone, a security architecture practice file for the participant's own organisation or for Nordvik Region or Hansa Mutual.

Keynote on the whole book · 45 minutes

Never approve what you could not have written: the security architect transformed

For security and architecture professionals, CISOs and executives at a conference or an internal leadership day

Five books made architecture, governance, the AI platform and cyber defence executable and examined the AI threat. Each conclusion rests on work someone has to do: deciding where a boundary runs, which credentials an agent may hold and where the stop path lives. This lecture describes what has happened to that person. It argues that the security architect is transformed, not abolished, along four shifts, shows what the craft looks like when boundaries are code and AI drafts the artefacts, and names what stays scarce: accountable human judgement, and the craft that makes verification possible.

6 min	The person the series kept meeting In autumn 2026 management bodies asked whether security decisions can keep pace with what now acts in the estate. The July 2026 incident failed on where a boundary was drawn and who could act on it, not on a model. Abolition, absorption and continuity are the rival answers; the thesis is transformation.
8 min	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. Code enables boundaries, boundaries enable speed, speed requires the AI team, and the AI team requires verification. Each shift fails when taken too far, and every failure removes the judgement the shift was meant to concentrate.
9 min	The boundary is the product A boundary is enforced outside the party it governs, owned, written as an artefact and tested; a system prompt is none of these. Instructions lower the rate of unwanted behaviour; only boundaries set a ceiling on its consequences. A control is verified only while a recent test and fresh evidence say so; otherwise it is declared or failed. Two first stop drills: 26 minutes against a budget of 15, and 17 against five. A measured shortfall can be fixed.
8 min	Decision rights before the pressure A role charter kept as code states what the architect decides, recommends, may veto and must escalate, each with a time limit. Decisions a rule can take belong at a gate; decisions that need judgement belong in a forum built to take them. The management body keeps the accountability the law names; the architect owes faithful mappings and honest evidence.
8 min	When AI drafts, verification is the constraint Agents draft and humans approve, as a property of the repository and not a habit. Soundness is defined in advance and checked by techniques that do not trust the proposer. Approvals in seconds are a failure of design, not of people; slow the agents instead of thinning the review. An action stays at Level 3 Bounded only while two architects could write its playbook unaided.
6 min	What remains, and what to do first What remains is smaller in volume and larger in consequence: deciding boundaries, verifying proposals and answering for both. Written authority before delegation, boundaries before speed, measurement before autonomy. Get decision rights in writing, time a stop path, and keep doing some of the work yourself.

What the audience takes away

The security architect's lasting product is a boundary that holds whatever anyone or anything inside it does, shown by a test from outside.
Delegation to gates and to AI is safe only with written decision rights, measured review quality and autonomy paced to the skills available to supervise it.
Accountability ends in a person, so the profession must remain the people who can tell when fluent is wrong.

Module 1 · Part I · The Role in Question

Part I asks what has happened to the security architect now that architecture is code and agents act in the estate. It frames the thesis that the role is transformed, not abolished, describes the inherited practice fairly, defines the four shifts with their evidence and failure modes, and ends with the role charter kept as code. Participants leave with a framed commission, an audit of their inherited practice, a shift assessment and a first set of written decision rights.

Lecture · 45 minutes

Transformed, not abolished: the security architect in question

The lecture carries the argument of Part I. In the autumn of 2026 management bodies began to ask whether security decisions can keep pace with what now acts in the estate. The lecture shows why the inherited practice of risk registers, reference documents and review boards was rational for its time and where it stopped scaling, defines the four shifts that replace its form while keeping its function, and closes on the role charter: written decision rights with time limits, and accountability attached to the boundary holding instead of to authorship.

7 min	The question that reached the board Three observable prompts: the July 2026 incident between OpenAI and Hugging Face, the Five Eyes call to act now, and agents changing production daily while architecture forums met fortnightly or monthly. None of the failures in the July incident was a failure of a model; each concerned where a boundary was drawn and who could act on it. Abolition, absorption and continuity each lead to a different budget and allocation of decision rights, which is why the question belongs to management bodies.
8 min	A coherent practice and its conditions ISO/IEC 27001 gave the risk frame, SABSA traceability, TOGAF a place in planning change; boards, reference architectures and signatures gave expertise, an answer to irreversibility and an accountable record. The conditions were annual cycles, a perimeter, a few hundred systems and adversaries working at human speed through human identities. Separate the function of the gate, independent challenge before an irreversible commitment, from its implementation as a meeting a project must pass.
12 min	Four shifts: medium, authority, tempo and authorship Shift 1, from documents to code, changes what the architect produces; Shift 2, from gatekeeper to boundary designer, changes how authority is exercised. Shift 3, from periodic to continuous, at machine speed, changes the tempo; Shift 4, from sole author to conductor of an AI team, changes who drafts. The shifts depend on one another: code enables boundaries, boundaries enable speed, speed requires the AI team, and the AI team requires verification, which requires code. Each fails when taken too far: code without judgement, boundaries without owners, speed without reversibility, an AI team that approves itself.
6 min	What remains scarce Accountable human judgement in three parts: authority to decide a boundary and answer for it, the ability to verify what code and AI propose, and the craft that makes verification possible. An agent can propose a boundary; it cannot answer for one. A boundary that looks right and is wrong is worse than none, because it is trusted.
8 min	The charter: rights, limits and time The mandate lists products, not activities: boundaries, policy decision points, the identity model, the control catalogue and stop paths. Four verbs, decide, recommend, veto and escalate, sit on four decision tiers with time limits, because a right to review without a limit is a right to delay. The architect is never a precondition for stopping a production agent; the stop holder on the incident rota acts. The approver is accountable for the approval and the gate author for what the gate lets through, so the chain never ends in an agent or a pipeline.
4 min	Two organisations, two versions of the question Nordvik Region: one post without written decision rights, boundaries held through tender annexes; the shifts are a sequence to start. Hansa Mutual: a team of six with architecture largely in code, blocked by a fortnightly board; the shifts are a sequence to repair.

What the audience takes away

The inherited methods were not mistakes; the transformed role replaces their form and keeps traceability, secure design principles, independent challenge and accountable sign-off.
The four shifts have a natural order, and Shift 4 must never run ahead of the containment that Shift 2 provides.
A role whose authority exists only in a job description cannot hold boundaries; a charter kept as code gives it testable rights with time limits.

Chapter 1 · 60 minutes

Introduction: The Security Architect Transformed

The lesson frames the book's question and thesis: the security architect is being transformed, not abolished. Participants meet the three prompts of autumn 2026, the three rival positions of abolition, absorption and continuity, the four shifts in brief, the three parts of accountable human judgement that remain scarce, and the European instruments that place duties someone must turn into architecture. They practise turning the question into a commission recorded as a decision record.

Learning objectives

Explain the thesis that the role is transformed, not abolished, and state what evidence would refute it under abolition, absorption and continuity.
Name the four shifts exactly and say which parts of the book carry each of them out.
Describe the three parts of accountable human judgement that the book says remain scarce.
Draft a commission for the security architect role as a decision record with a question, deliverables, a due date and constraints.

Key concepts

Transformed, not abolished: The thesis that the role 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 accountable conductor of an AI team.
Abolition, absorption and continuity: The three rival positions. Abolition lets machines generate and enforce boundaries and gives residual judgement to the CISO; absorption moves the content to platform engineering, governance and agent operators; continuity holds that the shifts are fashions. Each names evidence that would refute the thesis.
Accountable human judgement: What remains scarce, in three parts: accountability for a boundary, the ability to verify what code and AI propose, and the craft that makes verification possible, which the role must keep deliberately.
Architectural implication: The way the book reads law: each article of NIS 2, DORA, the AI Act or the Cyber Resilience Act becomes a boundary, a control, a test and a record only if someone designs them. Naming an accountable architect per boundary is expected practice, not a legal duty.
User and boundary designer: The architect's two relations to AI across the usage modes: using AI in Modes 1 to 3 under the architect's own identity differs in kind from designing identity, containment and stop paths for Mode 5 Autonomous production agents.

Teaching plan

10 min	The teacher presents the three prompts of autumn 2026 and asks participants which of them has already reached their own management body, and in what form.
15 min	Short lecture on the thesis, the three rival positions and the four shifts in brief, using Figure 1.1; participants note which shift they recognise most in their own work.
10 min	Group discussion of what remains scarce: accountability, the ability to verify and the craft, and why organisations cannot hire their way out.
20 min	Exercise: participants frame the question for their own organisation as a commission, following the practical guide, then compare it with AIDR-0500 and AIDR-0550.
5 min	Wrap-up: each participant reads out the one-sentence question a board could answer, and the group checks it names a decision.

Discussion

Which of the three rival positions, abolition, absorption or continuity, is argued most often in your organisation, and what observation would settle the matter there?
Nordvik's commission concerns one post's authority and budget, while Hansa's concerns throughput when actors are faster than the forum. Which of the two is closer to your situation, and why?
The chapter says a boundary that looks right and is wrong is worse than none, because it is trusted. Where in your estate could that already be the case?

Exercise · 20 minutes

Frame the commission as a decision record

Using the six steps of the chapter's practical guide, frame the question for your own organisation. Write down who is asking and why now. List the boundaries your AI and security decisions depend on and their owners, marking any that are unowned. List last year's decisions about those boundaries and how long each took. State the question in one sentence a board can answer, name the deliverables and a due date before a budget or board meeting, and record the constraints, such as pay scales, consultation duties and public-access rules.

Deliverable: A one-page decision record in the style of AIDR-0500 naming the question, the accountable person, the deliverables, the due date and the constraints, with the first two findings noted.

Self-test

According to the chapter, what did the failures in the July 2026 incident between OpenAI and Hugging Face concern?
1. A general-purpose AI model that behaved differently from its evaluation results
2. Where a boundary was drawn and who could act on it, not a failure of a model
3. A supplier that changed an ambient AI feature without notice to the deployer
4. A management body that had not approved its risk-management measures
Which three parts make up the accountable human judgement that the book says remains scarce?
1. Budget authority, supplier management and regulatory reporting
2. Document authorship, approval at the gate and the annual procured penetration test, as in the inherited role
3. Model evaluation, guardrail policy and agent permissions
4. Accountability, the ability to verify, and the craft that makes verification possible
How does the chapter treat the idea of naming an accountable architect for each boundary?
1. As an expected practice, not a legal duty, kept apart from observable law
2. As a duty that NIS 2 Article 20 places directly on security architects
3. As speculation that the book confines to its final two chapters
4. As a requirement of the ENISA Cybersecurity Architect profile

Chapter 2 · 60 minutes

What the Security Architect Did: The Role Before the Transformation

The lesson gives a fair account of the role before the transformation: risk-based management under ISO/IEC 27001, layered design with SABSA and TOGAF, review boards, reference architectures as documents and the reputation as the department of no. Participants learn the conditions those methods assumed, the five developments that strained them, and the four things the transformed role inherits. They audit an inherited practice and decide whether to keep, codify, delegate or retire each part.

Learning objectives

Describe the five inherited methods of the security architect and the conditions each assumed.
Explain the three legitimate purposes of the review board and why each survives the transformation.
Identify the five developments that strained the inherited practice, separating what is observable from what is expected.
Classify the practices of a security architecture function as keep, codify, delegate or retire, naming what covers each retired purpose.

Key concepts

Attested evidence: Evidence in which someone states in a spreadsheet that a control operated. The chapter calls attestation cheap to collect and expensive to trust, and notes that it ages from the day it is signed.
Three purposes of the review board: Scarce expertise concentrated and spread, a gate proportionate to the cost of reversing a design mistake, and an accountable record of who reviewed and who accepted the residual risk. Each survives at a different scale.
Function and implementation of the gate: The function is independent challenge before an irreversible commitment; the implementation was a meeting that a project must pass. The transformed role keeps the function and changes the implementation.
Keep, codify, delegate, retire: The four dispositions of the practice audit: keep when purpose and conditions hold, codify when a check could carry the form, delegate routine decisions to a named forum, pipeline or supplier with written decision rights, retire when the purpose is covered elsewhere or absent.
What the transformed role inherits: Four parts of the inherited content: traceability to business risk, the principles of secure design, independent challenge built into pipeline and record, and accountable sign-off by a named person with a decision right.

Teaching plan

15 min	Lecture on where the role came from and its methods, using Figure 2.1; for each method the teacher asks what condition of its time made it rational.
10 min	Discussion of the department of no: timing, asymmetry and culture, and what the evidence on external change approval does and does not show.
10 min	Walk through Nordvik's assessment RAA-NR-2026-01 section by section; participants predict each disposition before it is revealed.
20 min	Exercise: participants audit five recurring practices of their own function with the chapter's guide and record a disposition for each.
5 min	Wrap-up: pairs challenge one retirement each, asking which control, record or forum now covers its purpose.

Discussion

Which of the three mechanisms behind the department of no, timing, asymmetry or culture, weighs most in your organisation, and what would change the incentive?
The chapter says a stale layer is worse than an absent one, because readers trust it. Which document in your practice still carries authority that the estate no longer matches?
Nordvik has to build what Hansa already has, and Hansa has to remove what Nordvik never built. What does that contrast suggest about where your own transformation should begin?

Exercise · 20 minutes

Audit an inherited security architecture practice

Choose five recurring activities of your security architecture function, for example a review meeting, a reference architecture document, a supplier questionnaire, a hardening appendix and an exception letter. For each, state its purpose in one sentence using the gate's purposes (expertise, irreversibility, accountability) or the risk frame's (traceability, ownership, evidence). State the conditions it assumed, namely release frequency, number of systems, acting identity and adversary speed, and mark each as holding, partly holding or no longer holding. Classify each practice as keep, codify, delegate or retire. For every retirement, name the control, record or forum that now covers its purpose.

Deliverable: A practice audit table of five rows in the form of the chapter's practice-audit example, with purpose, conditions, disposition, what covers the purpose and a review date.

Self-test

What did Forsgren, Humble and Kim find about approval of changes by an external body, as the chapter reports it?
1. It was associated with slower delivery and no better stability than peer review and automated checks
2. It was associated with slower delivery but clearly fewer failed changes in production
3. It made no measurable difference to either delivery speed or stability
4. It improved stability, but only in organisations that deployed between once a month and once every six months
In Nordvik's assessment of its 2024 security reference architecture, what happened to section 6, logging and monitoring?
1. It was kept unchanged because it was technology-neutral
2. It was retired in favour of supplier baselines referenced by version
3. It was delegated to the managed security service provider under NR-2025-044
4. It was codified as a containment profile for the AI gateway
Which assumption of the inherited methods does a Mode 5 Autonomous production agent break?
1. That suppliers deliver products and not services
2. That every action traces to a person or a person-owned service account
3. That the management body reviews the system at planned intervals
4. That each control traces to a business attribute

Chapter 3 · 75 minutes

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

The lesson defines the four shifts precisely: what each is, the evidence for it, what it changes and leaves unchanged, and how it fails when taken too far. Participants learn why there are four and not fewer or more, how the shifts depend on one another, and which artefact makes each concrete. They rate a practice on a four-stage scale using evidence only and apply the dependency checks that flag an AI team running ahead of its containment.

Learning objectives

Define each of the four shifts by what it changes: the medium, authority, tempo and authorship of the architect's work.
Distinguish which claims about each shift the chapter labels observable, expected or speculation.
Explain how the shifts depend on one another and name the failure mode of each.
Assess a security architecture practice on the four-stage scale with evidence links and dependency flags.

Key concepts

Boundary: A place where a rule is enforced by something other than the party it governs, with a named owner and a test. It is the central product of Shift 2, from gatekeeper to boundary designer.
Dependencies between the shifts: Code enables boundaries, boundaries enable speed, speed requires the AI team, and the AI team requires verification, which requires code. The natural order is Shift 1, then 2, then 3, with Shift 4 never ahead of its containment.
Four failure modes: Code without judgement, boundaries without owners, speed without reversibility and an AI team that approves itself. Each looks like success from inside and removes the human judgement the shift was meant to concentrate.
Four-stage scale: Stage 0 inherited, stage 1 starting with at least one artefact or decision in the new form, stage 2 established as the default in scope, and stage 3 verified, meaning tested, measured and reported.
Dependency check: A flag raised when Shift 4 is rated above Shift 2, because the AI team's autonomy then outruns its containment, or Shift 3 above Shift 1, because continuous measurement of what is not code usually rests on attestation.

Teaching plan

20 min	Lecture on Table 3.1: for each shift the teacher gives the definition, the recognition test, the evidence and its label, and what does not change.
10 min	Participants explain in pairs why a nightly pipeline is Shift 2 without Shift 3, and why an on-call architect who approves within minutes is Shift 3 without Shift 2.
10 min	Group work on the failure modes: each group takes one, describes how it would look like success from inside, and states the chapter's remedy.
30 min	Exercise: participants run the shift assessment for their own practice or for Hansa Mutual, rating on evidence only, and present their dependency flags.
5 min	Wrap-up: the teacher compares the results with AIDR-0509 and AIDR-0551 and the order of next steps each implies.

Discussion

Hansa Mutual is far along Shift 4 while still blocked on Shift 2. What risks follow from that order, and how would you explain the urgency to an executive board?
The chapter says Shift 3 has no artefact of its own because it is a property of the others. What does that mean for how you would report progress on it?
Which of the four failure modes would be hardest to notice from inside your organisation, and what measurement would reveal it?

Exercise · 30 minutes

Locate a practice on the four shifts

Follow the chapter's practical guide for your own security architecture practice. Sample the last 20 security architecture decisions, or all from the last quarter if fewer. For each shift, answer the indicator questions and assign a stage from 0 to 3. Rate on evidence only: a rating needs a link to an artefact, measurement or record no older than 90 days, and without one you take the lower stage. Apply the two dependency checks and state any flag. List the gaps and name the artefacts that would close each. If you have no practice to assess, reconstruct Hansa Mutual's assessment from the chapter and justify its single flag.

Deliverable: A shift assessment in the form of the chapter's example: a stage, evidence and gaps for each of the four shifts, the dependency flags and a list of next steps.

Self-test

Why does the chapter hold that 'from perimeter to zero trust' is not a fifth shift?
1. Because zero trust is not yet observable in European organisations and so cannot count as evidence for a shift
2. Because it applies only to Mode 5 Autonomous production agents
3. Because it describes content, one answer to Shift 2, and not a change in the role
4. Because it is already contained in Shift 3 as a measured property
How does the chapter label the effect of Shift 4 on the quality of architecture decisions?
1. Observable, on the adoption figures of the 2025 DORA research
2. Expected to be positive, because developers were faster in a controlled experiment
3. Expected to be negative, on the research on automation bias
4. Not established by any study found, so claims in either direction are speculation
In the shift assessment, what does it mean when Shift 4 is rated above Shift 2?
1. The AI team's autonomy outruns its containment, which raises a dependency flag
2. Continuous measurement of what is not code rests on attestation, which lowers the Shift 3 rating
3. The organisation may move its agents to Level 4 Autonomous
4. The peer reviewer must lower the Shift 4 rating to stage 0

Chapter 4 · 90 minutes

The Transformed Role Defined: Mandate, Accountabilities and Decision Rights

The lesson defines the transformed role as a role charter kept as code in roles/security-architect.yaml. Participants learn why a charter differs from a job description, what the mandate lists, how accountability attaches to the boundary holding and not to authorship, how the four decision rights sit on four tiers with time limits, what the role does not do, and who answers for what agents propose. They draft charter entries and test them against real decisions.

Learning objectives

Explain why the role is defined by a charter kept as code and what three properties that adds.
Distinguish accountability for a boundary from authorship of its artefacts, and name the three parts of that accountability.
Assign decide, recommend, veto or escalate to a decision class with a tier and a time limit.
Test a draft charter against past decisions and classify each result as resolved, ambiguous or too slow.

Key concepts

Role charter: A machine-readable statement of the mandate, accountabilities, decision rights with time limits, escalation paths, owned artefacts and exclusions of the role, precise enough to settle a contested decision. A job description describes a person; a charter describes what the role may decide and stop.
Accountability for the property: The charter attaches accountability to the boundary holding, in three parts: the design is adequate for the accepted risk, verification shows it holding, and risk owners have been advised in time and in plain language when a boundary cannot be held within appetite.
Decide, recommend, veto, escalate: The four verbs of decision rights. They sit on tier 1 pipeline gates, tier 2 design authority, tier 3 AI governance board and tier 4 management body, each with a time limit; a veto not exercised in time lapses to the escalation path.
Narrow veto: A veto limited to properties that are expensive to restore once a contract is signed or a system is live, such as a missing stop path or egress limit, judged against a short, testable criterion and subject to recorded override by a named higher authority.
The approval rule: The person who approved is accountable for the approval, and the person who designed the gate is accountable for what the gate lets through. An agent that drafted a change proposed it and is accountable for nothing.

Teaching plan

15 min	Lecture on why a charter and why as code, the mandate as products, and the seam between the security architect and the AI architect for agents.
15 min	The teacher walks through the decision-rights table; participants explain the two commented rows on stopping a production agent and stopping the architect's own agents.
15 min	Compare the charters ROLE-NR-SA-01 and ROLE-HM-SA-AI: what a single post needs and what a team of six needs, and who can override each veto.
35 min	Exercise: participants draft decision rights for their own role and test them against five past decisions, revising every ambiguous or too-slow case.
10 min	Debrief on the four exclusions and on Hansa's test case in which a stop took 22 minutes because the runbook treated the architect's confirmation as a precondition.

Discussion

The chapter says a right to review without a limit is a right to delay. Which of your current review rights would lapse if a time limit were attached, and what would be lost or gained?
Why does the charter deny the architect the right to accept residual risk, and what happens in a small organisation where one person both designs and operates?
Nordvik turns every right that would let one person approve their own work into a recommendation to the CISO. How would you handle the same problem in a function with a single post?

Exercise · 35 minutes

Draft and test charter decision rights

Collect ten decisions that your security architecture role took, influenced or was blamed for over the last year, including at least one contested decision, one slow decision and one supplier decision. Group them into decision classes. For each class assign a verb, defaulting to recommend, granting decide where the catalogue already sets the standard and veto only for properties expensive to restore, together with a tier and a time limit: working days for design decisions and minutes for anything touching a running agent. Write three exclusions under a heading of what the role does not do. Then resolve five of the past decisions against your draft and classify each as resolved, ambiguous or too slow, changing the draft for every case that fails.

Deliverable: A draft charter section listing decision classes with verb, tier, time limit and override holder, three exclusions, and a five-row test table showing resolved, ambiguous or too slow.

Self-test

Under the chapter's default decision rights, what is the architect's right when an agent or system in production must be stopped?
1. Decide, within two working days of the request being made
2. Veto, subject to a recorded override by the CISO
3. Recommend to the stop holder, never as a precondition
4. Escalate to the management body at tier 4 within minutes
Where a gate merged a delegated change class without human approval, who answers under the charter's rule?
1. The agent that drafted the change, because it proposed it
2. The pipeline's platform team, because it operates the gate
3. The system owner alone, because the owner accepted the residual risk when the change class was delegated
4. The gate policy's author for its adequacy, and the delegating forum for the delegation
What ceiling does Nordvik's charter ROLE-NR-SA-01 place on the architect's own AI use?
1. Level 0 Advisory, in Mode 1 only
2. Level 1 Assisted, in Modes 1 and 3 under MND-NR-01
3. Level 2 Supervised, in Modes 1 to 3 under MND-NR-01
4. Level 3 Bounded, for reversible repository edits

Module 2 · Part II · The Craft

Part II is the craft of the transformed security architect. Seven lessons move the work from documents to executable design: the architecture model and policy as code, threat models generated on every change, boundaries and containment that hold whatever an actor intends, identity for workloads and agents, the control catalogue with its evidence, time as a design property, and recoverability. Participants leave with the artefacts themselves: a boundary rule, a threat model entry, a containment profile, an identity record, a control entry, a timed stop drill and a reversibility test.

Lecture · 50 minutes

The craft: boundaries that hold, shown to hold, in time

The lecture follows one question through Part II: how does an architect make a claim about security that is true on every change and can be shown without anyone's cooperation? It starts from the model kept as code and the pull request as the unit of change, generates the threat model from it, turns threats into boundaries enforced outside the party they govern, anchors every actor in a registered identity that leads to named people, classifies every control as verified, declared or failed, and ends with the two properties periodic review never measured: how fast the estate can stop, and what it can return to.

8 min	From the reference document to the model A document keeps the views and loses the architecture beneath them; a model keeps the architecture and generates the views. A property that nothing tests is a comment: completeness, boundary and content rules make the model executable. The architect writes the principle once and the pipeline applies it to changes the architect never saw; review triggers bring only boundary changes to a named person.
7 min	The threat model that regenerates A workshop document describes the system on the day of the workshop; regeneration on every change that moves a boundary shows each significant change was considered. Every place where content can enter a model's context is a trust boundary, and the lethal trifecta gives agentic systems a one-line test. The generator works at Level 1 Assisted; no AI accepts a threat, a risk or an exception.
10 min	Boundaries and identity: verify the action and the actor A boundary is enforced outside the party it governs and states a ceiling on consequences; instructions lower the rate of unwanted behaviour but set no ceiling. The July 2026 incident: a mirror is an egress path, and a credential shared across runs makes every run a potential correspondent of every other. Blast radius is a design parameter with five dimensions, and the weakest dimension sets the radius. Every machine identity leads to an owner, operators and an authority who are named people; delegation is required and impersonation prohibited for agents.
8 min	Verified, declared or failed A control entry is complete when a stranger can tell what it does, who is accountable, where it is implemented, how it is tested and where the proof is. There is no amber: a rule derives the status, nobody types it in, and controls with a shared dependency count as one. An architect who designs a control and also declares that it works marks their own work; the test and the independent auditor give the opinion.
9 min	Time as a design property The estate clock has four intervals, notice, decide, act and verify, and in most estates the time goes in the decide interval. Patch velocity becomes a service level per class, and decisions for known-exploited vulnerabilities are delegated in advance under conditions the pipeline enforces. Hansa's first timed stop drill took 17 minutes against a budget of five; Nordvik's took 26 against 15. A measured shortfall can be fixed, and an untested claim cannot.
8 min	What the estate can return to A recovery plan states an intention; recoverability is the measured ability to carry it out, from complete, signed definitions held outside the blast radius. A recovered AI system is one shown to behave as it did before the incident, not merely one that is running. The fallback erodes between tests, so the fallback manifest is a designed artefact with weekly checks, and chaos experiments move recovery controls from declared to verified.

What the audience takes away

The architect's judgement moves from reading each design to choosing which principles deserve a rule and judging the exceptions.
Containment must not depend on intent: every boundary, identity and stop path is enforced and tested from a position the contained party cannot influence.
A control, a time to stop and a recovery are verified only while a recent test and fresh evidence say so; everything else is declared.

Chapter 5 · 75 minutes

Security Architecture as Code: From Documents to Executable Design

The lesson shows how security architecture becomes executable design: an architecture model kept as code with security properties on its elements, policy as code that fails a pull request when a principle is broken, decision records beside the code, and drift comparison against the running estate. Participants learn the three kinds of rule, the three mechanisms that decide who reviews a change, and which four kinds of document remain. They specify properties and a boundary rule for a small model.

Learning objectives

Explain four ways a reference document fails the architect and what a model kept as code offers instead.
Assign the security properties trustZone, dataClass, identity, usageMode, policyPoint and owner to the elements and relationships of a small estate.
Distinguish completeness rules, boundary rules and content rules and state what each checks.
Design the review path for an architectural pull request using policy checks, review triggers and decision rights.

Key concepts

Security properties on model elements: Named properties such as trustZone, dataClass, identity, usageMode, policyPoint and owner that turn a diagram into a security model. Each must be testable by a rule, and a closed vocabulary matters more than a rich one.
Completeness, boundary and content rules: Completeness rules require every element to carry the properties other rules need; boundary rules require a relationship between two zones to name an existing policy point; content rules restrict what may sit where, for example that a Mode 5 agent has an identity of its own.
Pull request as unit of change: An architectural change arrives as a pull request carrying the model diff, policy-check results, the linked decision record and a named author. Policy checks decide routine cases, review triggers route boundary changes to the architect, and decision rights set how long review may take.
Drift: The difference between model and estate, in two directions. An estate element the model lacks gives false assurance; a model element the estate lacks is mostly hygiene but hides the first kind. Each finding becomes a pull request and the drift rate is reported.
What remains a document: Generated narratives, rationale in decision records, policy statements for people and contracts. The test is whether a person will read it to decide or to act; if a rule could answer the question, the rule is the artefact.

Teaching plan

15 min	Lecture on the four failures of the reference document and the model that generates views, using Figure 5.1 and the question about what crosses into the core claims system.
15 min	Walk through Hansa's workspace fragment and boundary rule in plain language; participants predict what happens when a team adds a direct relationship from the agent to the core claims system.
10 min	Discussion of Nordvik's ownership file as a risk register: why a path with a single owner is a finding in its own right.
30 min	Exercise: participants model the zone crossings of one system, mark principles as testable or not, and write the boundary rule and review triggers in plain language.
5 min	Wrap-up on what stays with the architect: choosing which principles deserve a rule and judging the exceptions.

Discussion

The chapter expects about half the sentences in a reference document to be testable. What does that suggest about the other half, and where should that reasoning live?
Hansa's review board still reviews documents generated beside the model, so its decisions and the model can disagree. How would you resolve such a disagreement, and who should own the outcome?
Nordvik models its supplier's system as a single black-box element with contractual properties. What can such an element assert, and what can it not?

Exercise · 30 minutes

From reference document to model and rule

Take one section of your security reference architecture, or use Nordvik Region's zones and its supplier TriageSoft. List every sentence that states a principle and mark it as testable now, testable with a new property, or not testable. Define a closed vocabulary of three to six trust zones and three to four data classes. Model only the flows that cross a zone boundary, giving each element a stable name, a trust zone, an owner and, for AI elements, a usage mode, and each crossing a policy point. Write in plain language one completeness rule and one boundary rule, and list the protected paths with two owners each.

Deliverable: A one-page model sketch with properties on elements and crossings, a marked list of principles, two rules in plain language and an ownership table with a second owner on every protected path.

Self-test

In Hansa's worked example, a product team adds a relationship from the claims-triage agent directly to the core claims system. What happens?
1. The boundary rule reports a zone crossing without a policy point, and the pull request cannot merge
2. The fortnightly review board is convened to read the changed diagram
3. The change merges, and the drift comparison reports it as a finding to be corrected within the 30-day age limit
4. The completeness rule fails because the agent has no trustZone property
Why does the chapter say a closed vocabulary matters more than a rich one for model properties?
1. Because Structurizr limits the number of properties an element may carry
2. Because auditors can only review a short list of trust zones
3. Because a rule cannot test a property that two teams spell differently
4. Because DORA Article 8 prescribes a fixed list of asset classes
How does Hansa Mutual treat an agent identity found in the estate that the model does not contain?
1. As hygiene, to be cleared at the next quarterly review
2. As an exception that the platform team may approve
3. As a reason to switch the boundary rule to report-only mode
4. As a finding for the identity domain architect on the day it is found

Chapter 6 · 90 minutes

Threat Modelling Transformed: Continuous, Generated and AI-Assisted

The lesson shows how threat modelling changes from a workshop document to a model generated from the architecture repository, regenerated when a boundary moves and enforced by the pipeline. Participants learn the shared vocabularies, the six recurring trust boundaries of AI systems, the lethal trifecta, the limits of an AI generator at Level 1 Assisted, and the four decisions a named reviewer can take on a candidate. They write and decide threat entries for an agentic system.

Learning objectives

Explain why a regenerated threat model can show what an annual workshop cannot, and what the workshop is still for.
Identify the six recurring trust boundaries of an AI system and the legs of the lethal trifecta an agent holds.
Decide candidate threats as accepted, reclassified, rejected or deferred against the soundness criteria, recording a reason.
List the conditions under which the threat-model gate fails a merge.

Key concepts

Two layers of generation: A deterministic layer emits a boundary record and STRIDE threat stubs for every relationship crossing a trust zone and compares them with the last accepted model; an AI layer adds candidates the rules cannot derive. Each threat keeps an identifier that survives regeneration.
Lethal trifecta: Simon Willison's test for agentic systems: an agent with access to private data, exposure to untrusted content and the ability to communicate externally can be steered into disclosing the data. The model records which legs are present and which control removes the others.
Vector as a class of behaviour: A threat entry records the vector as a class of behaviour and never as an operational recipe. That is enough to design a control, a detection and a test, and keeps the model shareable with a supplier, an auditor and a works council.
Reviewer decisions: A named person accepts each candidate, reclassifies it, rejects it with a reason and a revisitWhen trigger, or defers it to an owner and a date after which the pipeline blocks. Accepting residual risk is a separate decision for the risk owner.
verifiedBy: The field that points an accepted threat to an attack case described by its set-up and expected outcome. A threat without one is declared, not verified, because an accepted threat that nothing tests is a belief.

Teaching plan

15 min	Lecture on the four questions, why the snapshot is harder to defend, and the five vocabularies with their limits; participants match STRIDE, ATT&CK, ATLAS and D3FEND to harm, route and answer.
15 min	The teacher walks the six AI trust boundaries and the lethal trifecta; groups record the legs held by an agent they know and the control that cuts one.
15 min	Read Hansa's threat model for the claims-triage agent: why T-101 is accepted, T-102 reclassified and T-103 rejected with a revisit trigger.
35 min	Exercise: participants write three threat entries for a changed boundary, decide each as a named reviewer and check them against the gate rules.
10 min	Debrief on review quality: provenance beside each candidate, a reason with every acceptance, and sampling by a second reviewer.

Discussion

The gate rule that fails when a boundary changed without any threat considered is called the most valuable. Why can a reviewer who reads only candidates not see that failure?
A long list of fluent candidates invites complacency and automation bias. What in the design of the review loop would you change to counter that in your own team?
Nordvik models a few systems in depth because its reviewers are few; Hansa needs generation because no person can read every pull request. Which constraint governs your choice of method?

Exercise · 35 minutes

Decide three candidate threats for a changed boundary

Work on Hansa Mutual's claims-triage agent, or on an AI system you know, after a change that adds a new intake path for third-party content. Record which legs of the lethal trifecta the system holds and which control cuts the remaining one. Write three candidate threats for the changed boundary. For each give a stable identifier, the boundary, a STRIDE category, the vector as a class of behaviour with no adversary strings, and a mitigation family outside the model. Then act as the named reviewer: accept, reclassify, reject with a reason and a revisit trigger, or defer with an owner and a date. For each accepted threat name an owned control and describe an attack case by its set-up and expected outcome.

Deliverable: A threat model excerpt with the trifecta record and three decided entries, each with reviewer, reason, controls and a verifiedBy attack case where accepted.

Self-test

At which autonomy level does the chapter place the AI generator of candidate threats by default?
1. Level 0 Advisory, with no access to the repository
2. Level 1 Assisted, writing only to a pull request comment
3. Level 2 Supervised, writing accepted items directly
4. Level 3 Bounded, accepting low-risk threats within a playbook
In Hansa's threat model, why is T-103, claim data leaving through an outbound channel, rejected?
1. Because the threat-modeller agent classified it under the wrong STRIDE category
2. Because the risk owner accepted the residual risk with an expiry date
3. Because the attack case in HM-SEC-003 passed in the last campaign
4. Because the manifest holds no outbound tool, and revisitWhen brings it back if one is added
Which mitigation does the soundness criterion on the right family explicitly rule out as a replacement for a control?
1. Improving the system prompt in place of a control outside the model
2. Entitlement filtering on the retrieval index
3. Task-scoped credentials for tool calls
4. Schema validation of output before it is written into a system of record

Chapter 7 · 90 minutes

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

The lesson treats the boundary as the security architect's main product. Participants learn its four properties, how zero trust is extended to agents by verifying the action as well as the actor at a policy decision point outside the model, why relays are egress paths, how correlated controls fail together, the six elements of containment that does not depend on intent, and blast radius as a design parameter. They design a containment profile and review it for shared dependencies.

Learning objectives

State the four properties of a boundary and explain why a system prompt has none of them.
Review a boundary for correlated controls, treating every service that relays for its clients as an egress path.
Design a containment profile for an agent using the six questions, with a checkable blast radius statement.
Specify tests that show a boundary holds from a position the contained party cannot influence.

Key concepts

Four properties of a boundary: A boundary is enforced outside the party it governs, states a ceiling on consequences instead of a hope about behaviour, is an artefact with an owner, a version history and a test, and can be shown to hold without the cooperation of what it contains.
Policy decision point outside the model: Deterministic code between model and tool servers that evaluates every tool request against a versioned permission manifest. It decides on structured facts such as tool, arguments, identity and target, never by a classifier judging whether output looks harmful.
Correlated controls: Controls that share a dependency, such as a credential, a shared service or the administrative plane, so that one failure defeats two or more. The chapter treats a correlated control failure as a design defect the architect can look for.
Blast radius: The largest harm an actor can cause with the permissions it holds before it is stopped, determined by reach, rate, duration, reversibility and spread. The weakest dimension sets the radius, and the architect writes it as a statement a reviewer can check.
Containment profile and permission manifest: The manifest is the agent's declared intent: purpose, identity, tools, constraints, approvals and budgets. The profile is the platform's commitment whatever the agent attempts. The profile must be at least as strict as the manifest and must not depend on the manifest being obeyed.

Teaching plan

15 min	Lecture on the boundary's four properties and on zero trust extended to agents; the teacher uses the July 2026 incident to show a mirror acting as an egress path.
15 min	Groups read the evidence on instructions and scope statements and explain in their own words why instructions lower the rate but set no ceiling.
15 min	Walk through CP-HM-ITOPS-01 and the tender annex TA-NR-S4: participants find the blast radius statement, the stop holders and the tests the Region can run without the supplier's cooperation.
35 min	Exercise: participants answer the six questions for a new agent, write its profile and run the correlated-controls review on it.
10 min	Debrief: each group states its blast radius in one sentence and names the weakest dimension; the others challenge whether it can be checked.

Discussion

A stop instruction sent to an agent is merely a request the agent processes. What in your estate is currently called a stop path but would not act if the system did not cooperate?
Nordvik must verify by evidence what it buys, and Hansa what it builds. What can a tender annex with verification rights achieve that a supplier questionnaire cannot?
The chapter says to fix a shared dependency instead of adding a compensating control. When is that advice hard to follow, and what should the decision record then say?

Exercise · 35 minutes

Design a containment profile in six questions

Choose an agent your organisation runs or plans, or take a hypothetical operations agent at Hansa Mutual. Answer the chapter's six questions: what may the agent change, with each write's target and reversibility; which legs of the trifecta it holds and which is removed; where it may send things, as a default-deny allow-list with relays treated as egress paths; what it borrows, such as credentials, shared services and log sinks; how much it can do before a person sees it, as budgets for steps, time, spend and writes; and who stops it and how that is shown. Write the blast radius as one checkable sentence. Then list each control's dependencies and mark any that appear under two controls or that the agent can reach.

Deliverable: A containment profile in the form of CP-HM-ITOPS-01 with ceiling, egress, blast radius statement, dependencies, stop holders and tests, plus a list of correlated-control findings with owners.

Self-test

What does the chapter mean by extending zero trust to agents?
1. Granting agents the same network location trust as managed devices
2. Asking a classifier to judge whether each output looks harmful
3. Verifying the action as well as the actor, at a policy decision point outside the model
4. Requiring agents to confirm in their instructions, before every tool call, that they will stay within scope
What did the review recorded as AIDR-0552 change in the containment of Hansa's IT-operations agent?
1. It raised the write budget from four to twenty actions per incident
2. It restricted the shared artefact mirror to a signed allow-list and removed it from the agent's destinations
3. It moved the stop decision from the on-call engineer to the review board
4. It replaced the weekly egress probe from outside the agent's network with a quarterly attestation by the profile's owner
According to the chapter, what happens to a control's classification when its boundary test fails or becomes overdue?
1. It stays verified until the owner confirms the finding in writing
2. It is removed from the catalogue until the next audit
3. It is marked amber and reported to the design authority
4. It moves from verified to declared automatically

Chapter 8 · 75 minutes

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

The lesson covers identity architecture for workloads and agents. Participants learn why distributed secrets are replaced by attested, short-lived identities issued outside the runtime, how to choose between an agent's own identity and a person's, how delegation differs from impersonation, why every machine identity leads to an owner, operators and an authority, how approvals are made to resist synthetic media, and the lifecycle from registration to retirement. They register an agent identity and trace an action back to a named person.

Learning objectives

State the four requirements for workload identity and explain why one identity per workload is the lesson of the July 2026 incident.
Choose between an agent's own identity, delegation and a person's identity for a given action, using the chapter's design test.
Draft an identity record for an agent with scopes, token lifetime, named roles, revocation and review.
Design an approval rule that holds against synthetic media using call-back, dual control and out-of-band confirmation.

Key concepts

Attested workload identity: An identity issued from outside the workload after attesting it from properties of its platform, short-lived and one per workload, so that a log line names exactly one actor and a revocation stops exactly one. SPIFFE and SPIRE are the chapter's reference.
Delegation versus impersonation: In OAuth 2.0 Token Exchange, impersonation makes the holder indistinguishable from the subject, while delegation identifies both and names the acting party in the act claim. The architect requires delegation and prohibits impersonation for agents so the audit trail keeps both visible.
Owner, operators and authority: The three kinds of person behind every machine identity. The owner answers for its existence and purpose, the operators watch it and can revoke its credentials, and the authority approves scope and autonomy level and accepts residual risk, and is never the agent's builder alone.
Approvals that resist synthetic media: Call-back through a contact from a trusted register, dual control by a second approver who did not receive the request, and out-of-band confirmation in an authenticated system of record, bound to changes in who or what may act as well as to payments.
Reconstruction exercise: Take an action from the last quarter at random and trace it to the person who answers for it without asking the agent anything. If the trace stops at an account, a team mailbox or a shared credential, the identity model has a design defect.

Teaching plan

15 min	Lecture on non-human actors, the failures they share and the four requirements for workload identity; the teacher ties one identity per workload to the shared credential of the July 2026 incident.
10 min	Participants apply the design test to five example actions and choose the agent's own identity, delegation or the person's identity for each.
15 min	Read the identity record HM-EVC-001 and the call-back rule CBR-NR-BEN-01; find the denied permissions, the revocation target and the reason the contact register is fixed at contract signature.
25 min	Exercise: participants register an identity for one agent and run a paper reconstruction of one of its actions back to a named person.
10 min	Debrief on the lifecycle and on the rule that a missed review disables the identity, including who the deputy is where there is a single post.

Discussion

The chapter calls collapsing agent and person into a single identity the most common mistake in AI integrations. Where does that happen in your estate, and whose accountability does it destroy?
At Level 3 Bounded, accountability concentrates on the authority who signs the playbook. How would you explain that to a manager who believes automation spreads the responsibility?
A missed review disables the identity by default. What operational objections would you expect, and how does the chapter's reasoning on improper offboarding answer them?

Exercise · 25 minutes

Register an agent identity

Choose one agent or automated workload that acts in production in your organisation, or use an evidence-collection agent of the kind Hansa Mutual runs. Follow the chapter's practical guide. Write the purpose in one sentence and choose the identity type. List the scopes as resources and actions, each with its autonomy level, starting read-only, and deny by name what an intruder would want most. Set the token lifetime and what the token is bound to. Name the owner, at least two operators and the authority as roles bound to holders, with different people as owner and authority. Define revocation by a path outside the agent's runtime with a target time, the review interval and what happens on a missed review. Then trace one action from token to named person.

Deliverable: An identity record in the form of HM-EVC-001 and a five-step reconstruction trace from one logged action to the person who answers for it.

Self-test

What revocation target does the chapter's practical guide set for a Mode 5 agent, by a path outside the agent's runtime?
1. 5 minutes, the same as the token lifetime
2. 15 minutes, the default token lifetime
3. 24 hours, after a cooling-off period
4. 60 seconds, tested by a revocation test
In Nordvik's call-back rule CBR-NR-BEN-01, why is the contact register fixed at contract signature?
1. Because public-access rules forbid later changes to supplier records
2. Because that was the one moment when the Region verified who TriageSoft's people are
3. Because the supplier's staff are not allowed to change during the contract
4. Because the European Digital Identity Wallet requires a fixed register
How does the chapter describe the rule that Level 4 Autonomous is never used for irreversible actions, in terms of identity?
1. As a rule of issuance: the broker issues no Level 4 token for an action the register classes as irreversible
2. As a rule of intent: the agent is instructed never to propose such actions
3. As a rule of review: the fortnightly board samples every Level 4 action afterwards and reverses those it rejects
4. As a rule of ownership: only the owner may request a Level 4 token

Chapter 9 · 90 minutes

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

The lesson makes the control catalogue, the evidence manifest and the assurance relationship the architect's artefacts. Participants learn the anatomy of a complete control entry, how one control is mapped once to many obligations, where evidence comes from and why it has a maximum age, the rule that classifies controls as verified, declared or failed, why shared dependencies count as one, and how the auditor's work changes. They write a control entry and classify a set of controls.

Learning objectives

Explain which three connections the architect owns in the catalogue and where that ownership stops.
Write a complete control entry with a falsifiable objective, an implemented_by path, a test, evidence with a fail condition and reviewed mappings.
Classify controls as verified, declared or failed by rule and open a finding for every status other than verified.
Describe how a catalogue as code changes the work of the auditor while preserving independence.

Key concepts

Falsifiable objective: One sentence that a test can disprove, such as: an agent cannot call a tool that its manifest does not name. A sentence such as 'access is appropriately managed' cannot be tested and so cannot be verified.
Assure once, comply many: A control is written once and mapped to every obligation it serves, each mapping with its relation, reviewer and date. Written four times it would drift into four controls; mapped four times it is tested once and the result serves every column.
Fail condition and maximum age: The fail condition names the observation that would prove failure, since a query that describes success invites confirmation. The maximum age turns a control declared the day its evidence expires, which also catches a collector that silently stops.
Verified, declared, failed: Verified: test passed within cadence and machine-generated evidence within its maximum age. Declared: no recent passing test, stale evidence or attestation only. Failed: the last test failed or the evidence query returned its fail condition. There is no amber.
Shared dependency: Two controls that depend on the same tool gateway or model provider fail together, so the coverage view counts controls with a common dependency as one. Counting controls is not the same as counting protection.

Teaching plan

15 min	Lecture on why the catalogue is the architect's artefact and where the ownership stops, using Figure 9.1 and the fields of a control entry.
15 min	Read CTRL-AGT-002 together: participants locate the objective, the fail condition, the maximum ages, the mappings and the pending-review mappings owned by local security officers.
15 min	Classify Nordvik's first ten entries before revealing the statuses, then discuss why supplier-held controls start as declared and what the failed entry is used for.
35 min	Exercise: participants convert three spreadsheet rows into control entries and derive a status for each, opening findings where needed.
10 min	Debrief on the architect and the auditor: read-only access, tests that can be re-run and reasoning written in pull requests.

Discussion

A declared entry is a known gap, not an error. How would your management review react to a first report in which most controls are declared, and how would you prepare it?
The chapter says evidence a system produces about itself is weaker than evidence from outside it. Which of your current evidence sources would fail that test?
Hansa brings the United Kingdom and Swiss mappings into the catalogue as entries the local security officers own. Why does the chapter keep authorship with them?

Exercise · 35 minutes

From spreadsheet row to control entry

Take three rows from your organisation's ISO/IEC 27001 Annex A spreadsheet or statement of applicability, or three supplier-held controls of the kind in Nordvik Region's catalogue. Remember that a row is a requirement and an entry is a control. For each, write an entry with a stable identifier, one falsifiable objective, the owner and the architect, the threats it answers, an implemented_by path to a real configuration, policy rule or contract clause, a test with its cadence, an evidence source with a fail condition and maximum age, and the obligations it maps to with relation and reviewer. Apply the classification rule to each and open a dated finding with an owner and a re-test for every declared or failed control.

Deliverable: Three control entries in the form of CTRL-AGT-002, each with a derived status, and a findings list for every entry that is not verified.

Self-test

Who or what sets the status of a control in the chapter's design?
1. A rule applied in the pipeline, owned by the architect and reviewed by the CISO
2. The control owner, who types it in after each test
3. The evidence-collection agent, which may promote controls it has checked
4. Internal audit, at the annual management review
In the first report from Nordvik's catalogue, why is CTRL-LOG-001 classified as failed?
1. The supplier TriageSoft had provided only a written statement, with no evidence the Region could collect itself
2. The evidence for the control was older than its maximum age
3. A replay found the managed security service provider's detections cover only some Region scenarios
4. The entry had no owner and so did not pass the validator
What does the coverage view say about CTRL-AGT-002 enforcing three agents' permission manifests through the same tool gateway?
1. That the three agents are protected by three independent controls
2. That the gateway is one point of failure, leading to a second independent control or an accepted risk
3. That the control must be split into one catalogue entry per agent, each with its own test and separate evidence
4. That the control answers no threat and is a candidate for retirement

Chapter 10 · 90 minutes

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

The lesson adds time to the properties the architect owns. Participants learn the evidence for the collapsing exploitation window and how it is labelled, the four intervals of notice, decide, act and verify, patch velocity as a service level built from EPSS, KEV, the EUVD and exposure, decisions delegated in advance under enforced conditions, detection and canaries designed in, and the stop path as a timed property. They set service-level classes and design a timed stop drill.

Learning objectives

Explain the four intervals of the estate clock and why the decide interval usually holds most of the time.
Define patch-velocity classes from public signals and exposure, each with a target and a decision path.
State the conditions under which a patch or containment decision can be delegated in advance.
Design a timed stop drill with a budget, instrumented intervals, named stop holders and a pass criterion.

Key concepts

Notice, decide, act, verify: The four intervals of the estate's clock: until someone who can act knows, until someone with the right has chosen, until the control is in effect, and until independent evidence shows the effect. A total alone hides where the time goes.
Patch velocity as a service level: The time from a vulnerability entering a priority class to a verified fix or compensating control, with a committed target per class and misses reported with reasons. Classes combine EPSS, KEV, the EUVD and exposure from the inventory.
Delegated in advance: For known-exploited vulnerabilities on exposed assets the decision is delegated beforehand and reviewed afterwards, under conditions that are properties of the architecture: a tested rollback, a health check, a canary ring and an exclusion list. The management body decides whether the delegation stands.
Canary: An object no legitimate process has a reason to touch, such as a decoy credential, host entry or tool, so a touch is a high-confidence alert that needs no baseline. Its registry sits outside the reach of what it watches.
Timed stop path: A stop path that lives outside the system it stops, has more than one mechanism sharing no dependency, is held by named people around the clock, and is measured by drill against a budget set from blast radius.

Teaching plan

15 min	Lecture on the collapsing window with the chapter's figures and labels, and on the four intervals using Figure 10.1.
15 min	Participants study the class table and AIDR-0554, and explain why a stale rollback test withdraws the delegation automatically and why the pipeline, not an agent, applies the fix.
15 min	Group analysis of drill STOP-HM-ITOPS-2027-Q1-01: where the 17 minutes went, and what design change each of the three findings implies.
35 min	Exercise: participants define patch-velocity classes for one asset group and design a stop drill for one system, splitting each target into the four intervals.
10 min	Debrief on the five indicators for the management body and how each is classified as verified, declared or failed.

Discussion

In most estates the time goes in the decide interval. Where does a known-exploited vulnerability on an exposed asset wait in your organisation, and who would have to approve removing that wait?
The chapter argues that an estate able to act in minutes loses little if the window stops shrinking. How persuasive is that argument for a board weighing the cost?
Nordvik cannot build machine-speed properties itself. What should a contract annex for a managed security service provider specify so that the numbers are observable and not declared?

Exercise · 35 minutes

Design a timed stop drill and a service level

Part one: for one group of internet-facing assets, define patch-velocity classes using the chapter's defaults as a starting point, recording any adaptation to your risk appetite, and split the target of the most urgent class into notice, decide, act and verify. Mark any interval that waits for a meeting. Part two: choose a system that can cause irreversible harm, or use Nordvik Region's integration route to the benefits-triage system. List every stop mechanism with its dependencies, name at least two stop holders for every hour of the week, set a budget from blast radius, state the trigger, and say how each interval is timestamped and what a pass means.

Deliverable: A class table with targets and decision paths, and a one-page drill plan with mechanisms, dependencies, stop holders, budget, trigger, timestamps for the four intervals and the pass criterion.

Self-test

In the chapter's default classes, what is the target for a known-exploited vulnerability on an internet-facing asset?
1. 7 days, as an expedited standard change
2. 30 days, as a standard change
3. 24 hours mitigation and 72 hours fix, delegated in advance
4. 4 hours fix, approved by the change advisory board
Why did Hansa's first timed stop drill of the IT-operations agent fail its five-minute budget?
1. The alert reached a duty analyst without the decision, and 15-minute tokens outlived the revocation
2. The canary registry was readable by the agent, which avoided the decoy
3. The managed security service provider held the runbook but lacked credentials to the integration gateway
4. The executive board had not yet approved the delegated playbook
How does the chapter label the claim that patch velocity will become a supervised metric?
1. Observable, because NIS 2 Article 21(2)(e) on vulnerability handling already requires a reported service level
2. Expected, on the signal of the European Central Bank's July 2026 letter to significant institutions
3. Speculation, as AI Platform and Security, Chapter 25, labelled it
4. Observable, because CISA's directive applies to European entities

Chapter 11 · 90 minutes

Resilience and Recovery by Design: The Architect's Share of Recoverability

The lesson sets out the architect's share of recoverability: design, verification and requirements, while operators run the recovery. Participants learn the four properties of known-good definitions, the four requirements for recovering AI systems, degraded modes, how the fallback erodes and how a fallback manifest and reversibility tests counter it, and security chaos engineering with its safety boundaries. They write a recovery definition and plan a reversibility test for a delegated function.

Learning objectives

Distinguish the architect's share of recoverability from the operators' share.
Specify completeness, integrity and provenance, separation and order for the known-good definitions of a system.
Draft a recovery definition for an AI system with degraded modes and named people who decide to resume.
Plan a reversibility test for a delegated function with acceptance criteria written beforehand.

Key concepts

Recoverability: The measured ability to carry out a recovery plan. Recovery time and point objectives are requirements on the architecture, each met by a design decision and shown by a test; an objective no design can meet is a finding for the risk owner.
Known-good definitions: The definitions from which a system is redeployed, which must be complete, signed with provenance the deployment path verifies, held with their keys outside the blast radius, and ordered in a dependency graph checked for cycles.
Recovered AI system: One shown to behave as it did before the incident, not merely one that is running. It needs a known-good source for every component or a design that needs none, an index rebuild path, pinned and replaceable provider components, and evaluation before return.
Degraded mode: A predefined configuration the organisation can switch to without a change process: a lower autonomy level, fewer functions or a manual procedure, for every AI system whose function the organisation cannot afford to lose.
Fallback manifest: A designed artefact that names the fallback procedure, the people who must be able to perform it, the interfaces it needs and the date it last ran. A scheduled check confirms links resolve, people still hold role and access, and the last exercise is within its interval.

Teaching plan

15 min	Lecture on recoverability as a property and the four properties of known-good definitions, including security tooling that itself becomes the thing to recover.
15 min	Walk through RCV-HM-CTA-01 and SCE-RC-007: why the old credentials are not restored, why memory is discarded and why the pipeline may not resume the agent.
15 min	Discussion of how the fallback erodes, using Nordvik's finding that only two caseworkers remembered how to work without the ranking.
35 min	Exercise: participants write a recovery definition for one AI system and plan a reversibility test for the function delegated to it.
10 min	Debrief on the safety boundaries of a chaos platform and on which recovery controls in the room are verified and which are declared.

Discussion

The chapter says the pipeline cannot restart what a person stopped. What would be lost and what protected if your organisation adopted that rule for its agents?
An annual test cannot catch an erosion that begins the week after it. Which fallback in your organisation was last performed by people who are still in role?
A platform that deliberately disturbs controls is among the most dangerous systems an organisation can run. Which of the chapter's safety boundaries would you insist on before a first experiment?

Exercise · 35 minutes

Recovery definition and reversibility test

Choose an AI system whose function your organisation could not afford to lose, or use the urgency ranking in Nordvik Region's benefits-triage system. Part one: write its recovery definition. State the objectives, the known-good source of each component and how it is verified, what happens to identity, memory and pending actions, the degraded modes with their triggers, and who decides to resume and on what evidence. Part two: plan a reversibility test for the delegated function. Write the scenario, the period and the acceptance criteria beforehand, including any statutory deadlines, name who applies the abort rule, list what you will measure, and say how the result will be classified as passed, passed with conditions or failed.

Deliverable: A recovery definition in the form of RCV-HM-CTA-01 and a one-page reversibility test plan with scenario, criteria, measures, abort rule and classification.

Self-test

What does Hansa's recovery definition RCV-HM-CTA-01 do with the claims-triage agent's memory and pending actions?
1. It restores both from the last evidence bundle and replays the queue automatically
2. It discards the memory and freezes pending actions for review, with no automatic replay
3. It keeps the memory and lets the pipeline replay the queue after evaluation
4. It archives both with the supplier until the supervisor has been informed
What did the architect at Nordvik Region find when rehearsing the manual degraded mode with a benefits team that had not taken part in the live exercise?
1. That the hosting provider could not deliver replacement accelerators within four hours
2. That the fallback called the same provider as the system it replaced
3. That the stop path took 26 minutes against a budget of 15
4. That only two caseworkers still remembered how to work without the ranking
Why is Level 4 Autonomous not used for recovery at all, according to the chapter?
1. Because DORA Article 12 names the level and prohibits it for restoration
2. Because recovery tooling cannot hold an identity of its own
3. Because Level 4 is never used for irreversible actions, and recovery contains some
4. Because chaos experiments must first reach 20 safe runs in production

Module 3 · Part III · The Architect's AI Team

Part III follows Shift 4, from sole author to conductor of an AI team, from one assistant to a governed agent team. Four lessons cover the architect's own use of AI in Modes 1 to 3, an agent team under a mandate manifest enforced outside the agents, review for soundness by techniques that do not trust the proposer, and the practices that keep the craft on which verification depends. Participants leave with a mandate manifest, a tiered review protocol, a review record and a craft-keeping programme.

Lecture · 45 minutes

The conductor must still be able to play

Part III asks what it takes for an architect to answer for work that AI drafts. The lecture starts with the mixed evidence on productivity and the consistent evidence on quality, and shows why confidentiality is a routing problem solved outside the client. It then builds the agent team: narrow roles, one identity per agent, a mandate manifest that the enforcing systems read, and the rule that agents draft and humans approve. It ends with the two conditions that make the arrangement safe: review that does not trust the proposer, and an architect who could still do the work unaided.

8 min	One assistant, the architect's identity Drafting, research, review and analysis each fail differently, so the verification that suits one does not suit the others. The productivity evidence is observable but mixed: gains for the less experienced, and experienced developers who took 19 per cent longer while believing they were faster. The quality evidence is consistent: generated code is often insecure, reviewers with assistants are more confident, and agentic tools can alter a scoring check.
7 min	Routing, oracles and records Label the work, not the person, default unlabelled work to confidential, and enforce the route at the gateway, because a client setting is a convenience, not a control. Tests, policies and schemas that act as oracles live in a path the tool cannot write to. A work log, a short-lived session record and, where an assistant shaped a hard-to-reverse decision, a decision record make the use reviewable.
10 min	From assistant to agent team Five narrow agents, reviewer, threat modeller, policy author, evidence collector and researcher, because five tasks have distinct failure modes and therefore distinct boundaries. The orchestration is a deterministic pipeline, not a manager agent, and the mandate manifest is not a prompt: the systems that enforce it read it. A change to a boundary, policy, control or threat model always waits for a named architect; only reversible evidence maintenance may run at Level 3 Bounded. The team must not be able to become, quietly, a system for evaluating people.
10 min	Review that does not trust the proposer Soundness is defined in advance: grounding, completeness, consistency with principles and stability under re-asking. Re-derivation, oracles the proposer cannot edit, and provenance pass the test; reading the rationale does not, and a second agent never approves. Hansa's median approval time fell from about eleven minutes to under thirty seconds while volume tripled: a failure of design, not of people. When review is the bottleneck, slow the agents; a longer queue is visible, thinner review is not.
10 min	Keeping the craft Bainbridge's ironies apply with force: the residue left to the architect is the hardest part of the work, and interventions cluster when the agents are stopped. An architect who approves fifty agent proposals a week is working, not practising; deliberate practice needs protected time and feedback the organisation manufactures. An action stays at Level 3 Bounded only while two named architects could write its playbook unaided and seeded-error detection stays above threshold.

What the audience takes away

Accountability does not move to the tool: the chain from an agent's draft to the management body runs through named people at every link.
Verification works only through checks whose result does not depend on the proposer being right, recorded in a signed review record.
Autonomy rises only as fast as the capacity to supervise it, and that capacity is kept by unassisted practice, seeded errors and degraded-mode exercises.

Chapter 12 · 75 minutes

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

The lesson treats the architect as a user of AI in Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants and Mode 3 Agentic work tools, where the AI acts with the architect's identity. Participants learn the four kinds of task and their characteristic failures, what the evidence says about productivity and quality, how architecture information is routed by class, which records make use reviewable, and the daily habits that keep judgement independent. They draft a mandate manifest and routing rule for their own use.

Learning objectives

Match each of the four kinds of assisted task to its characteristic failure and the verification that suits it.
Summarise what the cited studies found on productivity and on quality, and what the chapter labels observable and expected.
Design a routing rule for architecture information by class that is enforced outside the client.
Apply the three tests that decide when AI-assisted work needs a decision record.

Key concepts

Four kinds of task: Drafting fails as fluent text stating an unreached position, research as a fabricated or misattributed source, review as an invented or missed finding, and analysis as a pattern from an unrepresentative sample. The assistant is used where verification costs less than doing the work unaided.
Jagged frontier: The finding that consultants did better on tasks inside what the model could do and were 19 percentage points less likely to reach a correct answer on a task outside it. A plausible answer looks the same on both sides.
Protected oracles: Tests, policy-as-code rules and schemas kept in a path the tool cannot write to, because an agentic tool asked to make a failing test pass may change the test. A change that touches an oracle is flagged for review.
Routing by class: Public and internal work may use the approved enterprise tier of a cloud assistant; confidential and protected work reaches only self-hosted or sovereign-hosted models through the AI gateway from a workspace with default-deny egress. Unlabelled work defaults to confidential.
Work log, session record, decision record: Three records with distinct purposes: the work log says which drafts came from the tool and how they were verified; the session record keeps full prompts and outputs for a short fixed period; the decision record says why the architect decided as they did.

Teaching plan

15 min	Lecture on the four kinds of task and Modes 1 to 3 for architecture work; participants list their own current uses and the mode of each.
15 min	The teacher presents the studies on productivity and on quality; participants sort each finding as a gain, a loss or a warning about the reviewer's confidence.
10 min	Read MND-NR-01 together: find the autonomy per action, the denied actions, the protected oracle paths and the stop path at the gateway.
25 min	Exercise: participants write a routing rule and a mandate manifest for their own Mode 3 use, and start a work log.
10 min	Debrief on the five habits and on the three tests for a decision record, applied to one recent decision from each participant.

Discussion

Developers in the randomised trial predicted and afterwards still believed in a speed-up they did not have. How would you measure the effect of assistants on your own architecture work?
Self-hosting buys confidentiality at the price of a verification burden. Where would you draw the line between the cloud tier and the self-hosted route for your architecture information, and why?
The chapter says an architect who describes a design with evident confidence receives an answer shaped by that confidence. What changes in how you ask would counter that?

Exercise · 25 minutes

A personal AI workflow for architecture work

Following the chapter's practical guide, set up your own workflow on paper. Inventory the AI you already use in Modes 0 to 3, with the identity, reachable data and provider of each. Classify the architecture information you handle as public, internal, confidential or protected, and write the approved route for each class. Then write a mandate manifest for one Mode 3 tool: holder and approver, allowed models and route, allowed data classes and the three things that never leave the controlled route, autonomy per action with no more than Level 2 Supervised for edits, allowed tools, protected oracle paths, records and a stop path outside the tool. Add the first five lines of a work log.

Deliverable: A routing table by class, a mandate manifest in the form of MND-NR-01 and a five-line work log stating what was drafted with the tool and how it was verified.

Self-test

What did the randomised trial with sixteen experienced open-source developers on 246 real issues find?
1. Tasks were completed 55.8 per cent faster when AI was allowed
2. About a quarter more tasks were completed, with the larger gains going to the less experienced developers
3. Tasks took 19 per cent longer with AI, though the developers believed they had been sped up
4. No measurable difference in time, but fewer security weaknesses
In the mandate manifest MND-NR-01, version 1.0.0, what may the Mode 3 tool do with commits?
1. Nothing: commit and push are denied, while edits and commands run at Level 2 Supervised
2. Commit at Level 2 Supervised after the architect approves, but never push to the main branch of the repository
3. Commit and push at Level 3 Bounded within a playbook
4. Commit freely to an agent branch that the architect merges
According to the chapter, when does a decision that an assistant shaped materially need a decision record?
1. Whenever any draft text came from the assistant, however routine the decision
2. Only when a supervisor or auditor later asks for one, in which case it is written retrospectively and marked so
3. Only when the assistant ran on a cloud tier
4. When options, framing or evidence came from the assistant and the decision is hard to reverse

Chapter 13 · 90 minutes

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

The lesson moves from one assistant to a team of narrow agents, each with its own skills, identity, autonomy level per action and containment. Participants learn the five roles and why narrowness matters for security, what a mandate manifest contains and which systems enforce it, the seven containment measures for the architect's own agents, how disagreement between agents is escalated, how the team is operated and retired, and how it is kept from becoming a system for evaluating people. They write a mandate manifest.

Learning objectives

Describe the five agent roles of a security architecture team with what each writes, its mode, identity and default level.
Write a mandate manifest with a level per action, a list of what no agent may ever do, budgets, escalation rules and a stop path.
Explain the seven containment measures for the architect's own agents and why control artefacts stay out of their reach.
Assess whether an organisation has the capacity to supervise an agent team, using the staged introduction and Nordvik's decision to defer.

Key concepts

Narrow agents: Agents triggered by events in the architecture repository, each needing only what its task requires. One general assistant would need the union of all permissions; narrow agents can be bounded and stopped one at a time.
Mandate manifest: The written mandate of the architect's agents, kept as code and not a prompt. The identity provider, the policy decision point, the egress gateway and the branch rules read it, and where it disagrees with the containment profile the narrower one wins.
Agents draft; humans approve: A property of the repository, not a habit: branch protection requires review by code owners, the code-owner file lists only named architects, and the merge is always performed by a person. No agent approves its own output or another agent's.
Disagreement without arbitration: When the pipeline detects conflicting agent outputs on a pull request, it labels it, places both outputs side by side and requests review from the code owner of the affected path, who decides and records the rationale. No agent arbitrates and there is no vote.
Agents that read people's work: A review agent sees who wrote what, so agent output attaches to the change, not the person; the manifest prohibits per-person metrics and performance evaluation, and review-quality measures are reported at team level as agreed with employee representatives.

Teaching plan

15 min	Lecture on the step from assistants to an agent team and the five roles; participants explain why the researcher has no repository access and why the evidence collector is a Mode 5 agent.
15 min	Read MND-HM-01: the levels per action, the never list, budgets, escalation rules and the personal-data section.
10 min	Case discussion: the policy author's mirror rule and the threat modeller's objection in autumn 2026, and why the decision was the architect's.
35 min	Exercise: participants write a mandate manifest for a two-agent team or, where capacity is lacking, a decision record to defer with review triggers.
15 min	Debrief on the three-stage introduction and on consultation with employee representatives before agents read people's work in production.

Discussion

The chapter warns that a falling rejection rate may mean reviewers have stopped looking. What evidence would you require before granting an agent a higher autonomy level?
Nordvik's reasons for deferring an agent team concern capacity, not technology. Which of its review triggers would have to be met in your organisation before a team makes sense?
A review agent on an architecture repository holds all three legs of the lethal trifecta by default. How would you break the trifecta for each agent in a team you might run?

Exercise · 35 minutes

Write a mandate manifest for an agent team

Design a small architecture agent team for your organisation, starting with a reviewer and a threat modeller, or decide to defer. If you proceed, follow the chapter's seven steps: state purpose and scope with named repositories and no wildcard scopes; give each agent its own identity with a named owner and operators; list each action with a level, and an explicit list of what no agent may ever do; set data limits and budgets; write the escalation rules, the containment profile reference and the stop path with its holder by role; record personal data and its prohibited uses; set review and expiry. If you defer, write the decision record with the options rejected and the conditions that would reopen the question.

Deliverable: A mandate manifest in the form of MND-HM-01 for at least two agents, or a decision record in the form of AIDR-0503 with rejected options and review triggers.

Self-test

Which is the only action that runs at Level 3 Bounded in Hansa Mutual's architecture agent team?
1. The policy author pushing a tested egress rule to the main branch
2. The evidence collector refreshing an evidence link within an approved playbook
3. The reviewer approving documentation changes with no control effect
4. The threat modeller accepting low-risk candidate threats
How is the work of the agent team orchestrated, according to the chapter?
1. By a manager agent that assigns tasks to the narrow agents and filters their outputs for the architect
2. By the reviewer agent, which decides which drafts reach a person
3. By a vote among the agents when their outputs conflict
4. By a deterministic pipeline; no agent assigns work or decides which outputs reach the architect
Why did Nordvik Region reject option A, building a five-agent team, in AIDR-0503?
1. One architect cannot supervise a team and there is no second reviewer
2. Hosting outside the reserved capacity is not accepted
3. The union refused consultation under the co-determination agreement
4. Open-weight models were found too weak for threat modelling

Chapter 14 · 90 minutes

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

The lesson settles how an architect can know that an AI-proposed change is sound when it arrives faster than it can be re-done and reads fluently. Participants learn the four soundness properties defined in advance, the three techniques that do not trust the proposer, the limits of a second agent as critic, review depth by computed tier, automation bias as a design problem, the four signals of rubber-stamping, and the signed review record. They review a proposal and write its record.

Learning objectives

Define soundness in advance through grounding, completeness, consistency with principles and stability under re-asking.
Apply independent re-derivation, oracles and provenance to a proposed change and explain why reading the rationale is not enough.
Assign a review tier to a change by rule from reversibility, blast radius and artefact type.
Design a team-level measurement of review quality that does not monitor individuals.

Key concepts

Correct-looking versus sound: A proposal is correct-looking when it is well formed and carries a rationale that reads well; it is sound when its reasoning would survive scrutiny by someone who knows the system. Soundness is defined before review starts so the proposal does not define it.
Expectation note: Two or three lines the reviewer writes before opening the diff, stating what the change should contain and what it must not touch. It is the lighter form of independent re-derivation and anchors the review in the reviewer's reasoning.
Oracle: A check that decides whether an output is acceptable without reference to how it was produced. Oracles must be outside the proposer's reach, a proposal that changes one takes the highest tier, and a missing test for the property at risk is a finding.
Review tiers: Tier 0 routine, Tier 1 standard, Tier 2 significant and Tier 3 irreversible or self-referential, assigned by rule before any human reads the proposal. A human may raise a tier but not lower it without a recorded reason.
Signals of rubber-stamping: Time to approval relative to size and tier, a rejection and amendment rate near zero, reversals of approved changes, and the seeded-error detection rate, the only signal that measures review directly. Each is a finding about the review design, not about a person.

Teaching plan

15 min	Lecture on the open question, correct-looking versus sound, and the four soundness properties with the mechanical part the pipeline checks.
15 min	The teacher presents the three techniques and the design of the critic agent; participants explain why agreement between two agents is not verification.
15 min	Walk through REV-HM-0014: how the defect was found by a test the reviewer wrote, and how one critique objection was disposed of, not obeyed.
35 min	Exercise: participants tier three proposed changes, write an expectation note for one, name the oracle that would catch its likely defect and draft the review record.
10 min	Debrief on Nordvik's seeded errors, the missed citation S3 and the change it caused in the protocol.

Discussion

The chapter says slowing the agents is cheap to reverse, whereas thinning the review is invisible. How would you make that case to a manager who measures the team by throughput?
When an approved change later proves defective, the record shows whether the review or the tier rules failed. Why does that distinction matter for how the organisation responds?
What would have to be agreed with employee representatives before you could measure time to approval and seeded-error detection in your team?

Exercise · 35 minutes

Review an AI-proposed change by tier

Take three AI-proposed changes from your own practice, or use these: an evidence-link refresh, a change to one agent's tool policy for a single market, and a new requirement in a tender annex. Assign each a tier by rule from reversibility, blast radius and artefact type, and state the techniques and human review that tier requires. For the tool-policy change, write the expectation note before reading any proposed text, name the oracle that should pass and the property for which a test might be missing, list the provenance you would require, and dispose of two imagined critique objections with reasons. Record the result as a review record with tier, oracles, critique, reviewer, minutes spent and decision.

Deliverable: A three-row tiering table and one review record in the form of REV-HM-0014 with expectation note, oracle results, objections and dispositions, and a reasoned decision.

Self-test

Which soundness property does the chapter call the most specific to AI?
1. Stability under re-asking: the same inputs should produce materially the same change
2. Grounding: every identifier resolves in the model, catalogue or source register
3. Completeness: every boundary, market and control the change touches is addressed
4. Consistency with principles and earlier decisions
How was the defect in the policy change of review record REV-HM-0014 found?
1. The critique agent on a different model family rejected the proposal outright and the pipeline blocked the merge
2. The existing oracle suite for the claims-triage policy failed on the first run of the pull request
3. The reviewer saw no test covered market binding, wrote one, and the proposal failed it
4. A post-merge sample of Tier 0 changes revealed a control effect in the Dutch market overlay
Which tier does a change to an oracle, to the review protocol or to a mandate manifest always take?
1. Tier 1, with one named reviewer and an expectation note
2. Tier 3, the highest, with full re-derivation and two reviewers or the decision forum
3. Tier 2, with re-derivation of claims and a reason for approval in the domain owner's own words
4. Tier 0, with a random sample reviewed after merge

Chapter 15 · 75 minutes

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

The lesson sets the condition on which Shift 4 is safe: the conductor must still be able to play. Participants learn why the ironies of automation apply to the architect with particular force, what early studies show on reliance and deskilling and how the chapter labels them, the three parts of judgement, the seven craft-critical capabilities, deliberate practice, no-AI exercises and seeded-error drills, apprenticeship by design, and the gate that paces autonomy to the skills available. They design a craft-keeping programme.

Learning objectives

Explain three reasons why Bainbridge's ironies of automation take a sharper form for the security architect.
Distinguish what the evidence on deskilling shows as observable from what the chapter labels expected.
Design a quarterly craft-keeping programme with protected time, unassisted work, seeded-error drills and a degraded-mode exercise.
Apply the gate that keeps an action at Level 3 Bounded only while the skills to supervise it exist.

Key concepts

Judgement in three parts: Recognising what matters, including what is missing; weighing options whose costs and risks are not commensurable against a risk appetite with incomplete information; and answering for the decision to a board, a supervisor, an auditor or a court.
Craft-critical capabilities: The set of capabilities without which AI output cannot be checked, such as drawing trust boundaries, deriving threats no catalogue suggests, writing a policy rule and its tests, finding excess authority in a manifest, re-deriving a requirement from its legal article and designing a stop path.
Deliberate practice: Activities designed specifically to improve performance, requiring effort and giving feedback. Ordinary work does not count. Its three forms are unassisted design work, drafting first, and review without the assistant.
Seeded-error drill: Known design flaws placed in proposals in a drill channel behind a merge guard, at a limited rate, revealed to the reviewer within one working day and measured per capability at team level. The flaws are mistakes an architect must catch, not attacker techniques.
Unaided-competence gate: An action may be raised to or kept at Level 3 Bounded only while at least two named architects hold current evidence of writing and testing its playbook unaided and the detection rate for related seeds stays above threshold; otherwise it returns to Level 2 Supervised.

Teaching plan

15 min	Lecture on the ironies of automation applied to the architect and on the evidence, including the endoscopy study and its limits as a single observational study.
10 min	Participants rate themselves privately against the seven craft-critical capabilities and note which they last performed unaided, and when.
15 min	Compare CKP-HM-SA-2027 with Nordvik's exercise calendar in CMP-NR-01: a problem of scale and speed against a problem of isolation.
25 min	Exercise: participants design a quarterly craft-keeping programme for their team or single post, with a reporting rule agreed before the first drill.
10 min	Debrief on apprenticeship by design, using Hansa's plan AIDR-0562 and its choice to make the junior slower for six months.

Discussion

The chapter says the architect's estimate of what they could still do unaided is checked against nothing. How would you check it in your own case without turning the check into surveillance?
Automation removes the periphery where newcomers used to learn. Which junior architecture tasks would you reserve for unaided work, and what would that cost in the first year?
For a single post, team-level reporting is individual reporting. How does Nordvik's architect resolve this, and what would you do differently?

Exercise · 25 minutes

Design a craft-keeping programme

Design a craft-keeping programme for your security architecture team, or a calendar for a single post in the manner of Nordvik Region. List no more than ten craft-critical capabilities, starting from the chapter's seven. Reserve protected practice time and state how it may be reduced. Set the cadence for drafting first, unassisted reviews, seeded-error drills and a degraded-mode exercise in which AI tools are stopped and the real queue is worked unaided. Say where practice is recorded and in what form, who gives feedback, and at what level results are reported. State in writing that results are not used in appraisal. If any of your agents acts at Level 3 Bounded, write the gate that keeps it there.

Deliverable: A craft programme in the form of CKP-HM-SA-2027 or a four-quarter exercise calendar, with capabilities, cadence, evidence, reviewers and a reporting rule.

Self-test

What did the study in four Polish endoscopy centres find after AI-assisted colonoscopy was introduced?
1. Novices improved their detection rate while experts stayed level
2. Detection in AI-assisted colonoscopies rose from about 22 per cent to about 28 per cent within a few months
3. Experienced endoscopists refused to work without the AI after six months
4. Experienced endoscopists' unassisted adenoma detection rate fell from about 28 to about 22 per cent
What protected practice time does the chapter's quarterly craft-keeping programme set as a default?
1. One hour per architect per week, taken from review time
2. Half a day per architect per fortnight, about five per cent of working time
3. Two full days per architect per quarter, taken outside working hours and recorded by HR
4. Twelve days per team per year, shared among the architects
What happens to an action at Level 3 Bounded if fewer than two named architects hold current evidence of writing its playbook unaided?
1. It continues, provided the agents' acceptance rate stays high
2. It is suspended pending works-council consultation
3. It returns to Level 2 Supervised until the gate is met
4. It is escalated to the management body for risk acceptance

Module 4 · Part IV · The Role in the Organisation

Part IV places the security architect in the organisation. Five lessons cover the role map and its four seams with the AI architect, decision tiers and gates in place of meetings, European regulation read as engineering constraints, communication to five audiences from one source, and the two settings that change the role most: the public authority that procures and the multinational under many legal regimes. Participants leave with a role map, a tier policy, an article-to-control mapping, a one-page board report and a testable tender requirement.

Lecture · 50 minutes

From the door to the design: decision rights in the organisation

A security architect who must be present at every decision has become a queue, and a queue is not a control. The lecture follows Shift 2, from gatekeeper to boundary designer, through the organisation: who proposes, who holds the ceiling and who operates at each seam; which decisions a rule can take and which need a forum; how articles addressed to management bodies become controls that run; how one architecture is shown to five audiences without five versions; and how the boundary is held when a supplier builds the system or seven legal regimes apply to it.

9 min	Seams, ceilings and placement Where two roles collide, the cause usually sits at the seam: for each seam one role proposes, one holds the ceiling and one operates, and a file says which. The CISO decides appetite and the architect decides design; the security architect's rights at the seams with the AI architect are rights over ceilings, not over content. The recommended placement is an enabling hub reporting to the CISO, because a boundary held by the platform holds for every team on the golden path.
10 min	Gates instead of meetings Forums are slow, inconsistent and forgetful; a gate enforces, observes and remembers, but applies a threshold without setting it. The tier policy is data: a class that loosens a boundary is never delegated as far as one that tightens it. Hansa measured 187 board items: 70 per cent fell into five routine classes approved unchanged, with a median wait of 17 calendar days. An agent never changes its own boundary, and Level 4 Autonomous is never used for architecture changes.
10 min	Regulation as constraint Read the addressee, the verb, the date and the limit: approve and oversee describe a person's act, ensure and keep a property that a test can check. One incident can start several reporting clocks at once; the design answer is one pipeline with one awareness timestamp. The management body keeps ultimate responsibility; the architect answers professionally for the design, the mapping and the honesty of the evidence.
10 min	One architecture, five audiences Audiences differ in question and form, not in facts: a decision for the board, a demonstration for the supervisor, a sample for the auditor, a verdict for the engineer, a testable requirement for the supplier. The board page asks for at most three decisions and states what it does not know. A gate message that explains itself keeps the architect from remaining the gatekeeper. A provenance block discloses what AI drafted and who verified it; every figure is recomputed from the sources.
11 min	Procuring and spanning regimes The procuring architect holds identity, keys, logs, egress, the evaluation gate and the stop path on the authority's own side, and writes the rest as verifiable requirements at the tender. A contract clause is a control only when it has an owner, produces evidence and is tested; the exit plan is a rehearsed capability, not a clause. Digital sovereignty is four verifiable properties: where workloads run, which law governs, the ability to move and the ability to continue. A multinational keeps one pinned baseline with market overlays that may tighten but never relax it, enforced by a pipeline check.

What the audience takes away

Delegation moves the decision, not the accountability: the architect answers for the policy and the rules, verified by sampling and reported upwards.
The instruments place duties on management bodies and deployers; the architect turns articles into controls with owners, tests and honestly classified evidence.
Whether the lever is the contract or the platform, the boundary becomes a testable artefact whose evidence arrives on schedule.

Chapter 16 · 75 minutes

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

The lesson places the security architect among the CISO, the risk function and internal audit, the enterprise architect, the AI architect, platform and product teams and the roles the usage modes have created. Participants learn the seam rule, the four seams with the AI architect, the three placements of an architect, how Conway's law turns organisational seams into security seams, and the four rules of a RACI kept as code. They draw a role map from real decisions.

Learning objectives

Explain the division of labour between the CISO and the security architect as the difference between appetite and design.
Assign a proposer, a ceiling-holder and an operator to each of the four seams between the security architect and the AI architect.
Compare the enabling, embedded and platform placements by what each makes easy and hard.
Draft a role map with exactly one accountable role per cross-role decision.

Key concepts

Seam: A point where the work of two roles meets and a decision can fall between them. For each seam, one role proposes, one holds the ceiling and one operates, and a file in version control says which.
Rights over ceilings: Whoever knows the AI system best proposes; whoever knows the attacker's reach best holds the ceiling, because the ceiling must not depend on the model behaving. The security architect's rights at the seams are over ceilings, not over content.
Enabling hub: The book's default placement: an enabling team reporting to the CISO, with an architect embedded only where risk justifies it, keeping the hub reporting line and rotating after a fixed term, and a standing seat in the platform team's design reviews.
New neighbours: Roles the usage modes created: the AI system owner, the agent operator who may revoke a Mode 5 agent's credentials, the skills curator and the evaluation engineer. The architect's own agents appear on the map as tools, never as roles.
RACI rules: One accountable role per decision; a veto is not an accountability and is recorded separately; independent functions are never responsible for building; agents are never accountable. Stopping needs no approval, whereas restarting needs the system owner.

Teaching plan

15 min	Lecture on the role among roles, using Figure 16.1: the CISO, the risk function and internal audit, the enterprise architect and the AI architect.
15 min	Participants fill in Table 16.1 from memory for the four seams, then compare with the chapter and discuss the rule for disagreement and its 30-day lapse.
10 min	Read Hansa's decision-rights file: find who is accountable for the permission ceiling, who owns guardrail content, and why stop activation requires no approval.
30 min	Exercise: participants draw a role map from six real decisions, marking who was surprised, and assign one accountable role per seam.
5 min	Wrap-up: each group names one seam where two roles each believed the other was the owner.

Discussion

The architect recommends an exception but does not grant one. What goes wrong in organisations where the same person designs the boundary and accepts the residual risk?
The test of placement is whether the architect hears of a boundary problem from the team before an incident reveals it. How would your current placement fare on that test?
Nordvik holds boundaries through contracts, Hansa through the platform. Which seams in your organisation are held by neither, and who was surprised the last time one failed?

Exercise · 30 minutes

Draw the role map from real decisions

Collect six boundary-changing decisions from the last twelve months in your organisation, preferring slow or contested ones. For each, record who proposed, who decided, who did the work and who was surprised; the surprised column marks the seams. Cluster the decisions by seam. For each seam name the role that proposes, the role that holds the ceiling, the role that operates and exactly one accountable role, recording any veto separately with its scope. Add the stop decision: who may stop without asking, and who must approve a restart. Then test the map against two further decisions and note any it cannot route as a gap.

Deliverable: A role map in the form of Hansa's decision-rights file, with one accountable role per decision, separate vetoes, stop activation and release, and a list of gaps.

Self-test

At the seam on guardrail content and boundaries, what does the security architect hold?
1. The content of the guardrails: what they check, how they are evaluated and which thresholds they must meet
2. The ceiling: egress, workspace isolation, and the rule that no guardrail is the only control
3. The operation of the guardrails in the delivery pipeline
4. The evaluation thresholds that gate each release
What happens when the security architect and the AI architect disagree at a seam, according to the book's own conclusion?
1. The AI architect's position stands until the design authority meets, because the proposal depends on how models behave
2. The matter is put to a vote among the roles on the map
3. The platform team decides, because it operates the control
4. The more restrictive position stands until the named tier decides, and the default lapses after 30 days
Why does the chapter prefer a standing seat in the platform team's design reviews to making the architect a member of the platform team?
1. It keeps designer and builder apart, avoiding self-review
2. Platform teams are not permitted to employ architects under DORA
3. The enabling hub would otherwise lose its budget
4. Members of platform teams cannot hold a veto over the control catalogue

Chapter 17 · 90 minutes

Design Authority, Decision Forums and Gates Instead of Meetings

The lesson shows how the architect delegates routine decisions without losing accountability for them. Participants learn why forums fail, what a gate does that a meeting does badly, the tier policy as data with its three design rules, the properties of a working gate, the design authority, exceptions as expiring records, and the five rules that answer when an AI may change the architecture. They classify decisions into tiers and write an expiring exception.

Learning objectives

Explain the three ways forums fail and the three things a gate does that a meeting does badly.
Classify decision classes into the four tiers, with a decider, evidence, a time limit and a maximum autonomy level for an AI proposer.
Write an exception as an expiring record with a tested compensating control and renewal requirements.
Apply the delegation test and shadow running to redesign a review board as a design authority with gates.

Key concepts

Tier policy as data: A list of decision classes in version control, each with a tier, a decider, required evidence, a time limit and an owner, read by gates and forums. A class qualifies for tier 1 only if a machine can check its evidence.
Direction decides the ceiling: A class that loosens a boundary is never delegated as far as one that tightens it. For AI proposers, tightening or restoring changes may reach Level 3 Bounded behind an external gate; loosening changes stay at Level 2 Supervised or below.
Working gate: A gate whose rule is versioned and tested, whose rule is not owned by the author of the change it gates, whose bypass is possible, visible and reviewed, and which is itself reviewed for staleness. The override rate measures its health.
Design authority: The tier 2 forum for exceptions, deviations, precedent and contested items. It works asynchronously first on pull requests, has a written mandate and a quorum by role, and an objection from the security architect escalates to the next tier and is not outvoted.
Expiring exception: A record of a decision to live with a control gap for a stated time, with an owner, a tested compensating control and an expiry enforced by a gate. Renewal is a new decision that requires new evidence, not an extension.

Teaching plan

15 min	Lecture on forums and gates and on the four tiers; participants name a decision in their organisation that waits for a session although a rule could take it.
15 min	Read Hansa's tier policy: why C3 is a standing approval, and why C7 and C8 sit at Level 0 Advisory for any AI proposer.
10 min	Walk through EXC-NR-0007: the compensating control, the expiry at the tier 2 maximum, the renewal requirements and the two fields specific to a public authority.
35 min	Exercise: participants classify ten recent decisions into tiers with the delegation test, set the autonomy ceiling per class and write one expiring exception.
15 min	Debrief on delegation without abdication: sampling tier 1 decisions, measuring approval quality at forum level and reporting upwards.

Discussion

The chapter says a design authority that approves every pull request in seconds is a gate with a delay. How would you tell the difference in your own forum?
Gates that cannot be bypassed will be bypassed unseen. What would a break-glass path need to record in your pipeline for you to trust it?
Hansa measures and delegates; Nordvik designs a route and writes down who answers at the end of it. What does a tier policy offer an organisation with no standing board?

Exercise · 35 minutes

Tier ten decisions and write an exception

Take ten security architecture decisions from the last two quarters of your review board or equivalent, recording each item's class, wait and outcome. Apply the delegation test: a class moves to a gate only if it recurs, is reversible or low in blast radius, can be decided from machine-checkable evidence, and has a policy and an owner, with a stricter test for loosening classes. Assign each class a tier from 1 to 4, a decider, a time limit and the maximum autonomy level for an AI that proposes a change in that class. Then write one exception from your own estate as an expiring record with control, scope, reason, risk, owner, compensating control and its test, approver and tier, expiry and what renewal requires.

Deliverable: A tier policy table for the classes found, in the form of Hansa's policy, and one exception record in the form of EXC-NR-0007.

Self-test

Before a class of decisions is delegated from the board to a gate, what does the chapter's practical guide require of shadow running?
1. Two weeks in which the gate records no failures or overrides of any kind
2. One full quarter in which the board approves every item of the class unchanged and no exception is open against it
3. Gate and board agree on at least 95 per cent of at least 20 decisions, every disagreement explained
4. A sample of five per cent of the gate's decisions re-derived by internal audit
In Hansa's tier policy, at what maximum level may an AI propose a change to the tier policy itself or to a stop path?
1. Level 0 Advisory: an agent must never change the rule that governs it or the path that stops it
2. Level 1 Assisted, with the draft labelled as AI-generated
3. Level 2 Supervised, with each change approved by the head of security architecture and recorded at tier 3
4. Level 3 Bounded, where the change tightens the policy
What does the chapter say about renewing an exception?
1. It is extended automatically for the same period while the compensating control keeps passing its test
2. It may be extended once by the control owner without a new decision
3. It is granted by the gate when the expiry date is reached
4. It is a new decision that requires new evidence; a renewal attaching nothing new is declined

Chapter 18 · 90 minutes

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

The lesson reads the AI Act, NIS 2, DORA and the Cyber Resilience Act as engineering constraints, article by article. Participants learn the four reading rules, the articles that carry most of the architect's work in each instrument, the three lines along which accountability is distributed, the method for turning an article into a control, and how overlapping reporting clocks are met by one incident pipeline. They map an article to a control with a test. Everything is framed as architectural implication, not legal advice.

Learning objectives

Apply the four reading rules, addressee, verb, date and limit, to an article of a European instrument.
Identify, for each of the four instruments, the articles the chapter treats and the architectural implication of each.
Distinguish the accountability of the management body, the control owner and the architect's professional responsibility.
Convert one article into a catalogue control with a property, a test, evidence and a recorded reading.

Key concepts

Four reading rules: Read the addressee, the verb, the date and the limit. Approve, oversee or be trained describe a person's act; ensure, keep, implement or notify describe a property that architecture can provide and a test can check. Whether a reading is legally right belongs to counsel.
Under its control: The architectural hinge of AI Act Article 26: a deployer cannot keep for at least six months logs that a supplier writes only to its own environment, so the requirement belongs in the contract and the data flow.
Professional responsibility: What the architect answers for, as defined in the role charter: the soundness of the design advised, the faithfulness of the mapping from article to control, the honesty of the evidence classification and the escalation of a risk the architect cannot accept.
Property statement: The form in which an article becomes engineering: X holds for Y, checked every Z. If no test can fail, it is not yet an engineering statement. If the verb is approve or oversee, the output is an information requirement, not a control.
One incident pipeline: The design answer to overlapping reporting clocks: one awareness timestamp, one classification step that evaluates every regime and one evidence record from which each report is assembled.

Teaching plan

15 min	Lecture on regulation as a design input and the four reading rules; participants apply the verb rule to five article extracts the teacher reads out.
20 min	Groups each take one instrument, the AI Act, NIS 2, DORA or the Cyber Resilience Act, and present the chapter's articles with their architectural implications.
10 min	The teacher walks through Table 18.1 on reporting clocks and Hansa's mapping MAP-HM-CLAIMS-TRIAGE-01, including the conditional Article 26 entry held as declared.
35 min	Exercise: participants turn one article into a control using the six steps and record the reading with a reviewer.
10 min	Debrief on personal accountability: what the architect owes the management body, and the one failure the architect cannot allow.

Discussion

Reporting a declared control as verified is the one failure the architect cannot allow. What pressures in your organisation push towards that failure, and what protects against it?
The chapter says a control owned by a team alias is a failed control, whatever its test says. How many of your controls would survive that rule?
Hansa records for each entry whether an obligation is law or group policy. Why does that distinction matter in entities where the instruments do not apply by law?

Exercise · 35 minutes

Turn an article into a control

Choose one article the chapter treats that applies to your organisation, for example NIS 2 Article 23(4) on the early warning, AI Act Article 26(6) on logs under the deployer's control, or DORA Article 28(3) on the register of information. Follow the six steps. Identify the addressee and the verb. State the property in the form X holds for Y, checked every Z. Search your catalogue for an existing control and reuse it if one fits. Write a test that fails when the property is false and say when it runs. Name the evidence and its keeper and classify the control as verified, declared or failed. Record the reading with a reviewer other than yourself, review triggers and a review date.

Deliverable: One mapping entry in the form of Hansa's regulatory mapping, with article, property, control, test, cadence and status, plus a short record of the reading and its reviewer.

Self-test

In the chapter's example for NIS 2 Article 23(4)(a), what does the quarterly test assert?
1. That the final report is submitted within one month of the notification
2. That the management body has approved the incident process
3. That the supplier notifies the entity within 12 hours of awareness
4. That a synthetic incident replay produces an early-warning draft in under four hours
Why is the claims-triage agent recorded as not high-risk in Hansa's mapping?
1. Because it acts only at Level 2 Supervised with a person approving each route
2. Because Annex III, point 5(c), concerns risk assessment and pricing for life and health insurance, not claims routing
3. Because the Digital Omnibus moved all insurance systems out of Annex III
4. Because it works through the Polish service centre for four national entities, which places it outside the scope of the AI Act
What does CRA Article 12 mean for supplier evidence, as the chapter reads it?
1. A supplier's software bill of materials replaces the deployer's own duty to keep logs under AI Act Article 26(6)
2. A CRA declaration of conformity from the supplier relieves the management body of its approval and oversight duties under NIS 2 Article 20
3. A high-risk AI system meeting the CRA's essential requirements is deemed, as far as its declaration shows, to meet AI Act Article 15
4. A product with a support period of at least five years is exempt from the reporting clocks of CRA Article 14

Chapter 19 · 75 minutes

Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers

The lesson shows how one security architecture is communicated to five audiences without five versions of it. Participants learn the three rules of generated views, what boards, supervisors, auditors, engineers and suppliers each ask and in what form they are answered, the five indicators the architect reports and what is deliberately left out, and how AI's part in the work is disclosed through a provenance block. They write a one-page report for a management body and a gate message.

Learning objectives

Match each of the five audiences to the question it asks, the form of the view and its cadence.
Write a one-page architecture report that asks a management body for at most three decisions and states what it does not know.
Define the five indicators and explain why the architect leaves out activity counts and summed scores.
Compose a gate message with rule identifier, observed fact, reason and way forward.

Key concepts

One source, many projections: Every figure and diagram in a view carries the commit of the model, catalogue and evidence manifest it came from; a view that cannot name its sources is a draft. Views generated from the same commits cannot disagree.
Decisions, not information: A report asking for no decision is a briefing. The board page asks for at most three decisions, each with its cost, reversibility and what it affects, in risk language, and shows movement instead of state.
Standing pack: The supervisor view: a set of queries over the catalogue and evidence manifest that exists before anyone asks, opening with failed and declared controls, their owners and closure dates, and giving one answer for all supervisors.
Five indicators: Patch velocity, containment test results, recoverability, control status and review quality. Each describes a property someone can change, has an owner and a threshold, and is computed from evidence without opinion.
Provenance block: A disclosure produced by the generator, not typed, stating which sections an AI drafted, which agent or tool in which usage mode under which mandate manifest, what the verifier did and who verified. Disclosure does not share blame.

Teaching plan

15 min	Lecture on one architecture and several audiences, using the audience table and the example of three reports with three different control counts.
15 min	Compare the board page MGT-HM-2026-Q4 with Nordvik's briefing to the regional executive committee: decisions asked, what is named as failing and what is said plainly to be declared.
10 min	Participants rewrite a bare 'policy check failed' message into the four parts of a good gate message.
30 min	Exercise: participants write a one-page report for their own management body with indicators, three decisions, limits of knowledge and a provenance line.
5 min	Wrap-up: pairs swap pages and check that each decision can be answered in the meeting.

Discussion

A page that is green only because the red is unmeasured is called the commonest cause of a bad surprise. What is unmeasured in your current reporting, and how would you say so on one page?
The chapter warns that a patch-velocity target can be met by reclassifying services as not internet-facing. Which of your indicators could be improved by changing the report instead of the estate?
Independence is preserved by access, not distance. What would your auditors need in order to draw their own sample and re-perform a test without your help?

Exercise · 30 minutes

A one-page report for the management body

Write a one-page architecture report for your management body, or for Nordvik Region's regional executive committee using the figures in the chapter. Fix the template: decisions asked for, the five indicators with thresholds and owners, control status in three counts of verified, declared and failed, changes since the last page and a provenance block. Select at most three decisions, each with the consequence of not deciding, the cost, reversibility and what it affects, in risk language. Write a five-sentence narrative last. State what the page does not know, naming declared evidence and unmeasured areas. Add one line disclosing any part an AI drafted and who verified it.

Deliverable: A one-page management report with indicators, three decisions, a statement of what is not known and a provenance line, in the form of the chapter's board page.

Self-test

How many decisions should the board page ask for, and why?
1. At most three, because a board that receives seven requests decides none
2. Exactly five, one for each indicator the architect reports
3. None, because the page is a briefing and decisions belong to the CISO
4. As many as there are failed controls, so that none is hidden
Where an AI agent collects the evidence, what does the auditor do according to the chapter?
1. Repeats the agent's collection by hand for every control in the catalogue
2. Relies on the agent's own account of what it collected and when
3. Tests the agent: its links against the source system, its mandate against what it did
4. Asks the architect to choose which of the agent's records should be shown
At what level is the review-quality indicator reported?
1. By named reviewer, so that weak reviewers can be coached
2. At team level only, agreed in advance with employee representatives
3. By entity and reviewer, for the supervisor's standing pack
4. It is not reported, because it could monitor individuals

Chapter 20 · 90 minutes

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

The lesson covers the two settings that change the role most. In a public authority the architect procures far more than builds, so boundaries run through testable requirements, contracts as controls, rehearsed exit plans and what the authority holds on its own side. In a multinational the architect keeps one baseline with market overlays that may tighten but never relax it. Participants also learn digital sovereignty as four verifiable properties and how vendor AI in Mode 0 is contracted. They write a testable tender requirement.

Learning objectives

Explain the three moves by which a procuring architect holds a boundary in a system a supplier builds and runs.
Write a testable security requirement with identifier, result, level, verification at three moments, consequence and catalogue link.
Translate digital sovereignty into four properties, each with a check and evidence.
Review a market overlay for any value weaker than the baseline.

Key concepts

Testable requirement: A requirement with an identifier, the result required in functional terms, a level of mandatory or weighted, a verification naming method, evidence and frequency at evaluation, acceptance and operation, a consequence of failure and a link to its catalogue control.
Contracts as controls: A contract clause is a control only when it has an owner, produces evidence and is tested, so each clause family, such as stop path, logs and access, change notice, audit rights, incident notification and exit, is a catalogue entry with the supplier as evidence source.
Rehearsed exit: An exit plan that says what leaves, in what formats and how fast, what keeps the function running, and who has tried. For a procured system the realistic exit is often the process without the AI, so the plan includes a test of it.
Sovereignty as verifiable properties: Knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails. Each becomes a check with evidence, such as region pinning, key custody, an exit test record and a failover drill.
Tightening-only overlay: A market overlay on a pinned baseline that records regime, placement, timing and mappings to existing controls. A pipeline check fails when any overlay value is weaker than the baseline: shorter retention, fewer recipients, a later deadline or a control removed.

Teaching plan

15 min	Lecture on the architect who procures: what the authority holds on its own side, why the tender is the moment of greatest leverage and what Directive 2014/24/EU permits.
15 min	Read SECREQ-NR-2026-117: participants explain why SR-01 excludes supplier staff, why SR-02 sets twelve months and what SR-03 makes of a model update.
15 min	The teacher presents sovereignty as four properties and Hansa's UK overlay; participants find the attested mapping with an expiry and the empty relaxes list.
35 min	Exercise: participants write two testable requirements for a tender of their own or for Nordvik's renewal, and one exit test.
10 min	Debrief on vendor AI in Mode 0, using Nordvik's email-security gateway, and on what the contract must establish before such a feature is relied on.

Discussion

A requirement tested only at tender protects the authority only on the day of signature. Which requirements in your current contracts are verified in operation, and which only at award?
The chapter says the architect makes the facts of ownership, operation and key custody visible and leaves the legal reach of third-country law to counsel. Why is that division of work the right one?
Where a local rule appears to require less than the group baseline, the overlay may not relax silently. What are the two alternatives the chapter offers, and when would you choose each?

Exercise · 35 minutes

Write testable tender requirements and an exit test

Take a procurement your organisation is planning, or Nordvik Region's renewal of the benefits-triage contract. Write two security requirements following the chapter's guide. Start from a catalogue control and name the obligation or threat it serves. State the result in functional terms with a number where one exists, never naming a product only one supplier offers. Set the level as mandatory or weighted. Name the verification with method, evidence and frequency at acceptance and in operation, and who owns it. State the consequence of failure. Then describe one exit test: what is switched off or moved, for how long, what is measured and who takes part. Finally say how you would dry-run each test against the incumbent system before publication.

Deliverable: Two requirement entries in the form of SR-01 and SR-02 with verification and consequence, and a half-page exit test description with its measures.

Self-test

By default, how many mandatory requirements does the chapter's guide allow per tender, and what happens to the rest?
1. No more than five, and the rest are dropped
2. No more than twelve, with the rest weighted under the award criteria
3. No limit, as long as each has a verification
4. No more than twenty, with the rest moved to the contract schedule
Why does Nordvik's requirement SR-02 set log retention at twelve months when AI Act Article 26(6) sets a floor of six?
1. Because NIS 2 Article 23 requires twelve months for significant incidents
2. Because the supplier's log store cannot delete earlier
3. Because the Region's archives law forbids shorter retention for all records
4. Because appeals can arrive later than the six-month floor
What makes the pipeline check fail when a market overlay is added to Hansa's catalogue?
1. Any overlay value weaker than the baseline, or a protected control missing
2. Any overlay that adds recipients or tightens a deadline
3. Any mapping owned by a local security officer and not by the group
4. Any regime in which the AI Act applies as group policy and not as law

Module 5 · Part V · Competence and Career

Part V asks what a person must be able to do to hold the transformed role, how anyone can tell, and whether the role has a future. Three lessons cover a competence framework kept as code with six domains and four levels evidenced with and without AI, learning paths, certification, hiring and upskilling, and a horizon register with four scenarios for 2036. Participants leave with an assessment plan, an interview exercise that tests judgement in two conditions and a register of signals for the role.

Lecture · 40 minutes

Competence that shows without the assistant

When AI drafts much of the visible work, that work no longer shows who could have done it. The lecture follows this problem through Part V. It presents the competence framework and its central rule, that a person's level is the lower of what they demonstrate unaided and with AI; shows how the framework conditions decision rights and agent autonomy; turns it into learning paths and hiring exercises that run in two conditions; and ends with the horizon register for the role, four scenarios for 2036 and the seven measures that hold in all of them.

10 min	Six domains, four levels, two conditions Design, code, AI, adversary, law and people: no competence has disappeared, but recall and authorship of every draft have become less central. Each level is defined twice, unaided and with AI the person verifies, and the lower of the two counts. Evidence is unassisted demonstration, review records, artefacts that held under test and forum evidence; certificates support the lower levels only.
7 min	When decisions depend on the record The framework becomes an architecture artefact when decision rights in the charter and autonomy ceilings in the mandate manifest depend on evidenced levels. Hansa requires two holders of AI-03 at Advanced for the evidence collector's Level 3 ceiling; if unmet, the ceiling falls to Level 2 Supervised. A competence record is personal data with closed purposes, and a lapse is managed like an expired certificate on a service, not as a disciplinary event.
10 min	Growing and hiring architects Four starting points, security engineer, enterprise architect, developer and auditor, each strong in part of the framework; every path begins with a gap assessment, not a course catalogue. First draft by the learner, then the assistant; levels are gated by demonstration, not course completion. A certification validates knowledge on the day of an examination; an interview exercise run unassisted and assisted shows what a candidate can verify. Upskilling is the strategy and hiring is for scarce specialisms; the entry route is under observable pressure.
13 min	Will there be a security architect in 2036? Observable trends justify commitment, expected trends preparation and speculative trends reversibility; the register is kept by the role's holders but approved by the CISO. Four scenarios, speculation by construction: absorbed into platform engineering, a governance role, commander of agent teams, and the role disappears; each names what would be lost. The share of architecture changes at each autonomy level is the clearest signal of which scenario is arriving. Seven no-regret measures hold in all four, from keeping the craft to keeping the stop path outside what it stops.

What the audience takes away

A level is earned by what a person can do when the assistant is wrong or stopped, and by what they catch in AI output.
Learning paths and hiring exercises test verification in two conditions, because the difference between the scores is information about judgement.
The future of the role is governed by signals with thresholds and owners, not by forecast, and the no-regret measures are the commitment.

Chapter 21 · 75 minutes

Competences of the Transformed Security Architect: A Framework

The lesson presents a competence framework for the transformed security architect, kept as code: six domains, four levels from Foundation to Expert each defined unaided and with AI, and the evidence that demonstrates each competence. Participants learn the rule of the lower level, the five kinds of evidence and the limits of certificates, the mapping to ECSF, SFIA 9 and NICE with its local extensions, the competence record as personal data, and how the record conditions decision rights and agent autonomy. They plan an assessment by practical demonstration.

Learning objectives

Name the six domains of the framework and give one competence from each with the shift it most concerns.
Apply the rule that a person's level is the lower of the unaided and the AI-assisted demonstrated level.
Rank the kinds of evidence of competence and explain why certificates are never sufficient for Advanced or Expert.
Plan an assessment by practical demonstration with an unassisted scenario, a seeded review and a rationale interview.

Key concepts

Six domains: Design, code, AI, adversary, law and people, following the structure of the role in Parts II to IV. Design is the core; the AI domain exists because of Shift 4, which also changes how every domain is evidenced.
Rule of the lower level: Each level is defined twice, unaided and with AI the person verifies, and a person's level is the lower of the two demonstrated. An architect with excellent AI-assisted output who cannot produce a sound threat model unaided is Practitioner in that competence.
Unassisted demonstration: Work done without AI in a time-boxed exercise. It shows what the person can do when the assistant is wrong or stopped, and is the only evidence that answers the question of judgement directly.
Local extensions: Competences the mapping records as not covered by ENISA's Cybersecurity Architect profile, published in 2022: AI-02 on containment and identity for Mode 5 agents, AI-03 on autonomy levels and Level 3 playbooks, and ADV-02 on machine-speed defence.
Competence condition: A link from the record to decisions: each consequential decision right names the competences it requires and escalates when the record does not show them, and an autonomy ceiling in a mandate manifest depends on the supervising architects' evidenced level in AI-03.

Teaching plan

15 min	Lecture on why a framework and why as code, the six domains and the table of what has become less central than before.
10 min	Participants place three fictional architects on the levels table, applying the rule of the lower level, and defend their placements.
15 min	Read CMP-NR-01: purposes, readers, what the record is not used for, the levels and the development plan; discuss why working notes are deleted.
30 min	Exercise: participants plan an assessment for one architect, choosing competences, designing the unassisted scenario and the seeded review, and drafting the record schema.
5 min	Wrap-up on Hansa's condition of two holders of AI-03 at Advanced and what happened while only one was evidenced.

Discussion

The rule of the lower level can lower the recorded level of an architect whose repository looks excellent. How would you introduce the rule so that it is accepted as fair?
Expert is earned on designs that held under test, not on years in post. What would that change in how your organisation grades its senior architects?
A nightly check reads levels, never record content. Why does the chapter separate the record, the evidence and the working notes so strictly?

Exercise · 30 minutes

Plan an assessment by practical demonstration

Plan the yearly assessment of one security architect in your organisation, or of Nordvik Region's single post-holder. Select at most six competences from the framework: those due, those on which a decision right depends, and those the person wants to raise. Design a three-hour unassisted scenario on a sanitised or synthetic estate. Design an AI-assisted review of an AI-drafted artefact with three to five seeded errors, at least one a fluent omission, described as design flaws. Write four questions for the rationale interview. Name the lead assessor and the second assessor and say how levels are decided. Finally draft the record schema: purposes, what it is not used for, readers and validity.

Deliverable: A two-page assessment plan with scope, unassisted scenario, seeded review, interview questions, assessors and a competence record schema in the form of CMP-NR-01.

Self-test

An architect's AI-assisted threat models are excellent, but the architect cannot produce a sound threat model unaided. What level does the framework record in DES-02?
1. Advanced, because the repository shows the output that counts
2. The average of the two demonstrated levels
3. The lower of the two demonstrated levels, here the unaided one
4. No level until a certificate confirms the knowledge
How does the framework treat certificates such as CISSP-ISSAP as evidence?
1. As supporting evidence at Foundation and Practitioner, never sufficient for Advanced or Expert
2. As sufficient evidence at every level, provided the certificate was renewed within the two-year validity of evidence
3. As a precondition for holding any decision right in the charter
4. As irrelevant, because they evidence neither knowledge nor judgement
What happens to the evidence collector's Level 3 ceiling in MND-HM-01 if fewer than two architects hold AI-03 at Advanced?
1. The agent is retired until the next annual assessment
2. The ceiling falls back to Level 2 Supervised
3. The ceiling is unchanged, but internal audit is informed
4. The architects face a disciplinary review

Chapter 22 · 75 minutes

Learning Paths, Certification, Hiring and Upskilling

The lesson turns the competence framework into learning paths, hiring profiles and the choice between upskilling and hiring. Participants learn the four starting points and what each lacks, the four principles of a learning path, what certifications validate and what they do not, AI literacy for the architect as testable objectives, why interview exercises run unassisted and assisted, and what an organisation can do about the entry route. They design an interview exercise that tests judgement.

Learning objectives

Compare the four starting points for the role by what each is strong in, what to add first and the failure to watch.
Design a learning path on the four principles, with levels gated by demonstration and the first draft by the learner.
Explain what a certification validates and why a named certificate should not be a precondition in an advertisement.
Design an interview exercise with seeded flaws that runs in an unassisted and an assisted condition.

Key concepts

Four starting points: Security engineer, enterprise architect, developer and auditor. Each brings part of the framework and lacks another, so every path begins with an individual gap assessment against the six domains, not with a course catalogue.
Four principles of a learning path: Practice on real artefacts, fast feedback that the path manufactures, levels gated by demonstration instead of course completion, and protected unassisted practice under the rule: first draft by the learner, then the assistant.
Certification as a floor: A certification validates knowledge on the day of an examination, a real and inexpensive signal, but not one of judgement on the organisation's estate. Practical demonstration is the gate for levels in the competence record.
Two-condition exercise: An interview exercise run unassisted, showing what the candidate can design, and assisted, showing what the candidate can verify. The difference between the two scores is information about judgement.
Cooling-off period: A recorded interval before a person assures a system they helped to build, because an architect who designs a boundary and then assures it marks their own work. The chapter takes twelve months as a sensible default.

Teaching plan

15 min	Lecture on the four starting points and the four principles of a learning path; participants identify their own starting point and the domain to add first.
10 min	The teacher walks through the certification table; groups rewrite a job advertisement that demands a named certificate, tool names and years of experience.
15 min	Read Hansa's profile HP-HM-2027-01 and exercise IX-HM-2027-01: sittings, counterbalanced order, seeded flaws, the decoy and why version B is the telling one.
30 min	Exercise: participants design an interview exercise for one decision in their role charter, with a flaw catalogue and scoring criteria.
5 min	Wrap-up on the entry route and the four responses an organisation controls.

Discussion

The chapter argues that an examination's power to separate doers from recallers weakens as assistants improve, and labels that its own conclusion. What follows for how you read a candidate's credentials?
Nordvik upskills its post-holder with an external mentor and builds a deputy; Hansa hires from outside for one post. Which questions in the upskilling-or-hiring table decided each case?
A contracted architect who leaves nothing behind adds dependence. What three conditions does the chapter set for such engagements, and how would you check them?

Exercise · 30 minutes

Design an interview exercise that tests judgement

Following the chapter's guide, design an interview exercise for a security architect post in your organisation. Choose one decision from the role charter, for example the boundary of a Mode 5 agent acting on a core system. Write a short scenario for a fictional organisation so that no confidential configuration is disclosed. List five to eight seeded flaws of different kinds, structural, authority, evidential, scope and reversibility, described as design mistakes, plus one decoy that is unusual but sound. Write scoring criteria that reward finding each flaw, explaining its consequence and proposing a remedy. Set the two conditions, their timings and order, and state the data policy for candidates' answers.

Deliverable: An exercise specification with scenario outline, restricted flaw catalogue, decoy, scoring criteria, the two sittings with timings and a candidate-data policy.

Self-test

What is the chapter's rule for the use of an assistant during learning tasks?
1. The assistant drafts and the learner corrects, to save the mentor's time
2. No assistant is used at any point in the twelve months
3. The learner may use any tool as long as the artefact passes review
4. First draft by the learner, then the assistant, used as reviewer or tutor
In Hansa's hiring profile HP-HM-2027-01, how are applications screened?
1. By an AI ranking of candidates, reviewed by the hiring lead
2. By human review against the required levels, with no AI ranking of candidates
3. By years of experience and a named architecture certificate, as a floor for external candidates
4. By tool names matched against the platform's technology list
Which starting point does the chapter say is usually strong in law and evidence, and must add design and code first?
1. The auditor, who brings independence
2. The security engineer
3. The developer, who brings code
4. The enterprise architect, who brings design

Chapter 23 · 60 minutes

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

The lesson asks whether there will be a security architect in 2036 and answers with a horizon register for the role. Participants learn why a profession should not forecast its own future unaided, which trends the chapter labels observable, expected and speculation, the four scenarios with their leading signals and what each would lose, the seven no-regret measures, and how the author's own judgement is kept apart and labelled. They build a register with computed signals for their own role.

Learning objectives

Classify trends affecting the role as observable, expected or speculation and state what each label justifies.
Describe the four scenarios for 2036 with the leading signal of each and what would be lost.
Define computable signals with thresholds and owners for at least one scenario.
Explain why the seven no-regret measures hold whichever scenario arrives.

Key concepts

Horizon register for a role: A file beside the role charter in which every trend carries a label, its sources, the artefacts it affects and the decision it supports. It is kept by the role's holders but approved by the CISO, because holders have an interest in a particular answer.
Commitment, preparation, reversibility: What the three labels justify: observable trends are documented now and justify commitment; expected trends rest on a stated trend or decided instrument with uncertain timing and justify preparation; speculative trends justify keeping decisions reversible.
Four scenarios: Absorbed into platform engineering, a governance role, commander of agent teams, and the role disappears. They are speculation by construction; the most likely future is a mixture whose proportions differ by organisation.
Signal: A measure that can be computed, has an owner and has a threshold, preferably a ratio computed from repositories and team-level records. The share of architecture changes at each autonomy level is the clearest signal of which scenario is arriving.
No-regret measures: Seven measures that hold across all four scenarios: keep the craft, express boundaries as code with named owners, write decision rights down, register the role's own delegations, evidence competence with and without AI, protect the entry route, and keep the stop path outside what it stops.

Teaching plan

10 min	The teacher opens with the conflict of interest in a profession forecasting itself, and the purpose of scenarios as changing perception, not prediction.
15 min	Sorting activity: participants receive the chapter's trends on cards and place each under observable, expected or speculation, then compare with the chapter.
10 min	Groups each take one scenario and present its leading signal and what would be lost, using Table 23.1.
20 min	Exercise: participants write a register excerpt for their own role with trends, signals with thresholds and the status of the no-regret measures.
5 min	Wrap-up: the teacher reads the author's judgement, labelled as a projection, and asks what evidence would change it.

Discussion

The chapter calls the disappearance of the role the least likely and the most dangerous scenario, because it would come as a sequence of sensible delegations. Which delegations in your organisation could no longer be taken back?
Nordvik's leading signal is the share of tender requirements the post-holder wrote and can verify unaided. What would be the equivalent signal for your own role?
Why does Hansa's register give the signal for loosening changes merged at Level 3 a threshold of one?

Exercise · 20 minutes

Keep a horizon register for your role

Write the first version of a horizon register for the security architect role in your organisation. Enter five trends from the chapter, each with a label of observable, expected or speculation, its source or a statement that it is your organisation's own judgement, the artefacts it affects, such as the role charter, competence records, hiring profiles or tier policy, and the decision it supports. Choose the scenario you consider nearest and name at most three signals for it, each computed from repositories or team-level records, with a current value if known, a threshold and an owner. List the seven no-regret measures with their status. Name the owner, the approver and the review date before the budget and hiring plan are set.

Deliverable: A register excerpt in the form of HZN-HM-SA-01 with five labelled trends, up to three signals with thresholds and owners, and the status of the seven no-regret measures.

Self-test

How does the chapter label the trend that agents become reliable enough to verify architecture proposals without a competent human reviewer?
1. Observable, on the near-universal adoption reported by the 2025 DORA research
2. Speculation: no evidence was found, and evaluators favouring their own output argue against it
3. Expected, because the length of tasks that models complete keeps doubling
4. Expected, once the high-risk regime of the AI Act applies to Annex III systems on 2 December 2027
In the scenario where the architect becomes a commander of agent teams, what does the chapter say would be lost?
1. The view across the seams between platforms, suppliers and countries
2. The person who can answer for the boundary to a supervisor
3. The separation of those who design from those who assure
4. The route by which commanders and verifiers are made
Who keeps and who approves the horizon register for the role, and why?
1. HR keeps it and the works council approves it, because it concerns people
2. Internal audit keeps it and the management body approves it, because the register is an independent assurance document
3. The role's holders keep it and the CISO approves it, because holders alone would drift towards reassurance
4. The platform team keeps it and the architect approves it, because signals come from repositories

Module 6 · Part VI · Experience and Conclusions

Part VI turns from the craft to the experience of practising it. Four lessons cover three cases and five anti-patterns with a diagnostic, one year in the role at Nordvik Region and Hansa Mutual with what went wrong as well as what worked, the answers each organisation gave and its 24-month plan, and the book's conclusions with their firmness and a first-90-days plan. Participants leave with a diagnosed practice, a year review with a went-wrong field, a funded plan in which autonomy rises last, and their own first steps.

Lecture · 45 minutes

What a year in the role teaches: order, failure and people

Part VI tests the book against experience. The lecture reads three cases and five anti-patterns as ways of failing a shift, follows two practices through a year in which every timed stop path failed its first drill and every failure was caught by a mechanism the architects had designed, compares a contract-first plan with a delegation-first plan, and closes with the thesis restated and qualified: the scarce resource is accountable human judgement, and also the capacity to exercise it at the volume the estate now produces.

10 min	Five anti-patterns, three questions An anti-pattern is not a mistake but a reasonable-looking solution adopted repeatedly with the same bad outcome; each of the five is a way of failing one of the shifts. The agent incidents of 2025 and 2026 reduce to three questions: does the boundary depend on the agent's compliance, does it leak through a service the agent can reach, and does the alert reach the stop holder? The gate rule is the architect's product, and a wrong rule is wrong at scale, so sampling is the control on delegation. A contract is a boundary only when its terms are tested.
12 min	The year as a sequence Shift 1 came first, because a charter, a catalogue and a tier policy in the repository were what every later step read. Shift 3 became real only when the stop paths were timed and failed: 26 minutes against 15 at Nordvik, 17 against five at Hansa. At Hansa a deterministic gate restored a UK logging setting changed under an approved exception; the post-merge sample found it six days later. A timeline that records only decisions reads as a success story; the went-wrong field is evidence that the practice learns.
10 min	Two answers, two plans Nordvik mostly procures, so its lever is the contract; Hansa mostly builds, so its lever is the platform. What worked was the instrument each already had; what was hard was the resource each lacked, a second person and review capacity. Plan against the constraint, order measures by reversibility, and write autonomy increases as thresholds: in both plans autonomy rises last and only on recorded conditions.
13 min	The thesis tested The thesis held with three qualifications: judgement is also a throughput constraint, the transformation is uneven, and the role can be lost through a sequence of reasonable delegations. Seven cross-cutting conclusions, from the boundary as the product to evidence replacing attestation; those about boundaries, time and law are the firmest. The order that matters: written authority before delegation, boundaries before speed, measurement before autonomy. A new architect joins the approver pool on evidence of calibration, not on a date.

What the audience takes away

Run the catalogue of anti-patterns on your own practice from records, never from memory, and give every red answer an owner, a test and a date.
Failures caught by designed mechanisms and answered by decision records are the evidence that a practice learns.
What remains with the security architect is deciding boundaries, verifying what code and AI propose, and answering for both; never approve what you could not have written.

Chapter 24 · 90 minutes

Case Studies and Anti-Patterns

The lesson collects what recurs when a security architecture practice changes: two illustrative composite cases, one observable case built from public agent incidents, and five anti-patterns, each described by the shift it violates, its symptom, cause, remedy and test. Participants learn the three questions an architect asks of an agent incident, the five properties the successful cases share, and a twelve-question diagnostic answered from records. They diagnose a practice and write an anti-pattern record.

Learning objectives

Describe the five anti-patterns by the shift each violates, its symptom and the test that shows the remedy works.
Apply the three questions on boundary dependence, leakage and the stop decision to an agent incident.
Diagnose a security architecture practice with the twelve questions, answering from records and marking each red or green.
Draft an anti-pattern record with symptom, cause, remedy, verification test and owner.

Key concepts

Anti-pattern: Not a mistake but a solution that looks reasonable, is adopted repeatedly and produces the same bad outcome each time. The chapter describes each by five fields kept as code: the shift violated, the symptom, the cause, the remedy and the test.
The five anti-patterns: The architect as bottleneck, the diagram nobody runs, the AI that approved itself, the control catalogue nobody maps, and the sign-off in seconds. The first fails Shift 2 and with it Shift 3, the second and fourth Shift 1, the third and fifth Shift 4.
Three questions for an agent incident: Does the boundary depend on the agent doing what it was asked? Does it leak through a service the agent can reach? Does the alert reach the person who holds the stop decision, with the authority and means to use it?
Sampling as the control on delegation: The lesson of the review-board case: the gate rule is the architect's product and a wrong rule is wrong at scale, so a regular sample of gate decisions is what finds a rule that drifted from its intent.
Structural and behavioural forms: Two ways an AI team approves itself. In the structural form the permissions allow an agent to approve or to write to what it is checked against. In the behavioural form the rules hold, but the architect has become a signature on unchecked work.

Teaching plan

15 min	Lecture on how to read the cases, illustrative composites against the observable case, and on Table 24.1 linking each anti-pattern to a shift and a remedy.
15 min	Groups apply the three questions to the three public incidents using the chapter's table, and report which boundary depended on the agent's compliance in each.
15 min	The teacher walks the five anti-patterns field by field; participants vote privately on which their own practice shows and compare with Nordvik's and Hansa's findings.
35 min	Exercise: participants answer the twelve diagnostic questions for their practice from records and write one anti-pattern record for a red answer.
10 min	Debrief on the five properties the successful cases share and on how a bottleneck under pressure produces the sign-off in seconds.

Discussion

The chapter says asking people to be more careful is not a remedy for the sign-off in seconds. Why not, and what does it offer instead?
Both composite cases kept a single point of failure in the architect. How would you treat the architect's own capacity as a constraint in your organisation?
Both Nordvik and Hansa found that most remedies existed before the diagnosis. What did the diagnosis add, and why does that matter?

Exercise · 35 minutes

Diagnose your practice for anti-patterns

Run the chapter's diagnostic on your own security architecture practice for the last two quarters. Answer the twelve questions from records, never from memory, and mark each red when it meets the chapter's condition or cannot be answered: for example a median wait for routine classes above five working days, no pipeline check that reads the architecture model, any agent with write access to what it reviews, any catalogue entry without an owner, a mapping and a test, or no seeding of errors. Name an independent reader who would re-derive three answers. Then write an anti-pattern record for one red answer with the shift violated, the observed symptom, the cause, the remedy with its decision records, the verification test with a pass condition, an owner other than the person assessed and a review date.

Deliverable: A completed twelve-row diagnostic table with red and green marks and sources, and one anti-pattern record in the form of AP-HM-SIS-01.

Self-test

In the composite case of the review board that became a design authority, how was the faulty gate for new network paths discovered?
1. A supervisor requested the gate's decision log under NIS 2
2. The design authority reviewed every gate decision at its weekly session
3. An agent flagged its own approval of a path into a reclassified zone
4. A monthly sample of 10 per cent of gate decisions found it
What test does the chapter give for the remedy of the anti-pattern 'the AI that approved itself'?
1. A drill in which an agent identity tries to approve its own proposal on a protected path is refused and alerts a stop holder
2. A quarterly survey in which every reviewer confirms in writing that they read each agent proposal before approving it
3. A seeded-error detection rate of at least 80 per cent over a quarter, with a tier 2 median of two minutes
4. A deliberate off-model change in a test environment that is caught within a single run of the pipeline
Which diagnostic answer marks the sign-off in seconds as red for agent proposals at tier 2 and above?
1. A median wait of more than five working days for routine classes, or any change blocked during the architect's absence
2. An oldest unresolved drift finding more than 90 days old
3. A median approval time under 60 seconds, or a rejection rate under 2 per cent over 100 proposals
4. Fewer than half of routine decisions taken at a gate

Chapter 25 · 75 minutes

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

The lesson follows two security architecture practices through one year, from autumn 2026 to autumn 2027, in the order things happened and with the friction, mistakes and decision records of each turn. Participants see the four shifts as a sequence, learn what went wrong at Nordvik Region and Hansa Mutual and which designed mechanism caught each failure, how the architects' week changed, and how to review a year against the shifts. They write a year timeline with a went-wrong field.

Learning objectives

Trace the order in which the four shifts appeared in each organisation's year and explain why the order of artefacts mattered.
Identify, for at least four failures in the year, the mechanism that caught it and the decision record that answered it.
Compare how the architects' working week changed at Nordvik Region and Hansa Mutual between October 2026 and October 2027.
Review a year in the role as a timeline with decisions, failures, shifts and year-end claims classified as verified, declared or failed.

Key concepts

The shifts as a sequence: Shift 1 came first because the charter, catalogue and tier policy in the repository were what every later step read; Shift 2 followed through contracts and gates; Shift 3 became real when stop paths were timed and failed; Shift 4 took the form of a deferral or of review tiers and caps.
went_wrong field: The entry in the year's timeline for every failed drill, expired exception, missed seed and gate decision reversed by sampling, linked to the decision that answered it or marked open. It is what makes the timeline evidence that the practice learns.
Wrong at scale: Hansa's July failure: a tier 1 gate restored a UK logging setting to the group baseline although it had been changed under an approved exception, because the gate did not read the exception register. No agent was involved; the post-merge sample found it.
The later instrument governs: How Nordvik settled the conflict between its manifest, which allowed edits at Level 2 Supervised, and its charter, which capped the architect's own AI at Level 1 Assisted: the stricter, later charter governed until the manifest was aligned as version 3.0.0.
Human binding constraint: The year-end finding in both organisations: the limit was one person's availability at Nordvik and six people's review capacity at Hansa, where reviewing AI-drafted proposals became the largest use of the team's time.

Teaching plan

15 min	The teacher tells the year quarter by quarter from Table 25.1; participants keep a two-column note of what went wrong and what caught it.
15 min	Groups reconstruct one failure each: the expired exception, the missed seed, the two stop drills, the aborted chaos experiment, the held model update or the wrong gate rule.
10 min	Read the table of the architects' week before and after; discuss why verification takes time that the agents' drafting does not save.
30 min	Exercise: participants write a timeline of their own practice's last year with decisions, a went-wrong entry per failure and a shift per entry.
5 min	Wrap-up: each participant names the shift for which their year holds no measurement.

Discussion

Both first stop drills failed, and the chapter calls this what a drill exists to produce. How would such a result be received by your management body, and how would you present it?
During the architect's leave at Nordvik a model update was held for three weeks because only the architect's charter named one check. What does the fix in AIDR-0542 keep, and what does it change?
At Hansa consultation, not engineering, set the agent team's pace. Is that a cost or a control, and why?

Exercise · 30 minutes

Review your year against the four shifts

Write the timeline of your security architecture practice for the last four quarters, following the chapter's practical guide. For each quarter list the decision records produced; a turn that left no record is itself a finding. Add a went-wrong entry for every failed drill, expired exception, missed seeded error and gate decision reversed by sampling, and link each to the decision that answered it or mark it open. Place each entry against one or more of the four shifts, using their exact names. Classify each year-end claim as verified, declared or failed. List what is open at year end. Keep the plan for next year out of the timeline: it is a separate artefact.

Deliverable: A four-quarter timeline in the form of NR-SA-2026-2027 with decisions, went-wrong entries, shifts, measured values and a list of what is open at year end.

Self-test

Why did Nordvik's first out-of-hours stop drill of the benefits-triage integration route take 26 minutes against a budget of 15?
1. The canary alert reached a duty analyst who did not hold the decision, and tokens outlived the revocation
2. The managed security service provider held the runbook but not the credentials
3. Only two caseworkers remembered how to triage without the ranking
4. TriageSoft had not accepted the stop-path requirement in the annex
What did Hansa do when agent review volume rose by about 40 per cent after consultation and the Tier 2 queue lengthened?
1. It moved Tier 2 proposals to Tier 1 so that one reviewer sufficed
2. It let the critique agent approve proposals on low-risk paths
3. It lowered the proposal cap and recorded the decision to slow the agents as AIDR-0593
4. It raised the review agents to Level 3 Bounded for reversible policy changes so that fewer proposals needed a person
What caught the tier 1 gate that wrongly restored a UK logging setting to the group baseline at Hansa?
1. The post-merge sample, six days later
2. The policy-author agent's own report of the change
3. The UK supervisor's request for the evidence pack
4. The quarterly seeded-error drill

Chapter 26 · 75 minutes

Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

The lesson sets out what Nordvik Region and Hansa Mutual decided, the answer each gave to its governing body, what worked and what was hard, and a 24-month plan for each. Participants learn why the same four shifts produced a contract-first plan in one organisation and a delegation-first plan in the other, how a plan is built against a constraint with autonomy increases written as thresholds, and what remains unresolved. They build a 24-month plan for their own practice.

Learning objectives

Summarise the answer each organisation gave to its commission and the evidence behind what worked and what was hard.
Explain why the two plans differ in order, using the levers, the people and the law each organisation has.
Build a 24-month plan against the binding constraint, with owners, verifications and conditional autonomy increases.
State what the chapter leaves unresolved for each organisation and for accountability in general.

Key concepts

Contract-first and delegation-first: The two plans. Nordvik mostly procures, so its leverage is the contract and its plan starts with the deputy and supplier evidence. Hansa mostly builds, so its leverage is the platform and its plan starts with review quality and patch velocity.
Plan against the constraint: For each shift, name the one constraint that most limits the practice, such as the single post or review throughput, and order measures by the constraint they relieve and then by reversibility: reversible measures early, hard-to-undo commitments late and conditional.
Autonomy as a threshold: Autonomy increases are written as conditions on recorded evidence. The default is none without two consecutive quarters of review-quality evidence. In both plans autonomy rises last and only on recorded conditions.
Verification of a measure: Each measure has an owner by role and a verification that produces evidence, such as a drill time or a share of verified controls, so that the plan can be checked against what happened.
What remains unresolved: The single point of failure at Nordvik, including how the architect is replaced; review throughput at Hansa; the regimes outside the EU; and whether a court would accept the records that show who answers for an agent-proposed change.

Teaching plan

15 min	Lecture on one question and two answers: what each organisation decided across the book, with the artefact table at year end.
15 min	Two groups argue what worked and what was hard, one for Nordvik and one for Hansa, citing the figures the chapter gives.
10 min	Read PLAN-NR-SA-2027 and the excerpt of PLAN-HM-SA-2027: find the constraint, the verification of each measure, the conditions on autonomy and the revision triggers.
30 min	Exercise: participants build a 24-month plan for their own practice with at most three decisions for the commissioning body.
5 min	Wrap-up: what each organisation could learn from the other, measuring before delegating and writing records for a hostile reader.

Discussion

Nordvik had to build what Hansa already had; Hansa had to remove what Nordvik never built. Which sentence describes your organisation, and what follows for your first six months?
Hansa's cap turns the limit of six reviewers into a queue and not a rubber stamp. What would persuade your executives that a visible queue is the better outcome?
Whether a court would accept the organisations' records as sufficient remains untested. How should that uncertainty shape what you record today?

Exercise · 30 minutes

Build a 24-month plan for your practice

Following the chapter's six steps, draft a 24-month plan for your security architecture practice. List the last year's decisions as done, in progress or reopened. For each of the four shifts name the one constraint that most limits the practice, and choose the binding one. Write four to six measures ordered by the constraint they relieve and then by reversibility, each with a period, an owner by role and a verification that produces evidence, such as a drill time, a share of verified controls or a review-quality figure at team level. Write any autonomy increase as a threshold with its conditions and exclusions. Name at most three decisions for the commissioning body and the triggers on which the plan is revised.

Deliverable: A plan in the form of PLAN-NR-SA-2027 with constraint, four to six measures with owner and verification, conditional autonomy, up to three decisions and revision triggers.

Self-test

Under what condition does Nordvik's plan reopen the question of an agent team in months 18 to 24?
1. When the supplier TriageSoft offers a hosted review-agent service
2. When the verified share of tracked controls reaches 60 per cent
3. When two people with evidenced competence can supervise agents
4. When the regional executive committee funds a second architect post
What figures did Hansa's first quarterly report show for review quality after the redesign of AIDR-0556?
1. A Tier 2 median of 28 seconds, a rejection rate of 1 per cent and no seeding
2. A Tier 2 median of 11 minutes, a rejection rate near zero and 80 per cent of seeded errors caught
3. A Tier 2 median of four working days and 57 of 61 items agreed with the board
4. A Tier 2 median of 22 minutes, a rejection rate of 17 per cent and 86 per cent of seeded errors caught
According to the chapter, why does Nordvik upskill its post-holder instead of hiring a second security architect?
1. Because ENISA's profile forbids external hiring for public authorities
2. Because fixed pay scales and security vetting make hiring slow
3. Because the union refused to agree the assessment rules
4. Because the platform team already holds Advanced in design and law

Chapter 27 · 75 minutes

Conclusions: The Transformed Security Architect

The lesson tests the book's thesis and draws its conclusions. Participants learn the three qualifications of the thesis, the seven cross-cutting conclusions with how firm each is and what would change it, how the conclusions reinforce and pull against one another, which open questions the book answers, what to do first, next and later, and how a new architect takes up the role in the first 90 days. The author's own judgement is presented as a labelled projection. They write their own first-90-days plan.

Learning objectives

State the thesis and the three places where the concluding chapter qualifies it.
Explain the seven cross-cutting conclusions and classify each as observable or expected, with what would change it.
Sequence the actions the chapter recommends first, next and later, and justify the order.
Draft a first-90-days plan for taking up a transformed security architect role.

Key concepts

Three qualifications of the thesis: The scarce resource is also the capacity to exercise judgement at the volume the estate produces; the transformation is uneven across the four shifts; and it is not guaranteed, because the role could disappear through a sequence of reasonable delegations.
Seven cross-cutting conclusions: The boundary is the product, not the review; decision rights are written before the pressure; time is a design property and the drill its evidence; verification, not drafting, is the constraint; the craft is kept deliberately; accountability ends in a person; evidence replaces attestation.
Tensions held by written rules: Speed pulls against verification, delegation against the craft, and evidence against co-determination. Each tension is held by a written rule that a person reviews, such as the highest tier for irreversible changes or team-level reporting of review metrics.
First, next, later: The sequence follows the order the year found to matter: written authority before delegation, boundaries before speed, measurement before autonomy. It runs over the first six months, six to eighteen months and eighteen to thirty-six months.
Calibration before approval: A new architect joins the approver pool on evidence of a seeded-error calibration, by default 20 proposals with a catch rate at or above 0.85, not on a date, and until day 90 does not approve at the highest tier.

Teaching plan

15 min	Lecture on the thesis restated and qualified, and on the reflections on each part of the book.
15 min	Groups take the seven conclusions, state the firmness of each from Table 27.1 and argue what evidence would change it.
10 min	The teacher presents what to do first, next and later and reads the author's judgement as a labelled projection; participants say which advice they would act on first.
30 min	Exercise: participants write a first-90-days plan for themselves or for a new colleague, including what may not be done before day 90.
5 min	Closing round: each participant states one decision right they will get in writing and one stop path they will time.

Discussion

The author projects that Shift 4 is the hardest because it fails quietly. Do you agree, and what in your own practice would reveal such a failure?
The firmest conclusions concern boundaries, time and law; the least firm concern what AI will do to the architect's judgement. How should that difference shape where you commit and where you keep decisions reversible?
The chapter says what remains of the role is smaller in volume and larger in consequence. What does that imply for how the role should be graded, staffed and deputised?

Exercise · 30 minutes

Write a first-90-days plan

Write a plan for the first 90 days of a security architect taking up a transformed role, for yourself or for a new colleague, following the chapter's practical guide. For the first week, list the decision rights in the charter with time limits and overrides, or note that a charter must be drafted. For days 1 to 30, plan a boundary map of the post's boundaries from the architecture model with peer review and findings for untested boundaries. For days 31 to 60, plan one unaided threat model compared with an AI draft and a seeded-error calibration. For days 61 to 90, plan first approvals and one timed stop drill. State the ceiling on own AI use, the protected unassisted practice and what may not be done before day 90.

Deliverable: A plan in the form of PLAN-HM-SA-PL-90 with three phases, deliverables and verifications, an own-AI ceiling, protected practice and a not-before-day-90 list.

Self-test

Which of the seven cross-cutting conclusions does Table 27.1 label as expected and not yet observable?
1. Verification, not drafting, is the constraint
2. Time is a design property, and the drill is its evidence
3. The boundary is the product, not the review
4. The chain of accountability ends in a person
What does the chapter recommend doing in the first six months?
1. Raise an agent's autonomy on conditions recorded in advance, and bring every legal regime into the catalogue as an overlay
2. Write the role charter, put own AI use under a mandate manifest, start the control catalogue and time one stop path
3. Delegate the review board's routine classes to gates and open competence records
4. Keep a delegation register with yearly reversibility tests and mentor a junior
How does the concluding chapter leave question Q12, whether there will be a security architect in 2036?
1. Answered: the role will be absorbed into platform engineering
2. Answered: the role will exist as a governance role only
3. Partly answered, pending the first court ruling on agent-authored change
4. Open by nature, with the author's judgement given only as a labelled projection

Answers to the self-tests

Chapter 1	1B · 2D · 3A (1) The chapter states that none of the incident's failures was a failure of a model; each concerned where a boundary was drawn and who could act on it, which is the security architect's territory. (2) The chapter answers the question of what remains scarce with accountable human judgement in three parts: accountability, the ability to verify what code and AI propose, and the craft that makes verification possible. (3) The instruments are observable law and place duties on management bodies and deployers; none mentions the security architect. Naming an accountable architect per boundary is described as an expected practice, not a legal duty.
Chapter 2	1A · 2C · 3B (1) The chapter reports that external change approval was associated with slower delivery and no better stability than peer review and automated checks, and adds that the finding concerns external, periodic review, not review as such. (2) The gap was that no detections existed for AI gateway events, and the disposition was to delegate the section to the managed security service provider under NR-2025-044. It is the one section that changes owner. (3) Review, logging, segregation of duties and sign-off all depended on every action tracing to a person or a person-owned service account. A Mode 5 agent acts with its own identity and permissions at a pace no person's account matches.
Chapter 3	1C · 2D · 3A (1) More shifts would describe content instead of change in the role. The chapter gives 'from perimeter to zero trust' as one answer to Shift 2, and 'from compliance to evidence' as Shift 1 applied to assurance. (2) Shift 4 is observable in early adopters, but its effect on decision quality is not established by any study the book has found, so the chapter labels claims in either direction speculation. (3) The dependency check flags Shift 4 above Shift 2 because the AI team's autonomy then outruns its containment. This is Hansa Mutual's one flag: the agent team produces proposals faster than the group has delegated decisions.
Chapter 4	1C · 2D · 3B (1) The stop holder is the person on the incident rota who can act at three in the morning. Making the architect a precondition would make stopping more expensive than continuing, so the architect only recommends. (2) The gate policy's author answers for its adequacy and the forum that delegated the class answers for the delegation, so the chain of accountability never ends in an agent or a pipeline. (3) The charter caps the architect's own AI at Level 1 Assisted for Modes 1 and 3 under MND-NR-01, stricter than the Level 2 Supervised that version 1.0.0 of the manifest allowed; the stricter ceiling governs from the charter's effective date.
Chapter 5	1A · 2C · 3D (1) The second rule reports a crossing from agent-runtime to core-systems without a policy point and blocks the merge. The architect never read the diagram; the principle was written once and the pipeline applied it. (2) Each property must be testable by a rule, and a rule cannot test a property that two teams spell differently. The list of zones and classes is therefore itself a versioned file changed by pull request. (3) An unmodelled agent identity is a finding for the identity domain architect on the day it is found, because a Mode 5 agent the model does not know is a boundary no rule tests.
Chapter 6	1B · 2D · 3A (1) The generator works at Level 1 Assisted, writes only to a pull request comment and never to the accepted model, and no AI accepts a threat, a risk or an exception. (2) The architecture cuts the third leg of the trifecta by denying egress and the manifest has no outbound tool, so T-103 is rejected with the trigger revisitWhen: tools, which raises it again the day an outbound tool is added. (3) A candidate must be mitigated by the right family, never 'improve the system prompt' in place of a control outside the model, because prompt injection is a property of the architecture and the controls sit outside the model.
Chapter 7	1C · 2B · 3D (1) For an agent the identity is genuine and the permissions legitimate, but the sequence of actions is chosen at run time by a model reading content anybody may have written. Zero trust therefore verifies the action as well as the actor. (2) Before the review the shared mirror in Frankfurt could fetch from public hubs on request, so any workload that reached it could reach those hubs. Hansa restricted the mirror to a signed allow-list of upstream namespaces and removed it from the agent's destinations. (3) The test cadence follows the change cadence of the dependencies, and a failed or overdue test moves the control from verified to declared automatically, because a boundary that has not recently been tested is a declaration.
Chapter 8	1D · 2B · 3A (1) The guide defines revocation by a path outside the agent's runtime with a target of 60 seconds for a Mode 5 agent, and requires that it be tested; Chapter 10 places the test among the stop paths. (2) The register is fixed at contract signature, the one moment when the Region verified who TriageSoft's people are. Inbound voice, video, email, chat and SMS are all treated as untrusted channels for these changes. (3) The last row of the chapter's table is a rule of issuance, not of intent: the broker does not issue a Level 4 token for an action classed as irreversible, whatever the agent proposes or the owner requests.
Chapter 9	1A · 2C · 3B (1) A rule owned by the architect and reviewed by the CISO applies the status in the pipeline, so no control owner can type it in. The evidence-collection agent refreshes evidence but cannot alter the rule, the tests or the exceptions. (2) The replay found that the managed security service provider's detections cover only some of the Region's scenarios, so the control did not work as its objective states. The finding goes to the CISO for the contract discussion. (3) Each agent has its own manifest, but the same tool gateway enforces all three, which is one point of failure. The finding leads to a second, independent control or to an accepted risk with an expiring exception.
Chapter 10	1C · 2A · 3B (1) The exploited and exposed class, signalled by KEV or EUVD exploited status on an internet-facing asset, carries 24 hours for mitigation and 72 hours for the fix, with the decision delegated in advance. (2) The drill took 17 minutes: the alert went to a SOC duty analyst who had to page the operator and had no mandate to apply the deny rule, and credential revocation alone left 15-minute tokens valid. (3) The chapter labels it expected, on a stated signal: in July 2026 the European Central Bank wrote to significant institutions about AI-enabled cyber threats, placed the response with management bodies and asked for action plans.
Chapter 11	1B · 2D · 3C (1) The definition sets memory to discard and pending actions to frozen, reviewed by the operator rota in Poland, with autoReplay false. A new workload identity is issued and the old credentials are not restored. (2) Only two caseworkers still remembered how to work without the ranking. The finding extends the test for delegation DEL-NR-BEN-01 and becomes a change to the induction programme and a fallback manifest checked weekly. (3) Level 4 Autonomous is never used for irreversible actions, and because recovery contains some, it is not used for recovery at all. A system returned to service starts at a lower level and regains its level only after renewed approval.
Chapter 12	1C · 2A · 3D (1) The tasks took 19 per cent longer when AI was allowed, although the developers had predicted a 24 per cent speed-up and afterwards still believed in about 20 per cent. Feeling helped is not a measurement. (2) The manifest sets edit_files and run_commands at Level 2 Supervised, where the architect approves each, and denies commit_and_push. The tool also cannot write to the protected oracle paths. (3) The second test requires a record when the options, framing or evidence came from the assistant and the decision is hard to reverse, such as a boundary placed, an exception granted or a tender requirement written.
Chapter 13	1B · 2D · 3A (1) Only maintenance of the evidence record, which describes the architecture and does not change it, may run at Level 3 Bounded: the evidence collector's refresh of an evidence link, which keeps the previous link and changes no control. (2) The orchestration is a deterministic pipeline, not a manager agent. No agent assigns work to another or decides which outputs reach the architect, and conflicts are placed side by side for the code owner. (3) Option A was rejected because one architect cannot supervise a team and there is no second reviewer. Option B, a supplier's service, was rejected over hosting; option C extended MND-NR-01 with a research skill at Level 0 Advisory.
Chapter 14	1A · 2C · 3B (1) When two runs on identical inputs produce materially different changes, the proposal was not determined by the inputs alone. Instability does not prove a proposal wrong, but it is a cheap and reliable reason to look harder. (2) The oracle tests passed, but the domain security architect found that no test covered market binding for the new endpoint, wrote one, and the proposal failed it: the rule allowed the endpoint for claims from every market. (3) A change to an oracle, to the review protocol or to a mandate manifest always takes the highest tier, because it changes the standard every later proposal is judged against. Tier 3 covers irreversible or self-referential changes.
Chapter 15	1D · 2B · 3C (1) The adenoma detection rate of experienced endoscopists in standard colonoscopies without AI fell from about 28 per cent to about 22 per cent. The chapter notes it is a single observational study but the first clinical evidence of its kind. (2) The default is half a day per architect per fortnight, about five per cent of working time, reduced only by a recorded decision, because the assisted path is always faster that week. (3) If either condition of the gate fails, the two-architect evidence or the seeded-error detection threshold, the action returns to Level 2 Supervised, so autonomy rises only as fast as the capacity to supervise it.
Chapter 16	1B · 2D · 3A (1) The AI architect proposes what the guardrails check and how they are evaluated; the security architect holds the ceiling of egress, workspace isolation and the rule that no guardrail is the only control; the platform team operates. (2) The more restrictive position stands until the named tier decides, and the default lapses after 30 days so that restriction does not become a veto by delay. (3) Platform membership makes boundaries defaults for every team but makes self-review and the conflict between delivering and constraining features hard. A standing seat keeps designer and builder apart.
Chapter 17	1C · 2A · 3D (1) The class runs in shadow for four weeks and is delegated only when gate and board agree on at least 95 per cent of at least 20 decisions and every disagreement is explained. (2) Classes C7 and C8 are at Level 0 Advisory for any AI proposer, because an agent must never change the rule that governs it or the path that stops it. Both are tier 3 decisions. (3) Renewal is a new decision, not an extension, and requires new evidence such as a supplier's committed date or a fresh test result. A renewal attaching nothing new is declined.
Chapter 18	1D · 2B · 3C (1) The test replays a synthetic incident and asserts an early-warning draft in under four hours, leaving most of the 24 hours for human judgement. A new control covers the awareness timestamp. (2) Annex III, point 5(c), concerns risk assessment and pricing for life and health insurance, not claims routing. Article 26 is therefore conditional for the agent, and the pre-built oversight control is honestly held as declared. (3) Under CRA Article 12 such a system is deemed to meet the cybersecurity requirement of AI Act Article 15 in so far as its declaration of conformity shows it, so one piece of supplier evidence serves two instruments.
Chapter 19	1A · 2C · 3B (1) A report asking for no decision is a briefing, and the board page should ask for at most three decisions, each with cost, reversibility and what it affects; a board that receives seven requests decides none, so the architect prioritises. (2) The auditor tests the agent instead of repeating its work, checking its links against the source system and its mandate manifest against what it did. The test of the collector is itself a catalogue control. (3) Review quality is always aggregated at team level, never by named person, and agreed in advance with employee representatives who have rights over measures that could monitor individuals.
Chapter 20	1B · 2D · 3A (1) Mandatory requirements are kept to what law or risk appetite makes non-negotiable, by default no more than twelve per tender, with the rest weighted under the award criteria of Article 67 of Directive 2014/24/EU. (2) SR-02 requires every ranking, with inputs and model version, in the Region's log store within 15 minutes and kept at least 12 months, beyond the six-month floor, because appeals can arrive later. (3) The tightening check fails the pipeline if any value is weaker than the baseline, such as a shorter retention, fewer notification recipients, a later deadline or a control removed, or if a protected control is missing.
Chapter 21	1C · 2A · 3B (1) A person's level is the lower of the unaided and AI-assisted demonstrated levels, however good the repository looks. The rule rests on the automation literature: operators who rarely do a task manually lose the skill to take over. (2) Certificates evidence knowledge, so the framework accepts them as supporting evidence at Foundation and Practitioner but never as sufficient for Advanced or Expert, where judgement must be demonstrated. (3) Hansa's conditions file requires two holders of AI-03 at Advanced for the Level 3 ceiling; if unmet, the ceiling falls to Level 2 Supervised. A lapse is managed like an expired certificate on a service, not as a disciplinary event.
Chapter 22	1D · 2B · 3A (1) The rule is first draft by the learner, then the assistant, used as reviewer or tutor, because unrestricted assistance during practice lowers unaided performance afterwards. Supervised practice with Mode 3 tools comes only after the task can be done unaided. (2) Screening is human review against the required levels with ai_ranking_of_candidates set to false, and the profile does not screen on tool names, years of experience or a named certificate. AI used to filter applications is high-risk under Annex III, point 4(a). (3) The auditor is usually strong in law and evidence and adds design and code first; the failure to watch is fault found without a design owned. Nordvik's post-holder is closest to this path.
Chapter 23	1B · 2D · 3C (1) Reliable verification of AI by AI is labelled speculation. Chapter 14 found no evidence for it, and the finding that language-model evaluators recognise and favour their own generations argues against assuming it. (2) What would be lost is the route by which commanders are made, because an architect who has never written a threat model unaided cannot verify the one an agent drafts. The scenario is stable only if learning tasks are reserved. (3) Because of the conflict of interest, the register is kept by the role's holders but approved by the CISO, with signals computed from repositories and records where possible; a register that only the holders maintain will drift towards reassurance.
Chapter 24	1D · 2A · 3C (1) The gate read a local copy of the zone labels and not the architecture model, and approved three paths into a reclassified zone. A monthly sample of 10 per cent of gate decisions found it, which is why sampling is the control on delegation. (2) The test is an authorised drill in the organisation's own repository: an agent identity attempts to approve its own proposal on a protected path, which must be refused and must alert a person who holds the stop decision. (3) Question 11 is red when the median approval time for agent proposals at tier 2 and above is under 60 seconds, or the rejection rate is under 2 per cent over 100 proposals. Question 12 adds seeded-error detection under 80 per cent, or no seeding.
Chapter 25	1B · 2C · 3A (1) The provider held the runbook but not the credentials. Annex MS-1 then gave it authority to revoke credentials out of hours, AIDR-0541 added a scoped break-glass credential, and the October re-drill took 11 minutes. (2) Because the proposal cap held, the queue grew and the depth of review did not fall. The head of security architecture lowered the cap and recorded the decision to slow the agents as AIDR-0593. (3) The post-merge sample found the change six days later. No agent was involved: a deterministic rule did exactly what it said, which is why the sampling exists. AIDR-0591 made every tier 1 gate read the exception register.
Chapter 26	1C · 2D · 3B (1) Measure M4 reopens the agent-team deferral against its triggers on the condition that two people with evidenced competence can supervise agents, with the decision recorded either way. (2) After the redesign the first quarterly report showed a Tier 2 median of 22 minutes, a rejection rate of 17 per cent and 86 per cent of seeded errors caught, against a summer median under thirty seconds with rejections near zero. (3) The Region upskills because fixed pay scales and security vetting make hiring slow, building on the conclusion that upskilling is the strategy and hiring is for scarce specialisms. The funded post backfills the platform team so an engineer can serve as deputy.
Chapter 27	1A · 2B · 3D (1) That verification becomes the constraint is labelled expected, on the trend in AI task length and automation bias; reliable verification of AI by AI, which would change it, is speculation. Boundaries, time and law are observable. (2) First come the charter, a mandate manifest for the architect's own AI use with a ceiling of Level 1 Assisted, a control catalogue starting with agent egress, machine identities and the stop path, and one timed stop drill: written authority before delegation. (3) Table 27.2 leaves Q12 open by nature. The book answers eight of the twelve questions and three in part; the author's view that the role will exist in 2036 is a projection, labelled as such, and not one of the book's findings.

Final assignment

A security architecture practice file for one organisation. Assemble the artefacts of the course into one practice file for a single organisation: your own, or Nordvik Region or Hansa Mutual as the book describes them. The file must show the role with written decision rights, one boundary designed and tested, one control with evidence, one timed property, the rules under which AI takes part in architecture work, and a plan in which autonomy rises last. Every claim in the file is classified as verified, declared or failed, and every artefact names an accountable person by role. Present the file as a one-page report asking a management body for at most three decisions. Security content stays at the level of design, review, detection and drills.

Assessment criteria

Faithfulness to the book: the four shifts, usage modes, autonomy levels and artefact names are used exactly, and nothing is invented.
Testability: every boundary, control and time claim has a test that can fail, an owner and a status of verified, declared or failed.
Accountability: each decision right resolves to one holder, no agent approves or is accountable, and Level 4 Autonomous is never used for irreversible actions.
Honesty of evidence: declared and unmeasured items are stated as such, and AI-drafted parts are disclosed with their verifier.
Usefulness to the reader: the report asks for at most three decisions, each with cost, reversibility and consequence of not deciding.