Tools: teacher's guide

How to use this guide

The guide holds everything a teacher needs to run the course on Tools: 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 on what the toolbox is, how two organisations built theirs and how to tell whether one works. It follows the reader path the book gives a board member or programme owner: building a toolbox, the conclusions, then choosing, adopting and retiring tools.
One-day seminar (1 day): A working day that teaches the rules of the reference in the morning and then samples one tool family from each activity, with short exercises on Nordvik Region, Hansa Mutual or the participants' own organisation. Participants leave with a draft toolbox plan and three filled-in templates.
Full course (8 weeks, one module a week): The complete course: one module a week, each with a lecture on the part and one lesson per chapter with an exercise that produces a real artefact. The capstone, a toolbox for one service or system, is built up week by week and presented in the final session.

Keynote on the whole book · 45 minutes

The name, the owner, the test and the date: one toolbox for ten books

For a mixed audience of architects, governance and security leads, operators and managers in European enterprises and public authorities

Ten books of The Transformed Architecture define or name more than sixteen hundred tools. Read side by side, they show one design in many dialects: records with a shared anatomy, identifiers that link them into chains, evidence that carries a date, checks made from outside the thing checked, and autonomy that is earned, budgeted and revocable. The lecture shows how to find a tool in ten minutes, how a cautious buyer and a builder assemble different toolboxes from the same parts, and why the series' rule holds everywhere: adopted means in use, and working means tested with a date.

6 min	The problem: which of ten books holds the tool for X? A practitioner had to know which volume to open; the reference organises the tools by what the practitioner is doing. Four kinds: artefact, own tool, third-party tool and method; laws and bare concepts are not tools. The test of a reference: find the tools for the next piece of work in about ten minutes.
8 min	What every artefact has in common Purpose, inputs and outputs, an identifier, an owner, a decision record, links, a review date and an expiry. The chain from a service record of Nordvik Region to a failed restore test, a change and a risk acceptance reads in both directions. A prefix can name more than one artefact, so read the Origin row.
9 min	From rule to evidence, from threat to verified control A rule becomes a tool with an engine, tests, an independent decision point and a record of every decision. A threat, a detection and a recovery are claims until a dated test turns them into evidence. Authorised testing is scoped by a signed manifest, stoppable from outside and ends in a defensive improvement. A register that counts untested claims gives a board a smaller and more honest number.
8 min	Agents: a label without a control Mandate per agent, delegation profile per service; an unlisted action is undelegated and the lowest ceiling governs. An observer the agent cannot write, an autonomy budget the observer counts, and a stop path outside the platform. A rise in level is a recorded decision by a named authority; a fall is immediate.
7 min	People: agree first what a record may not be used for Every decision about a person has a named human decider, a route to contest and a reviewer outside the line. A competence record that cannot rank or discipline can be shared widely enough to condition an agent's autonomy. Contested claims are graded, labelled, owned and given triggers in both directions.
7 min	Two toolboxes and what to do on Monday The order follows the gap: Nordvik Region makes a procured system legible, Hansa Mutual bounds agents that already act. Measure the toolbox by evidence age, adoption and retirements. Read the Origin row, record the template version, choose defaults by decision, reserve identifier ranges and date every claim.

What the audience takes away

The series is one design in many dialects: anatomy, linked identifiers, evidence age, independence and earned autonomy.
Adopted means in use; working means tested with a date; a tool past its clock is unverified.
The tools are in the volumes; a toolbox adds the name, the owner, the test and the date.

Module 1 · Part I · The Toolbox

Part I sets the rules of the reference. The participant learns the four kinds of tool, how the catalogue was compiled from an inventory of ten volumes, how an entry is read, what all artefacts have in common, how identifier families link records into chains, and how a tool is selected, adopted, reviewed and retired. The participant leaves able to find a tool in about ten minutes and to say what evidence shows that it still works.

Lecture · 45 minutes

A toolbox is a set of dated claims, not a shelf of templates

The lecture carries the argument of Part I: a reference is useful in proportion to how fast it answers and how far its sources can be trusted. It defines the four kinds of tool, shows what the inventory of 1,629 entries claims and leaves out, walks the identifier chain from a service record of Nordvik Region to a risk acceptance, and then follows a tool through its four decisions: select, adopt, review and retire. The thread is the rule that adopted means in use and working means tested with a date.

8 min	What counts as a tool, and what does not The four kinds: artefact, own tool, third-party tool and method, with one example of each from the series. Laws and regulations are instruments that obligations come from; a tool may help to evidence an obligation but is never the obligation. The usage modes and the degrees of delegation are concepts; a delegation profile that applies them is an artefact.
8 min	How the catalogue was compiled and what it claims An inventory of 1,629 entries across ten volumes: 641 artefacts, 378 methods, 370 third-party tools and 240 own tools, of which 227 are publishing scripts. Three rules: nothing is invented, disagreements between volumes are recorded, and the order of the series holds. Appendix A is the safeguard: every entry is listed there, so a tool missing from the prose can still be found by name or prefix.
10 min	The common anatomy and the identifier chain Every artefact states a purpose, inputs and outputs, carries an identifier, names an owner, cites a decision record and gives a review date and an expiry. Field names differ between templates, so search by identifier and not by field name. The chain from SVC-NR-002 through SLO-NR-002, the failed restore test RST-NR-2027-002 and CHG-NR-2028-0007 to the risk acceptance in DRF-NR-001 reads in both directions. Some prefixes name more than one artefact, so the Origin row is read before the prefix is trusted.
12 min	Four decisions in the life of a tool Select against one unit of value: build, buy, reuse a feature already held, solve without AI or do nothing, each mapped onto a kind of tool. Adopt on a dated readiness reading, through a gate whose items name their evidence, and show use with a dashboard that protects the people it measures. Review from records; retire by criteria written into the decision record at adoption. An anti-pattern is closed by a passed re-test and not by a merged remedy.
7 min	Two organisations, two scales of toolbox Nordvik Region buys, has one legal regime, a seven-person platform team and no agent at Mode 5. Hansa Mutual builds, spans several jurisdictions and operates agents with write access to production. A tool that suits one often needs adaptation for the other, and the entries say so where the originating books do.

What the audience takes away

A tool is an artefact, an own tool, a third-party tool or a method; laws and bare concepts are not tools.
Search by identifier and read the Origin row, because field names differ and a prefix can name two artefacts.
Adopted means in use; working means tested with a date; retirement is decided when the tool is adopted.

Chapter 1 · 60 minutes

Introduction: A Toolbox for the Series

The lesson sets the boundary of the reference. Participants classify tools into the four kinds, separate tools from laws and from the series' concepts, read the inventory figures for what they claim, and practise reading an entry row by row. A worked search for the post-incident review shows the ten-minute test that the book sets for itself, and the two fictional organisations are introduced as two scales of tool use.

Learning objectives

Classify a given tool as an artefact, an own tool, a third-party tool or a method and justify the classification.
Explain why laws, usage modes and degrees of delegation are not tools in the sense of the book.
Read an entry by its fixed rows and follow its Origin and Inputs rows to related tools.
Locate a tool in Appendix A or the Tool Finder by name or identifier prefix.

Key concepts

Artefact: A template, manifest, record, register, checklist, policy or schema that a book defines: a document with a structure, usually YAML or Markdown, kept in version control and read by people and often by software. Artefacts are the largest group in the inventory.
Own tool: Software or a script that a book or its repository provides, such as the Maturity Radar of Architecture as Code. The 227 publishing scripts of the ten repositories are inventoried and listed in Appendix A but not treated in the chapters.
Third-party tool: Software, a platform, a library, a service or an open standard that a book names as something practitioners use, such as Terraform, Open Policy Agent or Sigma. It is described only from its own documentation and only as far as the series' claims go.
Method: A named, repeatable procedure with steps, an input and an output, such as burn-rate alerting, a game day or a pre-mortem. It differs from a general idea in that someone could follow it on Monday.
The rows of an entry: Kind, Origin, Purpose, Use when, Inputs, Outputs, Identifier family and Full template, in a fixed order. A row is omitted when the originating book does not say, and two to six sentences of prose follow the table.

Teaching plan

10 min	The teacher opens with the problem the book solves: a practitioner had to know which of ten volumes to open. Present the four kinds with the chapter's examples and the things that are not tools.
10 min	Walk through Tables 1.1 and 1.2 of the inventory and the three rules of compilation. Participants say what the count per volume does and does not show.
10 min	Read the rows of an entry together and replay the worked example: the search for the prefix PIR, the choice between the review of AI Blue and that of AI Operations.
20 min	Exercise: participants run the ten-minute test on their own next piece of work and record the path they took.
10 min	Debrief in plenary: which searches succeeded, which tools sat in an unexpected chapter, and how Nordvik Region and Hansa Mutual would differ in the choice.

Discussion

Why does the book refuse to treat the AI Act, the GDPR, DORA and NIS 2 as tools, and what would a reader lose if it did?
The count of entries per volume says how many tools a volume defines or names, not how useful it is. What other readings of Table 1.2 should a teacher warn against?
An entry may relate to two chapters and be treated in one. How should a team that builds its own catalogue handle the same problem?

Exercise · 20 minutes

The ten-minute test on your next piece of work

Name one piece of work you must do in the next month, for example a post-incident review, a supplier renewal or the approval of an agent. Using Appendix A or the Tool Finder at tools.geon.se, search by name or identifier prefix for the tools the series offers for it. For three tools, write down the kind, the originating book and chapter, the purpose in one sentence and the inputs you would need. Where two artefacts share a prefix, as the two post-incident reviews do, state which one fits your case and why. Time yourself and note where the search stalled.

Deliverable: A one-page search log: the task, three tools with kind, origin, purpose and inputs, the choice made between any artefacts that share a prefix, and the minutes used.

Self-test

According to the chapter, what distinguishes a method from a general idea?
1. It is defined in an appendix of a volume and carries an identifier prefix of its own, such as SVC or DLG
2. It has steps, an input and an output, so someone could follow it on Monday
3. It is implemented in software that one of the ten repositories provides alongside its publishing scripts
4. It is required by an article of a European legal instrument
Of the 240 own tools in the inventory, how many are publishing scripts that are listed in Appendix A but not treated in the chapters?
1. 13
2. 114
3. 533
4. 227
In the worked example, why does the reader preparing a review of a service outage choose the post-incident review of AI Operations over that of AI Blue?
1. The two share the prefix PIR, but the review of AI Operations serves a service incident and that of AI Blue a security incident
2. The review of AI Blue was withdrawn when AI Operations redefined the prefix PIR in a later volume
3. The review of AI Operations is shorter and takes only the ninety minutes the book allows
4. The review of AI Blue has no full template, so it cannot be filled in for an outage

Chapter 2 · 75 minutes

The Anatomy of a Tool: Kinds, Identifiers and Lifecycle

The lesson looks inside the artefacts. Participants learn the common anatomy (identifier, status, version and date, owner, decision record, links, review and expiry, evidence), the principal identifier families and the volumes that carry them, and how records cite one another. They trace the chain from the service record SVC-NR-002 to the risk acceptance in DRF-NR-001 and learn why evidence age, version control and an explicit lifecycle make a record trustworthy.

Learning objectives

Identify the parts of the common anatomy in an unfamiliar artefact template.
Trace a chain of records in both directions by their identifiers.
Explain why a reader should search by identifier and read the Origin row before trusting a prefix.
Describe the lifecycle stages of an artefact and the fields that carry review and expiry.

Key concepts

Common anatomy: A set of habits, not a formal schema: an artefact states an identifier, a status, a version and date, an owner, the decision record that approved it, links to other records, a review and expiry, and its evidence. Not every artefact has every part.
Identifier family: A prefix of usually two to four capital letters and a hyphen, followed by a rest that carries the organisation, the year or both and a sequence. The infix NR or HM is a convention of the examples; templates use XX.
AI Decision Record: The record that approves a decision about an AI system, to which nearly every other artefact points. From The Transformed Security Architect on, each volume reserves a number range, for example AIDR-0900 to AIDR-0999 in AI Operations.
Evidence age: A record that supports a claim says when the claim was last tested and when it expires. In AI Operations the default clock for a restore or failover test of a Tier 1 service is 180 days or a substantive change, whichever comes first.
Lifecycle of an artefact: Proposal, approval and first use, review, suspension, and expiry and retirement, as shown by the status, review and expiry fields of the templates. Lowering a ceiling is immediate; raising one needs a named authority's decision.

Teaching plan

15 min	Present Table 2.1, the common anatomy, with the field names of AI Operations. Show that the decision record is called decision_record in one template and decision in another.
15 min	Walk through Table 2.2 of identifier families. Participants pick out prefixes that name more than one artefact: DLG, CHG, CAP, RST and SCE.
15 min	Trace the chain of the worked example on the board: SVC-NR-002, SLO-NR-002, RST-NR-2027-002, CHG-NR-2028-0007 and the risk acceptance in DRF-NR-001, forwards and backwards.
20 min	Exercise: participants draw the identifier chain for one service or agent of their own organisation and mark the missing links.
10 min	Debrief: which review and expiry fields were missing, and what version control would let a pipeline check.

Discussion

The objective record SLO-NR-002 shows a failed restore test beside the recovery objective. What does an organisation gain and risk by publishing the failed evidence next to the promise?
The books do not force the frame onto a template where it does not fit: the service record has no status. When is a missing part of the anatomy a defect and when is it a sound design?
The chapter concludes that the more an actor can do without a person in the loop, the more of the anatomy must be present before it acts. How would you apply that to a new agent proposal?

Exercise · 20 minutes

Draw the identifier chain of one service

Choose one important service in your own organisation, or use the citizen e-service portal of Nordvik Region. List the records that exist for it and give each an identifier in the families of the series: a service record, an objective record, the most recent restore test, any change motivated by that test and any risk acceptance that covers a gap. Draw the chain with arrows for the fields that cite another record. For each record, write the owner, the date of its evidence and the review or expiry date. Mark every link, owner or date that you cannot fill in from an existing document.

Deliverable: A one-page chain diagram with at least four linked records, each with identifier, owner, evidence date and expiry, and a list of the gaps found.

Self-test

What did the restore test RST-NR-2027-002 show about the citizen e-service portal of Nordvik Region?
1. Failover took 5 hours 20 minutes against an objective of 2 hours, so the claim was withdrawn
2. Failover completed in 2 hours, which confirmed the recovery objective for another 180 days of evidence
3. The test was planned for 2027 but never run, so the objective record cites no evidence at all for the portal
4. Backups restored within the recovery point objective of 5 minutes
Why does the chapter advise searching a repository by identifier and not by field name?
1. Identifiers are shorter than field names and therefore faster to type into the search box of a repository
2. Field names are encrypted in the templates of the later volumes of the series
3. The same part of the anatomy has different field names in different templates
4. Identifiers are assigned centrally by the author and are never reused for a second artefact in any volume
Which statement about raising and lowering a delegation ceiling matches the chapter?
1. Both raising and lowering need a new AI Decision Record before they take effect
2. Raising is immediate once tests pass; lowering needs the level authority's approval
3. Neither can change until the 90-day review of the delegation profile comes round
4. Lowering a ceiling is immediate; raising one is a named authority's decision

Chapter 3 · 90 minutes

Choosing, Adopting and Retiring Tools

The lesson follows a tool through four decisions: select, adopt, review and retire. Participants use the option comparison of AI Governance, the readiness scorecard of Architecture as Code, the adoption dashboard definition, the production readiness checklist and the anti-pattern records of the later volumes. The thread is the chapter's rule that adopted means in use and working means tested with a date, and its finding that the series has no single retirement artefact.

Learning objectives

Compare options for a tool against one unit of value and one quality constraint, including a non-AI option and doing nothing.
Interpret a readiness scorecard total and say what a band does and does not permit.
Design an adoption measure that shows use without reporting on named individuals.
Draft retirement criteria and an anti-pattern record that closes on a passed re-test.

Key concepts

Option comparison: An artefact of AI Governance, Chapter 16A: a fair comparison of build, buy, reuse, non-AI and do-nothing options against one unit of value, one quality constraint, a measured baseline, three-year cost ranges and exit and sovereignty terms.
Readiness scorecard: A 15-criterion scorecard of Architecture as Code (Chapter 26A), scored 1 to 5 across five dimensions. A total of 60 to 75 means ready to proceed with a focused pilot, 40 to 59 partial readiness, below 40 foundation work needed.
Adoption dashboard definition: A YAML metrics definition from AI Governance, Chapter 15, deployed by the same pipeline as the system. Its healthy range on the override rate encodes that both extremes fail: near zero means oversight has become ceremony.
Production readiness checklist: A YAML checklist of AI Platform and Security, Chapter 23, aligned to the deployer obligations of Article 26 of the AI Act. The pipeline blocks deployment until each item's evidence exists and is newer than the last model or prompt change.
Anti-pattern record: A record under the family AP with a pattern, evidence, a control, an owner and a re-test. Its closing rule is that the pattern is closed when a re-test passes, not when the remedy is merged.

Teaching plan

15 min	Present the lifecycle of Figure 3.1 and the two questions of the chapter. Map the five options of AI Governance, Chapter 16A, onto the four kinds of tool.
20 min	Teach adoption: the readiness scorecard and its bands, the five attributes of diffusion with their architectural responses, the champions charter and the adoption dashboard with its healthy range.
15 min	Teach gates, review and retirement: the production readiness checklist, knowledge hygiene, the four retirement instruments and the gap the chapter names. Compare the anti-pattern records of the volumes.
30 min	Exercise: groups write a five-phase adoption roadmap for one tool, modelled on the policy engine example of Nordvik Region.
10 min	Groups present one gate decision and one retirement criterion each; the room challenges any evidence that carries no date.

Discussion

The option comparison requires a row for solving the problem without AI and a row for doing nothing. Why do governance forums so often skip those rows, and what does skipping them cost?
The champions charter lists what champions do not do, including reporting on whether named colleagues use a tool. How does that list change what the adoption dashboard may show?
The chapter finds that the series has no single artefact that records a tool's retirement. What should such a record contain, and who should confirm it?

Exercise · 30 minutes

A five-phase adoption roadmap for one tool

