The Verification Loop

A finding that is written down is not a finding that is fixed, and a control that is declared is not a control that works. The tools of this chapter serve the activity that turns the first into the second: verification. They are the records and methods by which an organisation can say, about a technique or a control, what was tested, when, in which environment, with what result, and whether the person who says so could have been wrong in the same way as the thing being tested. They come mainly from three books: AI Purple, which defines the purple loop, its records and the independence principle (9, Nordqvist, 2026); AI Red Team, which first set out the loop from finding to verified closure and security chaos engineering (4, Nordqvist, 2026); and Architecture as Code (Chapters 9C and 13), which put codified failure experiments and drilled playbooks into the pipeline (1, Nordqvist, 2025). Smaller contributions come from AI Threat, The Transformed Security Architect, AI Blue and AI Operations.

All four kinds of tool appear. The artefacts are the purple session plan and record, the coverage record and its status rule, the regression case and the chaos experiment manifest. The methods are the purple loop itself, the practical guides for running a session and for turning a closed finding into a regression case, the steady-state hypothesis and the game day. The third-party tools are few and mostly standards or communities of practice: the Principles of Chaos Engineering, Chaos Monkey, ATT&CK and ATLAS as the vocabulary of the records, and the Center for Threat-Informed Defense's Summiting the Pyramid method. The series ships no verification software. The pipeline that evaluates a coverage status or runs a regression case is the organisation's own, and what the books provide are the records it reads and writes. Two rules recur and are applied to every tool: no tool says that something is covered without saying what was tested, when and with what result; and every tool that touches the estate says what can be undone and who can stop it, from outside the system being stopped. The authorisation tools that precede all of this, the rules-of-engagement manifest and the emulation plan, are treated in Chapter 11.

Figure 14.1 shows how the tools relate. The five stages of the purple loop produce a chain of records; the coverage record is derived from the last of them; chaos experiments enter the loop from the side, as findings if they fail and as evidence if they pass; and two things stand outside the loop and check it, the independence statement and the stop path.

Primary topics explored

1. Purple sessions
2. Coverage and evidence age
3. Regression cases
4. Independence between tester and tested
5. Security chaos engineering
6. Across the usage modes