Book Blueprint and Chapter Briefs

This blueprint records the editorial intent of AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities, Book 9 of The Transformed Architecture. It is the brief every chapter is written against; the authoritative proposal is DISPOSITION.md. The chapter briefs below are generated from scripts/outline_data.py by python3 scripts/generate_outlines.py; edit the data file, not the generated section. The conclusions of the earlier volumes that each chapter builds on are recorded in SERIES_FOUNDATIONS.md (F1 to F91 from Books 1 to 7, and the foundations of Book 8 from F92), and chapter references where a conclusion has no identifier.

Premise

The series has treated the two sides of cyber defence separately. AI Red Team (Book 4) put AI to work in cyber defence, Function by Function of NIST CSF 2.0, and defined the three teams: the red team emulates the adversary, the blue team defends, and the purple team is not a third team but the joint loop between them (AI Red Team, Chapter 26). AI Blue (Book 8) described the team that defends: five functions, the transformed SOC, the analyst and the craft. Both books treat the loop from one side only. AI Red Team gives it as the last step of a book organised by CSF Functions; AI Blue, Chapter 11, gives it as the second half of B5 Learn and leaves the red team's tradecraft and the joint practice to a later volume.

This book takes the loop itself as its subject. It asks what happens when AI sits on both sides of the table at once: an emulation side that can plan, vary and repeat adversary behaviour at a pace and cost that make continuous emulation possible, and a detection and response side whose triage, investigation and drafting of detections are increasingly done by agents, while the adversaries themselves use AI to shorten the time from disclosure to exploitation. The traditional rhythm, an annual penetration test and a quarterly purple session, was set by the scarcity of skilled red-team hours. AI loosens that constraint. It does not remove the need for what the loop was always for: an evidenced answer to the question "would we have seen and stopped this, and how do we know?"

The new risks are specific to a loop with AI on both sides. A loop that two systems close between themselves can agree with itself, because the emulation agent and the detection agent may share training data, a model family and blind spots. Detections can be overfitted to the scenarios that test them. A library of scenarios, findings and weaknesses becomes a map of the organisation that an adversary would value. An emulation agent is an offensive capability that runs inside the estate. And a continuous loop can become a dashboard of green ticks that nobody has questioned since the last time a person looked.

The European frame makes the question concrete in 2026 and 2027. DORA requires advanced testing by threat-led penetration testing for designated financial entities; NIS 2 Article 21 requires assessment of the effectiveness of security measures; the AI Act places adversarial testing duties on providers of general-purpose AI models with systemic risk and robustness and cybersecurity duties on high-risk systems; works councils and unions have rights over any exercise that touches staff; and managed-service and cloud providers must consent to testing that crosses their boundary. These constraints decide who may emulate what, where, when and with whose consent. Every article number is verified against the live text before it is written.

The book answers through what the loop did before and why it is under pressure (Part I), the five stages of the loop (Part II), the loop applied to AI systems and to the defenders' AI (Part III), the loop's own AI and the independence principle (Part IV), the loop in the organisation: coverage, measures, operating models, decision rights, regulation and boundaries (Part V), the people who run it (Part VI), and what two organisations experienced and what follows (Part VII).

Thesis

The working thesis has five parts, tested in Parts II to V and judged in Chapters 25 and 29.

Purple is a loop, not a team. What is scarce is a shared, verified account of what the defence does against what the adversary does. Whoever supplies it, in-house red team, contracted tester, automated pipeline or all three, the loop closes only when a change has been re-tested and the evidence attached.
AI moves the loop from the event to the pipeline, and keeps the event. Continuous, automated emulation and regression make verification routine, so the work shifts from running exercises to engineering scenarios, detections and tests as code. The exercise remains where novelty, judgement and trust are produced.
A loop closed by machines alone verifies nothing new. Verification needs independence between the side that tests and the side that is tested: different model families and data, human-authored novelty, seeded errors and an evidence trail that a person can reproduce. The independence principle is the central design rule of the book (Chapter 15).
Coverage is a claim that needs evidence. "We detect technique T" is a statement with an age, a condition and a result. Untested is not covered; evidence expires; detections decay.
Safe and legitimate emulation is a design question. Scope, authority, blast radius, stop path, consent of third parties and the rights of staff are decided before an agent acts, in a signed rules-of-engagement manifest enforced outside the agent. Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise has been authorised to touch, or that targets a named person.

The thesis would be shown wrong by evidence that fully automated emulation and automated detection engineering, with no human-authored novelty and no independent verification, sustain real detection of novel intrusions better over several years, as judged by independent threat-led tests, than a loop that keeps those properties; or by evidence that the continuous loop leaves the capacity for human-led, creative adversary emulation intact without people who practise it.

Audience

CISOs and heads of security operations; red-team leads, penetration testers and the contracted testers who serve organisations without a red team; SOC managers, detection engineers, threat hunters, intelligence analysts and incident commanders; purple-team coordinators and exercise controllers (the white team); security architects and AI architects; boards and management bodies with duties under NIS 2 Article 20 and DORA Article 5; procurement and vendor managers who buy penetration testing, managed detection and response and breach-and-attack simulation; supervisors and auditors who receive the evidence; works councils, unions and data protection officers; and public-sector leaders. Chapter 1 gives reading paths.

Boundaries

The book builds only on Books 1 to 8 and never refers to a later volume. It takes their conclusions as given and does not repeat them.

Not a second AI Red Team. That book gives the technical design of adversary emulation and continuous red teaming (Chapter 12), red teaming AI systems (Chapter 13), security chaos engineering (Chapter 25) and the five-state loop with the golden-dataset evaluation (Chapter 26). This book takes the loop as the subject and extends it to continuous operation, independence, coverage as an evidenced claim and the organisation that runs it.
Not a second AI Blue. That book describes the SOC, B5 Learn and the SOC agent team. This book treats the red and joint side and the practice between the teams, and reuses the blue team's artefacts.
Not a second AI Threat. The threat register is the source of scenarios and evaluation awareness is a limit on automated verification; whether the threat is real is not re-argued.
Not a second The Transformed Security Architect or AI Boss. The method for verifying AI proposals and the treatment of surveillance, pace, health and co-determination are applied, not repeated.
Not a second AI Platform and Security. Security for AI systems, containment, evaluation and observability are the platform on which emulation runs and the controls it tests.
Defensive only. Adversary behaviour is described by technique (MITRE ATT&CK and ATLAS identifiers) at the level needed to design scenarios, detections, controls and tests. The book contains no exploit code, malware, payloads, jailbreak or injection strings, phishing kits or step-by-step intrusion instructions. Every offensive activity described is authorised, scoped by written rules of engagement, run against the organisation's own or contracted systems and ends in a defensive improvement. Covert monitoring of staff and defeating employee representatives' rights are never described as methods.
Legal content is attributed to the instrument and article, verified against eur-lex.europa.eu, and framed as architectural and organisational implication, not legal advice.

Red threads