Choose one tool your organisation is considering, or take the policy engine at Nordvik Region. Write a roadmap in the five phases of the chapter's worked example: select, pilot and prove, expand and federate, govern and optimise, sustain and retire. For each phase name the tools of the chapter you would use, the decision at the gate and the evidence that closes the phase. In the select phase include a non-AI option and do nothing. In the last phase write the retirement criteria as they would stand in the decision record, and list what would be revoked, deleted, archived and confirmed.

Deliverable: A table with five rows (phase, tools, gate decision, closing evidence) and a short list of retirement criteria with a review date.

Self-test

A readiness scorecard for a planned pilot totals 52 points. What does the scoring guidance of Architecture as Code say?
1. Ready to proceed: begin with a focused pilot in one domain
2. Foundation work needed: follow the remediation roadmap first
3. Partial readiness: address the critical gaps before scaling
4. Certified: no further readiness review for twelve months
In the adoption dashboard definition, what does an override rate near zero indicate?
1. That the system is accurate enough for its owner to propose a move to a higher level of delegation
2. That oversight has become ceremony, which is a failure just as a high rate is
3. That staff have not been trained and cannot find the override function in the systems of record they use
4. That the dashboard is aggregating below its minimum group size
When, according to the anti-pattern records of AI Operations and AI Blue, is an anti-pattern closed?
1. When the remedy has been merged into the main branch
2. When the owner of the record signs the remedy off
3. When the next quarterly review finds no new signal
4. When a re-test of the control has been run and passes

Module 2 · Part II · Architecture and Delivery

Part II covers the tools of architecture and delivery: models and decision records kept as text, policies that an engine evaluates on every change, pipelines that sign and store what they checked, and the platform layers on which AI systems run. The participant leaves able to choose a model language, write a decision record, read a Rego gate, pick one shape of evidence manifest and say which platform components a team may adapt and which it may not remove.

Lecture · 45 minutes

Text, checks and evidence: one pull request from model to proof

The lecture carries the argument of Part II. The model, the requirements and the reason for a decision are text under version control, reviewed in one pull request. A rule becomes a tool when an engine can evaluate it, it has tests, a decision point its author does not control evaluates it and every decision leaves a record. The platform is declared in files that a pipeline can check, and the declaration is kept apart from the system it governs. Examples come from Architecture as Code, AI Platform and Security, The Transformed Security Architect and AI Operations.

10 min	Architecture that a rule can read Diagram decay: a drawing and a system drift apart when updating the drawing is a separate manual act. The C4 model in the Structurizr DSL is the series' default; CALM is an alternative with a younger ecosystem. Trust zone, data class, usage mode, identity, owner and policy point as properties let a pipeline fail an unprotected crossing.
8 min	Why it looks that way: the decision record family The ADR, the AI Decision Record and the decision minute are one family with different jobs. Keep the format small and add only fields that a script reads. A validator is part of the record's definition: the repository of Architecture as Code ships four scripts for its ADRs and describes one in a chapter.
12 min	From rule to gate to evidence Open Policy Agent and Rego are the common engine and language; the policies differ mainly in their input documents. A gate is only as good as the inputs it reads, so a check on the resulting state belongs with every gate that reads a plan. Bill of materials, provenance attestation and signature answer what is in an artefact, how it was built and who vouches for it. Evidence is written once, signed by the pipeline run, bound to an obligation and given an expiry.
10 min	The platform as declared files State needs its own care: it can hold secrets, and declared and actual state diverge between runs. The gateway is the one component that is not optional, because logging, redaction, routing and budgets apply there to every AI call. Every promotion has an owner who did not build what is promoted.
5 min	Limits on autonomy that these tools set The policy decision point stays outside the agent at every degree of delegation. An agent-authored change has an independent human approver, and no agent identity holds the right to sync a state engine.

What the audience takes away

Choose a model language by whether a rule can read it, and keep the decision beside the model.
A rule is a tool only with an engine, tests, an independent decision point and a record of every decision.
Choose one shape of evidence manifest, keep the gateway, and give every promotion an approver who did not build it.

Chapter 4 · 75 minutes

Architecture and Decision Tools

The lesson treats the tools for describing an architecture and recording why it looks as it does: the C4 model, Structurizr, CALM, the declarative reference architecture model of AI Platform and Security, the Structurizr workspace with trust-zone properties of The Transformed Security Architect, and the Architecture Decision Record with its validators. Participants learn how much must be modelled and recorded at each usage mode.

Learning objectives

Compare the C4 model in the Structurizr DSL with CALM as a model language that pipelines can check.
Draft an Architecture Decision Record with status, review dates and deciders in the template of Architecture as Code.
Annotate model elements with the security properties that a zone-crossing rule needs.
Determine which decision record a usage mode requires and at what threshold.

Key concepts

Diagram decay: The drift between a diagram drawn in a graphical tool and the system it shows, because updating the diagram is a separate manual act. Architecture as Code answers it with one text model under version control from which diagrams are generated.
Declarative reference architecture model: An artefact of AI Platform and Security, Chapter 4, that declares the layers, patterns and control plane as code with a pinned version. A team records deviations in an AI Decision Record but does not remove the gateway, registry, evaluation service or control plane.
Workspace with trust-zone properties: A Structurizr workspace from The Transformed Security Architect, Chapter 5, in which trust zone, data class, usage mode, identity, owner and policy point are element and relationship properties, so a pipeline rule can fail a pull request that creates an unprotected crossing.
Architecture Decision Record: A short text document, after Nygard, that captures one decision with its context and consequences in a numbered file under version control. The number ADR-NNNN is permanent even if the record is later deprecated or superseded.
Market overlay: An artefact of AI Platform and Security that applies jurisdiction-specific constraints on top of the pinned reference model. Nordvik Region runs its reduced variant as an overlay on a pinned base, recorded in AIDR-0002.

Teaching plan

15 min	Present Figure 4.1, from model to decision record, and the three model languages. Note that Structurizr Lite, the standalone CLI and the cloud service have reached end of life.
15 min	Read the excerpt of the Hansa Mutual workspace: the claims-triage agent with its trust zone, data class, usage mode and identity. Ask what the missing direct relationship to the core claims system proves.
10 min	Walk through the ADR template and what validate_adrs.py requires. Present the table of decisions recorded per usage mode.
25 min	Exercise: participants write one ADR and annotate three elements of their own architecture with security properties.
10 min	Pairs review each other's record: is the review date set, are the deciders named, could a script read every added field?

Discussion

The chapter says CALM's adoption is observable but its standing in regulated sectors is expected, not established. How should that label affect a choice of model language today?
A reader adopting the ADR template should add only fields a script will read. Which fields in your own decision records does nothing read, and what do they cost?
For Modes 0 to 3 the series asks only for a short record and an inventory entry. Where does that lighter requirement become a risk in practice?

Exercise · 25 minutes

One decision record and three annotated elements

Take one recent architecture choice in your own organisation, or Hansa Mutual's choice that the claims-triage agent has no direct write path to the core claims system. Write it as an Architecture Decision Record in the template of Architecture as Code: identifier, title, status, date, last reviewed, next review due, deciders, context, decision and consequences. Then list three elements of the architecture the decision touches and give each the properties of the trust-zone workspace: trust zone, data class, usage mode, identity, owner and, for each crossing between zones, the named policy point. Mark any property you cannot fill in.

Deliverable: One completed ADR and a table of three elements with their security properties and any missing values flagged.

Self-test

Which rule holds for every adaptation of the declarative reference architecture model, according to AI Platform and Security, Chapter 4?
1. A team may remove any layer of the model as long as an Architecture Decision Record explains the cost saving and names an owner
2. A team may change nothing in the model without a new pinned major version issued by the platform team
3. A team records deviations in an AI Decision Record but keeps the gateway, the registry, the evaluation service and the control plane
4. A team must run all the layers itself, including the training machinery, at every usage mode
What does the validator validate_adrs.py of Architecture as Code check?
1. That each ADR front matter is complete and its status is one of the four lifecycle statuses
2. That each ADR was approved by two reviewers from different teams
3. That each ADR links to a Structurizr view generated in the same pull request
4. That each ADR has been superseded within its review period
For which usage modes does the chapter's table require the full AI Decision Record always, for each system or agent?
1. Mode 0 Ambient AI and Mode 1 Conversational assistants, because suppliers change them most often
2. Mode 2 Embedded workplace assistants and Mode 3 Agentic work tools
3. Every mode from Mode 1 Conversational assistants upwards, once per user of the service
4. Mode 4 Built AI applications and Mode 5 Autonomous production agents

Chapter 5 · 90 minutes

Policy, Pipeline and Evidence Tools

The lesson follows one chain: a rule becomes a check that runs on every change, and the result becomes evidence someone else can verify. Participants meet Open Policy Agent, Rego and Conftest, the gating policies of the volumes (model approval, zone crossing, threat-model gate, change gate), the supply-chain tools SLSA, Sigstore and the bills of materials, and the six shapes of the evidence manifest, and work through a gate that rejects an unsigned model artefact.

Learning objectives

Explain the four conditions under which a rule becomes a tool in the sense of the chapter.
Read a Rego gate and state its input document, its deny reasons and its default.
Distinguish a bill of materials, a provenance attestation and a signature by the question each answers.
Select one shape of evidence manifest for a given question and justify the choice.

Key concepts

Policy decision point: The place where an engine evaluates a structured input against policy and returns allow or a set of deny reasons. In the series it is not controlled by the author of the change and stays outside the agent at every degree of delegation.
Change gate policy: An illustrative Rego policy of AI Operations that computes the change class from the plan, requires an independent named human approver for agent-authored change and refuses release outside the window. The author's declared class is treated as a claim.
Model approval policy: A Rego policy of AI Governance, Chapter 9, that approves a model version only if its model card is complete, its evaluation meets the thresholds of its risk tier, its licence is allowed, its provenance attestation verifies and its register entry is within appetite.
Evidence manifest: One idea in six shapes across six volumes, binding artefacts to controls, a release to obligations, a promotion to its checks or a re-test to a finding. A team should choose one shape, keep it in version control and index it.
Evidence pack index: An artefact of AI Governance, Chapter 11, family EP: a signed index of audit questions, the artefacts that answer them and their hashes, generated by query so a second auditor can regenerate it. An empty section is itself a finding.

Teaching plan

15 min	Present Figure 5.1, the policy, pipeline and evidence chain, and its two recurring properties: the decision point sits outside the author, and the pipeline writes the evidence store.
20 min	Read two gates side by side: the model approval policy and the change gate policy. Participants name the input document, the deny reasons and the default of each.
15 min	Teach supply chain and evidence: SLSA and in-toto, Sigstore and OpenSSF Model Signing, the ML-BOM, the six evidence manifests, and the warning that a scanner is itself a dependency.
30 min	Exercise: groups specify a gate and its evidence for one change type, following the five steps of the unsigned-model example at Hansa Mutual.
10 min	Debrief on what each group's gate does not prove, and where a check on the resulting state would sit.

Discussion

The worked example's gate checks that a signature was verified, not that the signer was the right party or that the model is safe. Which other tools of the chapter carry those claims?
The series records that a scanner one of its volumes lists to rely on was compromised. What follows for the way a team pins, verifies and reviews the tools that produce its evidence?
Why does the series insist that an agent-authored change needs a human approver who is neither the requester nor the author, even at Level 3 Bounded?

Exercise · 30 minutes

Specify a gate and the evidence it leaves

Choose one kind of change in your own organisation that should not reach production unchecked, or use the promotion of a model at Hansa Mutual. Specify a pipeline gate for it without writing code: the input document the policy reads, at least four deny reasons in plain sentences, the default decision, who controls the decision point, and the test you would write for each deny reason. Then specify the evidence the run leaves: which shape of evidence manifest you choose from the six in the chapter and why, what it binds, who signs it and when it expires. Finish with two things the gate does not prove.

Deliverable: A one-page gate specification with input, deny reasons, tests, decision point owner, chosen evidence manifest shape, signer, expiry and stated limits.

Self-test

According to the chapter's Summary, which four things make a rule a tool?
1. It is written by the security architect, approved by the management body, published on the intranet and reviewed once a year by internal audit
2. An engine can evaluate it, it has tests, a decision point its author does not control evaluates it, and every decision leaves a record
3. It is expressed in Rego, stored in a wiki, enforced by the agent whose change it gates and closed to exceptions
4. It cites a legal article, names a control owner, has a budget and is audited by a third party
Which property of evidence does AI Purple add that the earlier evidence manifests lack?
1. The manifest is signed by the pipeline run
2. The manifest binds artefacts to control identifiers
3. The manifest is generated by a store query
4. The evidence carries an expiry
What does the reconciler sync policy of AI Operations say about an agent identity and the right to sync a state engine?
1. An agent identity with the right to sync is something the artefact must never contain
2. An agent identity may sync during the allow window of the project if a named person is on call for the service
3. An agent identity may sync catalogued standard classes at Level 4 Autonomous
4. An agent identity may sync once the sync-policy review checklist shows all eleven points as passed

Chapter 6 · 75 minutes

Platform and Infrastructure Tools

The lesson covers the tools for building and running the AI platform: infrastructure as code with Terraform and OpenTofu, Kubernetes, the model registry entry, MLflow, the self-hosting readiness check, the RAG system configuration, the gateway security configuration and the team artefacts around a platform. Participants learn to separate open standards and replaceable components from products whose replacement has a price, and to say which tools apply at each usage mode.

Learning objectives

Explain why infrastructure state is treated as sensitive and how engines that compare when run differ from engines that reconcile continuously.
Complete a model registry entry that links a version to its run, data, evaluation and independent approvals.
Assess a model for self-hosting against the readiness check of AI Platform and Security.
Identify which platform tools apply at each usage mode and why the gateway is not optional.

Key concepts

Model registry entry: An immutable record from AI Platform and Security, Chapter 7, that links a model version to its run, data, model card, evaluation and approvals. Pipelines write it, except for the approvals, which name people who did not build the model.
Self-hosting readiness check: A checklist artefact, all of whose items must pass before a model is self-hosted in production. Each key has an owner or a test; the default patch times are seven days for critical vulnerabilities and 24 hours where exploitation is known.
RAG system configuration: An artefact that codifies ingestion, chunking, embedding, index and retrieval settings in one versioned file linked to an AI Decision Record. The entitlement filter runs before search, so a user's permissions limit what can be retrieved.
Gateway security configuration: A gateway policy of AI Platform and Security, Chapter 17, with a model allow-list, signed models, a client workload identity and guardrail layers that each assume the previous one failed. It is a defensive control kept in the repository.
Data product descriptor: The file the platform reads before it trains: it describes a data product's owner, schema, quality, lineage and access, including a classification block for personal data.

Teaching plan

15 min	Present Figure 6.1, the layers of the platform, and the two kinds of choice: open standard or replaceable component, versus product with a replacement price. Cover Terraform, OpenTofu and state.
15 min	Read the Nordvik Region registry entry for claims-ranker 4.0.0 and the self-hosting readiness check line by line; participants name the owner or test behind each item.
10 min	Present the RAG configuration and the gateway configuration, then the table of tools per usage mode and the rule to route traffic through the gateway wherever a tool allows it.
25 min	Exercise: participants run the self-hosting readiness check and draft a registry entry for one model.
10 min	Debrief: which items had no owner or test, and whether the approver of each promotion built what was promoted.

Discussion

The volume ties the retention of a model version to administrative law, not to storage cost: a case handled with a version can be appealed. What does that imply for the registry of a public authority?
The chapter says the answer to local model servers called by agentic coding tools is the gateway, not a ban. What makes a ban the weaker control?
Nordvik Region keeps the gateway, the registry, evaluation and the control plane but leaves training machinery to its providers. What does it still have to be able to show about a procured model?

Exercise · 25 minutes

Readiness check and registry entry for one model

Pick one model your organisation runs or plans to run itself, or take a fallback model that Hansa Mutual self-hosts in Frankfurt. First apply the self-hosting readiness check: for licence review, no unauthenticated endpoint, patch times for critical and known-exploited vulnerabilities, and weights taken only from the registry in a signed form, write the owner or the test and whether the item passes today. Then draft a model registry entry for the version: artefact location and signature, training run, data versions, model card, evaluation report, and the names or roles of approvers who did not build the model. State the retention you would set and the reason.

Deliverable: A completed readiness check with pass or fail per item and a drafted registry entry with independent approvers and a retention line.

Self-test

Why does the chapter call the gateway the single platform component that is not optional?
1. It is the only component that a supplier cannot provide as a managed service
2. It is the only place where logging, redaction, routing and budgets apply to every AI call
3. It is the component in which models are trained and their weights are stored
4. It is required by name in Article 26 of the AI Act for every deployer
In the RAG system configuration, when does the entitlement filter run, and why?
1. After generation, so that restricted passages can be redacted from the answer
2. During ingestion only, so that restricted sources are never embedded at all
3. Before search, so that a user's permissions limit what can be retrieved
4. At promotion time, so that the evaluation set covers every data class
What do the approved_by fields of the model registry entry record?
1. People who did not build the model
2. The pipeline identity that signed the artefact
3. The supplier that trained the base model
4. The data protection officer of the deployer

Module 3 · Part III · Governing AI

Part III covers the tools for governing AI. The participant follows a system from inventory and classification through risk and impact assessment, exception and AI Decision Record, then maps obligations to controls and evidence, tests a control independently, reads a maturity result with care, and binds a supplier from tender to exit. The participant leaves able to keep a small set of records that each say who owns this, what it is for and when it stops being valid.

Lecture · 50 minutes

Governing AI with records that expire

The lecture carries the argument of Part III: governance is a small number of records, each with an owner, a purpose and a date on which it stops being valid. It follows the chain from the inventory entry to the AI Decision Record, then the second chain from an article of law to a control, an independent test and a board page, and the third chain from tender to exit test. It shows where the volumes use one name for different things, and why an exception without an expiry or a mapping without an evidence age is not a weaker tool but an unmanaged thing.

