A loop that is run well and measured badly will drift towards what its measures reward. This chapter asks what the purple loop should report about itself, to the people who run it and to the board that is accountable for it, and which numbers to refuse. It concerns three stages. P3 Observe produces the evidence ages, the generalisation gap and the findings that most measures start from. P4 Improve produces the changes whose cycle time and debt the loop must show. P5 Verify decides what may be counted as closed, and it is the stage whose records make the best measures because a re-test cannot be argued with. The chapter defines six measures of the loop, names the measures that mislead, applies Goodhart's law to a loop with AI on both sides, and fixes the rule that keeps all of it on the right side of employee representatives' rights: the loop is measured, and the people in it are not.
The chapter builds on conclusions that earlier volumes recorded. Architecture as Code (Chapter 15A) concluded that evidence is machine-collected and that attestation, a person asserting, differs from evidence, the system's own record (87, Nordqvist, 2025). AI Red Team, Chapter 26, fixed the closure rule that every measure here depends on: a finding closes when the re-test passes and the evidence is attached (90, Nordqvist, 2026). AI Threat, Chapter 30, classified controls as verified, declared or failed (91, Nordqvist, 2026). AI Blue, Chapter 20, replaced the speed measures of the old SOC with four families, speed, coverage, quality of judgement and learning, each with a gaming check, and set the rule that measures about people are agreed first, reported in aggregate and never per named analyst (94, Nordqvist, 2026). AI Boss, Chapters 13 and 23, supplied the law and practice behind that rule (93, Nordqvist, 2026). Chapter 11 of this book defined the closure rule and the evidence expiry, and Chapter 15 defined the generalisation gap and seeded gaps. This chapter does not repeat them. It decides which of their numbers go on a page, in what form and for whom.
A measure of the loop is a number computed from the loop's records. That sounds obvious and has two consequences. First, a measure that cannot be traced to records (a finding, a regression case, an evidence manifest, a coverage cell) is an opinion, and the page must say so. Second, because the records are about techniques, scenarios, detections and findings, the natural grain of every measure is the technique, the class or the team. Nothing in the loop's records needs a person's name to be measured.
Primary topics explored
- What to measure
- What to avoid
- Goodhart and the loop
- Leading and lagging measures
- AI-specific measures
- Aggregation and works-council constraints
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 18: Measuring the Loop: Cycle Time, Yield, Re-test Pass Rate and the Metrics That Mislead in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Loop in the Organisation” and is one of 33 drawn from the manuscript.