The five stages of the purple loop. P1 Target, P2 Emulate, P3 Observe, P4 Improve, P5 Verify (Chapter 4). Every chapter in Parts II to V names, in its opening and Summary, the stages it concerns. They map to the five record states of AI Red Team, Chapter 26: Finding is the output of P3, Control and Detection of P4, Re-test and Evidence of P5.
Degrees of delegation across the stages. Every narrative chapter has an ### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table, applying Level 0 Advisory to Level 4 Autonomous per stage and action class.
The independence principle (Chapter 15) recurs wherever AI is on both sides of a check.
Coverage with evidence age. No chapter states that something is covered without saying what was tested, when and with what result.
Stop paths and reversibility. Every chapter that concerns P2 Emulate says what can be undone and who can stop it, outside the system being stopped.
Observable, expected, speculation. Every outlook carries one of the three labels; the author's projections stay in Chapters 25 and 29.
Constructive debate. Chapters 8, 15, 24 and 25 stage a debate in four steps (the case for concern, the case for calm, where the positions meet, what can be done) before a verdict.
Two organisations. Nordvik Region and Hansa Mutual in every narrative chapter, in worked examples and in a short ### Nordvik Region and Hansa Mutual subsection before the Summary. Nordvik buys the loop and its leverage is the contract; Hansa runs it and its leverage is the pipeline.
New artefacts. SCN-* (Chapter 5), EMU-* (7), PRP-* (9), REG-* and EVD-* (11), MND-*-EMU-* (14), COV-* (17), with RoE-*, FND-*, DLG-*, ROLE-*, CMP-*, DET-*, PBK-*, PIR-*, THR-*, TTX-* reused from earlier volumes and AI Decision Records AIDR-0800 to AIDR-0899 (Nordvik Region 0800 to 0849, Hansa Mutual 0850 to 0899).

Status

The repository was bootstrapped on 2026-11-10 from the engine of AI Blue. All 29 chapters are drafted, fact-checked against their sources and reconciled against the ledger in docs/EXAMPLE_ORGANISATIONS.md (see reviews/ and HANDOVER.md); each brief below carries the status draft. The status complete is reserved for the merge to main, after the bibliography has been renumbered with scripts/renumber_sources.py and format_citations.py --fix and update_reference_backlinks.py have been run. scripts/generate_outlines.py regenerates the briefs from scripts/outline_data.py and never overwrites a drafted chapter.

Length and weighting

Narrative chapters run 3,600 to 5,500 words; Chapters 6, 15, 17 and 21 may run to 6,500 words. A chapter that grows beyond about 6,500 words, or a section beyond about 2,500 words that treats a distinct subject, is split into a companion chapter, recorded here. Chapters 19 and 20 are the first candidates to merge, and Chapters 23 and 24 the second, if the drafts turn out thin.

Chapter briefs

Part I: The Loop in Question

Chapter 1: Introduction: The Purple Loop with AI

File: 01_introduction.md
Status: draft
Purpose: Introduce the book on its own terms. The earlier volumes treat the loop between red and blue from one side each (AI Red Team, Chapter 26, from the red side; AI Blue, Chapter 11, from the blue side); this book treats the loop between them, now that AI sits on both sides. State the question, the five-part thesis and what would refute it, the five stages and the independence principle, and why the question is European in 2026 and 2027 under DORA, NIS 2, the AI Act and the rights of staff.
Builds on: F48, F50, F60, F62, F70, F76, AI Red Team, Chapter 26, AI Blue, Chapter 11
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: A quarterly session and a continuous pipeline, two nights; The loop in 2026; The question the series had not asked of the loop; The working thesis; Five stages and five degrees; Why Europe, and why now; Rules of the book; Two organisations; How to read this book
Practical guides: A one-page inventory of every place where AI already takes part in testing or in detection, including vendor AI in managed services and simulation tools
Worked examples: The audit committee's question to Nordvik's CISO recorded as AIDR-0800 and the board's question to Hansa Mutual's group CISO recorded as AIDR-0850, each with a reviewer and a report date
Nordvik Region and Hansa Mutual: Nordvik's CISO is asked by the audit committee what the first threat-led exercise has proved (AIDR-0800); Hansa Mutual's group CISO is asked by the board whether continuous automated red teaming makes the quarterly purple session redundant (AIDR-0850).
Usage modes and degrees of delegation: The chapter introduces the usage modes as the series uses them and separates AI that assists a tester or analyst under that person's identity (Modes 1 to 3), AI built or procured to perform a loop function (Mode 4) and agents with identities of their own (Mode 5).
Observable, expected, speculation: AI on the emulation side, AI in detection tooling and shorter exploitation windows are observable; continuous verification as the normal case is expected; a self-improving defence without review is speculation, treated in Chapter 25. The thesis is the book's own claim, tested in Parts II to V and judged in Chapters 25 and 29.
Figure: The purple loop at the centre: five stages, the red, blue and white teams around it and the chapters that treat each stage

Chapter 2: What the Loop Did Before: Penetration Tests, Red Teams, Tabletops and Purple Sessions

File: 02_what_the_loop_did_before.md
Status: draft
Purpose: Describe the loop before the transformation, as the baseline for Chapters 5 to 11: penetration test, red team engagement, threat-led test, tabletop, purple session and breach-and-attack simulation; the roles (red, blue, white, trusted agent, exercise controller); how results flowed and where they stalled. A short history of the terms, which the researcher must verify before it is written.
Builds on: F7, F43, F59, F60, AI Red Team, Chapter 12, AI Red Team, Chapter 26, AI Blue, Chapter 11
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: A map of testing forms; Who plays what; The report as the end of the loop; Why findings stalled; Cost and cadence; What each form can and cannot show
Practical guides: Classifying the testing a team already does by form, role, cadence and what it proved
Worked examples: A testing-forms register for Nordvik Region and Hansa Mutual
Nordvik Region and Hansa Mutual: Nordvik Region procures an annual penetration test per system and has never run a threat-led exercise; Hansa Mutual runs red team engagements, quarterly purple sessions and a breach-and-attack simulation tool, with findings that wait a median of 19 days for a control.
Usage modes and degrees of delegation: Pre-AI baseline; the chapter marks where Mode 0 features already sit in simulation and detection products.
Observable, expected, speculation: The history and practice of testing forms is observable; the claim that findings stalled for want of a re-test is supported by the sources the researcher verifies and is otherwise the book's own conclusion.
Figure: Six forms of testing mapped against the five stages, with the stage each form usually leaves unfinished

Chapter 3: The Pressure on the Loop: Machine-Speed Adversaries, Detection Decay and the Annual Test

File: 03_the_pressure_on_the_loop.md
Status: draft
Purpose: Explain why the traditional rhythm no longer fits: exploitation windows that collapse, estates that change daily, detections that decay, scarce red-team hours, finding backlogs, and compliance that rewards an annual report. Add what AI changes for good: cheaper variation and repetition. Summarise the evidence of AI Platform and Security, Chapter 18, and AI Threat, Chapter 18, from the standpoint of the loop.
Builds on: F35, F36, F29, F67, F62, F66, AI Platform and Security, Chapter 18, AI Threat, Chapter 18, AI Blue, Chapter 3
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: The shrinking window; An estate that changes faster than the test; Detection decay; The finding half-life; Scarce talent on both sides; What AI makes cheaper and what it does not
Practical guides: Estimating a team's test-to-change ratio: how many production changes occur between two verifications of a priority technique
Worked examples: A decay estimate for three detections at Hansa Mutual
Nordvik Region and Hansa Mutual: Nordvik Region's annual test covers a benefits-triage service that is released every two weeks; Hansa Mutual's quarterly sessions cover 34 priority techniques while the estate changes daily.
Usage modes and degrees of delegation: The pressure falls differently on Mode 1 to 3 assistants (which speed individual testers) and on Mode 4 and Mode 5 pipelines (which change the cadence).
Observable, expected, speculation: AI-assisted adversaries and shortened exploitation windows are observable; continuous verification as the normal case is expected; self-improving defence without review is speculation.
Figure: Four curves over twelve months: estate change, detection decay, finding backlog and verification coverage, against the cadence of an annual test and of a pipeline