12 min	From inventory to decision record You cannot classify what you cannot list: the inventory is derived from descriptors, and the usage-mode register catches Modes 0 to 3. The questionnaire, the classification policy and the risk appetite statement turn a use into a tier. A record without an owner, a review date or a trigger is treated as stale, and a stale record counts as an open risk. The AI Decision Record carries the decision and its retirement criteria; each volume reuses it with its own number range.
8 min	Exceptions that stay temporary As a meeting outcome an exception tends to become permanent; as a record with an expiry it stays temporary. The exception gate rule denies a change that relies on an expired exception. The prefix EXC names three different records in two volumes, so the kind and the schema identify the record.
12 min	From article to board page Assure once, comply many: execute and evidence a control once and map it to many frameworks. The mapping tools differ in what they refuse to leave out: an assurance artefact, a gate and evidence path, an evidence age and an owner. A catalogue entry without a test is a statement; assurance is said by someone other than the control's owner. Oversight-quality metrics are reported for groups and never to evaluate individual overseers.
8 min	What a maturity result means Two models of the series with different scales and subjects are not interchangeable. Maturity models measure practice, not outcome, and a self-assessment that nobody tests is a conversation starter.
10 min	Buying AI and being able to leave A requirement states how it will be verified, and a clause names the control that enforces it. An annex fixes a sample and a stop right outside the provider's platform. Origin assessment, requirements profile and decision matrix are three sovereignty tools that should not be confused. An exit plan carries the date and the result of its last test.

What the audience takes away

Every governance record answers who owns it, what it is for and when it stops being valid.
The chain from article to board page breaks at its weakest field, usually a missing evidence age.
Dependence on a supplier is acceptable when it can be undone and the exit has been tested.

Chapter 7 · 90 minutes

Inventory, Classification and Risk Tools

The lesson follows the chain of records made before an AI system does work: the AI system inventory entry and usage-mode register, the risk-tiering questionnaire and classification policy, the risk register entry and impact assessments, the exception record with its gate rule, and the AI Decision Record in its structured form. Participants learn which record is primary at each usage mode and why an exception without an expiry is an unmanaged thing.

Learning objectives

Draft an inventory entry and a risk register entry for one AI system with owner, review period and reopening triggers.
Explain how the risk-tiering questionnaire, the classification policy and the risk appetite statement together produce a tier and a decision.
Write an exception record with a compensating control, an expiry and renewal evidence.
Identify the unit of inventory and the primary record for each usage mode.

Key concepts

AI system inventory entry: A descriptor of one AI system, from AI Governance, Chapter 9, from which the organisation's inventory and a public register entry are generated. The deployment gate refuses status deployed for a high-risk entry without an EU database identifier.
Usage-mode register: A YAML register beside the inventory that lists use cases by usage mode with a baseline status per control. It catches uses in Modes 0 to 3 that never pass through a procurement of an AI system.
Risk register entry: A version-controlled entry, family RISK, that links a hazard to controls, assessments and the triggers that reopen it. An entry whose review period has passed is stale and is treated as an open risk.
Exception record: An expiring exception from The Transformed Security Architect, Chapter 17, with owner, compensating control and the evidence required to renew. The chapter's defaults are 90 days at tier 2 and 180 days at tier 3, to be adapted.
AI Decision Record as structured data: The machine-readable YAML form of the AIDR from AI Platform and Security, read by pipelines. A field that does not apply is marked not applicable with a reason, and the registry refuses to promote a model whose system has no accepted record.

Teaching plan

15 min	Present Figure 7.1, from intake to decision record, and the two rules that recur: stale records count as open risks, and the record, not a meeting, carries the decision.
20 min	Walk the Nordvik Region benefits-triage example through the inventory entry and the risk-tiering questionnaire, then read the register entry RISK-2026-014 of a benefits eligibility decision-support system. Participants name the basis cited for each answer.
15 min	Teach exceptions and decision records: read EXC-NR-0007, the exception gate rule and the excerpt of AIDR-0030. Show the table of unit of inventory and primary record per mode.
30 min	Exercise: participants produce the record chain for one system of their own, from inventory entry to exception.
10 min	Peer check: each pair looks for a record without an owner, a review date or a trigger in the other's chain.

Discussion

The substantial-modification rule does not decide that a change is a substantial modification; it decides that a human must make the judgement. Why is that division of work the right one?
The low tiers in Modes 0 to 3 hold only while the permitted uses hold. How does an excluded-uses list make drift visible, and who should watch for it?
Hansa Mutual classifies the same system once per regime in the countries where it operates. What does that do to the design of a register entry?

Exercise · 30 minutes

The record chain for one AI system

Choose one AI system in your own organisation, or the benefits-triage system of Nordvik Region. Write four short records for it in the forms of the chapter. First, an inventory entry with intended purpose, owner, role under the AI Act, risk tier, human oversight and linked assessments. Second, a risk register entry with one hazard, harm categories, controls, owner, review period and at least three triggers that reopen it. Third, an exception record for one control that cannot be met today, with reason, compensating control, expiry and what a renewal must attach. Fourth, the fields of the AI Decision Record that state intended and prohibited uses and retirement criteria.

Deliverable: Four linked records for one system: inventory entry, risk register entry, exception record and the key fields of an AI Decision Record, each with owner and dates.

Self-test

Why does every answer in the risk-tiering questionnaire carry a legal reference?
1. So that the questionnaire can be filed in the EU database without further review
2. So that the supplier, not the deployer, is accountable for the resulting tier
3. So that the classification policy can skip questions that have a reference
4. So that a reviewer challenges the basis of an answer rather than the conclusion
What does the exception gate rule of The Transformed Security Architect do?
1. It denies a change that relies on an exception whose expiry has passed
2. It renews an exception automatically when the compensating control passes its test
3. It escalates every exception at tier 3 to the design authority for a vote
4. It converts an expired exception into a risk register entry with a new owner
What is the unit of inventory for Mode 0 Ambient AI in the chapter's table?
1. The tenant deployment of the office suite
2. Each supplier feature that is switched on
3. Each agent and its delegated authority
4. The tool and its permitted uses

Chapter 8 · 90 minutes

Obligation, Assurance and Maturity Tools

The lesson answers three questions in a fixed order: which obligation applies and which control answers it, whether the control works according to someone independent of its owner, and where the organisation stands. Participants use the Control Mapping Matrix, the EU AI Act obligation mapping, the regulation-to-control mapping record, the control catalogue entry, the audit test procedure, oversight-quality metrics and the two maturity models of the series, and learn the limits of each.

Learning objectives

Map one obligation to a control, a test, an evidence item and an evidence age using a mapping tool of the chapter.
Compare the mapping tools by what each refuses to leave out.
Write a control catalogue entry with enforcement, evidence freshness and a test.
Interpret a maturity result from either model of the series and state what it does not show.

Key concepts

Assure once, comply many: A method stated in Architecture as Code (Chapter 10): execute and evidence a control once, then map it to many frameworks. It fails when the mapping is a list of articles with no evidence beside each row.
Regulation-to-control mapping record: An artefact of AI Operations, family RCM: one row per control with the instruments it serves, the evidence age and review dates. Its owner is in the second line and independent of operations, and a failed test withdraws the claim.
Control catalogue entry: A control, family CTRL, with an owner, the obligations it serves, its enforcement, an evidence source with a freshness in days, a test and a status. The chapter's verdict: an entry without a test is a statement.
Oversight-quality metric: A metric, family OQM, that shows whether human oversight is real by override rate, seeded-error catch rate and review time. It is reported for groups and never to evaluate individual overseers, and three volumes define it differently.
Maturity self-assessment: The record of the AI Governance model: five levels from Exploring to Optimising over eight dimensions. An organisation is at a level when it meets that level's indicators and every level below; one overall level is the lowest dimension.

Teaching plan

15 min	Present Figure 8.1, assure once and comply many, and the five families. Stress that laws appear only as what the tools are mapped to.
20 min	Compare four mapping tools on one slide: Control Mapping Matrix, EU AI Act obligation mapping, obligation register and RCM record. Participants find what each refuses to leave out.
15 min	Teach assurance and maturity: the audit test procedure TP-AI-014 on Nordvik Region's caseworker override control, the oversight-quality metric, and the two maturity models with their different scales.
30 min	Exercise: participants build a mapping row and its catalogue entry for one control and a design and operating test for it.
10 min	Debrief: which rows lacked an evidence age, and who independent of the control's owner could run the test.

Discussion

The series does not claim that holding a certificate under a standard shows that controls work. What should a board ask for instead of the certificate?
Why is the rule that an oversight-quality metric is never used to evaluate individuals described as the condition on which employee representatives agree to it?
The Architecture as Code model counts from Level 0 to Level 5 and the AI Governance model from 1 to 5, with different subjects. What goes wrong if a report mixes the two?

Exercise · 30 minutes

One control from article to evidence

Choose one control that more than one instrument or standard demands in your organisation, for example logging or human oversight, or take the caseworker override control of Nordvik Region. Write a mapping row in the style of the regulation-to-control mapping record: the instruments and articles it serves as your organisation reads them, the owner of the mapping and their independence from the function mapped, the evidence, its age and its age limit, and the result. Then write the control catalogue entry: title, owner, obligations, enforcement, evidence source, freshness in days and test. Finish with one design test and one operating-effectiveness test in the manner of the audit test procedure.

Deliverable: A mapping row, a catalogue entry and a two-part test procedure for one control, with evidence age and independent owner stated.

Self-test

What is the stated limit of the Control Mapping Matrix of Architecture as Code?
1. It covers only the GDPR and cannot hold other frameworks
2. It requires a policy engine before a single row can be written
3. It holds clause references for each control, and not tests
4. It can be maintained only by an external auditor
In the maturity model of AI Governance, how is one overall level derived where one is needed?
1. It is the average of the eight dimensions
2. It is the lowest level found among the eight dimensions
3. It is the level of the governance dimension
4. It is the highest level reached in four dimensions
What makes the regulation-to-control mapping record of AI Operations a second-line artefact?
1. It is generated automatically by the pipeline that deploys the service
2. It is signed by the provider of the managed service it describes
3. It is published to the supervisor every six months without review
4. Its owner is independent of operations

Chapter 9 · 90 minutes

Supplier, Contract and Sovereignty Tools

The lesson follows the supplier lifecycle from tender to exit. Participants use the vendor assessment record and the contract clause checklist of AI Governance, the requirement annexes of The Transformed Security Architect, the operational annexes of AI Blue and AI Operations, the model-origin assessment and sovereignty tools, and the exit and substitution plan with its exit test. The thread is that each link is useful in proportion to the evidence attached to it.

Learning objectives

Assess a model provider by recording what was received, not what was claimed.
Draft tender requirements that each state a verification the buyer can run and a consequence on failure.
Distinguish the model-origin assessment, the sovereignty requirements profile and the sovereignty decision matrix by the decision each supports.
Design an exit plan with triggers, a second source and a dated exit test.

Key concepts

Vendor assessment record: An artefact of AI Governance, Chapter 7, that assesses a model provider against AI Act and contract criteria and records, per artefact, whether it was received. A missing artefact blocks the contract or becomes a recorded exception with an owner.
Procurement security requirements annex: A versioned tender annex, family SECREQ, in which every requirement has an identifier, a level (mandatory or weighted), a catalogue link, a verification with an owner and a consequence on failure.
Operations annex: An annex to a managed-service contract, family OPA, from AI Operations: change notice, incident transparency, observer rights, a provider AI declaration with sampling, a stop right, a test calendar and an exit with a transition period.
Model-origin assessment record: A record, family GEO, that scores a model or provider across five categories: legal access, continuity, behaviour, supply chain and regulatory. The overall rating is the highest category score, not the average.
Exit and substitution plan: A plan, family EXIT, that keeps a second source ready so that a sanction, ruling or supplier failure is an operational event and not a crisis. The exit test gives the plan evidence: a date, an elapsed time and a quality gate.

Teaching plan

15 min	Present Figure 9.1, the supplier lifecycle with exit test, and the five families. Open with the observation of AI Governance that buying AI is buying an obligation.
20 min	Read the tender annex for a supplier boundary (requirements S4.1 to S4.5) and the annex MS-2. Participants identify the test the buyer can run without the supplier's cooperation.
15 min	Teach sovereignty and exit: the assessment GEO-2026-017 of Hansa Mutual, the profile for tender NR-2026-031 of Nordvik Region, and the three definitions of the exit plan.
30 min	Exercise: groups write four testable requirements and an exit plan outline for one AI supplier.
10 min	Groups exchange requirements and try to find one that cannot be verified by the buyer; the room rewrites it.

Discussion

In the model-origin example, how a model is run mattered more than where its developer is established. What does that imply for a policy that bans suppliers by country?
AI Purple says a clause that lets the provider tell its staff which alerts are tests is not an injected test. Why does this clause most often fail in negotiation, and what is lost when it does?
Mode 0 is the case procurement most often misses because no purchase takes place. What change control would catch a supplier switching on an AI feature in an existing product?

Exercise · 30 minutes

Testable requirements and an exit plan for one supplier

Choose one supplier of an AI service to your organisation, or the supplier of Nordvik Region's benefits-triage system at renewal. Write four requirements in the form of the procurement security requirements annex: identifier, level (mandatory or weighted), the control it links to, the verification the buyer can run and its owner, and the consequence on failure. Make one requirement put the stop path outside the supplier. Then outline an exit and substitution plan: the triggers, the second source, what must be portable (prompts, evaluation suite, data), the drilled switch time you would aim for, and the date and form of the first exit test.

Deliverable: A four-row requirements annex with verification and consequence per row, and a one-page exit plan with triggers, second source and a scheduled exit test.

Self-test

How is the overall rating of a model-origin assessment record derived from its five category scores?
1. It is the highest category score, not the average
2. It is the average of the five scores, weighted by data class
3. It is the score of the legal access category alone
4. It is the sum of the scores divided by the deployment mode
In the sovereignty requirements profile, which requirements are made mandatory?
1. Every requirement the platform team would like the supplier to meet
2. Only those that carry a Gaia-X self-description as evidence
3. Only what the legal analysis makes non-negotiable; everything else is weighted
4. None, because mandatory requirements conflict with public procurement law
Which requirement does the first item of the worked procurement security requirements annex for Nordvik Region set?
1. The supplier must host the ranking function in a hyperscaler EU region and prove it with a Gaia-X self-description at every renewal
2. The supplier must deliver a bill of materials with every monthly release
3. The supplier must grant the buyer access to its training data on request, verified by a yearly joint exercise
4. Named stop holders can suspend the ranking function without the supplier's staff or software taking part

Module 4 · Part IV · Securing and Testing

Part IV covers the tools for securing and testing, all of them defensive. The participant names threats with shared vocabularies and records them as code, authorises and plans a test under signed rules of engagement, keeps detections, cases, hunts and intelligence as records, carries an incident from declaration to a proved recovery, and closes the loop with coverage records, regression cases and chaos experiments. The participant leaves able to ask of any claim: what was tested, when, with what result and by whom.

Lecture · 55 minutes

From named threat to verified control: securing and testing as one chain

The lecture carries the argument of Part IV. A threat is a belief until a test named in the threat model verifies it. A test is lawful and safe only inside signed rules of engagement enforced outside the executor, and every authorised offensive activity ends in a defensive improvement. A detection is a record, not a rule, and a passing test has a half-life. Recovery is a claim with six parts and an age. The purple loop joins these into one chain in which closure is a named person's signature and the checker can fail in ways the checked does not share.

10 min	Naming and recording threats STRIDE names the harm, MITRE ATT&CK and ATLAS name how an adversary produces it, D3FEND names what answers it. The threat model as code is regenerated on change, reviewed against seven soundness checks and enforced by a gate. The priority list connects the model to the test plan; a technique never selected for a scenario remains a belief.
10 min	Authorised testing under rules of engagement The rules-of-engagement manifest comes first: scope, window, permitted scenarios, AI participation, stop conditions and stop path. The expectation is written before the run, so a result is compared with a commitment. Libraries and simulation products show that a control reacted to a catalogued behaviour, not that anyone acted.
10 min	Detection and investigation as records A detection record adds to the rule an owner, tests, an alert budget and a review date. A case record separates what the AI did from what a person checked. The chain from intelligence record to hunt to detection to case shows an auditor how a detection came to exist.
12 min	Response and recovery: the age of a proof Incident records fix times and decision holders and keep the assistant's contributions marked as drafts. A clock sheet makes reporting deadlines owned before they are needed. A recoverability claim has six parts; a failed result is never overwritten, and a later pass supersedes it. A register whose denominator includes untested claims gives a board a smaller and more honest number.
13 min	The verification loop Five stages: P1 Target, P2 Emulate, P3 Observe, P4 Improve, P5 Verify. Coverage status is computed from the record's fields and never edited by hand. Five kinds of independence, model, data, authorship, vendor and time, are not interchangeable. Every tool that touches the estate names a rollback, a blast radius and a stop path outside the system it stops.

What the audience takes away

A threat, a detection and a recovery are each a claim that only a dated test turns into evidence.
Authorised testing is scoped by a signed manifest enforced outside the executor and ends in a defensive improvement.
Ask of any coverage claim what was tested, when, in which environment, with what result and by whom.

Chapter 10 · 75 minutes

Threat Modelling and Adversary Frameworks

The lesson covers the vocabularies and methods of threat modelling: STRIDE, MITRE ATT&CK, ATLAS and D3FEND, the OWASP lists of AI security risks, the methods that generate and review candidate threats, the threat model as code in its three schemas, and the priority list of AI Purple. Participants learn that a framework names, a model records, and only a test named in the model turns a threat from a belief into evidence.

Learning objectives

Explain what STRIDE, ATT&CK, ATLAS and D3FEND each contribute to a threat model and the limit of each.
Review a candidate threat against the seven soundness checks of AI Red Team.
Draft a threat entry with a classification, an owned control and a verifying test.
Rank techniques for a service on a priority list with stated reasons.

Key concepts

Working rule of the vocabularies: STRIDE names the harm at a boundary, ATT&CK and ATLAS name how an adversary produces it, and D3FEND names the class of countermeasure that answers it. ATT&CK itself does not say whether a technique is relevant to a service or whether a detection exists.
Threat model as code: A versioned file of kind ThreatModel that declares assets, trust boundaries, threats and linked controls, with reviewer decisions and a pointer to the test that verifies each threat. Three books define it with different schemas.
Soundness checks: Seven reviewer questions from AI Red Team, each with an automated part: grounding, classification, mitigation family, likelihood basis, impact basis, completeness and stability. Completeness flags a changed boundary that has no candidate threat.
Priority list: An artefact of AI Purple, family PRI: the 20 to 40 ATT&CK or ATLAS techniques that matter most for a service, each with tiers for impact, relevance and uncertainty from 1 to 3, an emulation route and the scenarios that test it.

