A finding is a claim about the past: on a given day, a technique reached its objective, or a detection did not fire, or an alert was closed by a system that should not have closed it. A change is a claim about the future: this will not happen again. Between the two claims sits P5 Verify, the stage that decides whether the second claim may be believed. It is where the loop either closes or merely appears to. The chapter defines closure, designs the re-test, explains why re-running the exact scenario proves less than it seems, shows how a re-test becomes a regression case that runs for as long as the control exists, and treats the evidence as code that is signed, versioned and, above all, dated. It concerns P5 Verify and takes its input from P4 Improve (Chapter 10) and its tests from P2 Emulate (Chapters 7 and 8); the comparison of result with expectation is P3 Observe (Chapter 9) run a second time.
The chapter builds on conclusions that earlier volumes recorded. Architecture as Code (Chapter 15A) concluded that evidence is machine-collected, signed and versioned rather than assembled in audit season (87, Nordqvist, 2025). AI Governance, Chapter 11, added that attestation is a person asserting and evidence is generated by the system (88, Nordqvist, 2026). AI Red Team, Chapter 26, defined the purple loop as five record states, finding, control, detection, re-test and evidence, and fixed the exit condition that this chapter develops: a finding is closed only when the re-test passes and the evidence is attached (90, Nordqvist, 2026). AI Blue, Chapter 11, set out the blue team's half of the loop and added that a finding is closed with a pointer to the passing re-test and that the date of the last passing re-test is part of the record (94, Nordqvist, 2026). Those chapters state the rule. This one asks what it takes to apply the rule honestly when a machine can run the re-test every night and another machine can write the fix.
The rule has four clauses, and each answers a way that closure goes wrong.
Primary topics explored
- The closure rule
- Designing the re-test
- Variants
- Regression suites in the pipeline
- Evidence as code
- Expiry
About AI Purple
AI Purple is Book 9 of The Transformed Architecture. It takes the loop between the red team and the blue team as its subject and asks what happens when AI sits on both sides of the table: the five stages of the loop (target, emulate, observe, improve, verify), rules of engagement and safe emulation, continuous emulation, the independence principle, coverage as a claim that needs evidence, the loop's own AI and how to defend it, operating models, decision rights, regulation, and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss and AI Blue.
Chief information security officers, heads of security operations, red-team leads, penetration testers, SOC managers, detection engineers, purple-team coordinators and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 11: Verify: Re-test, Regression and Evidence in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Stages of the Loop” and is one of 33 drawn from the manuscript.