Chapter 4: The Purple Loop Defined: Five Stages, Evidence and the Independence Principle

File: 04_the_purple_loop_defined.md
Status: draft
Purpose: Define the book's frame: P1 Target, P2 Emulate, P3 Observe, P4 Improve, P5 Verify, with the record each stage produces (scenario, emulation plan, finding, change, regression case, evidence); the closure rule (a finding is closed only when the re-test passes and the evidence is attached); the degrees of delegation per stage; the independence principle; the roles of red, blue, white and the purple coordinator; and the mapping to the five record states of AI Red Team, Chapter 26, and to B5 Learn in AI Blue.
Builds on: F50, F52, F60, F62, F63, F73, F75, F76, AI Red Team, Chapter 26, AI Blue, Chapter 11
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: Why a loop; The five stages; The records; The closure rule; Degrees of delegation per stage; Independence; Roles and accountability; What the loop is not
Practical guides: Writing a delegation profile per stage and action class for a loop
Worked examples: A loop charter and delegation profile as code for each organisation
Nordvik Region and Hansa Mutual: Nordvik Region writes a three-stage minimum loop that its contracted tester and its managed provider can both sign; Hansa Mutual maps its existing five record states to the five stages and finds that P5 is the weakest.
Usage modes and degrees of delegation: The delegation ceiling per stage is the chapter's central table: P1 and P4 up to Level 2 Supervised, P2 and P3 up to Level 3 Bounded for catalogued safe scenarios, P5 up to Level 3 with a person accountable for closure.
Observable, expected, speculation: The stages and records are the book's own design, built on observable practice; the ceilings are the book's own recommendation.
Figure: The five stages as a cycle with the record each produces and the delegation ceiling per stage

Part II: The Stages of the Loop

Chapter 5: Target: Threat-Informed Scenarios, Risk and Priority Techniques

File: 05_target.md
Status: draft
Purpose: Show how scenarios are chosen: from intelligence (AI Blue, Chapter 5), the threat register (AI Threat, Chapter 32), risk assessment (AI Red Team, Chapter 10) and incidents. Priority techniques by impact and likelihood rather than novelty; the scenario library as code; AI proposing scenarios at Level 1 Assisted; selection bias and the risk of testing only what is easy to emulate. This is P1 Target.
Builds on: F1, F2, F55, F64, F65, F36, AI Blue, Chapter 5, AI Red Team, Chapter 10, AI Threat, Chapter 32
Purple loop stages: P1 Target
Sections: From intelligence to scenario; ATT&CK and ATLAS as vocabulary; Priority techniques; The scenario record; AI-proposed scenarios and who decides; What not to test
Practical guides: Building a first priority list of 20 to 40 techniques
Worked examples: Scenario records SCN-NR-0001 and SCN-HM-0007 as code
Nordvik Region and Hansa Mutual: Hansa Mutual's 34 priority techniques are re-ranked from the threat register; Nordvik Region builds a first list of nine for the benefits-triage service.
Usage modes and degrees of delegation: Mode 1 to 3 assistants help an analyst draft scenarios; a Mode 4 curator proposes from intelligence feeds at Level 1; no mode selects without a person.
Observable, expected, speculation: Technique prevalence is observable; AI-curated scenario libraries are expected; autonomous scenario selection is speculation.
Figure: From intelligence, register and incident through risk ranking to a versioned scenario library

Chapter 6: Rules of Engagement and Safe Emulation: Scope, Blast Radius and the Stop Path

File: 06_rules_of_engagement_and_safe_emulation.md
Status: draft
Purpose: Set the conditions under which emulation is allowed to run: authorisation by a named authority, scope and exclusions, blast radius, safe-by-construction techniques, simulation markers and canaries, data handling, third-party consent (cloud, managed provider, SaaS), the stop path outside the emulating system and the white team's role. The RoE-* manifest is code enforced by a policy decision point, extending AI Red Team, Chapter 7. This is P1 Target and P2 Emulate.
Builds on: F45, F52, F54, F63, F27, F74, AI Red Team, Chapter 7, AI Platform and Security, Chapter 19
Purple loop stages: P1 Target; P2 Emulate
Sections: Authority and mandate; Scope as code; Safety classes for scenarios; Production versus pre-production; Third parties; Data and personal data; Stop path and abort conditions; The white team; Records
Practical guides: Writing a rules-of-engagement manifest that a policy decision point can enforce
Worked examples: RoE-NR-2027-001 and a Hansa safe-scenario class table as code
Nordvik Region and Hansa Mutual: Nordvik Region signs RoE-NR-2027-001 for the benefits-triage service and the citizen-service assistant with its contracted tester; Hansa Mutual extends RoE-HM-2027-TLPT with a policy decision point and a stop path held by the white team.
Usage modes and degrees of delegation: Level 3 Bounded is the ceiling for catalogued safe scenarios in production; Level 4 Autonomous is never used for an irreversible or out-of-scope emulation action, for personal data beyond the authorisation or for an action targeting a named person.
Observable, expected, speculation: Safe-by-construction emulation design is observable practice; automatic enforcement of rules of engagement across vendors is expected.
Figure: A scenario passing through scope, safety class, consent and policy decision point to execution, with the stop path drawn outside the emulating system

Chapter 7: Emulate: Adversary Emulation Plans, Human-Led and AI-Assisted

File: 07_emulate.md
Status: draft
Purpose: Describe the campaign: a plan built from intelligence, executed by people, with AI assistance for planning, variation, tooling choice and documentation. What a human contributes that AI does not (creativity, judgement about consequence, social context); what AI adds (breadth, speed, cost). Defensive-level description only; the emulation plan EMU-*; the trusted agent and the white team during a live exercise. This is P2 Emulate.
Builds on: F43, F44, F52, F53, F75, F61, AI Red Team, Chapter 12
Purple loop stages: P2 Emulate
Sections: From scenario to plan; Roles in a live exercise; AI in planning and variation; AI in execution and its limits; Recording what was done; Hand-over to P3
Practical guides: Writing an emulation plan that gives the blue team ground truth without giving it the plan
Worked examples: An EMU-* record for a two-week exercise at each organisation
Nordvik Region and Hansa Mutual: Nordvik Region's contracted tester runs RoE-NR-2027-001 with the Region's analysts as blue team; Hansa Mutual's red team of five runs RoE-HM-2027-TLPT.
Usage modes and degrees of delegation: Modes 1 to 3 help the tester under the tester's identity; a Mode 4 planner proposes variants at Level 1 or 2; Mode 5 execution is limited to catalogued safe scenarios.
Observable, expected, speculation: Human-led, AI-assisted emulation is observable; agent-run campaigns inside signed scope are expected; self-directed campaigns are speculation and outside the book's rules.
Figure: An emulation campaign from plan to hand-over, showing which steps are done by people, which by AI-assisted tooling and where the white team may stop it

Chapter 8: Emulate Continuously: Breach-and-Attack Simulation, Atomic Tests and Automated Red Teaming