Teaching plan

15 min	Present Figure 10.1, from framework to threat model to test, and the table of five vocabularies with the limit of each. Stress pinning catalogue versions.
15 min	Walk through the seven soundness checks using the Nordvik Region citizen-service assistant example, including the rejected candidate that stays in the file with its reason.
10 min	Present the priority list and the usage-mode table: who judges and with whose identity. Explain why Mode 5 agents are scored as if an adversary held their permissions.
25 min	Exercise: participants write three threat entries for one trust boundary and review a neighbour's entries against the soundness checks.
10 min	Debrief: which threats had no verifying test, and which would go on a priority list first.

Discussion

AI Purple calls the ATT&CK Navigator a sensible tool for planning and a poor tool for asserting. What does a coloured cell fail to tell a board?
Why does the series keep a rejected candidate threat in the model file with its reason instead of deleting it?
The OWASP lists describe observed weaknesses and so describe the past. How should a team use them without mistaking them for a complete threat model?

Exercise · 25 minutes

Three threats at one boundary, reviewed

Choose one trust boundary in a system you know, or the boundary between the retrieval sources and the citizen-service assistant of Nordvik Region. Write three threat entries at the level of design, with no attack content: the STRIDE category, the ATT&CK or ATLAS technique identifier you would look up and pin, the control with its owner, and the test that would verify it. Mark where a control acts outside the model. Then exchange entries with a neighbour and apply four of the soundness checks: grounding, classification, mitigation family and completeness. Record each check as passed or failed with one sentence of reason.

Deliverable: Three threat entries with category, technique reference, owned control and verifying test, plus a neighbour's four-check review of each.

Self-test

Which failure does the completeness check catch that a reviewer reading only the candidate threats would never see?
1. A threat whose likelihood cites no named assumption and no dated intelligence object
2. A control that does not resolve to deployed configuration
3. A boundary that changed in the pull request without any candidate threat
4. A score that changed since the last accepted version of the model without a stated reason
What limit does the series state for MITRE ATLAS when it is used in a threat model?
1. It is young and still changing, so identifiers are pinned and checked against a named data release
2. It names families of defence and not the organisation's own configuration
3. It is costly and therefore reserved for a few high-value goals
4. It names the harm at a boundary but not the route to it
How are Mode 5 Autonomous production agents treated when a threat model is written?
1. As trusted components whose actions need no scoring in the model at all
2. As well-meaning insiders that can be manipulated, with permissions scored as if an adversary held them
3. As external adversaries that are denied every permission by default in the design and are tested only in a separated range
4. As conversational tools whose only modelled risk is a person misled by an answer

Chapter 11 · 90 minutes

AI Red Teaming and Emulation Tools

The lesson covers the tools of authorised testing, described defensively throughout: the rules-of-engagement manifest, threat-led testing under TIBER-EU, the two forms of emulation plan, the continuous emulation pipeline, the AI red-team campaign plan, the finding record and the outcome taxonomy. Participants learn that every test is authorised, scoped, stoppable from outside the executor and ends in a defensive improvement.

Learning objectives

Draft the scope, stop conditions and stop path of a rules-of-engagement manifest for an exercise.
Explain why an expectation per step is written before an emulation run.
Classify the result of an emulated step with the outcome taxonomy of AI Purple.
Assess what open libraries and breach-and-attack simulation do and do not show about a defence.

Key concepts

Rules-of-engagement manifest: A signed, versioned manifest of scope, window, permitted tactics or scenarios, AI participation, stop conditions and stop path for an exercise. It works as a control only when a component outside the executor enforces it.
Emulation plan: A plan that turns signed rules into steps. In AI Red Team each step names an ATT&CK technique, an executor, an autonomy level and the detection or control it expects; in AI Purple the plan, family EMU, sequences three to eight scenarios.
Continuous emulation pipeline definition: An artefact of AI Purple that defines triggers, gates, variation, tagging and the abort path. In the template, safety class S1 inside scope runs at Level 3 Bounded, anything above S1 at Level 2 Supervised, and Level 4 never.
AI red-team campaign plan: A plan for a time-boxed campaign against a copy of an AI system, mapped to OWASP and ATLAS categories. Each objective states a property that must hold, and adversarial inputs are kept out of every record.
Outcome taxonomy: A seven-class classification from AI Purple of what happened to each emulated step. Each step ends in exactly one outcome, the last layer at which the defence did what the expectation said, such as prevented, detected or alerted but not triaged.

Teaching plan

15 min	Present Figure 11.1, an authorised test from scope to finding, and the six questions a manifest answers. Note that the stop path and the policy decision point sit outside the executing system.
20 min	Study the Hansa Mutual emulation plan example: the detection fired but the alert was queued at medium severity and triaged after 47 minutes. Classify the outcome together.
15 min	Teach continuous emulation and AI red teaming: schedule triggers, Atomic Red Team and Caldera, the limit of simulation products, and the Nordvik Region campaign finding of a withdrawn page still in the retrieval index.
30 min	Exercise: groups draft the governing parts of a rules-of-engagement manifest and three expectations for a tabletop scenario.
10 min	Debrief: who can stop each group's exercise, from where, and what defensive change each expected finding would lead to.

Discussion

The same identifier, RoE-NR-2027-001, names a shorter manifest in AI Red Team and a longer one in AI Purple. What should a team that adopts the template do about version and provenance?
The practical guide classifies every AI component that executes emulation steps as Mode 5 with its own permission manifest. What risk does that classification address?
A detection that fires but is triaged after 47 minutes: is that a detection problem or a process problem, and which record should carry the change?

Exercise · 30 minutes

Rules of engagement for a scoped exercise

As a design exercise only, draft the governing parts of a rules-of-engagement manifest for a purple exercise on a system of your own organisation, or on Nordvik Region's citizen-service assistant in a separated test range with synthetic data. State who approves and on what date, what is in scope and out of scope, which catalogued benign scenarios may run, whether any AI component takes part and at what level, the stop conditions, and who holds the stop path and from where. Then, for three steps described only by technique name, write the expectation per layer before the run and the defensive improvement you would make if the expectation is not met.

Deliverable: A one-page manifest outline with approvals, scope, AI participation, stop conditions and stop holders, and three written expectations with their defensive follow-up.

Self-test

In the continuous emulation pipeline template of AI Purple, at which level do scenarios above safety class S1 run?
1. Level 4 Autonomous, inside the signed scope
2. Level 3 Bounded, with tagging
3. Level 0 Advisory, as proposals only
4. Level 2 Supervised
What limit does the chapter state for open test libraries and breach-and-attack simulation alike?
1. They cannot be mapped to ATT&CK techniques, so their results cannot feed a coverage record or a regression case
2. They show that a control reacted to a catalogued behaviour, not that anyone acted on it
3. They may only be run by an external provider in the testing phase of a TIBER-EU test
4. They require an AI agent classified as Mode 5 to execute each step under a permission manifest
What did the first AI red-team campaign against Nordvik Region's citizen-service assistant find under objective OBJ-03?
1. A page withdrawn from the public website was still in the retrieval index and was cited as current
2. The assistant's gateway accepted calls from an unsigned model version that was absent from the model allow-list
3. The campaign had been run on production data without a signed rules-of-engagement manifest
4. The contracted tester's credentials outlived the exercise window by a month

Chapter 12 · 90 minutes

Detection, Investigation and Intelligence Tools

The lesson covers the records of a security operation: the detection record with Sigma logic and tests, the decay estimate, the grounded triage record, the case record and the five checks before an AI-assisted case is closed, the hunt record, the intelligence record and the vulnerability prioritisation sources. Participants learn that a detection is a record, not a rule, and how an AI-assisted investigation is made reproducible by a second person.

Learning objectives

Draft a detection record with data sources, technique mapping, tests, owner, origin and review date.
Explain how a case record separates the work of an AI system from what a person checked.
Write a hunt record that states what was not searched.
Trace the chain from intelligence record to hunt, detection and case by identifier.

Key concepts

Detection record: An artefact of AI Blue, family DET, that defines a detection with its logic, data sources, ATT&CK mapping, tests, owner and review date. Its origin block names the drafting system and its level, which makes an AI-drafted detection auditable.
Decay estimate: An artefact of AI Purple, family DCY, that estimates how fast detections decay between tests and gives each a state: current, at-risk or expired. The example gives priority detections a 90-day expiry and others 180 days.
Case record: A record, family CASE, of evidence, queries, reasoning and who or what reached each conclusion, so the case is reproducible. It separates the AI's work from the analyst's and keeps a list of corrections.
Hunt record: A record, family HNT, of a hunt's hypothesis, data, queries, result and coverage statement, with a conversion target: a detection identifier or a repeat date. Its most important field says what was not searched.
Grounded triage record: A JSON record from AI Red Team of an AI triage verdict tied to evidence. Its not_established field records the absence of evidence instead of leaving a fluent gap, and a field for the analyst's decision is left empty.

Teaching plan

15 min	Present Figure 12.1, the detection lifecycle, and the chapter's two questions. Read the record DET-HM-0455 and its origin block and silence limit per data source.
20 min	Teach investigation: the grounded triage record, the case record CASE-HM-1207 and the five checks before closure, including independent reproduction by a route that does not reuse the AI's work.
15 min	Teach hunts and intelligence: the hunt record, the intelligence record that keeps what a reviewer rejected, and why KEV, EUVD, EPSS and SSVC inform a decision and do not make one.
30 min	Exercise: participants write a detection record and its tests for one behaviour and peer review it with the method for an AI-drafted detection.
10 min	Debrief: which records omitted a review date or an origin, and how the decay estimate would treat each.

Discussion

The chapter concludes that a passing test has a half-life. What events in your estate should put a detection in the at-risk state before its clock runs out?
Why does the series set Level 1 Assisted as the default for AI in detection change and not use Level 4 Autonomous for detection logic?
An intelligence record keeps the attribution a reviewer rejected. What is the value of recording rejections as well as accepted items?

Exercise · 30 minutes

A detection record with tests and a review date

Choose one behaviour your organisation should detect, described by its ATT&CK technique name only, or take Nordvik Region's rule for a benefit payee account changed outside the caseworker role. Write a detection record in the form of AI Blue: identifier, title, status, owner, origin (who or what drafted it and at what level), data sources with a maximum silence for each, the technique mapping, an alert budget and a review date. State the logic in plain sentences. Add a test file in words: two events that must alert and two that must not. Exchange with a neighbour and check grounding and technique fit.

Deliverable: One detection record with origin, data-source silence limits, alert budget, review date and four described test cases, with a neighbour's review note.

Self-test

What does the hunt record's coverage statement add that a result alone does not?
1. The number of analysts who took part in the hunt
2. The cost of the queries in the data platform
3. A statement of what the hunt did not search
4. The supplier of the telemetry that was used
Which chain of identifiers does the chapter call the series' most useful lead for showing an auditor how a detection came to exist?
1. SVC to SLO to RST to CHG to DRF
2. SCN to EMU to FND to REG to COV
3. RISK to EXC to AIDR to MAP
4. INTEL to HNT to DET to CASE
What is the limit of the series' claim about KEV, EUVD, EPSS and SSVC?
1. None of them is a verdict; they inform a prioritisation decision and are used in combination
2. Each of them alone decides the patch order for a critical service
3. They apply only to AI systems and not to conventional software
4. They may be used only by financial entities in scope of DORA

Chapter 13 · 105 minutes

Response, Recovery and Resilience Tools

The lesson covers the records that carry an incident from declaration to review and the tools that prove recovery: the incident record and its AI variants, the clock sheet and incident clock, the recovery plan as code, the degradation-mode definition, the restore-test record with its five kinds of test, the post-incident reviews of AI Operations and AI Blue, and the resilience register. The thread is the chapter's conclusion that the age of a proof is part of the proof.

Learning objectives

Draft a clock sheet for one service that names each reporting regime, its owner and its limits as the organisation reads them.
State a recoverability claim with its six parts and derive its status from a restore-test record.
Select the kind of restore test that proves a given claim and its default clock.
Review an incident so that each action closes only on a signed re-test.

Key concepts

Incident record: The single account of an incident, family INC, from AI Operations: clocks, timeline, hypotheses by author, the assistant's contributions and the decisions with their holders. It must never contain a cause written by the assistant and stated as fact.
Clock sheet and incident clock: Complements. The clock sheet is written once per service before any incident and says which reporting clocks could open and who owns each; the incident clock, family CLK, is created per incident and opens the clocks from the moment of awareness.
Recoverability claim: A claim defined in AI Operations, Chapter 19, by six parts: subject, scenario, objective, result, date and expiry. A claim that lacks one is an assertion, and the test clock stops when an independent probe confirms an acceptable state.
Resilience register: A register of every recoverability claim, one row per claim, with six statuses derived from the latest test record and never edited. Its denominator includes untested and asserted claims.
Degradation-mode definition: An artefact of AI Red Team on the rule lose speed, never lose the defence: named modes from normal to manual with entry conditions. The monitor runs outside the agent's runtime, and the agent never chooses its own mode.

Teaching plan

15 min	Present Figure 13.1 and the incident records. Explain the four classes of AI incident in AI Operations and the rule that every time is written by a system or a named role.
20 min	Read the Hansa Mutual clock sheet for underwriting support and compare it with the incident clock of AI Blue. Participants explain the awareness rule and the date the instruments were read.
20 min	Teach recovery: the recovery plan whose restore point is defined relative to the earliest indicator of compromise, the five kinds of restore test with default clocks, and the failed record RST-HM-2027-004.
10 min	Teach review and register: the two post-incident reviews, the action closure rule, the six statuses and the quarterly review checklist.
30 min	Exercise: participants write recoverability claims and a register extract for one service and plan the next test.
10 min	Debrief: how many claims were verified, asserted or untested, and what the board would be told.

Discussion

The restore test clock stops when an independent probe confirms an acceptable state, never when the restore command returns. What changes in a team's reported recovery times when this rule is applied?
In the review example an action stays open because the re-test took 14 minutes against a 10-minute target. What pressure does a closure rule of this kind put on an organisation, and is it healthy?
The chapter says a register with every claim in the denominator gives a board a smaller and more honest number. How would you introduce that number to a board used to a list of passed tests?

Exercise · 30 minutes

Recoverability claims and a register extract

Take one Tier 1 service of your organisation, or the claims core system of Hansa Mutual. Write three recoverability claims for it, each with the six parts: subject, scenario, objective, result, date and expiry. For each claim choose the kind of restore test that would prove it (restore from backup into a segregated environment, failover, rebuild from code, degraded or manual mode, restore at scale) and note the default clock. Then build a register extract of three rows giving the latest record, its age and a status. Where no test exists, say so. Finish by naming the next test to schedule, the independent probe and the attester.

Deliverable: Three six-part claims, a three-row register extract with status and evidence age, and a scheduled next test with probe and attester named.

Self-test

Which default clock does AI Operations propose for a rebuild-from-code test of a Tier 1 service?
1. 180 days
2. 90 days
3. 365 days
4. 30 days
How is the restore point defined in the recovery plan as code of AI Red Team?
1. As the latest available backup at the time of the incident
2. As the backup taken at the last quarterly restore drill
3. As the point the supplier's contract guarantees
4. Relative to the earliest indicator of compromise
What happens to a failed restore-test result when the test is later repeated and passes?
1. The failed record is deleted, so that the resilience register shows a clean history to the management body
2. The failed record is edited to show the new measured time
3. The failed result is never overwritten; the later passing record supersedes it
4. The failed record is moved out of version control into the evidence store of the supplier

Chapter 14 · 90 minutes

The Verification Loop: Purple, Chaos and Coverage Tools

The lesson covers the tools that turn a written finding into a verified control: the purple loop with its five stages, the purple session plan and record, the coverage record and its status rule, the regression case, the five kinds of independence between tester and tested, and security chaos engineering with its experiment manifest and safety-boundary policy. Participants learn to replace a heat map with records that carry age.

Learning objectives

Describe the five stages of the purple loop and the record each produces.
Compute the status of a coverage record from its fields with an ordered rule.
Turn a closed finding into a regression case with variants, a negative control and a cadence.
Formulate a steady-state hypothesis for a security chaos experiment with rollback, blast radius and stop path.

Key concepts

Purple loop: A method of AI Purple with five stages, P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify, in which every finding ends as a verified control, detection and re-test with evidence, and closed findings return as regression cases.
Coverage record: An artefact, family COV, stating per technique and environment what was tested, when, how, with what outcome and when the evidence expires. It is derived, and its status is computed from its fields and never edited by hand.
Regression case: A closed finding kept as a repeatable test, family REG, with the base scenario, variants, a held-out variant, a negative control and a cadence. Re-testing only the exact scenario protects the path and not the technique.
Independence between tester and tested: A principle of AI Purple with five kinds of shared dependency that can hide failure: model, data, authorship, vendor and time. Each has its own control, and the kinds are not interchangeable.
Security chaos experiment manifest: A catalogue entry, family SCE, that injects a condition, not an attacker technique, to verify one control property, with rollback, blast radius and failure routing. On failure a finding goes to the purple backlog.

Teaching plan

15 min	Present Figure 14.1, the purple loop with the coverage record, independence statement and stop path outside it. Explain why the expectation is written, hashed and sealed before the run.
20 min	Read the coverage record COV-HM-0112 and the status rule in which the first match wins. Participants compute statuses for three invented field combinations.
15 min	Teach regression cases and independence, then security chaos engineering: the steady-state hypothesis, the experiment SCE-DE-014 on a silent log source, and the safety-boundary policy.
30 min	Exercise: participants convert a small heat map into coverage records and write one regression case and one chaos hypothesis.
10 min	Debrief: how many cells of each heat map survived as tested with unexpired evidence.

Discussion

Nordvik Region's coverage page reports nine techniques as five tested, two asserted by the provider and two not tested. Why is this page more useful than a fully green map?
A re-test run straight after the fix shares a dependency with the fix in time. Which of your current re-tests would fail the independence table, and on which kind?
The chapter says the chaos platform that injects the conditions is itself a tier-0 asset that is tested. What follows for who may operate it and how its credentials are issued?

Exercise · 30 minutes

From heat map to coverage records

