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

Part I has asked what the loop between the red team and the blue team did before AI joined it (Chapter 2) and why its traditional rhythm no longer fits (Chapter 3). This chapter defines the loop the rest of the book uses. It fixes five stages, the record each produces, the rule by which a finding is closed, the ceiling of delegation to AI at each stage, the independence principle that governs every check with AI on both sides, and the roles that hold the loop. Two definitions in this chapter are used unchanged by every later chapter: the closure rule (a person signs every closure) and the independence principle (five kinds of separation, one rule between roles, three proofs). It concerns all five stages by name: P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify. Parts II to V take the stages one by one; this chapter is the definition they refer back to.

The definition is the book's own design. It builds on observable practice: the five record states of AI Red Team, Chapter 26, the blue team's half of the loop in AI Blue, Chapter 11, and the threat-led testing frameworks of European supervisors. The ceilings of delegation are the book's own recommendation, and the chapter says so where it makes them.

Figure 4.1: The purple loop: five stages, the verified closure, and the stop path and independence that sit outside any stage.

Why a loop

An exercise produces a report. A report records that a technique was tried, what the defence saw and what it did not. A report is also the point at which most exercises end: the testers leave, the findings enter a backlog, and the next evidence about whether anything changed arrives a year later, from the next test. The earlier volumes made the same observation from two sides. AI Red Team, Chapter 26, distinguished a debrief from a loop by a fixed sequence of states and one exit condition (90, Nordqvist, 2026). AI Blue, Chapter 11, put the same point as a difference between a report, which records that a technique was missed, and a loop, which leaves behind a test that it will not be missed again and the date on which that was last shown (94, Nordqvist, 2026).

A loop does three things an event cannot. It carries a finding to a change and the change to a proof, so that the unit of work is the verified control and not the report. It makes the age of every claim visible, because each record carries the date of the test that supports it. And it gives the practice a rhythm independent of the calendar: a change to a detection, a connector or a mandate can trigger a re-test the same day, where an annual test can only wait for its slot. Chapter 3 argued that estates change faster than tests, that detections decay and that the supply of skilled red-team hours is scarce. A loop is the structure that makes cheaper variation and repetition useful, because it gives them somewhere to land.

The loop is also the answer to a question that supervisors and boards ask in different words: would we have seen and stopped this, and how do we know? NIS 2 Article 21 requires essential and important entities to take cybersecurity risk-management measures, which include policies and procedures to assess their effectiveness (Article 21(2), point (f)); Article 20 places the approval and oversight of the measures on the management body (3, European Union, 2022). DORA Article 5(2) requires the management body of a financial entity to define, approve, oversee and be responsible for the arrangements of the ICT risk management framework (2, European Union, 2022). The architectural implication, which is not legal advice, is that effectiveness has to be shown by something other than assertion. A loop that closes on a re-test and keeps its evidence is a way to show it.

The five stages

The stages are named exactly so in every chapter of the book. They are distinct from the Functions of NIST CSF 2.0 (24, NIST, 2024), from the five blue team functions of AI Blue and from the five management functions of AI Boss. Each stage answers one question and ends in one kind of record.

P1 Target chooses what the loop will test. The question is which adversary behaviour matters most to this organisation, and it is answered from intelligence, the threat register, risk assessment and incidents, expressed in the vocabulary of MITRE ATT&CK and, for AI systems, MITRE ATLAS (17, MITRE, n.d.) (18, MITRE, n.d.). P1 produces a scenario record: the technique set, its source, the expected outcome per layer (prevention, telemetry, detection, alert, triage, action), a safety class and an owner. P1 also covers the rules under which scenarios may run, which Chapter 6 treats as the signed rules-of-engagement manifest. The selection is the stage's weak point: a team tends to test what is easy to emulate, and AI makes the easy cheaper. Chapter 5 treats the countermeasure.