File: 08_emulate_continuously.md
Status: draft
Purpose: Treat emulation as a pipeline: breach-and-attack simulation, atomic tests and continuous automated red teaming (HM-SEC-004, AIDR-0314), triggered by change, schedule and intelligence. Safe-in-production design; variation to avoid overfitting; cost and drift. Stage the debate: does continuous automated emulation replace the human red team? This is P2 Emulate.
Builds on: F43, F44, F59, F62, F66, F68, AI Red Team, Chapter 25, AI Red Team, Chapter 26
Purple loop stages: P2 Emulate
Sections: The pipeline; What runs where; Scheduling around change; Variation; Overfitting and Goodhart; The cost of realism; The debate; Verdict
Constructive debate: Concern: Automated emulation repeats the known; it cannot find what nobody has thought of, and a loop that stops asking people to be creative loses the capacity to find novel intrusions while its dashboard stays green. Calm: Automation covers breadth, repetition and cost that no red team can; regression of known techniques every day is a better verification than a yearly test, and it frees the humans to do the work only they can do. Where they meet: Both agree that automation repeats and varies what is known, that novelty is human, and that evidence from automation is only as independent as the pipeline's design. What can be done: Keep a protected share of human-led, novel emulation; measure novel-finding yield separately; vary scenarios on purpose; review what the pipeline does not cover.
Practical guides: Choosing triggers and cadence for a continuous emulation pipeline
Worked examples: A pipeline definition for HM-SEC-004 and a Nordvik atomic-test subset as code
Nordvik Region and Hansa Mutual: Hansa Mutual runs HM-SEC-004 and asks whether the quarterly session is still needed; Nordvik Region has no pipeline and asks which five atomic tests give the most for its contracted tester's report.
Usage modes and degrees of delegation: Pipelines are Mode 4 (procured tools) or Mode 5 (agents with their own identity); Level 3 Bounded for catalogued safe scenarios, never Level 4 for anything irreversible.
Observable, expected, speculation: Breach-and-attack simulation and continuous automated red teaming are observable; AI-generated variants at scale are expected; replacement of the human red team is speculation.
Figure: A continuous emulation pipeline with triggers, safety class gate, variation, execution, telemetry tag and abort path

Chapter 9: Observe: Telemetry, Detection and Response Compared with Expectation

File: 09_observe.md
Status: draft
Purpose: Compare what happened with what was expected, layer by layer: prevention, telemetry, detection, alert, triage, action. An outcome taxonomy (prevented, detected, alerted but not triaged, triaged but not acted on, missed, no telemetry, not tested); ground truth from tagged emulation events; time-to-detect per technique; AI correlating emulation logs with detections and its failure modes; the purple session PRP-* as the place where red and blue read the result together; the finding record. This is P3 Observe.
Builds on: F20, F46, F52, F54, F66, AI Blue, Chapter 6, AI Blue, Chapter 7, AI Red Team, Chapters 18 and 19
Purple loop stages: P3 Observe
Sections: Expectation first; Ground truth; The outcome taxonomy; Telemetry gaps; Reading results together; Raising a finding; AI in observation
Practical guides: Running a purple session in which expectations are written before results are shown
Worked examples: A PRP-* record and an outcome table for one scenario at each organisation
Nordvik Region and Hansa Mutual: Nordvik Region compares the contracted tester's log with its managed provider's alerts and finds a gap between detected and triaged; Hansa Mutual correlates tagged events with detections across the group SOC and finds three techniques with no telemetry.
Usage modes and degrees of delegation: A Mode 1 to 3 assistant helps an analyst read the log; a Mode 4 correlator joins emulation and detection records at Level 2; no mode may mark a technique covered without a person.
Observable, expected, speculation: Outcome taxonomies and ground-truth tagging are observable practice; AI correlation of exercise logs is expected to become routine; automated finding triage is expected under review.
Figure: Layers from prevention to action with the seven outcomes and the point at which a finding is raised

Chapter 10: Improve: From Finding to Change in Detections, Controls, Playbooks and Mandates

File: 10_improve.md
Status: draft
Purpose: Turn a finding into the right change: a detection (AI Blue, Chapter 6), a control (AI Red Team, Chapters 14 to 17), a playbook (AI Blue, Chapter 10) or an agent mandate (AI Blue, Chapter 13). Prioritisation, ownership and the finding half-life; AI-drafted detections and fixes reviewed for soundness (The Transformed Security Architect, Chapter 14); the cost of false positives; change safety and regression risk. This is P4 Improve.
Builds on: F2, F51, F60, F66, F69, F75, F76, AI Blue, Chapter 6, AI Blue, Chapter 10, AI Blue, Chapter 13
Purple loop stages: P4 Improve
Sections: Choosing the kind of change; Ownership; AI-drafted changes; Review; False-positive cost; The backlog and the half-life; Findings no one can fix
Practical guides: Writing a finding-to-change decision that a second person can reproduce
Worked examples: A change record for one finding at each organisation, with owner, review and expiry
Nordvik Region and Hansa Mutual: Nordvik Region sends a finding to its managed provider through annex MS-1 and tracks the response; Hansa Mutual's detection-engineering team of four drafts changes with an AI assistant and a finding-to-control median of 19 days.
Usage modes and degrees of delegation: Modes 1 to 3 draft changes under the engineer's identity; a Mode 4 drafting agent works at Level 1 or 2; a change never reaches production without a named reviewer.
Observable, expected, speculation: AI-drafted detections are observable; AI-drafted controls reviewed by AI are expected under independence rules; autonomous change to production controls is speculation.
Figure: A finding routed to detection, control, playbook or mandate, each with owner, review and the regression case it hands to P5

Chapter 11: Verify: Re-test, Regression and Evidence

File: 11_verify.md
Status: draft
Purpose: Define closure: the re-test, the regression case REG-* with variants, the evidence manifest EVD-*, signed and versioned (Architecture as Code, Chapter 15A). Why a re-test of the exact scenario is not enough (variants); evidence expiry and re-validation cadence; the ratchet that keeps a closed finding closed; reporting an implemented-but-unverified control as open. This is P5 Verify.
Builds on: F4, F20, F59, F60, F62, F68, Architecture as Code, Chapter 15A, AI Red Team, Chapter 26
Purple loop stages: P5 Verify
Sections: The closure rule; Designing the re-test; Variants; Regression suites in the pipeline; Evidence as code; Expiry; Reporting
Practical guides: Turning a closed finding into a regression case with variants and a cadence
Worked examples: A REG-* case and an EVD-* manifest as code for one finding
Nordvik Region and Hansa Mutual: Nordvik Region requires the managed provider to pass an injected test before it reports a finding closed; Hansa Mutual finds that 25 of 34 priority techniques are verified and the rest are implemented but not verified (BTP-HM-2027-Q3).
Usage modes and degrees of delegation: Modes 4 and 5 may run re-tests at Level 3; a person signs closure; a re-test run by the same agent that drafted the fix is not independent (Chapter 15).
Observable, expected, speculation: Regression and evidence as code are observable practice; supervisor acceptance of automated evidence is expected; evidence that never expires is not credible.
Figure: A finding from change through re-test, variants and signed evidence to closure, with the expiry clock

Part III: The Loop Meets AI Systems

Chapter 12: Purple for AI Systems and Agents: Attacks on Models and Detections That Catch Them