Take five techniques your organisation currently shows as covered, or five priority techniques for the benefits-triage service of Nordvik Region. For each, write a coverage record in outline: technique and knowledge-base version, environment, what was tested, when, by which method, with what outcome, who other than the detection owner verified it, and when the evidence expires. Give each a status using an ordered rule in which the first match wins: untested, failed, implemented-unverified, asserted, expired, verified. For one tested technique write a regression case with three variants and a negative control. For one untested technique write a steady-state hypothesis for a benign chaos experiment, with rollback and stop holder.

Deliverable: Five coverage record outlines with computed status and expiry, one regression case and one chaos hypothesis with rollback and stop holder.

Self-test

What is the distinguishing feature of the purple session method of AI Purple?
1. The blue team is told the full plan a week before the run
2. The session is recorded on video so that individual performance can be reviewed
3. The red team grades the result alone and reports to the board
4. The expectation is written, hashed and sealed before the run
How does the coverage-status rule file treat a manual override of a computed status?
1. No override is allowed; an extension is a recorded decision with a named person, a reason and a new date
2. An override is allowed for the detection owner during a change freeze, provided the white-team lead is told within a working day
3. An override is allowed once per quarter for each priority technique
4. An override is allowed if the provider asserts in writing that the technique is covered
What does a security chaos experiment manifest inject, according to AI Red Team?
1. A working exploit against a production control
2. A condition, such as log forwarding from one host stopping
3. A new detection rule drafted by an AI system
4. A full adversary campaign planned by the red team

Module 5 · Part V · Operating

Part V covers the tools of operating: seeing a service and stating what users are promised, changing it and bringing it back within bounds, and keeping it big enough, affordable and measured in its use of energy. Most tools come from AI Operations, with roots in Architecture as Code, AI Governance and AI Platform and Security. The participant leaves able to write an objective with burn-rate alerts, bound a change and a runbook by data, and steer cost with files that the gateway and the report both read.

Lecture · 45 minutes

Operating by record: see, act within bounds, account for the cost

The lecture carries the argument of Part V. The chain from signal to person has a tool for every link, and the observer is itself a service that needs something outside it to watch it. An action on a service is bounded by a record that is data, evaluated by something other than the actor and stoppable from outside, and its ceiling moves with evidence. A decision about cost, capacity or energy is written in a file with an owner and a date before money is committed, and the system that enforces it reads the same file as the report.

12 min	From signal to person Seven links: instrumentation standard, collector, service record, objective record, burn-rate rules, correlation policy and metric catalogue. An objective is measured at a point outside the service as well as inside it, so the service cannot report itself healthy alone. A heartbeat to a receiver outside the platform tells a quiet observer from a failed one. A correlation policy gives an AI layer a mandate, a never-suppress list, sampling and stop conditions.
13 min	Acting within bounds A change is classified by the diff and the target; the declared class is a claim. Rings and bake times bound exposure, and the first ring is never skipped for any class. A runbook manifest bounds a remediation by preconditions, a dry run and an independent verification. No engine supplies independence: verifier, policy decision point and stop path are separate components.
8 min	Ceilings that move with evidence A class is suspended on two correlated incidents, and a runbook drops a level when it is past its review date. A Level 3 class falls a level when its autonomy budget is consumed. A tool that states its ceiling without a suspension rule has stated a hope.
12 min	Cost, capacity and energy as decisions in files The allocation map and the envelope attribute and limit consumption at the gateway. The unit of cost of an agent is the run, so a daily cap alone is not a control. A capacity record without a back-test and an uplift is a hope. An energy figure without a metered boundary cannot be compared; the right entry is that the claim is not yet available.

What the audience takes away

Every tool that watches needs something outside it that watches the watcher.
Bound every action by data, evaluate it outside the actor, and keep the stop path outside the platform.
Write cost, capacity and energy decisions in the file that both the enforcing system and the report read.

Chapter 15 · 90 minutes

Observability and Service Objective Tools

The lesson follows the path from telemetry to page. Participants meet OpenTelemetry and its conventions for generative AI, the telemetry collector configuration that redacts personal data, the service record and service level objective record of AI Operations, burn-rate alerting, the alert-correlation policy with its evaluation record and noise budget, and the metric definition catalogue. They learn that a claim that alerting works is a claim about a date and a result.

Learning objectives

Write a service level objective for a user journey with an error budget and a budget policy.
Calculate the failure ratio at which a multi-window burn-rate rule fires for a given objective.
Draft an alert-correlation policy with a never-suppress list, sampling and stop conditions.
Define a metric with the decision it informs, its population, its clock and its known misuse.

Key concepts

Service level objective record: A record, family SLO, of what users are promised and how it is measured, alerted on and evidenced, including burn-rate alerts, the budget policy and the evidence that the alerts work. It is reviewed when the service, gateway or collector changes.
Burn-rate alerting: Multi-window alerting on the speed at which the error budget is consumed. A burn rate of 1 exhausts the budget exactly over the window; a rule fires at the burn rate multiplied by the permitted failure ratio.
Watchdog alert and observer heartbeat: An alert that is always firing, so that its absence at a receiver outside the platform shows that the alerting pipeline is broken. AI Operations generalises it: every observer emits a heartbeat to an external receiver.
Alert-correlation policy: An artefact, family ACP, that sets per alert class what a correlation layer may group, suppress or page, what it may never suppress, the sampling by a person and the seeded-miss rates that freeze its promotion. Its mandate is a ceiling.
Metric definition catalogue: Entries, family MET, that define each metric with the decision it informs, its population, clock, source and subject, a minimum group size, misuse notes and gaming checks. A report function shows a metric without a mean.

Teaching plan

15 min	Present Figure 15.1, from telemetry to page. Cover OpenTelemetry, the collector that separates a sampled operational pipeline from an unsampled evidence pipeline, and the service record as anchor.
20 min	Work through the objective record template and Table 15.1 of burn-rate parameters. Participants compute the one-hour page threshold for an objective of 99.9 per cent.
15 min	Teach correlation and measurement: the policy ACP-HM-2028-01, the evaluation against a golden set held outside the correlator, the noise budget and a metric catalogue entry.
30 min	Exercise: participants write an objective record and a correlation policy outline for one service.
10 min	Debrief: where is each objective measured from outside, and what evidence shows that its alerts work.

Discussion

The chapter says a metric that an agent reports about itself is a claim and not a measurement. Which figures on your operations dashboard are of that kind?
The noise budget judges an alerting estate by what it costs the rota, not by what it detects. What would change in your alert reviews if that were the measure?
The abbreviation DORA names both a regulation and a research programme, and the volumes differ on the number of key metrics. How should a report to a board handle such ambiguity?

Exercise · 30 minutes

An objective record and a correlation policy for one service

Choose one service with a critical user journey in your organisation, or the citizen e-service portal of Nordvik Region. Write a service level objective record in outline: the indicator for the journey, the objective and window, the measurement point inside and the probe outside the service, the page and ticket burn-rate rules with long and short windows from Table 15.1, the budget policy, the owner and the review date, and the evidence that the alerts fire. Then outline an alert-correlation policy for the same service: three alert classes by consequence, what may be grouped or suppressed and at what level, the never-suppress set, the weekly human sample and two stop conditions.

Deliverable: An objective record outline with burn-rate rules and alert evidence, and a one-page correlation policy with never-suppress set, sampling and stop conditions.

Self-test

In the starting parameters of Table 15.1, which burn rate pages on a one-hour long window with a five-minute short window?
1. 1, consuming 10 per cent of the budget
2. 6, consuming 5 per cent of the budget
3. 14.4, consuming 2 per cent of the budget
4. 28.8, consuming 1 per cent of the budget
What ceiling does the worked alert-correlation policy set for suppressing a customer-facing objective alert?
1. It may be suppressed at Level 3 Bounded during a freeze
2. It is never suppressed above Level 1 Assisted
3. It may be suppressed at Level 4 Autonomous if recall is 1.00
4. It may be suppressed by the vendor's default configuration
Why does the telemetry collector configuration of AI Platform and Security keep an unsampled evidence pipeline beside the sampled operational one?
1. The stores have different purposes: the operational one is cheap to query and ages out, the evidence one is a full record
2. Sampled traces cannot be exported through a collector to any OpenTelemetry back end, so a second pipeline carries them
3. The evidence pipeline is where personal data is kept in full, before redaction, for later analysis of incidents
4. The operational pipeline is reserved for the supplier's own monitoring

Chapter 16 · 90 minutes

Change, Restore and Runbook Tools

The lesson covers the tools that bound an action on a service: the change class and change record, the progressive-delivery policy, GitOps engines and the sync policy read as a mandate, the runbook manifest with remediation tiers and the autonomy budget, and the freeze calendar. Participants learn the shared structure: the action is bounded by a record that is data, evaluated by something other than the actor and stoppable from outside.

Learning objectives

Define a standard change class with eligibility, verification, rollback and a suspension rule.
Design a progressive-delivery policy with rings, bake times, stop conditions and an independent verifier.
Write a runbook manifest that a policy decision point can enforce and a person can audit.
Assign a ceiling per degree of delegation to change and restore actions and state what is required outside the agent.

Key concepts

Change class and change record: A class states what may be released without a person in the path; the record, family CHG, carries author, reconciler, computed class, plan summary, independent approvers, tested rollback and verification. The class is computed from the diff and the target.
Progressive-delivery policy: An artefact, family ROL, defining rings, bake times, stop conditions and the stop path for one service, and naming a verifier independent of the author, the pipeline and the telemetry path. The first ring is never skipped.
Runbook manifest: An artefact, family RBK, that makes a runbook executable under a bound: preconditions, dry run, action, independent verification, failure path, who may stop it and when it was last exercised. It is signed on release.
Remediation tiers and autonomy budget: Four tiers: notify at Level 0 Advisory, propose at Level 1 Assisted, execute with approval at Level 2 Supervised and execute within a mandate at Level 3 Bounded. Each Level 3 class carries a tolerance for faulty actions per 28-day window.
Sync policy as a mandate: The reading in AI Operations of a GitOps engine's settings (automated sync, self-heal, prune, sync windows, suspend) as ceilings on what the reconciler may do alone. A reconciler that applies is an actor in the change system.

Teaching plan

15 min	Present Figure 16.1, from change to restore with the stop path outside the platform. Read the change record CHG-NR-2028-0007, authored by an agent, and the class HM-STD-002.
20 min	Teach progressive delivery and GitOps: the policy ROL-HM-001, the four OpenGitOps principles and Table 16.1 of sync settings with their ceilings.
15 min	Read the runbook manifest RBK-HM-0007, a Level 3 Bounded restart of one stateless web instance. Present remediation tiers, the autonomy budget, freezes and Table 16.2.
30 min	Exercise: participants define a standard change class and a runbook manifest for one recurring action.
10 min	Debrief on what can be undone and who can stop each action, outside the system being stopped.

Discussion

The Argo CD manifest of Architecture as Code enables prune on a production namespace, which the later ceilings of AI Operations would not permit. How should a team treat an older template when a later volume tightens the rule?
A progressive-delivery controller can abort a rollout but should not be the only judge of it. Who or what is the independent verifier in your own delivery path?
The runbook example allows restarting one of five instances but not the last healthy one. What does it mean that preconditions protect capacity and not only correctness?

Exercise · 30 minutes

A standard change class and a bounded runbook

Pick one kind of change your organisation has made by hand many times without incident, for example a certificate renewal, or use Hansa Mutual's class for services outside critical functions. Write the change class as data: eligible service tiers, limits on resources and deletes, the verification by a probe the pipeline does not run, the tested rollback, the level for drafting and for release, and the rule that suspends the class. Then write a runbook manifest for one recurring condition: trigger, preconditions that protect capacity, dry run, action, independent verification, failure path, stop holders outside the platform, level, and the date it was last exercised.

Deliverable: A change class definition with suspension rule and a runbook manifest with preconditions, independent verification, stop holders and last-exercised date.

Self-test

When, according to the practical guide of AI Operations, is a kind of change eligible to become a standard change class?
1. When an agent has drafted it once and a named reviewer, independent of the requester, has approved the draft in a pull request
2. When the change advisory board has not met to discuss that kind of change for twelve months
3. When the supplier's documentation describes the change as safe to automate without any approval
4. When it was made by hand at least 20 times in twelve months with no change-correlated Tier 1 or Tier 2 incident
How does the change gate treat a change whose declared class is lower than the class computed from its diff?
1. It denies the change, because the declared class is a claim and the computed class is the fact
2. It accepts the declared class, because the author knows the change best
3. It releases the change to the first ring only and skips verification
4. It asks the agent that authored the change to reclassify it
Which ceiling does Table 16.1 set for prune in a GitOps sync policy?
1. Level 3 Bounded for any class that passed the gate
2. Any named holder, with no approval needed
3. A named person for stateful kinds, and never Level 4 where it would delete data
4. Level 4 Autonomous outside a freeze window

Chapter 17 · 75 minutes

Capacity, Cost and Energy Tools

The lesson covers the records that steer the cost, capacity and energy of AI services: the allocation map and team consumption envelope of AI Governance, the capacity record and cost-and-latency budget of AI Operations, the capacity plans and cost-aware routing policy of AI Platform and Security, and the Software Carbon Intensity calculation. Participants learn that a decision is written in a file with an owner and a date before money or capacity is committed.

Learning objectives

Draft a team consumption envelope with soft and hard thresholds, per-task ceilings and gateway behaviour at the cap.
Review a capacity record for its back-test, uplift, guardrails and approving person.
Design a cost-and-latency budget for an AI service with a fallback ladder and a stop outside the agent.
State an energy claim with its boundary, method and limitations, or record that the claim is not yet available.

Key concepts

Allocation map: An artefact of AI Governance, Chapter 16A, that maps API keys, agent identities and reserved capacity to use cases and cost centres. The gateway and the showback report read the same map, and the gateway refuses any unmapped identity.
Team consumption envelope: A per-team envelope for agentic work tools in Mode 3, where consumption follows the task and not the person. At the hard cap, premium models are disabled for the rest of the period while self-hosted models stay available.
Capacity record: A record, family CAP, that turns a forecast into a proposal: back-test, uplift for under-coverage, the guardrails capacity may not be cut below, and the approving person. A forecast is a distribution, not a value.
Cost-and-latency budget: An artefact of AI Operations, also family CAP, holding capacity, unit cost, objectives, a fallback ladder and a stop for an AI service, with per-run, daily and monthly cost limits where the service is an agent.
Software Carbon Intensity calculation: A method computing emissions per functional unit: energy times carbon intensity, plus allocated embodied emissions. The specification of the Green Software Foundation is adopted as ISO/IEC 21031:2024; the record states boundary, method and limitations.

Teaching plan

15 min	Present Figure 17.1, the cost steering loop. Read the Hansa Mutual allocation map and the envelope of EUR 5,600 a month for 14 seats with its thresholds and per-task ceiling.
15 min	Teach capacity: the record CAP-HM-2028-014 and what it must never contain, the GPU capacity plan with its utilisation-floor alert, and the routing policy that evaluates data classification first.
10 min	Teach token economics and energy: the cost-and-latency budget CAP-NR-AI-001 and the Nordvik Region Software Carbon Intensity record, read for what it refuses to claim.
25 min	Exercise: participants write an envelope and a cost-and-latency budget for one AI service or team.
10 min	Debrief: where does each stop sit, and which energy claims had no metered boundary.

Discussion

The chapter concludes that the unit of cost of an agent is the run, so a daily cap alone is not a control. What can go wrong within one run that a daily cap would not catch?
The capacity record must never take its cost estimate from the agent instead of the provider usage export. Why does the source of the figure matter?
The right entry when no metered energy figure exists is that the claim is not yet available, with the party and the date. How would your sustainability reporting change under that rule?

Exercise · 25 minutes

An envelope and a budget for one AI service

Choose one team that uses agentic work tools or one AI service in your organisation, or take the citizen-service assistant of Nordvik Region. First write a team consumption envelope: cost centre, seats, monthly envelope, soft and hard thresholds, a per-task ceiling, a retry limit and what the gateway does at the hard cap. Then write a cost-and-latency budget for the service: capacity, unit cost per outcome as percentiles and not a mean, the latency objective, per-run, daily and monthly limits, the fallback ladder down to a staffed manual rung, the named holder of the stop outside the agent, and the review date. State the energy claim only if it is metered; otherwise record who will meter it and by when.

Deliverable: A consumption envelope and a cost-and-latency budget with fallback ladder, stop holder, review date and an honest energy line.

Self-test

What does the cost-aware model routing policy of AI Platform and Security evaluate first?
1. The remaining monthly budget of the business area, so that a request is refused before any model is called
2. Data classification, so that a confidential or personal request never leaves EU-hosted capacity
3. The task type, so that simple tasks go to the smallest model
4. The energy per million tokens of each model tier, so that the route with the lowest footprint is always taken
What does the utilisation-floor alert of 0.45 in the GPU capacity plan do?
1. It triggers on-demand bursting when the interactive queue grows
2. It disables premium models for the rest of the billing period
3. It reserves standby capacity for a failover re-test
4. It turns accelerator hoarding into a visible finding
Which of these may a capacity record of AI Operations never contain?
1. A forecast without a back-test
2. A decision by the service owner
3. A review date and expiry conditions
4. An uplift for under-coverage

Module 6 · Part VI · Agents and Autonomy

Part VI covers the tools that govern agents. The participant writes down what an agent may do in a mandate manifest and a delegation profile, attaches an autonomy budget, specifies an observer the agent cannot write, proves by drill that the stop path works, and secures the agent itself with an identity of its own, short-lived credentials, a permission manifest and a containment profile. The participant leaves able to assemble the chain from scale to register and to find the broken link.

Lecture · 50 minutes

A label without a control: mandates, observers and containment for agents

The lecture carries the argument of Part VI. Deciding what an agent may do is a chain: scale, decision record, delegation profile, mandate, enforcement point, observer, budget and register. A break at any link, such as a Level 3 entry that names no enforcement or a budget counted by the agent itself, leaves a label without a control. The observer is a design and not a dashboard, a stop path is a timed property, and a level is earned and expires. The agent itself is a principal with one identity, and its containment must hold whether or not its manifest is obeyed.