P2 Emulate executes the scenario. It may be human-led, AI-assisted or continuous, and in every form it runs inside the signed scope, under a stop path held outside the emulating system. P2 produces an emulation plan, which names the scenarios, their sequence, the target scope, the window and the abort conditions, and the log of what was done, tagged so that it can be told from real activity. Because P2 is the stage that touches the estate, it carries the rule that recurs through the book: say what can be undone and who can stop it. In this chapter's definition, reversibility is a property of the scenario's safety class (a benign, tagged, reversible scenario is not the same object as one that changes production state), and the stop holders are people named in the manifest who can revoke the emulation identity at a point the emulating system does not control. Chapters 6, 7 and 8 treat P2 in three forms.

P3 Observe compares what happened with what was expected. The expectation is written before the run, which is what turns an exercise into a measurement. The outcome is read layer by layer and classified: prevented, detected, alerted but not triaged, triaged but not acted on, missed, no telemetry or not tested. P3 produces a finding where the outcome falls short of the expectation, and a purple session record where red and blue read the result together. The finding is the first record that belongs to the blue team's world as well as the red team's, and Chapter 9 treats its quality.

P4 Improve turns a finding into the right change. The change may be a detection (AI Blue, Chapter 6), a control, a playbook (AI Blue, Chapter 10) or an agent mandate (AI Blue, Chapter 13), or an explicit decision that no change is justified, taken by a person with authority to accept the residual risk. P4 produces a change record and, where it applies, the detection, playbook or mandate it changed, each with its own test. P4 is where most AI-drafted work in the loop appears, and where the verification discipline of The Transformed Security Architect, Chapter 14, applies: the reviewer must be able to check a draft without starting from the draft's own account of itself (92, Nordqvist, 2026). Chapter 10 treats the stage.

P5 Verify proves the change. The scenario that produced the finding runs again, together with at least one variant of it, and the result is stored with the change, the telemetry references and the reviewer's confirmation. P5 produces a regression case, which turns the closed finding into a repeatable test with a cadence, and an evidence manifest, which is signed and versioned in line with Architecture as Code (Chapter 15A) (87, Nordqvist, 2025). Chapter 11 treats the stage, including why a re-test of the exact scenario is not enough.

The loop is a cycle in the diagram because a closed finding does not leave. Its regression case joins the scenario library and is run again when the estate changes or the evidence expires. That return path is the difference between a loop and a sequence.

The records

The stages are defined by their records, not by their meetings. Each record is a file in a repository with an owner, a date and a state, in the manner of Architecture as Code (Chapter 9C), where findings return as pull requests (87, Nordqvist, 2025). The table lists the chain.

Stage	Record	Identifier	Written by	Accepted by	State in AI Red Team, Chapter 26
P1 Target	Scenario record	SCN-NR-*, SCN-HM-*	Scenario owner; AI may draft	Named owner of the library	Not covered (the loop began at the finding)
P2 Emulate	Emulation plan and run log, bounded by RoE-*	EMU-*	Red-team operator or contracted tester	White team	Not covered
P3 Observe	Finding; purple session record	FND-*; PRP-*	Red and blue jointly	Finding owner on the side that must change	Finding
P4 Improve	Change record; detection, playbook or mandate	CHG-*; DET-*, PBK-*, MND-*	Detection engineer, playbook owner, agent operator; AI may draft	The owner of the artefact, after review	Control; Detection
P5 Verify	Regression case; evidence manifest	REG-*; EVD-*	Re-test runner; reviewer	The person accountable for closure	Re-test; Evidence

Two observations follow from the table. First, the loop of AI Red Team began with a finding. This book adds two stages in front of it, because the quality of a finding depends on what was chosen and how it was run: a finding from a scenario chosen because it was easy, or from a run that left no tagged log, cannot be read with confidence. Second, the table maps cleanly onto the blue team's own artefacts. P3 to P5 are the exercise-driven half of B5 Learn in AI Blue, P4 changes the artefacts of B2 Detect and B4 Respond, and P1 draws on the intelligence of B1 Anticipate. The purple loop is therefore not a parallel process to the blue team's functions; it is the route by which an adversary's behaviour reaches them as a test.

The coverage record, COV-NR-* and COV-HM-*, is derived and not a stage record. It states, per technique and environment, what was tested, when, with what outcome and when the evidence expires, and it is built from the regression and evidence records. Chapter 17 treats it. No chapter of this book says that something is covered without saying what was tested, when and with what result, and the chain of records is what makes that sentence writable.