File: 12_purple_for_ai_systems_and_agents.md
Status: draft
Purpose: Apply the loop to the organisation's own AI. AI Red Team, Chapter 13, and AI Platform and Security, Chapters 16, 17 and 20, cover testing and securing AI systems; this chapter adds the detection and response side: telemetry from the AI gateway and agent runtime, detections for tool misuse, anomalous retrieval and permission-ceiling breaches, and the loop that turns an AI red-teaming finding into a detection and a regression case. Technique by ATLAS identifier; no injection strings. Covers P1 to P5.
Builds on: F39, F40, F43, F44, F54, F37, F45, AI Red Team, Chapter 13, AI Platform and Security, Chapters 16 and 20
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: AI systems as targets in the loop; Telemetry from the platform; Detection for agents; From AI red-teaming finding to detection; Evaluation versus detection; The compound system
Practical guides: Writing a detection record for an agent that exceeds its permission ceiling
Worked examples: A DET-NR-* record for the citizen-service assistant and a DET-HM-* record for the claims-triage agent
Nordvik Region and Hansa Mutual: Nordvik Region's citizen-service assistant and benefits-triage service are first tested in RoE-NR-2027-001; Hansa Mutual's claims-triage agent and IT-operations agent feed telemetry into the group SOC.
Usage modes and degrees of delegation: Modes 1 to 3 are a person's identity and so are detected as the person; Mode 4 and Mode 5 systems have their own identities and need their own baselines and ceilings.
Observable, expected, speculation: Attacks on deployed AI systems are observable; detection engineering for agents is expected; claims of complete coverage for AI threats are speculation.
Figure: An AI system with its platform telemetry, the detections that read it and the path from an AI red-teaming finding back into the regression suite

Chapter 13: Testing the Defenders' AI: SOC Agents, Playbooks and Providers' AI under Emulation

File: 13_testing_the_defenders_ai.md
Status: draft
Purpose: Use the loop to test the blue team's own AI: investigation, triage and drafting agents, playbooks, stop paths and the provider's AI that closes alerts. Emulation as the source of seeded incidents and hostile inputs (AI Blue, Chapters 14 and 15), the closure rule for agent findings, and injected tests written into managed-service contracts (annexes MS-1 and MS-2). Covers P2 to P5.
Builds on: F49, F52, F57, F67, F76, F68, AI Blue, Chapter 14, AI Blue, Chapter 15, AI Blue, Chapter 16
Purple loop stages: P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: What to test in a defender's AI; Seeded incidents from emulation; Testing the stop path; Testing a provider's AI through the contract; Findings against agents and mandates; Limits of testing in production
Practical guides: Writing an injected-test clause for a managed-service contract
Worked examples: An injected-test schedule and a seeded-incident register for each organisation
Nordvik Region and Hansa Mutual: Nordvik Region runs a quarterly injected test against its managed provider's AI under annex MS-1; Hansa Mutual feeds seeded incidents to its investigation agent and tests HM-SEC-001.
Usage modes and degrees of delegation: The tested systems are Mode 4 and Mode 5; an agent's delegation level is lowered after a failed test and restored only on re-test.
Observable, expected, speculation: Seeded-incident testing of SOC AI is observable at leading teams; contractual injected tests are expected to spread; fully automated attestation of provider AI is speculation.
Figure: A SOC agent and a provider's AI under test: seeded incident in, observed behaviour and stop path out, finding and re-test back into the loop

Part IV: The Loop's Own AI

Chapter 14: An AI Agent Team for the Loop: Skills, Mandates and Containment

File: 14_an_ai_agent_team_for_the_loop.md
Status: draft
Purpose: Decide which loop functions may be given to agents and at what level: scenario curator, emulation planner, emulation runner, observation correlator, detection drafter, finding triager, re-test runner, critic. Mandate manifests MND-*-EMU-*, delegation profiles, containment and identity for an agent that holds offensive capability. A brief section on the practitioner's own use of AI in Modes 1 to 3 refers to AI Blue, Chapter 12, and The Transformed Security Architect, Chapter 12, without repeating them.
Builds on: F27, F45, F49, F50, F51, F73, F75, AI Blue, Chapter 12, AI Blue, Chapter 13, The Transformed Security Architect, Chapter 12
Purple loop stages: P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: Candidate functions; Delegation per stage; Mandates and permission ceilings; Identity and credentials; Containment; The practitioner's own use of AI; Budgets and stop
Practical guides: Writing a mandate manifest for an emulation runner
Worked examples: A MND-HM-EMU-* manifest and a Nordvik delegation profile as code
Nordvik Region and Hansa Mutual: Nordvik Region delegates only the critic and the correlator to AI and keeps the rest with its contracted tester; Hansa Mutual delegates eight loop functions at different levels and records them as delegation profiles.
Usage modes and degrees of delegation: The chapter is the book's delegation table: functions by stage, usage mode and level, with Level 4 never for irreversible, out-of-scope or person-targeting emulation.
Observable, expected, speculation: Agent teams in testing are observable; agent teams with mandates and ceilings are expected; self-expanding mandates are speculation and prohibited by design.
Figure: An agent team for the loop with each function's identity, permission ceiling and stop path

Chapter 15: Independence: Verifying the Loop When AI Is on Both Sides

File: 15_independence.md
Status: draft
Purpose: State the book's central design rule. Where tester and tested share a model family, training data, prompts or vendor, errors correlate and coverage reports are inflated. Evaluation awareness and test-aware behaviour (AI Threat, Chapter 23); leakage of scenarios into detections; critic agents on a second model family; human-authored novelty; seeded errors and seeded gaps; held-out scenario sets; reproducibility. Stage the debate: can the loop be closed by machines alone?
Builds on: F62, F66, F68, F76, F28, F84, AI Threat, Chapter 23, The Transformed Security Architect, Chapter 14
Purple loop stages: P3 Observe; P4 Improve; P5 Verify
Sections: Correlated failure; Kinds of independence; Held-out scenarios; Seeded gaps; Test-aware behaviour; Reproduction by a person; The debate; Verdict; An independence checklist
Constructive debate: Concern: A loop closed by machines checks the machines against themselves: shared blind spots stay hidden, scenarios leak into detections, and a model that behaves differently under test passes the test and fails in the world. Calm: Machines can run far more checks than people, a second model family and held-out sets already break much correlation, and human review of every result is neither affordable nor better than well-designed automation. Where they meet: Both accept that independence is a property that must be designed and shown, that people must be able to reproduce a result, and that human-authored novelty must stay in the loop. What can be done: Require a second model family, held-out scenarios, seeded gaps and reproduction by a person for any claim of coverage; disclose vendor and model dependencies; report independence with the coverage.
Practical guides: Running an independence review of a loop and producing a one-page statement for a supervisor
Worked examples: An independence checklist applied to Hansa Mutual's pipeline and to Nordvik's provider annex
Nordvik Region and Hansa Mutual: Nordvik Region asks whether its managed provider's AI and the tester's AI share a model family; Hansa Mutual finds that its emulation agent and its detection drafter use the same vendor.
Usage modes and degrees of delegation: Independence requirements rise with the delegation level; Level 3 loops need a second model family and a human-authored held-out set; Mode 0 vendor AI must be disclosed.
Observable, expected, speculation: Correlated failures and evaluation awareness are observable; independence requirements in supervisory practice are expected; guaranteed independence between frontier models is speculation.
Figure: Tester and tested sharing model family, data and vendor, with the independence controls that break each shared dependency

