AI Purple · Whitepaper

Chapter 17 · The Loop in the Organisation

Coverage as a Claim

Technique Maps, Evidence Age and Detection Decay

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 10 November 2026
Build number 2026.11
purple-team adversary-emulation ai-governance architecture-as-code ai-agents
Figure 17.1: Regression cases and assertions feed coverage records, a status rule gives five statuses, and a named person declares coverage.
Figure 17.1: Regression cases and assertions feed coverage records, a status rule gives five statuses, and a named person declares coverage.

"Covered" is the most used and least examined word in security reporting. A technique map coloured green says that something is covered, and the reader is left to guess what was done, when, in which environment and by whom. This chapter treats coverage as a claim that has to be written down with its evidence, in the way a finding or a control is. It concerns P3 Observe, where a step is compared with its expectation and the result is recorded, and P5 Verify, where re-tests and evidence turn a result into something that can be relied on and that expires. The coverage record, COV-NR-* and COV-HM-*, is the artefact that joins them. Chapter 4 introduced it as derived and not a stage record, and this chapter defines it.

The argument is short. A claim of coverage has five parts: a technique, an environment, a result at a named layer, a date and an expiry. A claim that lacks any of them is a hope. A claim whose evidence has outlived its expiry is a memory. A claim that rests on someone else's statement is an assertion, and a technique that nobody has tested is not covered, whatever the colour of its cell. The chapter shows how to make these distinctions mechanical, so that the status of a technique is computed from records and not decided in a meeting, and how to report coverage so that a board or a supervisor sees the age of what it is told.

The chapter builds on conclusions of the earlier volumes and on the stage chapters of this book. Architecture as Code (Chapter 15A) concluded that evidence is machine-collected, signed and versioned and not assembled in audit season (87, Nordqvist, 2025). AI Governance, Chapter 11, separated attestation, which is a person asserting, from evidence, which the system generates (88, Nordqvist, 2026). AI Red Team, Chapter 25, set the safety boundaries of continuous verification, and Chapter 3 of the same volume introduced the CSF profile kept as code, which Chapter 17 uses below (90, Nordqvist, 2026). AI Threat, Chapter 30, classified controls as verified, declared or failed and required a control-to-threat matrix that counts controls sharing a dependency once, and Chapter 32 fixed the register that reaches the board on one page (91, Nordqvist, 2026). Within this book, Chapters 5, 9, 10, 11 and 15 defined the priority techniques, the outcome taxonomy, the routes for a finding, the regression case and evidence manifest, and the independence principle; none is repeated here.

Primary topics explored

  1. From heat map to evidence
  2. What covered means
  3. The coverage record
  4. Evidence age and expiry
  5. Decay
  6. Environments and variants

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.

Who should read this

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.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 17: Coverage as a Claim: Technique Maps, Evidence Age and Detection Decay 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.