The closure rule

The rule comes from AI Red Team, Chapter 26, and AI Blue, Chapter 11, which required that the re-test passes and the evidence is attached. This book adopts it and adds two clauses: the re-test includes at least one variant, and a named person signs the closure, which carries an age (a date and the conditions under which it lapses). So a finding is closed only when the re-test and its variant pass, the evidence is attached, a named person signs and the closure is dated. Chapter 11 operates the rule. This chapter also adds a vocabulary of states, so that the rule can be audited. A finding moves through five states, and only one of them is closed.

1. Open. The finding is confirmed, has an owner and a severity, and awaits a change or a decision.
2. Implemented, unverified. A change is merged or deployed. The finding is reported as open. A remediation believed to work that did not is a familiar failure of improvement, and this state exists to make it countable.
3. Re-test failed. The re-test did not pass; the finding returns to P4 with the failed result attached.
4. Closed and verified. The re-test, including its variant, passed, the evidence manifest is signed and attached, and a named person has signed the closure with its date.
5. Risk accepted. A named authority, within the decision rights of Chapter 20, has decided not to change anything. The finding is not closed. It is reported separately, with the authority, the reason and an expiry date at which the acceptance is reviewed.

The distinction between the last two states matters to the reader of a report. A dashboard that counts both as "done" hides the difference between a defence that was shown to work and a weakness that was knowingly left. The same classification applies to every claim the loop supports. AI Threat, Chapter 30, classified controls as verified, declared or failed, and held that a control counts as a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation (91, Nordqvist, 2026). The closure rule is that classification applied to findings. A tool may run the re-test and assemble the evidence; it never signs.

Evidence expires. A closed finding is closed as of the date of its last passing re-test, and the signed closure says when it lapses; and the regression case has a cadence that returns it to the queue when the estate changes or the evidence ages. The cadences are organisational choices: Hansa Mutual's priority techniques carry evidence that expires after 90 days, and other techniques after 180 days. The default of this book is to state the cadence in the regression case itself, so that expiry is a property of the record and not a calendar reminder.

Degrees of delegation per stage

AI is present at every stage, in more than one usage mode, and the question for each is how far its work may go without a person deciding. This book uses the series' autonomy levels, applied per stage and per action class, as degrees of delegation. As AI Red Team, Chapter 6, defines them: at Level 0 Advisory the AI suggests and a person decides and acts; at Level 1 Assisted it drafts and a person reviews and executes; at Level 2 Supervised it executes after explicit approval of each action; at Level 3 Bounded it executes pre-approved, reversible actions inside a codified playbook, enforced by a policy decision point outside the model, with a person informed and able to stop it; at Level 4 Autonomous it selects and executes without per-action approval (90, Nordqvist, 2026). The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.

Four absolute limits apply in this book, and the delegation profile restates them. 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 limits cover the properties that make emulation different from defence: its actions are offensive in form, they run with credentials, and they can become an incident. Beyond the limits, the book recommends ceilings that stop below Level 4 for every stage. Those ceilings are its own recommendation, not an observed practice, and they are set from the same four properties plus the stage's exposure to input an adversary or a tested system can write.

Stage	Action class	Ceiling	Who holds the decision
P1 Target	Propose candidate scenarios from intelligence	Level 1 Assisted	Scenario owner
P1 Target	Add a technique to the priority list	Level 2 Supervised	Library owner
P2 Emulate	Run a catalogued S1 scenario (benign, tagged, reversible) in production, inside the signed scope	Level 3 Bounded	The manifest, enforced by the policy decision point; stop holders named
P2 Emulate	Run an S2 or S3 scenario, or any step that is not reversible but is not S4	Level 2 Supervised	Red-team operator, with white-team approval
P2 Emulate	Run an S4 scenario (impact, irreversible, or involving staff or third parties)	Level 0 Advisory (AI may plan; named people act)	Named operator, with white-team approval per step
P2 Emulate	Vary a scenario beyond its catalogued parameters	Level 1 Assisted	Red-team operator
P3 Observe	Correlate emulation logs with telemetry and detections (read only)	Level 3 Bounded	Finding owner reviews conclusions that matter
P3 Observe	Classify an outcome and raise a finding	Level 2 Supervised	Purple-team coordinator
P4 Improve	Draft a detection, playbook or mandate change	Level 1 Assisted	Artefact owner
P4 Improve	Merge a reviewed change	Level 2 Supervised	Artefact owner
P5 Verify	Run a codified re-test and its variant, and record the result	Level 3 Bounded	The regression case, enforced outside the runner
P5 Verify	Declare a finding closed and verified	Person; no delegation. The runner proposes, the closure owner signs	The person accountable for closure