Chapter 16: Defending the Loop's AI: Scenario Libraries, Findings and Emulation Agents as Tier 0

File: 16_defending_the_loops_ai.md
Status: draft
Purpose: Treat the loop's own assets as the adversary's best map: the findings register lists unfixed weaknesses; the scenario library describes what is not detected; emulation agents hold offensive capability and privileged access. Classification and access control, segregation of the findings store, supply chain of scenario content and tools, data handling when findings are sent to hosted models, misuse and insider scenarios, and containment that does not depend on intent (AI Platform and Security, Chapter 19).
Builds on: F27, F34, F39, F45, F47, F54, F56, AI Platform and Security, Chapter 19, AI Blue, Chapter 15
Purple loop stages: P1 Target; P3 Observe; P4 Improve
Sections: What the loop holds; The findings register as a crown jewel; The emulation agent as a privileged insider; Supply chain of scenarios and tools; Handling of findings in AI tools; Detection of misuse; Evidence
Practical guides: Classifying and segregating a findings register
Worked examples: A classification policy and an access policy as code for each organisation's findings store
Nordvik Region and Hansa Mutual: Nordvik Region keeps findings in the provider's ticket system and decides to hold its own copy in the Region's tenant; Hansa Mutual segregates the findings store and restricts hosted models to redacted summaries.
Usage modes and degrees of delegation: Modes 1 to 3 inherit the person's access to the register; Mode 4 and Mode 5 loop agents need their own least-privilege identities and no standing access to open findings.
Observable, expected, speculation: Theft or leakage of findings is observable in incident reports of testing firms; agent-specific misuse is expected; autonomous misuse by loop agents is speculation.
Figure: The loop's assets, findings, scenarios, plans and agent credentials, as a tier-0 set with segregation and detection around it

Part V: The Loop in the Organisation

Chapter 17: Coverage as a Claim: Technique Maps, Evidence Age and Detection Decay

File: 17_coverage_as_a_claim.md
Status: draft
Purpose: Define what 'covered' means. A coverage record COV-* per technique and environment states what was tested, when, how and with what outcome, and when the evidence expires. Distinguish prevented, detected and merely logged; distinguish tested from asserted; describe decay of detections with change, dashboards that hide age, and how a CSF profile kept as code (AI Red Team, Chapter 3) draws on coverage. This is P3 Observe and P5 Verify.
Builds on: F4, F20, F59, F62, F64, F65, AI Red Team, Chapter 3, AI Blue, Chapter 6
Purple loop stages: P3 Observe; P5 Verify
Sections: From heat map to evidence; The coverage record; Evidence age and expiry; Decay; Environments and variants; Honest 'not tested'; Reporting
Practical guides: Replacing a technique heat map with coverage records that carry age and expiry
Worked examples: A COV-HM-* record and a Nordvik coverage page
Nordvik Region and Hansa Mutual: Hansa Mutual converts its 34-technique heat map into coverage records and finds that nine have expired evidence; Nordvik Region reports nine techniques with three states: tested, asserted by the provider and not tested.
Usage modes and degrees of delegation: Assistants (Modes 1 to 3) help compile records; a coverage agent (Mode 4) may propose status at Level 2; only a person declares a technique covered.
Observable, expected, speculation: Evidence age and decay are observable; coverage-as-code is expected; continuous coverage without expiry is speculation.
Figure: A technique-by-environment coverage record with last-tested date, outcome, evidence reference and expiry shading

Chapter 18: Measuring the Loop: Cycle Time, Yield, Re-test Pass Rate and the Metrics That Mislead

File: 18_measuring_the_loop.md
Status: draft
Purpose: Define measures of the loop, not of people: finding-to-control cycle time, finding half-life, re-test pass rate, share of priority techniques verified within their expiry, yield per exercise, detection debt. Metrics that mislead (number of scenarios run, number of findings, green percentages); Goodhart and gaming; measuring without monitoring individuals (AI Boss, Chapters 13 and 23); what the board needs.
Builds on: F20, F60, F62, F66, F82, F85, F86, F89, AI Boss, Chapters 13 and 23, AI Blue, Chapter 20
Purple loop stages: P3 Observe; P4 Improve; P5 Verify
Sections: What to measure; What to avoid; Leading and lagging measures; AI-specific measures; Aggregation and works-council constraints; The board page
Practical guides: Designing a board page for the loop that cannot be improved by running more scenarios
Worked examples: BTP-HM-2027-Q3 and Nordvik's four-measure page as records
Nordvik Region and Hansa Mutual: Hansa Mutual's BTP-HM-2027-Q3 shows 25 of 34 techniques verified and a median of 19 days from finding to control; Nordvik Region's four-measure page shows verified share, cycle time, provider closure rate and evidence age.
Usage modes and degrees of delegation: Measures that include AI-run work separate what the agent did from what a person verified; individual-level data from Modes 1 to 3 assistants is not collected for the loop's measures.
Observable, expected, speculation: Goodhart effects are observable; measuring yield rather than activity is expected; fully automated board reporting without review is speculation.
Figure: Loop measures arranged by stage, with the misleading measures crossed out and the board page drawn from the others

Chapter 19: Operating Models and Team Design: In-House, Contracted, Hybrid and Sovereign Loops

File: 19_operating_models_and_team_design.md
Status: draft
Purpose: Show who runs the loop: an in-house red team and detection-engineering team (Hansa Mutual), a contracted tester and a provider (Nordvik Region), a shared sector capability, a vendor's automated service. The roles (purple coordinator, emulation engineer, detection engineer, exercise controller, white team) and role charters ROLE-*; where the loop sits in the organisation; sovereignty of test data and findings; procurement of testing and simulation tools.
Builds on: F9, F10, F22, F24, F47, F73, F78, AI Blue, Chapter 16, AI Blue, Chapter 17
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: Four operating models; Roles and charters; The purple coordinator; Independence between roles; Sovereignty and findings; Procurement; Small teams
Practical guides: Choosing an operating model with a decision record and exit criteria
Worked examples: Role charters for a purple coordinator and an exercise controller
Nordvik Region and Hansa Mutual: Nordvik Region buys the loop and its leverage is the contract; Hansa Mutual runs it and its leverage is the pipeline.
Usage modes and degrees of delegation: Roles differ by mode: in Modes 1 to 3 AI extends a person; in Modes 4 and 5 the role includes accountability for an agent.
Observable, expected, speculation: The four models are observable; hybrid and sector models are expected to grow; a fully vendor-run loop is speculation for regulated entities.
Figure: Four operating models for the loop against the roles each requires and where findings and data are held

Chapter 20: Decision Rights, Authorisation and the White Team