12 min	Two answers to one question: mandate and delegation profile The mandate belongs to the agent; the delegation profile belongs to the system, team or service. The books use the prefixes MND and DLG with different schemas, so adopt the numbers of the book whose file you copy. An unlisted action is undelegated, the lowest ceiling governs, and Level 3 Bounded needs a codified playbook and a decision point outside the agent. A rise is a recorded decision by a named authority; a fall is immediate.
8 min	The autonomy budget and the register A ceiling says what the agent may do; a budget says how much of that allowance it may keep. The observer counts faulty actions, not the agent; review at 70 per cent, demotion by one level at 100 per cent. The register and the reversibility test show whether a delegation can be withdrawn.
12 min	Observers, seeds and stop paths Three tests: verification independent of action, an observer not dependent on the observed system, a stop path that works when the platform does not. A check that has never failed has not been shown to work, so seeded faults, gaps and errors give a measured catch rate. A stop that works by telling the agent to stop is a request, not a control. The record of a failed drill is worth more than a policy that has never been exercised.
10 min	The agent as a principal One identity per agent, issued by a broker outside its runtime, short-lived and bound to a task. The permission manifest is the agent's declared intent; the containment profile is the platform's commitment. A read-only switch in a tool server is a convenience; the hard limit is the permission of the identity behind it.
8 min	Why the operator's AI is Tier 0 Credentials, runbooks, telemetry and the stop path meet in the operator's AI. Its controls are designed for reach and not intent. Level 4 Autonomous is never used for an irreversible action on production data, outside an authorised window, to disable observation or the stop path, or to decide about a named person's access to work.

What the audience takes away

Mandate per agent, profile per service: an unlisted action is undelegated and the lowest ceiling governs.
An observer the agent cannot write and a stop path outside the platform are tested, timed and dated.
Containment must hold whether or not the manifest is obeyed, because it is designed for reach and not intent.

Chapter 18 · 105 minutes

Mandate, Delegation and Autonomy Tools

The lesson covers the tools that decide in writing what an AI agent may do: the usage-mode and autonomy-level scales of AI Red Team, the eleven action classes of AI Operations, the mandate manifests of five volumes, the delegation profiles and registers, the reversibility test, the autonomy budget and the promotion and demotion rules. Participants learn to tell a mandate from a delegation profile and to find a label that has no control behind it.

Learning objectives

Distinguish a mandate manifest from a delegation profile by what each bounds and who reads it.
Set a ceiling per action class from reversibility, blast radius, evidence and window.
Draft a delegation profile for one agent on one service with an autonomy budget and stop holders.
Explain the evidence needed to raise a level and the events that lower it at once.

Key concepts

Mandate manifest: A file, family MND, that bounds one agent: scope, action classes and levels, approvals, credentials, budgets, prohibitions and stop path, with a named owner. It is read by the systems that enforce it, such as the identity provider and the policy decision point.
Delegation profile: A file, family DLG, that records the degree of delegation for a system, team or service per function or action class, so that a supervisor, an auditor or a works council can read in one file what has been delegated.
Delegation ceiling: The ceiling for an action class on a service is the lowest of four written answers: reversibility, blast radius, evidence and window. A model's confidence score does not lift a ceiling, because it does not change what a wrong action costs.
Autonomy budget: A method of AI Operations: a tolerance for faulty actions per window and Level 3 class, counted by the observer, with review at 70 per cent and demotion by one level at 100 per cent. The default window is 28 days.
Reversibility test: A test, introduced in AI Threat, Chapter 26, of working without the AI for a delegated function, recorded with the delegation register entry. It is run at least yearly and after any step that removes human review.

Teaching plan

20 min	Present Figure 18.1 and Table 18.1, the same prefixes in six books. Establish the three readings: mandate per agent, profile per system, and adopt the numbers of the book you copy.
20 min	Teach scales and ceilings: the five levels, the eleven action classes, the four answers that set a ceiling and the four cases where Level 4 is never used.
20 min	Read the worked profile DLG-HM-OPS-001 row by row, with its budget, then the rules for promotion and demotion: shadow period, held-out evaluation, seeded fault and drilled stop.
35 min	Exercise: groups write a delegation profile and the key fields of a mandate for one agent on one service.
10 min	Groups swap profiles and look for a Level 3 entry that names no runbook, no enforcement point or no observer.

Discussion

AI Blue says confidence is the input that does least for a ceiling. Why is a high model score so often used to argue for more autonomy, and how would you answer the argument?
Unused tolerance in an autonomy budget is not banked, and the book warns that a budget can become a target to be gamed. What gaming would you expect, and who is placed to see it?
A mandate nobody reviews decays to Level 0 when its evidence expires. What does this rule demand of the people who own agents in your organisation?

Exercise · 35 minutes

A delegation profile for one agent on one service

Choose one agent your organisation runs or plans, or the IT-operations agent of Hansa Mutual on its claims core system. Write a delegation profile in the form of AI Operations. List at least six action classes from the eleven (for example read, notify, restart, reconfigure, roll back, delete) and set a ceiling for each as the lowest of four answers: reversibility, blast radius, evidence and window. For each Level 3 class name the runbook, the enforcement point outside the agent and the probe that verifies the effect. Add the autonomy budget (window and tolerance per class), the review interval, the authority that may raise a ceiling and the stop holders. State that anything unlisted is undelegated.

Deliverable: A delegation profile with six or more action classes, reasoned ceilings, runbook and probe per Level 3 class, autonomy budget, level authority and stop holders.

Self-test

According to the chapter's readings of the books, what is the difference between a mandate and a delegation profile?
1. The mandate belongs to the agent; the delegation profile belongs to the system, team or service
2. The mandate is written by the supplier; the delegation profile is written by the works council
3. The mandate covers people; the delegation profile covers only infrastructure
4. The mandate is a law; the delegation profile is a voluntary code of practice
Who counts the faulty actions against an autonomy budget?
1. The agent, in its own run log
2. The supplier of the model the agent uses
3. The independent observer, not the agent
4. The author of the runbook that was executed
In the worked profile DLG-HM-OPS-001, what is the ceiling for the action class fail over?
1. Level 3 Bounded, within quota and under a cap of EUR 6,000 per month
2. Level 4 Autonomous, with personal data redacted for the agent
3. Level 2 Supervised, as a candidate for Level 3 after two quarters of evidence
4. Level 1 Assisted, with the incident commander as approver

Chapter 19 · 90 minutes

Observer, Stop Path and Evaluation Tools

The lesson covers the tools that show, by evidence an agent cannot write, that what the agent did worked, that it can be stopped and that its level is still earned: the observer manifest and independence statement, the seeded-fault and seeded-gap records, the stop-path test record and stop drills, and the promotion and demotion policy. Participants learn that an observer is a design, not a dashboard, and that an untested stop path is a claim.

Learning objectives

Specify an observer that meets the three tests of the observer principle for one service function.
Compare the five kinds of independence in AI Purple with the six in AI Operations and apply them as a union.
Design a seeded test with an author, a scope, a way to stop and a catch-rate rule.
Plan a timed stop drill and state what its record must show.

Key concepts

Observer principle: Three tests from AI Operations: verification is independent of the action, the observer does not depend on the observed system, and the stop path works when the platform does not. An agent that reads the health endpoint its own restart resets has a mirror, not an observer.
Observer manifest: An artefact, family OBS, that declares the probes, heartbeat and stop path verifying an agent's actions, and the observer's independence in model, data, authorship, credential, failure domain and time. Its statement of independence expires.
Seeded-fault record: A record, family SDF, of a deliberately introduced, authorised and scoped fault that tests whether the agent's verification and the independent probe notice it. Three kinds of seed: silent failure, observer loss and stop path.
Stop-path test record: A record of AI Threat, family SPT, of a test that an agent can be stopped by a route it cannot block. A failing result blocks any widening of autonomy until a re-test passes.
Promotion and demotion policy: An artefact of AI Operations stating the evidence needed to raise an agent's level and the events that lower it at once. Promotion needs shadow, offline, seeded and stop evidence; demotion is automatic.

Teaching plan

15 min	Present Figure 19.1, the observer principle as a set of tools, and the two sets of kinds of independence. Explain why the series uses them as a union.
20 min	Read the observer manifest OBS-HM-0001 and the seeded-fault record SDF-HM-2028-002, in which the agent's own verification reported success and an independent probe said otherwise 61 seconds later.
15 min	Teach stop paths: the agent stop policy, the failed stop-path test at Hansa Mutual where a scheduler was not on the stop-path map, and the timed drill records.
30 min	Exercise: participants specify an observer and plan one seeded fault and one stop drill as a tabletop for a service.
10 min	Debrief: which probes could the agent influence, and who outside the platform holds each stop.

Discussion

The source says the value of the stop-path test record at Hansa Mutual is that it fails. Why is a failed drill worth more than a policy that has never been exercised?
A record that says only that a different model was used proves one kind of independence. Which of the other kinds is hardest to achieve in your organisation, and why?
Seeded errors are also planted in the queues of human reviewers. What agreements with staff and their representatives must exist before such a programme starts?

Exercise · 30 minutes

An observer, a seed and a stop drill on paper

Choose one service function on which an agent acts or will act, in your organisation or at Hansa Mutual. First specify the observer: one probe that measures an outcome and not an endpoint the agent can influence, the failure domain it runs from, a heartbeat and its receiver outside the platform, and the date on which the statement of independence expires. Check it against the six kinds of independence and mark the weakest. Second, plan one silent-failure seed for a pre-production mirror: authorising role, author outside the agent's team, hypothesis, how to stop and how to undo. Third, plan a timed stop drill: who invokes it, by which route outside the agent, the time budget and what the record must show.

Deliverable: A one-page observer specification with independence check, a seeded-fault plan with authorisation and undo, and a stop drill plan with route, holder and time budget.

Self-test

Which two kinds of independence does AI Operations name that the list of AI Purple does not contain?
1. Model and data
2. Credential and failure domain
3. Authorship and time
4. Vendor and budget
What does the field stop_message_sent_to_agent: false in the stop-path test record signify?
1. That the agent was not informed of the result of the test after the production drill had been completed and reviewed by the stop holders
2. That the test was run without the knowledge of the stop holders named in the stop policy
3. That the stop was carried out by the agent on its own initiative when it detected an anomaly
4. That the stop used a route outside the agent; a stop that asks the agent to stop is a request, not a control
What does a catch rate from seeded tests carry with it, according to the chapter?
1. A stop rule that lowers or freezes delegation when the rate falls below a floor
2. A bonus rule that rewards the reviewers who found the most seeds
3. A publication rule that sends each result to the supervisor
4. A pricing rule that reduces the supplier's fee per missed seed

Chapter 20 · 90 minutes

Defending the Agent: Identity, Credential and Protocol Tools

The lesson covers the tools that secure the agent itself, described defensively: the agent identity record and credential profile, the protocols and identity standards agents rely on, the tool registry entry, the agent permission manifest, the containment profile and the Tier-0 checklist for the operator's AI. Participants learn that a manifest states intent, a containment profile states the platform's commitment, and an instruction file is never a source of permission.

Learning objectives

Register an agent identity with owner, scope, lifetime and a tested revocation.
Distinguish the permission manifest from the containment profile by purpose and by who enforces each.
Classify the tools of a tool server by effect and attach approval requirements to irreversible ones.
Assess an operator's AI against the idea of Tier 0 and identify the control that carries the weight in each usage mode.

Key concepts

Agent identity record: A record from The Transformed Security Architect, Chapter 8, registering an agent identity with owner, operator, authority, scope, lifetime and revocation. The broker issues from it, and an expiry disables the identity if a review is missed.
Agent permission manifest: A deny-by-default declaration, from AI Platform and Security, of the tools, data, identity, budgets and approval gates an agent may use. It is kept in version control and read by the policy decision point and the pipeline.
Containment profile: A per-agent ceiling, family CP, of identity, egress, data, blast radius, stop holders and verification tests. The pipeline rejects a manifest grant the ceiling does not cover, and the profile must hold whether or not the manifest is obeyed.
Tool registry entry: A registration of a tool server with owner, scopes and trust, classifying each tool as read, reversible-write or irreversible. The agent pipeline refuses a manifest that names a server or tool absent from the registration.
Tier-0 checklist for the operator's AI: A checklist of AI Operations with controls for remediation agents, runbook libraries, observability pipelines and configuration maps. The operator's AI is Tier 0 because credentials, runbooks, telemetry and the stop path meet there.

Teaching plan

15 min	Present Figure 20.1, agent identity and containment: four files the agent cannot write. Read the identity record of Hansa Mutual's evidence-collection agent.
20 min	Teach protocols and standards: the Model Context Protocol, Agent2Agent, Agent Skills, SPIFFE and token exchange, the tool registry entry, and the rule about read-only switches.
15 min	Compare the permission manifest and the containment profile CP-HM-ITOPS-01, including its dependencies block. Read the AGENTS.md example and state its limit.
30 min	Exercise: participants write an identity record, a permission manifest outline and a containment ceiling for one agent.
10 min	Debrief: for each agent, would the containment hold if the manifest were ignored?

Discussion

The dependencies block of the containment profile lists what its controls share, so that two controls that fail together are not counted as two. Which of your agent controls share a dependency?
An instruction file for a coding agent carries instructions, not enforcement. What does Hansa Mutual pair it with, and what would you pair it with in your repositories?
The standards that agents rely on carry calls and identities, but none decides who answers for what the calls do. Which record of this chapter gives that answer?

Exercise · 30 minutes

Identity, manifest and containment for one agent

Choose one agent in your organisation, or a coding agent working in a Hansa Mutual repository. Write three short files as outlines. First, an identity record: the decision record that grants the level, the workload identity, the issuer outside the agent runtime, owner and operator, scopes with levels, maximum token lifetime, review date and how revocation is tested. Second, a deny-by-default permission manifest: the tool servers it may reach, each tool classed as read, reversible-write or irreversible, with an approval requirement on every irreversible tool, plus budgets. Third, a containment ceiling: egress default, data classes, blast radius, stop holders, and the verification test for each. Mark any control that relies on the agent obeying an instruction.

Deliverable: Three outlines for one agent: identity record, permission manifest with tool classes and approvals, and containment ceiling with verification tests.

Self-test

What rule does the series draw from the tool servers that offer a read-only setting?
1. A read-only setting is sufficient as the hard limit for a remediation agent
2. A read-only setting should be switched off so that the agent can verify its own actions
3. A read-only switch in a tool is a convenience; the hard limit is the permission of the identity behind the server
4. A read-only setting makes the tool registry entry unnecessary
How does the chapter divide the work between the permission manifest and the containment profile?
1. The manifest is written by the supplier of the agent runtime for each release, and the profile is issued by the supervisory authority for the sector
2. The manifest states the agent's declared intent; the profile is the platform's commitment and holds even if the manifest is not obeyed
3. The manifest covers the people who operate the agent, and the profile covers its budgets only
4. The manifest becomes optional once a containment profile has been classified as verified
Who sets the classification of a containment profile as verified, declared or failed?
1. The owner of the profile, at each quarterly review
2. The agent, from its own run log
3. The supplier of the agent runtime
4. The last test result, not the owner

Module 7 · Part VII · People, Organisation and Society

Part VII covers the tools that concern people, organisation and society. The participant fixes what a role may decide in a charter, records competence so that it can condition an agent's autonomy without ranking anyone, shows who decided about a person and how that person can contest it, and weighs contested claims about AI with an evidence ladder, a threat register and a debate in four steps. The participant leaves able to agree first what a record may not be used for.

Lecture · 50 minutes

Who decides, who can do it, who can contest it, and what to believe

The lecture carries the argument of Part VII. The tools about people work only under limits agreed with employee representatives: a record that cannot be used for ranking, pay or discipline can be shared widely enough to be useful. A role charter fixes decision rights, a competence record conditions autonomy, a Management Decision Record names the human decider and a contestation record gives the person a reviewer outside the line. The same discipline is applied to belief: a claim is graded and labelled, held in a register with an owner and triggers, and debated in four steps.

12 min	Roles and competence as architecture A role charter states decision rights with a time limit and names what is never delegated. A competence framework counts the lower of the unassisted and the AI-assisted level. Competence conditions read only levels and validity, and lower an agent's ceiling when too few evidenced holders remain. The first thing to agree with employee representatives is what the record may not be used for.
13 min	Decisions about people: before, after and in dispute Before: the delegation profile and the decision-rights file fix what a system may do per management function, M1 Direction to M5 Care. After: the Management Decision Record shows a named human decider, the basis and the route to contest. In dispute: a reviewer is never the decider, and a contest is never an input to evaluation. Level 4 Autonomous is never used for M3 Consequence, and an adverse consequence is never above Level 1 Assisted.
8 min	What no single decision shows A disparate-impact test, agreed with the representatives, looks for group disadvantage on every release. The change-class annex keeps a works agreement true as the system changes. Care tools protect development and rest as constraints, not as intentions.
12 min	Weighing evidence about threats and futures The evidence ladder has five rungs: fiction, argument, laboratory demonstration, incident in the wild, pattern at scale. The rung and the label observable, expected or speculation are kept in separate fields. The threat register holds no probability; it holds rung, label, exposure and influence, with triggers in both directions. The constructive debate ends in cruxes with owners and no-regret actions.
5 min	The common thread Figures about people are reported at team level unless the person asks for their own. Reversibility is the posture for what cannot be evidenced, and the stop path outside the system is the common no-regret action.

What the audience takes away

Agree prohibited uses first: a record that cannot rank or discipline can be shared widely enough to be useful.
Every decision about a person has a named human decider, a route to contest and a reviewer outside the line.
Grade the evidence, label the outlook, name an owner and write the trigger that would change your mind.

Chapter 21 · 90 minutes

Role, Competence and Career Tools

The lesson covers the tools that decide what a person in a role may decide and show what that person can do: the role charters of five volumes, the competence frameworks, the competence record, the competence conditions on autonomy of AI Blue, the on-call charter and learning paths. Participants learn the four design decisions of the competence record and why the lower of the unassisted and assisted level is the one that counts.

Learning objectives

Write a role charter with decision rights, time limits and a list of what is never delegated.
Explain the four design decisions that distinguish a competence record from a training log or a score.
Draft a competence condition that ties an agent's ceiling to evidenced human competence.
Assess a competence by practical demonstration with and without the assistant.

Key concepts