The safety classes S1 to S4 are defined in Chapter 6. Three rules read the table. The lowest ceiling governs: where an action has several properties, the strictest applies, so a step that is reversible but leaves the signed scope is not delegated at Level 3. Any action not listed is undelegated and waits for a person. And lowering a level is immediate, whereas raising one is a decision by a named authority, recorded in an AI Decision Record, with a first review 90 days after the increase. These are the rules of the delegation profile in AI Blue, Chapter 4, applied to the loop (94, Nordqvist, 2026). A person is named for every row, because accountability does not pass to a tool: NIS 2 Article 20 and DORA Article 5 place responsibility on the management body, and the delegation profile records who delegated what to which system.

Practical guide: Writing a delegation profile for a loop

Purpose. Fix, before the first agent runs, how far each stage may be delegated, who holds each decision and who can stop the loop. Roles. The purple-team coordinator drafts; the CISO or the head of security operations decides; the white-team lead or a person independent of the red team and the detection owner reviews the P2 rows; the data protection officer and, where staff are involved, the employee representatives are consulted.

1. List the action classes for each stage, using the table above as the starting point. Add the classes that are specific to the organisation and delete none without a reason recorded.
2. Put four questions to each class: is the action reversible; does it stay inside the signed scope; does it touch personal data beyond what the exercise is authorised to touch; does it name a person. A "no" to the first two, or a "yes" to the last two, caps the class at Level 2 Supervised or below and forbids Level 4. Closure is not a class to be delegated: a person signs it.
3. Set the ceiling at the lowest level any answer permits. Do not set a ceiling above the level the organisation has actually evidenced: a class whose supervisors have not practised the manual route stays one level lower until they have.
4. Name the decider for each row, the person who delegated it and the stop holders, with a deputy and a second deputy. The stop holders revoke the emulation identity at the identity provider or the policy decision point, so that the stop works when the emulating system is degraded or disagrees.
5. Write the conditions of each ceiling as numbers, not as intentions: the share of runs sampled by a person, the seeded gaps per quarter, the catch rate below which delegation freezes, the time within which a stop must take effect. A default to adapt to the contract, the works agreement and the risk appetite is a stop drill each quarter with a target of two minutes to revoked credentials, and a freeze of further delegation when a seeded-gap catch rate falls below 0.80.
6. State the independence declaration (see the next section) for every row where AI sits on both sides of a check: the kinds of separation shown, the incentive rule and the proofs available.
7. Sign the profile, version it and record the decision in an AI Decision Record.

Definition of done. Every row has a ceiling, a decider and a stop holder; the closure row names a person; every row at Level 3 cites the manifest or regression case that bounds it; a stop drill has run once and its time is recorded; the profile is in the repository with the date of its next review.

Worked example: Loop charter and delegation profile

The illustrative charter below is Nordvik Region's. It has no red team and no emulation agent. It signs the three stages that cross the boundary to the contracted tester and the managed provider, keeps the two stages that are the Region's own decisions, and sets the ceilings accordingly.

# Illustrative: Nordvik Region, minimum loop charter and delegation profile
kind: LoopCharter
id: LOOP-NR-2028-01
decision: AIDR-0802
effective: 2028-03-01
review: 2028-09-01
owner: {role: ROLE-NR-SEC-DET, person: Karin Lund}   # also purple-team coordinator
signed_stages:                       # stages the tester and the provider also sign
  P2: {party: contracted-tester, agreement: NR-2026-071, rules: RoE-NR-2027-001}
  P3: {party: mssp, agreement: NR-2025-044, annex: MS-1, delivers: tagged-event outcomes within 5 working days}
  P5: {party: [contracted-tester, mssp], annex: MS-2, retest: within 30 days of change notice}