File: 20_decision_rights_and_the_white_team.md
Status: draft
Purpose: Define who may authorise an emulation, change its scope, stop it, accept a residual finding and declare a technique covered; the white team (exercise control) and the trusted agent; decision tiers and the design authority (AI Governance, Chapter 13); incidents during an exercise (an emulation that becomes a real incident, or a real incident that hides behind an exercise); the decision record DRF-* and tabletop TTX-*.
Builds on: F17, F18, F19, F63, F74, F78, F83, AI Blue, Chapter 18, AI Governance, Chapter 13
Purple loop stages: P1 Target; P2 Emulate; P4 Improve; P5 Verify
Sections: Decisions for the loop; Authorisation; Stopping; Acceptance of risk; Real incident during an exercise; Records and tabletop
Practical guides: Writing decision rights for the loop and testing them in a tabletop
Worked examples: A DRF-* table and a TTX-* record for an emulation that becomes an incident
Nordvik Region and Hansa Mutual: Nordvik Region names its CISO as authorising authority and its contracted tester's white-team lead as the stop holder; Hansa Mutual names its group CISO and a white-team lead with stop authority outside the red team.
Usage modes and degrees of delegation: Decision rights do not shift with the mode, but the speed of the stop does: a Mode 5 emulation agent needs a stop in seconds, not at the next forum.
Observable, expected, speculation: Decision rights as records are observable; machine-readable authorisation is expected.
Figure: A decision table for the loop showing authority, stop holder, risk acceptor and the white team's position

File: 21_regulation_as_constraint.md
Status: draft
Purpose: Set out the legal frame for emulation, attributed to instrument and article and framed as architectural implication (every article number to be verified against the live text at eur-lex.europa.eu): DORA testing, including threat-led penetration testing and its tester and provider requirements; supervisory frameworks such as TIBER-EU and national variants; NIS 2 Article 21 effectiveness assessment and Article 20; the AI Act Articles 15 and 55 for adversarial testing; the Cyber Resilience Act's vulnerability handling; GDPR where an exercise touches personal data; criminal-law and computer-misuse exposure of testers; co-determination and consultation for exercises that involve staff.
Builds on: F31, F46, F78, F85, F86, F29, AI Blue, Chapter 19, AI Boss, Chapters 21 to 24
Purple loop stages: P1 Target; P2 Emulate
Sections: DORA and threat-led penetration testing; Supervisory frameworks; NIS 2; The AI Act; The Cyber Resilience Act; The GDPR and exercise data; Staff and representatives; Criminal-law exposure and authorisation; Design consequences
Practical guides: Mapping a legal obligation to a loop control and its evidence
Worked examples: An obligation-to-control table for the loop in each organisation
Nordvik Region and Hansa Mutual: Nordvik Region meets its works council before the first exercise that involves staff; Hansa Mutual aligns its continuous testing with the DORA threat-led test under TIBER-DE (illustrative) and two works agreements.
Usage modes and degrees of delegation: Obligations attach to the use, not the mode; Modes 4 and 5 add AI Act duties for the provider or deployer of the tooling.
Observable, expected, speculation: Current text of instruments is observable; supervisory acceptance of continuous testing as evidence is expected; harmonised treatment across Member States is speculation.
Figure: Instruments in a ring around the loop, each attached to the stage it constrains

Chapter 22: Across Boundaries: Suppliers, Managed Providers, Sector Exercises and Authorities

File: 22_across_boundaries.md
Status: draft
Purpose: Treat loops that cross organisational boundaries: testing through a managed detection provider and cloud providers (consent, shared responsibility, notice); sector-wide and cross-border exercises; sharing findings and detections with peers and CSIRTs without exposing weaknesses; vulnerability disclosure in both directions; supervisors as recipients of evidence; public authorities and multinationals.
Builds on: F28, F30, F47, F57, F78, AI Blue, Chapter 16, AI Blue, Chapter 19
Purple loop stages: P2 Emulate; P3 Observe; P4 Improve
Sections: Testing through a provider; Consent and shared responsibility; Sector exercises; Sharing without exposing; Disclosure; Cross-border; Evidence to supervisors
Practical guides: Writing a consent and notice protocol for a test that crosses a provider boundary
Worked examples: A provider annex clause and a sector-sharing protocol
Nordvik Region and Hansa Mutual: Nordvik Region needs its managed provider's consent for every test of the out-of-hours chain; Hansa Mutual shares detections with a sector group under a sharing protocol and handles seven regimes.
Usage modes and degrees of delegation: Vendor AI in a provider's service (Mode 0 or Mode 4) must be disclosed and testable; sharing agents (Mode 4) work at Level 1 or 2.
Observable, expected, speculation: Sector exercises and provider testing clauses are observable; standardised injected tests in contracts are expected.
Figure: Organisation, provider, cloud and sector loops with consent, notice and sharing paths marked

Part VI: People and Career

Chapter 23: Red and Blue as People: Trust, Incentives, Safety and Wellbeing

File: 23_red_and_blue_as_people.md
Status: draft
Purpose: Describe the human side of an adversarial practice: incentives that pit red against blue ('red wins when blue loses'), the conditions for a blameless purple session, psychological safety, the pressure of exercises and of being tested, the effect of automation on the sense of craft and of being watched; apply AI Boss (Chapters 13, 14 and 26) to people on both sides. Describe effects by what studies measured; never call anyone lazy, stupid or replaceable.
Builds on: F53, F66, F69, F81, F84, F86, F89, AI Boss, Chapters 13, 14 and 26, AI Blue, Chapter 21
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: Incentives; Trust and blamelessness; Being tested; Wellbeing and load; Staff exposed to exercises; The purple coordinator as translator
Practical guides: Setting ground rules for a blameless purple session
Worked examples: A purple session charter and an exercise-information notice for staff
Nordvik Region and Hansa Mutual: Nordvik Region's six analysts work with a contracted tester for the first time and agree session rules in writing; Hansa Mutual's red team and detection engineers share one target on a joint scorecard.
Usage modes and degrees of delegation: AI changes what people are measured by: assistants (Modes 1 to 3) can make individual traces visible, so what is recorded and who sees it must be decided.
Observable, expected, speculation: Studies on stress and trust in security teams are observable and limited; AI effects on the sense of craft are expected; claims about long-term identity are speculation.
Figure: Red and blue incentives, the shared target and the purple coordinator as the link, with the safety conditions for a blameless session

Chapter 24: Competences, Training and Keeping the Red Craft

File: 24_competences_and_keeping_the_red_craft.md
Status: draft
Purpose: Define competences for the loop (scenario design, emulation engineering, detection engineering, observation and analysis, exercise control, evidence), competence records CMP-* and learning paths. Face the apprenticeship problem on the red side: if AI does the routine emulation, where do new red operators and detection engineers come from? Stage the debate: does automated emulation erode the craft of the adversary's mind?
Builds on: F11, F25, F26, F53, F66, F69, F77, F79, AI Blue, Chapters 22 and 23
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: A competence framework; Learning paths; The red apprenticeship; Exercises as training; The debate; Verdict; Hiring and contracted testers
Constructive debate: Concern: If AI does the routine emulation and routine detection work, the junior work through which people learned the adversary's mind disappears, and the loop will one day have no one who can think like an adversary. Calm: Routine was never the craft; AI frees time for design, new techniques and judgement, and the best operators learned from exercises and mentoring rather than from repetition. Where they meet: Both agree that skills erode without practice, that routes into the craft must be built on purpose, and that some work must stay human. What can be done: Protect a share of unassisted, novel emulation, build explicit apprenticeships, record competence, and use contracted testers to bring in skills the team lacks.
Practical guides: Designing an apprenticeship route that survives automation of routine emulation
Worked examples: A CMP-* record for a purple coordinator and a learning path
Nordvik Region and Hansa Mutual: Nordvik Region has no red apprenticeship and relies on its contracted tester; Hansa Mutual's red team of five protects a share of each quarter for unassisted emulation.
Usage modes and degrees of delegation: Unassisted practice is set per mode: Modes 1 to 3 need practice without the assistant; Modes 4 and 5 need practice in the degraded mode after a stop.
Observable, expected, speculation: Skill erosion with AI reliance is observable; apprenticeship redesign is expected; the end of human adversary emulation is speculation.
Figure: A learning path from analyst to emulation engineer and back, with the unassisted-practice checkpoints