Role charter: A machine-readable statement, family ROLE, of what a role is for, what it decides, what it only recommends and what it never does. The Transformed Security Architect uses the verbs decide, veto, recommend and escalate, each with a time limit.
Competence framework: A statement of what the people of a function must be able to do, at which level and by what evidence. The framework of The Transformed Security Architect has six domains by four levels and the rule: lower of unassisted and AI-assisted demonstrated level.
Competence record: A personal record, family CMP, of assessed levels with references to evidence, a closed list of purposes, a list of prohibited uses agreed with employee representatives before the first assessment, named readers and a development plan.
Competence conditions on autonomy: A file of AI Blue that makes an agent's autonomy ceiling depend on evidenced human competence. Each condition names a manifest and a ceiling; the check reads only levels and validity and lowers the ceiling when too few evidenced holders remain.
On-call charter: An artefact of AI Operations, family ONC, that sets coverage, response targets, noise budget, rest after call-out, escalation, handover and attribution of agent actions, agreed with employee representatives before a rota or an AI operations tool changes.

Teaching plan

15 min	Present Figure 21.1, the chain from role charter to competence record to conditions. Note that a competence record is personal data and that representatives agree its uses first.
20 min	Read the charter ROLE-HM-OPS-001 of the operations conductor: the right to stop any operations agent with no approval, and what is never delegated. Compare with the line manager's charter.
15 min	Teach frameworks, records and conditions: the record CMP-HM-OPS-007, the competence conditions file, and the method of assessing with and without the assistant.
30 min	Exercise: participants write a role charter from recent decisions and one competence condition for an agent the role supervises.
10 min	Debrief: what each group listed as prohibited uses of the competence record, and why.

Discussion

A skill that exists only beside the assistant is a skill of the pair. What follows for how your organisation assesses people who now work with assistants every day?
The series treats certificates as a floor, not as evidence of judgement. What kinds of evidence would you accept for judgement in your own function?
The validity of a competence record is 24 months in one volume, twelve in another and 90 days in a third. How should an organisation choose, and what should drive the difference?

Exercise · 30 minutes

A role charter and a competence condition

Choose a role in your organisation that supervises or approves the work of an AI system, or the operations conductor of Hansa Mutual. From ten real decisions of the past year, class each by who actually decided and how long it took. Write a role charter: mandate, accountabilities, decision rights with a verb (decide, veto, recommend, escalate) and a time limit each, the agents overseen, the stop right, and what is never delegated. Then write one competence condition in the manner of AI Blue: the agent's manifest and ceiling it applies to, the competence and level required, the minimum number of evidenced holders, and what happens to the ceiling when the condition fails. List three prohibited uses of the underlying competence records.

Deliverable: A role charter with timed decision rights and a never-delegated list, one competence condition with its consequence, and three prohibited uses of the record.

Self-test

Which level does the series count when a competence has been demonstrated both unassisted and with an AI assistant?
1. The higher of the two, because the assistant is always available
2. The average of the two, rounded to the nearest level
3. The lower of the two
4. Only the assisted level, because that is how the work is done
What do competence conditions on autonomy read from the competence records?
1. Levels and validity only, never the content of the evidence
2. The full assessment notes of both assessors
3. The override rate of each named reviewer
4. The pay grade and tenure of each record holder
What does the chapter call the series' most reusable rule about competence records?
1. A record should be reviewed by the supplier of the assistant before it is stored
2. A record that cannot be used for ranking, pay or discipline can be shared widely enough to be useful
3. A record should hold the complete evidence so that auditors need no other source
4. A record is valid only when it maps every competence to an external framework

Chapter 22 · 90 minutes

Tools for Managing People with AI: Decision, Contestation and Care

The lesson covers the tools of AI Boss for governing AI that takes part in managing people: the Management Decision Record and its schema, the decision-rights file agreed with representatives, the contestation record and the appeal path, the disparate-impact test record, the co-determination tools and the care tools. Participants learn the few rules that survive across all of them, attributed to the instruments as architectural implication and not as legal advice.

Learning objectives

Complete a Management Decision Record that names a human decider, the basis and the route to contest.
Draft a decision-rights file with a ceiling per management function and named stop rights.
Design an appeal path in which the reviewer is never the original decider and corrections are propagated.
Plan a disparate-impact test with the representatives and state how its figures are reported.

Key concepts

Management Decision Record: A record, family MDR, of one management decision that AI made or shaped about a person: function, system, recommendation, named human decider, basis, explanation and contestation route. The decider field holds a role and a name and may not be system or agent.
Decision-rights file: A file, family DRF, that gives every class of management decision a decider, a ceiling and a stop right, agreed with the representatives and adopted as an AI Decision Record before the first delegation profile.
Contestation record: A record, family CNT, of a worker's challenge, the reviewer (never the original decider), the time limits, the outcome and the correction propagated to data or system. A decider may grant a contest in full on the first look; one that is not granted is referred to the reviewer.
Disparate-impact test record: A record of a test, agreed with the representatives, of whether an evaluating or allocating system disadvantages a group, run on every release and at least every six months, with a reporting floor of 20 people per cell.
Change-class annex: An annex to a works agreement, in the example KBV-IT-2024 at Hansa Mutual, that classes changes to a continuously changing AI system so that the agreement stays true as the system changes.

Teaching plan

15 min	Present Figure 22.1, decision, contestation and appeal, and the five management functions M1 Direction to M5 Care. State that legal references are architectural implication, not legal advice.
20 min	Read MDR-NR-0001 and the schema rules, then Nordvik Region's decision-rights file DRF-NR-01 with its ceilings and four stop rights.
15 min	Study the contest CNT-NR-0001 from the Strandvik unit: zero minutes planned between two visits, and a correction that ran through rule, data, risk assessment and a test. Then the test record DIT-HM-CTA-01.
30 min	Exercise: groups write a decision record and an appeal path for one system that shapes decisions about staff.
10 min	Debrief: who is the reviewer in each path, by when must the person have an answer, and where does the correction land.

Discussion

In the Strandvik case the shortened visit was recorded as caused by the route, not by the worker. Why does it matter where a record places the cause?
A contest is never an input to any M2 Evaluation of the worker. What would happen to an appeal path if that rule were absent?
Several tools of AI Boss, such as the appeal form and the weekly review protocol, exist as descriptions only. How would you adopt a tool for which the originating book gives no template text?

Exercise · 30 minutes

A decision record and an appeal path

Choose one system in your organisation that directs, evaluates or allocates work for staff, or the rostering system of Nordvik Region. Write a Management Decision Record for one decision it shaped: decision class, management function, system and its recommendation, the degree of delegation and the profile it comes from, the named human decider by role, the basis, the explanation given to the person and the route to contest. Then design the appeal path: the contestable decisions, who receives a contest, the reviewer outside the line, time limits for each step, the first-look rule, the kinds of correction (decision, data, rule, model, register) and how you would test the path with a test contest before go-live.

Deliverable: One completed Management Decision Record and a one-page appeal path with reviewer, time limits, correction types and a planned test contest.

Self-test

Which value may the decider field of a Management Decision Record never hold?
1. The role of a unit manager
2. The name of an HR director
3. A role with a personal name
4. The value system or agent
Which two rules about degrees of delegation does the MDR schema of AI Boss enforce?
1. No M1 Direction above Level 2 Supervised, and no M5 Care flag or protective block above Level 0 Advisory
2. No M3 Consequence at Level 4, and no adverse consequence above Level 1 Assisted
3. No M2 Evaluation of teams below Level 3 Bounded, and no M4 Development at Level 1 Assisted
4. No decision of any function below Level 2 Supervised
In the chapter's two contests, what follows when the original decider does not grant a contest on the first look?
1. It is referred to a reviewer outside the decider's line
2. The decider rejects it if the system's log supports the decision
3. The decider forwards it to the supplier for a ruling
4. It is added to the evaluation file of the worker

Chapter 23 · 90 minutes

Tools for Weighing Evidence: Threat Registers, Debate and Foresight

The lesson covers the tools for deciding what to believe when evidence is contested or lies in the future: the ten tropes as hypotheses and the evidence ladder of AI Threat, the graded evidence record, the AI threat register with its schema and triggers, the constructive debate in four steps with its crux map, and the labels observable, expected and speculation with the horizon register of AI Governance. Participants practise grading a claim and writing a register entry.

Learning objectives

Grade a claim about an AI threat on the five rungs of the evidence ladder and state what would move it.
Label an outlook as observable, expected or speculation and attach the matching posture.
Write a threat register entry with rung, label, exposure, influence, owner, controls and triggers in both directions.
Facilitate a debate in four steps that ends in a crux map and no-regret actions.

Key concepts

Evidence ladder: A five-rung grading of claims from AI Threat: fiction, argument, laboratory demonstration, incident in the wild, pattern at scale. A claim is graded at the highest rung its evidence reaches; the ladder does not measure risk.
Observable, expected, speculation: Three labels defined in AI Governance, Chapter 22. An observable trend is documented now and justifies commitment; an expected one justifies preparation; a speculative one is plausible but not supported by present evidence and justifies reversibility.
AI threat register: A version-controlled register, family THR, with one file per entry carrying scale, trope, rung, label, exposure, influence, owner, controls and triggers. It deliberately holds no probability, and review is triggered by change in both directions.
Constructive debate in four steps: A method: the case for concern, the case for calm, where the positions meet, and what can be done, before a verdict. Each case is stated at its strongest and with the same charity.
Crux map: The recorder's output of a structured discussion: each crux linked to a register entry, an owner and a trigger, with the value questions and the no-regret actions that hold whichever side is right.

Teaching plan

15 min	Present Figure 23.1 and the evidence ladder with its three rules. Separate capability from propensity, and the rung from the label.
20 min	Read the register entry THR-NR-02 on AI-accelerated exploitation and the four conditions for an entry. Contrast the two Hansa Mutual entries: one owned and tested daily, one that asks the board to confirm a rule.
15 min	Teach the debate in four steps and the crux map from Nordvik Region's audit committee workshop, then the three labels and the horizon register.
30 min	Exercise: groups grade one claim, write a register entry and run a short debate in four steps on it.
10 min	Debrief: where exactly did groups disagree, in the rung, the label, the exposure or the controls?

Discussion

A behaviour shown in fifty laboratories stays a laboratory demonstration. Why does repetition in the laboratory not move a claim up the ladder?
The register holds no probability because, for contested tail risks, a single figure records a choice between camps of experts. What does a board lose and gain without the figure?
A register that never changes a label is not being tested. How would you build the habit of confirming or changing at least one label per review?

Exercise · 30 minutes

Grade a claim, enter it, debate it

Take one claim about an AI threat that has reached your organisation through a briefing, a news report or a supplier, stated without any operational detail. In groups of four, appoint a grader, a challenger, an owner and a recorder. State the claim precisely, grade it on the evidence ladder at the highest rung its evidence reaches, and label the outlook. Write a register entry: scale, rung, label, exposure given current controls, influence, owner, two controls that do not depend on the system being assessed, one trigger that would raise and one that would lower the entry, and a review date. Then run a ten-minute debate in four steps and record one crux, one value question and one no-regret action.

Deliverable: A graded claim with the challenger's dissent noted, one threat register entry with triggers in both directions, and a crux map of one crux, one value question and one no-regret action.

Self-test

Why does the AI threat register keep the rung and the label in separate fields?
1. Because the rung is set by the supplier and the label by the regulator
2. Because the label is confidential and the rung is published
3. Because the same rung can support different outlooks
4. Because the schema allows only one free-text field per entry
Which posture does a trend labelled speculation justify?
1. Commitment to the trend
2. Preparation for the trend
3. Dismissal of the trend
4. Reversibility
Which of these is one of the four conditions for an entry to belong in the AI threat register?
1. A role can be named to own it
2. Its probability has been agreed by two experts
3. It has reached the rung pattern at scale
4. A supplier has confirmed it in a system card

Module 8 · Part VIII · Experience and Conclusions

Part VIII puts the toolbox together. The participant follows Nordvik Region and Hansa Mutual through an illustrative year of building a toolbox, learns why the order follows the gap and not the catalogue, and measures a toolbox by evidence age, adoption and retirements. The conclusions then name five patterns that recur across ten volumes, the gaps and inconsistencies the inventory found, and seven actions for Monday. The participant leaves with a toolbox plan and a local gap list.

Lecture · 40 minutes

One design, many dialects: building and judging a toolbox

The lecture carries the argument of Part VIII. A toolbox is not built from a list of tools: its order follows the obligation or risk that is already present and has no tool. A cautious buyer and a builder take up the same tools in a different order and leave different things out on purpose. Read side by side, the ten volumes show one design in many dialects: a shared anatomy, linked identifiers, evidence age, independence and earned autonomy. The gaps concern names, numbers, locations and dates, and a practitioner can act on them at once.

10 min	The order follows the gap Nordvik Region starts by making a procured high-risk system legible: inventory entry, tier, decision record with retirement criteria. Hansa Mutual starts by bounding agents that already act: mandate manifest and delegation profile. What is left out is part of the design and is recorded with the condition under which it returns.
8 min	Three measures of a toolbox Evidence age: the share of tools in use whose evidence is within its clock. Adoption: use by the unit for which the tool was chosen, the team at Nordvik Region and the market at Hansa Mutual. Retirements against stated criteria: a year with none means that no tool was reviewed. The toolbox grows with delegation, and the measure that matters most at Level 3 is the one that can fail.
10 min	Five patterns across ten volumes A shared anatomy and identifier families that link records into chains. Evidence age: a claim without a date is not a claim the organisation can make. Independence: a check is evidence only if the checker can fail in ways the checked does not share. Autonomy that is earned, budgeted and revocable.
7 min	Gaps, dialects and what the series does not ship Thirty-two prefix families appear in two or more volumes, and only the AI Decision Record has reserved ranges. The series provides texts, records and procedures, not software: 227 of 240 own tools are publishing scripts. No finding was a disagreement about a conclusion; they concern names, numbers, locations and dates.
5 min	Monday Read the Origin row, take the template with its version, and record a decision where the series gives two defaults. Reserve identifier ranges, treat a script shown in a chapter as a design, and date every claim with an independence statement.

What the audience takes away

Start from the obligation or risk that has no tool, not from the catalogue.
Judge a toolbox by the age of its evidence, its adoption and its retirements.
The tools exist in the volumes; a toolbox adds the name, the owner, the test and the date.

Chapter 24 · 90 minutes

Building a Toolbox: Nordvik Region and Hansa Mutual

The lesson follows Nordvik Region and Hansa Mutual through an illustrative year of building and running a toolbox. Participants see which tool each takes up first and why, what each leaves out on purpose, and the three measures the chapter assembles: evidence age, adoption and retirements. They learn to separate what the earlier volumes establish from what the chapter proposes as illustration, and to plan a toolbox from their own first gap.

Learning objectives

Identify the obligation or risk in an organisation that is already present and has no tool.
Sequence the adoption of tools over four quarters and justify the order by the gap.
Record a tool that is deliberately left out with the condition under which it returns.
Measure a toolbox by evidence age, adoption and retirements against stated criteria.

Key concepts

The first gap: The question asked before any other: which obligation or risk is already present and has no tool? For Nordvik Region it is the high-risk benefits-triage system; for Hansa Mutual it is the agents that already act on production.
Evidence age as a toolbox measure: The share of tools in use whose evidence is within its clock. A toolbox review lists each tool with the date of its last test and the clock that governs it, and a tool past its clock is shown as unverified.
Adoption by unit: Whether a tool is used by those for whom it was chosen. For Nordvik Region the unit is the team that has taken a tool over; for Hansa Mutual it is the market, since a tool applied in one country of seven is adopted in one country.
Retirements against criteria: How many tools are retired, and against which criteria. The series has no single retirement artefact, so each organisation assembles one; a toolbox with no retirements in a year is a sign that no tool was reviewed.
Leaving a tool out: A recorded design decision that names the condition under which the tool comes back. Nordvik Region would revisit emulation tooling if it gave an agent write access to production.

Teaching plan

15 min	Present the two starting points and Figure 24.1. Make clear which facts the earlier volumes establish and that the year and its quarters are illustrative.
20 min	Walk both years: Nordvik Region (know and decide, map and gate, buy and operate, delegate at Level 2) and Hansa Mutual (bound the agents, observe and stop, verify coverage, weigh and sustain).
15 min	Teach the three measures and the table across the degrees of delegation. Use the two stop drills of Hansa Mutual: 17 minutes against a target of 5, later 250 seconds against 300.
30 min	Exercise: participants plan a four-quarter toolbox for their own organisation, starting from its first gap.
10 min	Participants compare plans in pairs: is the organisation more like the cautious buyer or the builder, and what did each leave out?

Discussion

Hansa Mutual bounds its agents before its inventory is complete, while Nordvik Region starts with the inventory. Under what conditions is each order the right one?
The independence statement moved two cells of Hansa Mutual's purple loop to failed. Why does the chapter say a toolbox that reports failed cells where a dashboard once showed green is working as designed?
Both organisations found that most remedies existed before the diagnosis, and that the diagnosis added the name, the owner, the test and the date. What does that suggest about where to spend effort first?

Exercise · 30 minutes

A four-quarter toolbox plan from your first gap

For your own organisation, name the obligation or risk that is already present and has no tool. Decide whether your situation is closer to Nordvik Region, the cautious buyer, or Hansa Mutual, the builder. Plan four quarters: for each, give a heading, two or three tools from the earlier modules with the originating volume, and the evidence that would show the quarter is done. List two tools you deliberately leave out, each with the condition under which it returns. Finish with the three measures: which clock governs the evidence of each tool, the unit in which you would read adoption, and one retirement criterion. The Toolbox Maturity tool at tools.geon.se may be used to check the plan.

Deliverable: A one-page toolbox plan: first gap, four quarters with tools and closing evidence, two recorded omissions with return conditions, and the three measures.

Self-test

Which tools does Hansa Mutual take up first in the illustrative year, and why?
1. The threat register and horizon register, because the board asked for them
2. The sovereignty requirements profile, because it buys under public procurement law
3. The mandate manifest with its delegation profile, because Mode 5 agents already act on production with nothing bounding them
4. The coverage record and regression case, because they need no other tool to exist
What does the chapter say about a toolbox with no retirements in a year?
1. It is a sign that no tool was reviewed, not a sign of health
2. It shows that every tool was chosen correctly at selection
3. It proves that the exit clauses in the contracts are strong
4. It means the adoption dashboard is within its healthy range
What does the toolbox add at Level 3 Bounded that a year spent at Level 2 Supervised does not need?
1. An inventory entry with a usage mode and a decision record with retirement criteria for each of the systems in use
2. A mandate and a named approver for every executable class of action
3. A golden-set evaluation and an adoption dashboard with a healthy range
4. An observer, a stop path outside the agent and an independence statement, each with its own date