internal_stages: [P1, P4]            # decided by the Region alone
closure_rule: {retest_passed: true, variant_run: true, evidence: EVD, signed_by: named-person, dated: true, states: [open, implemented-unverified, retest-failed, closed-verified, risk-accepted]}
delegation:                          # profile DLG-NR-LOOP-01
  P1: {ceiling: 1, note: "drafting assistant may not draft the detection for a scenario it helped choose"}
  P2: {ceiling: 0, note: "no Mode 5 emulation agent without a signed mandate; tester declares Modes 1 to 3"}
  P3: {ceiling: 1}
  P4: {ceiling: 1, approver: Karin Lund}
  P5: {ceiling: 2, closure_signed_by: Karin Lund}   # a person signs; the tester's re-test and the provider's seeded incidents supply the evidence
  level_4: {forbidden_for: [irreversible, out_of_scope, personal_data_beyond_authorisation, named_person]}
stop:
  holders: [Karin Lund, mssp-shift-lead, tester-fieldwork-lead]
  mechanism: revoke test identity at the Region identity provider   # outside the tester's tooling
  target_seconds: 120
independence:                          # kinds not shown are treated as shared (Chapter 15)
  incentive_rule: finding_quality_owner_is_not_closure_owner
  tester_is_not_detection_owner: true
  provider_ai_is_not_regions_ai: true
  seeded_incidents_per_class_per_quarter: 5     # from MS-2
unlisted_actions: undelegated

Karin Lund holds the closure role and the detection role, which is the weakness of a small team: she accepts the P4 change and also holds the P5 closure. The charter compensates with the tester's re-test and the provider's seeded incidents, which are independent of her, and with the audit committee's right to sample the register. Chapter 19 returns to roles in small teams.

Hansa Mutual's profile is wider, because four of its loop agents hold a mandate and the ceilings differ by agent.

# Illustrative: Hansa Mutual, loop delegation profile (agents fixed in Chapter 14)
kind: DelegationProfile
id: DLG-HM-LOOP-01
decision: AIDR-0852
effective: 2028-03-15
owner: {role: group-ciso-office, white_team_lead: required_for_P2}
stages:
  P1: {agent: MND-HM-EMU-02, ceiling: 1, human: Mareike Hartmann}   # scenario curator
  P2:
    - {agent: MND-HM-EMU-01, class: S1-in-scope, ceiling: 3, enforced_by: policy-decision-point}
    - {agent: MND-HM-EMU-01, class: above-S1, ceiling: 2, approver: white-team-lead}
  P3: {agent: MND-HM-EMU-03, ceiling: 1, mode: read-only}           # observation correlator; the book ceiling is 3, Hansa has not yet evidenced it
  P4: {agent: MND-HM-EMU-07, ceiling: 1, merge: Lena Vogel}         # detection drafter (HM-SEC-002); drafts only
  P5: {agent: MND-HM-EMU-06, class: REG-cases, ceiling: 3, scope: run-and-record, closure_signed_by: head-of-detection-engineering}   # re-test runner records; a person signs
critic: {agent: MND-HM-EMU-04, ceiling: 0, model_family: second}
independence: {statement: IND-HM-2028-Q1, incentive_rule: finding_quality_owner_is_not_closure_owner, unshown_kinds: treated-as-shared}   # Chapter 15
freeze_when: {seeded_gap_catch_rate_below: 0.80, stop_drill_over_seconds: 60}   # runner of HM-SEC-004; Chapter 6
evidence_expiry_days: {priority_techniques: 90, others: 180}
level_4: {forbidden_for: [irreversible, out_of_scope, personal_data_beyond_authorisation, named_person]}

Independence

The independence principle is the central design rule of the book, and this chapter defines it; Chapter 15 develops it and stages its debate. The principle is that a check is evidence only if the side that performs it can fail in ways the side being checked does not share. A re-test that asks the system that produced a fix whether the fix works is not a check. A coverage report that an emulation agent and a detection agent have agreed between themselves is not a measurement.