Chapter 25: The Future of the Loop: Will Red and Blue Be Separate Teams in 2036?

File: 25_the_future_of_the_loop.md
Status: draft
Purpose: Give the outlook under the three labels. Possible futures: autonomous purple pipelines; convergence of red, blue and detection engineering into one engineering function; regulation tightening continuous testing; adversary AI that tests defences continuously; collapse of the independence assumption. Stage the debate: will red and blue be separate teams in 2036? Collect the author's own projections here and in Chapter 29.
Builds on: F32, F33, F69, F70, F71, F80, F87, AI Blue, Chapter 24, AI Threat, Chapter 34
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: What is observable; What is expected; What is speculation; The case for convergence; The case for separation; Where the positions meet; What to do now; Verdict
Constructive debate: Concern: If red, blue and detection engineering converge, the independence that makes tests worth anything disappears, and with it the supervisor's reason to believe a result. Calm: Separation was an accident of scarcity; one engineering practice with strong reviews and independent verification can be better than two teams that share a quarterly meeting. Where they meet: Both agree that independence must exist somewhere, whether between teams, models or people, and be shown. What can be done: Decide where independence lives, record it, test it, and keep the choice reversible.
Practical guides: Keeping a horizon register for the loop with owners and review dates
Worked examples: A horizon register for each organisation
Nordvik Region and Hansa Mutual: Nordvik Region plans for a single detection-and-emulation engineering role; Hansa Mutual keeps red and blue separate and adds a purple coordinator.
Usage modes and degrees of delegation: Futures differ by mode: Mode 4 and Mode 5 pipelines shift the question from who runs the test to who verifies it.
Observable, expected, speculation: Every statement carries a label; the author's own projections are collected here and in Chapter 29.
Figure: Three futures for the loop in 2036 on a timeline, each tagged observable, expected or speculation

Part VII: Experience and Conclusions

Chapter 26: Case Studies and Anti-Patterns

File: 26_case_studies_and_anti_patterns.md
Status: draft
Purpose: Collect composite and published cases and anti-patterns: purple theatre (sessions with no re-test), the red team that grades its own homework, coverage by assertion, the green dashboard, overfitted detections, the emulation that became an incident, the findings register that leaked, and the contract with no testing right. Anti-pattern records AP-*.
Builds on: F28, F62, F66, F67, F69, AI Blue, Chapter 25
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: Purple theatre; The red team that grades its own homework; Coverage by assertion; The green dashboard; Overfitted detections; The emulation that became an incident; The findings register that leaked; The contract with no testing right
Practical guides: Recognising the early signs of each anti-pattern in a loop review
Worked examples: AP-* records with signs, cause and remedy
Nordvik Region and Hansa Mutual: Nordvik Region recognises a contract without a testing right; Hansa Mutual recognises overfitted detections.
Usage modes and degrees of delegation: Each anti-pattern is shown at the modes where it is most likely.
Observable, expected, speculation: Cases are observable or composite and labelled; no anti-pattern is predicted beyond the evidence.
Figure: Eight anti-patterns placed on the loop where each breaks it

Chapter 27: A Year in the Loop: Nordvik Region and Hansa Mutual

File: 27_a_year_in_the_loop.md
Status: draft
Purpose: Give a narrative year for four named people (Nordvik's detection owner Karin Lund and the contracted tester; Hansa Mutual's detection-engineering lead Lena Vogel and the red-team lead), following the scenario, the exercise, the finding, the change and the re-test, including a failure and a recovery.
Builds on: F66, F67, F69, F81, AI Blue, Chapter 26
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: May to December 2027: the background; The starting position in January 2028; January to April 2028; The reports of 2028-04-30; What the year shows
Practical guides: Using the year as a template for an own annual calendar for the loop
Worked examples: An annual loop calendar for each organisation
Nordvik Region and Hansa Mutual: Karin Lund and the contracted tester at Nordvik Region; Lena Vogel and the red-team lead at Hansa Mutual.
Usage modes and degrees of delegation: The year is told with the delegation level of each stage on each date.
Observable, expected, speculation: The year is illustrative and labelled so.
Figure: A twelve-month timeline for each organisation with the stages, the exercise, the failure and the re-test

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

File: 28_conclusions_for_nordvik_and_hansa.md
Status: draft
Purpose: Draw a conclusion for each organisation and a comparison, with the plan for the next two years as a decision record (AIDR-0849 and AIDR-0899).
Builds on: F70, F78, AI Blue, Chapter 27
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: Nordvik Region; Hansa Mutual; A comparison; The next two years
Practical guides: Writing a two-year loop plan as a decision record
Worked examples: AIDR-0849 and AIDR-0899
Nordvik Region and Hansa Mutual: Nordvik's risk is a loop that never starts; Hansa's is a loop that runs without anyone questioning it.
Usage modes and degrees of delegation: The plans set target delegation levels per stage.
Observable, expected, speculation: Plans are the author's projections for illustrative organisations and are labelled so.
Figure: Two organisations' loop maturity today and in two years

Chapter 29: Conclusions: The Purple Loop with AI

File: 29_conclusion.md
Status: draft
Purpose: Give the author's verdict on the five-part thesis, the independence principle and the questions the book leaves open; the author's own projections, labelled.
Builds on: F70, F71, F80, F91
Purple loop stages: P1 Target; P2 Emulate; P3 Observe; P4 Improve; P5 Verify
Sections: The five-part thesis judged; The independence principle; Open questions; The author's projections; What to do on Monday
Practical guides: A first-week plan for a loop
Worked examples: A one-page loop charter
Nordvik Region and Hansa Mutual: Both organisations are revisited at the end of the plan.
Usage modes and degrees of delegation: The verdict states the delegation ceilings the author recommends.
Observable, expected, speculation: The author's projections are labelled as such.
Figure: The five stages with the verdict on each part of the thesis

Appendices

30_glossary.md: Defines the vocabulary of the purple loop and AI: the five stages (P1 Target to P5 Verify), the degrees of delegation and usage modes, the book's artefacts (scenario, emulation plan, rules of engagement, finding, coverage record, purple session record, regression case, evidence manifest, mandate manifest, role charter), red, blue, white and purple team, and the terms of DORA, NIS 2, the Cyber Resilience Act, the GDPR and the AI Act that bear on emulation.
31_appendix_a_code_examples.md: Appendix A: complete versions of the artefacts in the chapters: scenario record, rules-of-engagement manifest, emulation plan, coverage record, purple session record, regression case, evidence manifest, mandate manifest for an emulation agent, delegation profile and loop charter. No attack tooling.
appendix_templates_and_tools.md: Appendix B: templates and tools: purple session agenda, scenario template, independence checklist, coverage-record template and exercise decision rights.
32_references.md: The only bibliography of the book: European instruments on cybersecurity, resilience, data protection and AI, frameworks and taxonomies, threat assessments, published purple-teaming and simulation literature and the earlier volumes of the series. Only verified sources are listed.
33_about_the_author.md: About the author of The Transformed Architecture, placed at the very end of the book.