Chapter 25 · 75 minutes

Conclusions: One Toolbox for the Series

The lesson draws the book's own conclusions. Participants learn the five patterns that recur across the ten volumes, read the tables of gaps and inconsistencies (prefixes that name several artefacts, one artefact under several names, templates named but missing, scripts shown but absent, differing defaults), and apply the seven actions for Monday. They learn why only the later of two volumes can reconcile a conflict and which statements are the author's labelled projections.

Learning objectives

Explain the five patterns that recur across the tools of the ten volumes and how they depend on one another.
Classify an inconsistency between volumes by the kinds the chapter uses and say which volume should resolve it.
Apply the seven actions for Monday to a tool the participant intends to adopt.
Distinguish the chapter's findings from the author's projections labelled expected and speculation.

Key concepts

Five recurring patterns: A shared anatomy; identifier families that link records into chains; evidence age; independence; and autonomy that is earned, budgeted and revocable. The anatomy makes an identifier worth reserving, and the identifier lets a date be attached to a claim.
One design, many dialects: The chapter's first conclusion: the 1,629 inventory entries share a design, but field names, schemas and identifier forms differ between volumes. The five patterns are what lets a reader move between volumes.
Who resolves a conflict: The series builds in publication order and no volume refers to a later one, so a conflict between two volumes can be reconciled in a text only by the later of them. The earlier volume can correct only its own internal faults.
Reserved identifier ranges: The only reservation in the series is for the AI Decision Record, and that family shows no collision. For every other family the chapter advises a rule of prefix, organisation, area and sequence, and a list of prefixes in use.
Local gap list: The seventh action for Monday: where a tool of the series conflicts with another or with the organisation's estate, record the conflict beside the tool, with an owner and a review date, as for a register entry.

Teaching plan

15 min	Present Table 25.1 and the three observations: almost no operating software, more artefacts and methods as the series goes on, and about a third of entries with a full template.
15 min	Teach the five patterns and their dependence on one another, each with the chapter of the book it rests on.
15 min	Read selected rows of Tables 25.2 to 25.8: the prefixes CHG, DLG and EXC, the six evidence manifests, scripts shown but absent, and defaults that differ. Explain who resolves each.
20 min	Exercise: participants apply the seven actions for Monday to one tool they intend to adopt and start a local gap list.
10 min	Close the course: each participant states one default they chose, one identifier rule and one claim they will date this week.

Discussion

None of the findings was a disagreement about a conclusion; they concern names, numbers, locations and dates. Why do such differences still matter to a practitioner who combines tools from several volumes?
The author labels a single machine-readable schema registry for the series as speculation and notes it would remove a volume's freedom to shape an artefact to its subject. How would you weigh that trade-off in your own organisation?
The series ships texts, records and procedures, not software. What does it take to treat a script shown in a chapter as a design and still end up with a tested check?

Exercise · 20 minutes

Seven actions on one tool, and a local gap list

Choose one tool of the series that you intend to adopt in the coming quarter. Using the Tool Finder or Template Library at tools.geon.se, apply the seven actions for Monday to it. Confirm in the Origin row which book and chapter defines it and whether its prefix names another artefact. Note which version of the template you take. Where the series gives two defaults that affect the tool, choose one and write the reason as a decision in your own range. State your identifier rule. Say whether any script it relies on is a design you must build and test. Write how its claim will be dated and by whom verified. Finally, open a local gap list with at least two entries, each with an owner and a review date.

Deliverable: A one-page adoption note for one tool covering the seven actions, and a local gap list with two or more entries, owners and review dates.

Self-test

According to the chapter, which volume can reconcile a conflict between two volumes of the series in its text, and why?
1. The earlier volume, because it defined the artefact first and owns the prefix
2. The later volume, because the series builds in publication order and no volume refers to a later one
3. Either volume, whichever happens to be revised first by its editor
4. Neither volume, because only the companion book may record the relation
What does the chapter conclude about the software that the series provides?
1. Each volume ships a complete engine for the checks it describes
2. The later volumes ship observer, probe and emulation software in their repositories, and the earlier volumes ship only publishing scripts
3. The series ships its policy gates as tested, runnable packages
4. The series provides texts, records and procedures, not software; the checks are designs to build and test
Which identifier family is the only one with reserved ranges in the series, and what does the chapter observe about it?
1. The mandate manifest family, which collides in five volumes
2. The change record family, reserved by AI Operations alone
3. The AI Decision Record family, in which the findings show no collision
4. The role charter family, with one pattern in every volume

Answers to the self-tests

Chapter 1	1B · 2D · 3A (1) The chapter defines a method as a named, repeatable procedure with steps, an input and an output that the reader applies. Identifier prefixes belong to artefacts, and laws are not tools at all. (2) 227 of the 240 own tools are the publishing scripts of the ten repositories. The remaining 13 own tools and the other 1,402 entries are treated in the chapters; 114 is the number of third-party entries mentioned only in passing. (3) The two artefacts share a prefix and serve two kinds of incident. The reader's first decision is which one fits, and for a service outage it is the review of AI Operations, whose Inputs row leads to the incident record.
Chapter 2	1A · 2C · 3D (1) The test of 2027-10-12 failed over the portal in 5 hours 20 minutes against a 2-hour objective; the review found a DNS time-to-live and an unrenewed certificate. The record withdraws the claim and the objective record shows the failed evidence. (2) The AI Decision Record is decision_record in one template and decision in another. A reader who searches by field name will miss records; a reader who searches by identifier will not. (3) The delegation profile separates the agent's owner from the authority that may raise a ceiling. Lowering is immediate, and raising needs the named authority's decision, which the commit and the decision record then show.
Chapter 3	1C · 2B · 3D (1) The bands are 60 to 75 ready to proceed, 40 to 59 partial readiness and below 40 foundation work needed. A total of 52 falls in the middle band, and the chapter adds that readiness is a dated reading, not a certificate. (2) The healthy range on the override rate encodes that both extremes are failures: a rate near zero means oversight has become ceremony, and a high rate means the model is not good enough to deploy. (3) The closing rule makes the record more than a note: the pattern is closed when a re-test passes, not when the remedy is merged. The chapter repeats the rule in its Summary.
Chapter 4	1C · 2A · 3D (1) The file is a template for the form, not a prescription of the contents, with one fixed rule: deviations are recorded, but the gateway, registry, evaluation service and control plane stay because later controls depend on them. (2) The validator requires the scalar fields such as adr_id, title, status, date, last_reviewed and next_review_due, and accepts only the four lifecycle statuses. It is the one ADR script of four that a chapter describes. (3) Modes 0 to 3 need a short record and an inventory entry. Modes 4 and 5 need the full record always, and for Mode 5 again whenever permissions widen, because the organisation operates all the layers.
Chapter 5	1B · 2D · 3A (1) The chapter's own conclusion names exactly these four conditions. Open Policy Agent and Rego are the common engine and language, but the conditions, not the product, make the rule a tool. (2) The chapter states that AI Purple adds the property that the earlier manifests lack: evidence expires. Its manifest also records the versions tested, the runs including the failed one, and who reproduced and signed it. (3) In the table across the degrees of delegation, the operations agent of the example may read state but cannot sync, and an agent identity with the right to sync is a thing the artefact must never contain.
Chapter 6	1B · 2C · 3A (1) The Summary states that the gateway is the single component that is not optional because logging, redaction, routing and budgets apply there to every AI call; in Modes 1 to 3 the effort goes into making traffic reach it. (2) The volume's design point is that the entitlement filter runs before search, so a user's permissions limit what can be retrieved rather than relying on a later layer to hide it. (3) The approvals are the one part of the registry entry that pipelines do not write, and they name people who did not build the model. The chapter generalises this: every promotion has an owner who did not build what is promoted.
Chapter 7	1D · 2A · 3B (1) The questionnaire walks the AI Act decision tree with a legal basis stated for every answer. The chapter says every answer carries a reference so that a reviewer challenges the basis rather than the conclusion. (2) The rule is the enforcement half of the exception record: an eight-line Rego rule that denies a change relying on an expired exception. The book calls it the smallest useful gate rule. (3) For Mode 0 the unit is each supplier feature, recorded in a supplier-feature register, with an AIDR for each feature that processes personal or confidential data. The tenant deployment is the unit for Mode 2.
Chapter 8	1C · 2B · 3D (1) The matrix is the simplest tool with the widest reach because it asks only for a table. Its limit, the chapter says, is that it holds clause references and not tests. (2) An organisation is at a level in a dimension when it meets that level's indicators and those of every level below, and one overall level, where needed, is the lowest dimension. (3) AI Operations adds that the owner of the record is independent of operations, so the mapping is itself a second-line artefact, and that a failed test withdraws the claim on its row.
Chapter 9	1A · 2C · 3D (1) The chapter states that the overall rating is the highest category score, not the average; the record gives a score and a rationale for each of the five categories. (2) Only what the legal analysis makes non-negotiable is mandatory; everything else, including a Gaia-X self-description, is weighted, which keeps the tender open to competition. A mandatory failure excludes the tender. (3) In the worked example the first requirement puts the stop path outside the supplier: named stop holders can suspend the ranking function without the supplier's staff or software taking part, verified by a drill at acceptance and in operation.
Chapter 10	1C · 2A · 3B (1) The completeness check asks whether every boundary changed in the pull request has threats considered; its automated part flags changed boundaries without candidates, a gap invisible to someone who reads only the candidates. (2) ATLAS is described by the originating book as young and still changing, so identifiers must be pinned. The other limits belong to D3FEND, attack trees and STRIDE respectively. (3) The chapter states that Mode 5 agents are modelled as well-meaning insiders that can be manipulated or compromised, so their permissions are scored as if an adversary held them.
Chapter 11	1D · 2B · 3A (1) Delegation is explicit in the template: safety class S1 inside scope at Level 3 Bounded, anything above S1 at Level 2 Supervised, and Level 4 never. (2) The Summary states that the libraries and the product class give cadence and breadth, and that their limit is the same: a reaction to a catalogued behaviour, not proof that anyone acted or that other behaviour is covered. (3) The significant finding was that withdrawal of a page did not trigger re-indexing, so the assistant cited a withdrawn page as current. The finding ends in a defensive change to the indexing process.
Chapter 12	1C · 2D · 3A (1) A hunt is recorded with what it did not search; the chapter calls this the most important field of a record that another hunter can review and repeat. (2) The Summary states that the records chain by identifier, INTEL to HNT to DET to CASE. The other chains belong to operations, the purple loop and governance. (3) The chapter says none of these is a verdict: the vulnerability sources inform a decision and do not make one, and they are used in combination, not alone.
Chapter 13	1B · 2D · 3C (1) The table of five test kinds gives 180 days for restore from backup and failover, 90 days for rebuild from code and 365 days for degraded mode and restore at scale. Tier 2 clocks double. (2) The restore point is defined relative to the earliest indicator of compromise, not as the latest backup, because the latest backup may already contain the adversary's changes. (3) The chapter states that a failed result is never overwritten and that a later passing record supersedes it. A failed result withdraws the claim and opens a problem record in the meantime.
Chapter 14	1D · 2A · 3B (1) The expectation is written, hashed and sealed before the run, so that the session compares a result with a commitment, not with a memory. The charter excludes audio or video recording. (2) In the rule file the first rule that matches wins and no override is allowed. If evidence must be extended, that is a recorded decision with a named person, a reason and a new date. (3) The entry injects a condition, not an attacker technique. In the example, log forwarding from one host stops, and the hypothesis is that the security operations queue shows a silent-source alert within the stated time.
Chapter 15	1C · 2B · 3A (1) The table gives a page at burn rate 14.4 over one hour with a five-minute short window, consuming 2 per cent of the budget; 6 belongs to the six-hour page and 1 to the three-day ticket. (2) The mandate in the record is a ceiling, not a recommendation: a customer-facing objective alert is never suppressed above Level 1 Assisted, a hold expires, and stop conditions freeze promotion. (3) The configuration separates two stores with different purposes: a sampled operational pipeline that is cheap to query and ages out, and an unsampled record of events routed to an append-only store, both after redaction of personal data.
Chapter 16	1D · 2A · 3C (1) The guide's condition for use is at least 20 manual executions in twelve months with no change-correlated Tier 1 or Tier 2 incident. The class then turns that history into data a gate can evaluate. (2) A change is classified by the diff and the target, not by what its author says. The illustrative gate denies a change whose declared class is lower than its computed class. (3) Prune deletes what left Git. The ceiling in AI Operations is a named person for stateful kinds, and never Level 4 where it would delete data. The no-approval holder applies to suspend.
Chapter 17	1B · 2D · 3A (1) The policy in Appendix A evaluates data classification first, then task type and the later rules, so that cost never overrides the hosting constraint for confidential or personal requests. (2) The plan reserves for the baseline and bursts only when latency is at risk; its utilisation-floor alert turns accelerator hoarding into a visible finding. (3) The artefact must never contain a forecast without a back-test, a reduction of the standby floor before a failover re-test, or a cost estimate taken from the agent. The chapter concludes that such a record is a hope.
Chapter 18	1A · 2C · 3D (1) The first reading the chapter draws from the books is that the mandate belongs to the agent and the delegation profile to the system, team or service. Both are artefacts of the organisation. (2) The observer counts, not the agent. The chapter's Summary names a budget counted by the agent itself as an example of a broken link that leaves a label without a control. (3) The table gives fail over a ceiling of Level 1 with the incident commander as approver. Level 4 applies only to read and annotate, and roll back sits at Level 2 as a candidate for Level 3.
Chapter 19	1B · 2D · 3A (1) AI Purple names model, data, authorship, vendor and time; AI Operations names model, data, authorship, credential, failure domain and time. The sets differ by two items, and the series uses them as a union. (2) The chapter calls it the field to watch: a stop that works by telling the agent to stop is a request, not a control, so the record shows that the stop used mechanisms the agent cannot block. (3) All the seeded tests carry a catch rate and a stop rule. The catch rate is the share of seeds found within the target time, and the stop rule lowers or freezes delegation when the rate falls below a floor.
Chapter 20	1C · 2B · 3D (1) The chapter states the rule directly: a read-only switch in a tool is a convenience, and the hard limit is the permission of the identity behind the server, enforced outside the model. (2) The Summary states that the two artefacts have two jobs, the agent's declared intent and the platform's commitment, and that the profile must hold whether or not the manifest is obeyed. (3) The profile is owned by a named person, but its classification as verified, declared or failed is set by the last test result and not by the owner.
Chapter 21	1C · 2A · 3B (1) The framework records the rule lower of unassisted and AI-assisted demonstrated level, and the Summary repeats that a framework counts the lower of the unassisted and assisted forms. (2) The conditions read levels and validity only. Figure 21.1 states that the conditions read levels, never content, which is what lets the record condition an agent's ceiling without exposing personal assessments. (3) The chapter's conclusion is that a record that cannot be used for ranking, pay or discipline can be shared widely enough to be useful, and that the first thing to agree with representatives is what it may not be used for.
Chapter 22	1D · 2B · 3A (1) The decider field holds a role and a name and may not be system or agent. The schema validates that a person is the decider before any record is stored. (2) The schema validates a person as decider, a contestation route and a retention rule, and rejects M3 Consequence at Level 4 and any adverse consequence above Level 1. The Summary lists both among the rules that survive. (3) At Nordvik Region the unit manager granted the contest in full on the first look. At Hansa Mutual the sales manager did not grant it, so it was referred to an HR business partner outside her line; the reviewer is never the original decider.
Chapter 23	1C · 2D · 3A (1) The grade and the label are kept in separate fields because the same rung can support different outlooks: a laboratory demonstration that is cheap to exploit may be expected, while another stays speculation. (2) The postures are the same in every volume: observable justifies commitment, expected justifies preparation and speculation justifies reversibility. The Summary calls reversibility the posture for what cannot be evidenced. (3) The four conditions are a plausible path to harm, a material change that AI makes to the harm, a claim precise enough to be graded, and a role that can be named to own it. No probability is held.
Chapter 24	1C · 2A · 3D (1) Hansa Mutual's first gap is agents acting on production with no mandate, so waiting for a complete inventory would leave a privileged workload unbounded. Coverage tools come third because they need the observer and the mandate. (2) The third measure is how many tools are retired and against which criteria. The chapter states that a toolbox with no retirements in a year is not a sign of health but a sign that no tool was reviewed. (3) The toolbox grows with delegation: Level 2 needs a mandate and a named approver, and Level 3 adds an observer, a stop path outside the agent and an independence statement, each with its own clock.
Chapter 25	1B · 2D · 3C (1) Because no volume refers to a later one, only the later of two volumes can state the relation to the earlier or choose a distinct identifier. The earlier volume can correct only its own internal faults. (2) Of 240 own tools, 227 are publishing scripts and 13 remain; no volume provides an emulation engine or observer software. The checks the volumes describe are designs for an organisation to build and to test. (3) The only reservation in the series is for the AI Decision Record, and that family shows no collision, while families without a reserved range show many. This is the basis for the advice to reserve ranges.

Final assignment

A dated toolbox for one service or AI system. Build a small, working toolbox for one service or AI system of your own organisation, or for one system of Nordvik Region or Hansa Mutual as the book describes them. Start from the obligation or risk that is already present and has no tool. Select eight to twelve tools from at least four parts of the book, take each template from the originating volume through the Template Library, fill in at least five of them, and link them by identifier into a chain. For every tool state the owner, the last test, the clock that governs its evidence, a measure of use and a retirement criterion. Record what you deliberately leave out and why. Use only defensive, authorised and scoped activities for anything that tests a control.

Assessment criteria

Fidelity: every tool, purpose and identifier family traces to the book and the originating volume, with nothing invented
Evidence: every claim that a tool covers, recovers or verifies something carries a date, a result and a clock
Coherence: the artefacts cite one another by identifier and the chain can be followed in both directions
Judgement: the order follows the gap, omissions are recorded with return conditions, and defaults are chosen by a stated decision
Safety and respect: tests are authorised and scoped, stop paths sit outside the system stopped, and no record ranks or monitors named individuals