The reason the principle needs stating in this book is that AI lets both sides of the loop be filled by systems that resemble each other. An emulation agent and a detection-drafting agent may share a model family, training data, a vendor and a prompt style, and so may share blind spots. Where they do, errors correlate: a technique neither side thinks of is neither emulated nor detected, and the loop reports success. AI Threat, Chapter 23, adds a second reason, which is that models may behave differently when they are tested, so that assurance cannot rest on any single evaluation (105, Needham et al., 2025). The human side has a corresponding weakness: reviewers who depend on an automated aid tend to check less, and the documented effect is automation complacency and bias (101, Parasuraman & Manzey, 2010). The principle does not assume that AI is unreliable. It assumes that agreement between two things is informative only if they could have disagreed.

A loop declares its independence in three layers, and the delegation profile records the declaration for every row where AI sits on both sides of a check. Chapter 15 develops them and uses the same names.

• Five kinds of separation between the side that tests, the side that is tested and the side that checks: model (no shared model family or lineage, or the sharing is declared and compensated), data (no shared training data, retrieval corpus or intelligence feed), authorship (the scenario and the detection it tests are not written by the same author, human or agent, and a defined share of the library is human-authored novelty), vendor (no shared vendor, platform or gateway tenant, including provider AI embedded in a service) and time (the re-test is not run at once and with the fixer's data, and the evidence expires). A kind that is not shown is treated as shared.
• One rule between roles, the incentive rule: the party accountable for the quality of a finding is not the party accountable for closing it, in line with AI Blue, Chapter 11 (the red team or tester answers for the findings' quality, one named role for the age of the register), and nobody marks their own work (Chapter 19) (94, Nordqvist, 2026).
• Three proofs: held-out scenarios, which the builders of the detections did not see; seeded gaps and seeded errors, which show that the check can fail; and reproduction, by which a person can redo the key result by another route from the evidence manifest alone.

Human-authored novelty in every cycle is the requirement that the held-out set serves.

These measures are not free, and they concern people as well as systems. Seeded errors and catch rates are measures of the review process and are reported in aggregate, agreed with employee representatives beforehand, as the earlier volumes concluded for oversight quality. The independence declaration is also not a certificate. It is a statement that can be tested, in the first instance by the seeded gap: a scenario deliberately left out of the detections that should miss, whose catch or non-catch tells the organisation whether its loop can fail.

Roles and accountability

AI changes the work of the teams in the loop and does not change who answers for it. AI Red Team held that AI changes the work of red, blue, purple and white teams but not their accountability (90, Nordqvist, 2026). The roles are defined as follows, using the terms of the series and of the TIBER-EU framework, which names red team testers who emulate the adversary, a blue team that defends and a control team, the small group in the entity that knows of the test and governs it (earlier TIBER-EU guidance, and this book, call it the white team) (20, ECB, 2025).

Role	What it is	Accountable for	Never
Red team (or contracted tester)	People who emulate the adversary, inside the signed scope	Quality of findings and of the emulation record	Closing its own findings; tuning the defender's rules
Blue team	The people and functions that defend, including detection engineering	The detection, playbook or mandate change; the age of its part of the register	Marking a change verified without the re-test
White team	The control group that governs the exercise: authorises, controls the window, holds the stop with others	That the exercise stays within its authority and scope	Taking part in the red or blue work it controls
Purple-team coordinator	The role that runs the loop: schedules, makes sure findings reach their owners in a usable form, tracks the age of open findings	The flow and legibility of the register	Being a third team; deciding what red or blue should do
Closure owner	One named person per class of finding	Declaring a finding closed on the evidence	Closing on attestation
Agent operator	The person who runs a loop agent under a mandate manifest	That the agent works within its manifest	Widening the manifest

The purple-team coordinator deserves the second look, because the term invites the misreading that purple is a team. In this book the purple team is the joint loop between red and blue, and the coordinator is a role that serves the loop, not a member or head of a third team. AI Blue, Chapter 17, placed it in the blue team's loop, and where there is no red team it is a fraction of the duties of the person who commissions and receives the penetration test and any contracted exercise (94, Nordqvist, 2026). The coordinator holds the register, not the findings, and does not own the changes. This chapter adds the closure owner as a separate named responsibility. The earlier volumes made one role accountable for the age of the register; this book also needs one person accountable for each closure, because a register can be well kept and still close findings on attestation.

Three accountability rules follow. Accountability for a missed closure rests first with the class owner and with those who designed the review and granted the level, and then with the reviewer, but only if the process allowed real review. The white team's independence is by position, not by sentiment: it sits outside both the red team and the SOC. And a person who holds the stop does not need to justify using it: the right to stop is cheaper to exercise than the right to continue, and a stop made in good faith is never a failure (91, Nordqvist, 2026).

What the loop is not

Three misreadings recur, and each is a failure the later chapters meet again as an anti-pattern.

The loop is not a team. There is no purple team that sits beside the red team and the blue team with its own staff and budget; the term names the joint practice. An organisation that creates a third team to "do purple" tends to create a third queue.

The loop is not an event. A quarterly purple session is a valuable place for the stage P3 reading, and it is also the setting where the human contributions that no pipeline supplies, novelty, judgement about consequence and trust, are produced. It is not the loop. A session with no re-test is a debrief, and Chapter 26 gives it the name purple theatre. The thesis of the book is that AI moves the loop from the event to the pipeline and keeps the event; the definition here leaves room for both.

The loop is not a dashboard. A dashboard that shows green is a view of the records, and it is only as good as the age and test behind each cell. The loop's own records carry the date of the last passing test. A percentage of "techniques covered" without that date is a count of assertions.

Observable, expected, speculation

That threat-led testing frameworks prescribe roles and a control team is observable (20, ECB, 2025). The five-state loop and its closure rule are the earlier volumes' design, which the two fictional organisations of this book apply but cannot evidence. That continuous emulation and regression become the normal way of keeping the loop current, with human-led exercises kept for novelty, is expected, as a consequence of the cheaper variation Chapter 3 described. That a loop could close itself, with no human-authored novelty and no independent verification, and sustain detection of novel intrusions, is speculation, and the independence principle is the book's position that it should stay so until evidence says otherwise.

Across the usage modes

The same stage looks different according to how the AI taking part in it is deployed, because the mode sets whose identity it uses and therefore what it can reach.

Usage mode	In the loop	Main risk	Usual ceiling
Mode 0 Ambient AI	Vendor AI in the simulation tool, the endpoint product or the provider's alert closure	Autonomy nobody decided; the provider's AI is on the blue side of the check	Declared, not delegated; contract rights first
Mode 1 Conversational assistants	A practitioner drafts a scenario or a summary	Content that enters the library without review	Level 0 Advisory
Mode 2 Embedded workplace assistants	Drafting inside the ticketing or document tools	Drafts treated as records	Level 1 Assisted
Mode 3 Agentic work tools	A practitioner's agent assembles a plan or a timeline with the practitioner's identity	Reach of the practitioner's credentials	Level 1 to Level 2
Mode 4 Built AI applications	A correlator or a scenario curator with read-only access	Shared model family with the other side	Level 1 Assisted in practice; Level 3 is the ceiling only for read-only correlation at P3
Mode 5 Autonomous production agents	An emulation runner or re-test runner with an identity of its own	A privileged insider holding offensive capability	Level 3 Bounded for S1 and REG cases (recording a result, never closing), Level 2 above S1, Level 0 for S4; Level 4 never in the listed classes

Nordvik Region and Hansa Mutual

Nordvik Region buys the loop, and its leverage is the contract. It has no red team, a contracted tester under call-off agreement NR-2026-071 and a managed provider under NR-2025-044. Its January 2028 question, from the audit committee, is what the first threat-led exercise proved beyond a list of closed findings (AIDR-0800). The answer begins with this chapter's definition. The Region writes a minimum loop it can get both counterparties to sign (LOOP-NR-2028-01, AIDR-0802, dated 2028-02-22): the three stages that cross the contract boundary, P2 Emulate for the tester, P3 Observe for the provider's delivery of tagged-event outcomes and P5 Verify for the re-test and the provider's seeded incidents. P1 Target and P4 Improve stay internal, because they are decisions about the Region's own priorities and artefacts. Its risk is a loop that never starts or stops after the first report, and the charter gives the loop a clock and a named owner. Its weakness is that one person holds several roles, which the independent re-test partly compensates.

Hansa Mutual runs the loop, and its leverage is the pipeline. It already keeps the five record states of AI Red Team, Chapter 26, in a repository, and when the group CISO's office maps them to the five stages (AIDR-0852, dated 2028-02-15) the mapping fits P3 and P4 well and exposes P5 as the weakest stage. The evidence is in figures it already had: of the nine priority techniques not verified at BTP-HM-2027-Q3, four carried evidence past its expiry, three had failed a re-test and two had never been tested. A white-team sample of 20 findings closed in the third quarter of 2027 found that 14 had a re-test log and an evidence manifest and 6 had been closed when the change merged (illustrative). The 6 are findings in the state "implemented, unverified" reported as closed. The remedy is the closure rule applied as a state, with expiry as a property of the regression case, and a closure owner named per class. Hansa's risk is a loop that runs without anyone questioning it, and the independence declaration in DLG-HM-LOOP-01 is how it arranges to be questioned.

Summary

The purple loop has five stages, named exactly so throughout the book: P1 Target chooses what to test, P2 Emulate executes it inside a signed scope under a stop path outside the emulating system, P3 Observe compares the outcome with a written expectation and raises findings, P4 Improve turns a finding into a change, and P5 Verify proves the change by a re-test and attaches the evidence. Each stage produces a record: a scenario, an emulation plan, a finding and a purple session record, a change, and a regression case with an evidence manifest. The five states of AI Red Team, Chapter 26, map to P3 to P5, and P3 to P5 are the exercise-driven half of B5 Learn; P1 and P2 are the stages this book adds in front of them.

The closure rule is the exit condition: a finding is closed only when the re-test and its variant pass, the evidence is attached, a named person signs and the closure is dated. Five states keep the rule auditable, and an accepted risk or an implemented but unverified change is reported separately and never as closed. Evidence expires, so a closed finding is closed as of the date of its last passing test.

Delegation is a degree, set per stage and action class. The book recommends ceilings of Level 2 Supervised for P1 and P4, Level 3 Bounded for catalogued S1 scenarios at P2 and for read-only observation at P3, Level 0 Advisory for S4 scenarios, and Level 3 for running and recording a re-test at P5, with closure always a named person's signature. 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 is authorised to touch, or that targets a named person. The independence principle requires that the side that tests and the side that is tested can fail in different ways, declared as five kinds of separation, one rule between roles and three proofs, and shown by seeded gaps. The roles of red, blue, white, the purple-team coordinator and the closure owner hold the loop, and none of them is a third team.

Chapter 5 begins Part II with the first stage, P1 Target, and the question of how a scenario is chosen from intelligence, risk and the threat register, and why a team left to itself tests what is easy to emulate.

Sources

1. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
3. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
4. MITRE Corporation. MITRE ATT&CK. (17, MITRE, n.d.)
5. MITRE Corporation. MITRE ATLAS. (18, MITRE, n.d.)
6. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (24, NIST, 2024)
7. Parasuraman, R. & Manzey, D. H. Complacency and Bias in Human Use of Automation. (101, Parasuraman & Manzey, 2010)
8. Nordqvist, G. Architecture as Code. (87, Nordqvist, 2025)
9. Nordqvist, G. AI Red Team. (90, Nordqvist, 2026)
10. Nordqvist, G. AI Threat. (91, Nordqvist, 2026)
11. Nordqvist, G. The Transformed Security Architect. (92, Nordqvist, 2026)
12. Nordqvist, G. AI Blue. (94, Nordqvist, 2026)
13. Needham, J., Edkins, G., Pimpale, G., Bartsch, H. & Hobbhahn, M. Large Language Models Often Know When They Are Being Evaluated. (105, Needham et al., 2025)