This chapter gives the author's verdict on the book. It judges the five-part thesis of Chapter 1 against what Parts II to VI showed, says whether the conditions that Chapter 1 set for refuting the thesis occurred, restates the independence principle and the closure rule as the operating rules of the book, answers the twelve questions that the book took up, gives the author's own projections, each labelled, and says what a reader in each role can do on Monday morning. It concerns all five stages of the loop by name: P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify. It also adds one commitment to the argument that the series has made since Architecture as Code: that the test of a defence is itself a system that has to be recorded, stopped, verified and owned.
A word on method before the verdicts. The evidence of this book is of four kinds: research and agency sources that the chapters cite; conclusions that the earlier volumes of the series established; design reasoning of the book's own; and the illustrative cases of Nordvik Region and Hansa Mutual, who are fictional and whose figures are illustrative. None of it is a measured outcome from a real loop observed over several years, judged by independent threat-led tests. When this chapter says that a part of the thesis held, it means that it survived the tests the book could apply: the literature, the instruments, the design and the worked cases. It does not mean that it is proved. This chapter is also, with Chapter 25, the place where the author's own projections are allowed, and it keeps them apart from the verdicts so that a reader can accept the one and doubt the other.
The working thesis of Chapter 1 had five parts, and Chapter 1 committed in advance to the evidence that would show it wrong. Each part is judged below against the chapters that tested it. A verdict is one of four: held, where the evidence available to the book supports the claim and no chapter found a counter-case; held with qualifications, where the claim survived but the book itself found cases that limit it; held in part, where a chapter showed that the strong form of the claim is not supported and a weaker form is; and argued but not proved, where the book offers design and argument but no outcome evidence. No part earned a plain held.
Primary topics explored
- The thesis tested
- The two operating rules
- The twelve questions
- The author's projections
- What to do on Monday
- The series' argument
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 29: Conclusions: The Purple Loop with AI in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Experience and Conclusions” and is one of 33 drawn from the manuscript.