This chapter treats P4 Improve, the stage of the purple loop in which a finding becomes a change. P3 Observe (Chapter 9) ends with a finding: a statement that a layer of the defence did not do what it was expected to do against a catalogued scenario, in a stated condition, on a stated date. P4 Improve decides what kind of change the finding calls for, who owns it, who reviews it, what it costs and how long it may take, and it ends by handing a regression case to P5 Verify (Chapter 11). The chapter concerns P4 Improve above all, and it touches P3 Observe for what it receives and P5 Verify for what it hands on.
The stage is where most loops lose their value quietly. Exercises find things, and a year later the same techniques are found again, because the finding went into a backlog that no one owned. AI sharpens the problem from both ends. Continuous emulation (Chapter 8) raises the rate at which findings arrive, and AI drafting of detections and fixes raises the rate at which changes can be proposed. Neither raises the rate at which a person can review a change for soundness. The chapter argues that P4 Improve is bounded by review, not by drafting, and that the design task is to make review real: a named owner, a decision a second person can reproduce, a counted cost and a visible age.
The chapter builds on four conclusions of the earlier volumes. A finding ends as a verified control, under the closure rule that Chapter 4 adopts and Chapter 11 operates (AI Red Team, Chapter 26; AI Blue, Chapter 11) (90, Nordqvist, 2026), (94, Nordqvist, 2026). A detection is a record with logic, data sources, ATT&CK mapping, tests, owner, alert budget and review date, and it counts only when a recent test shows that it fires (AI Blue, Chapter 6). Autonomy in response is matched to reversibility, and the lowest ceiling governs (AI Blue, Chapters 10 and 13). And verifying what AI proposes, when the reviewer depends on the AI, needs soundness defined in advance, review that does not start from the AI's answer and independent reproduction (The Transformed Security Architect, Chapter 14) (92, Nordqvist, 2026).
Primary topics explored
- What P4 Improve receives and hands on
- The finding record and the change record
- Choosing the kind of change
- Ownership
- AI-drafted changes
- Review
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 10: Improve: From Finding to Change in Detections, Controls, Playbooks and Mandates 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.