AI Blue · Whitepaper

Chapter 11 · The Craft

Learn: Post-Incident Review, Purple Teaming and Detection Debt

Key insights from Chapter 11 of "AI Blue"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 10 November 2026
Build number 2026.11
blue-team security-operations ai-governance architecture-as-code ai-agents
Figure 11.1: The learning loop from incident or exercise through finding, change, re-test and verified control.
Figure 11.1: The learning loop from incident or exercise through finding, change, re-test and verified control.

This chapter describes B5 Learn as the blue team now has to run it: the post-incident review, the purple loop and the upkeep of detections, playbooks and mandates, in a team where AI drafts reviews, proposes improvements and tracks closure. It concerns B5 Learn above all, and it touches B2 Detect and B4 Respond because those are the functions whose artefacts a review changes. The chapter argues that a review is engineering, not ceremony: it ends in changes to code, and a finding is closed only when a re-test passes. It also names the risk that is new with AI, a review that reads well, is produced in minutes and teaches the team nothing.

The chapter builds on the finding-to-verified-control path of AI Red Team, Chapter 26, and on the conclusion recorded there: every finding, whether from an exercise, an AI red-teaming campaign, a chaos experiment or an incident, ends as a verified control, and a finding is closed only when the re-test passes (64, Nordqvist, 2026). It also takes over the classification of controls in AI Threat, Chapter 30: a control is a defence only when a test that re-runs its scenario has passed recently, and controls are classified verified, declared or failed (65, Nordqvist, 2026). Chapter 10 defined the playbook manifest and the stop path that this chapter tests, and Chapter 6 defined the detection record that this chapter maintains.

A post-incident review is worth the time when it changes something that can be tested. The test is simple: after the meeting, is there a pull request, a contract change request or a mandate change with an owner and a date, and is there a re-test that will show whether the change works? If the answer is a document of observations, the review was a ritual.

Primary topics explored

  1. Review as engineering
  2. AI in the review
  3. The finding-to-control path
  4. The purple loop
  5. Detection debt and playbook debt
  6. Learning across boundaries

About AI Blue

AI Blue is Book 8 of The Transformed Architecture. It examines how the blue team, the people and functions that defend an organisation, is transformed when artificial intelligence takes part in their work: anticipating, detecting, investigating, responding and learning, the team's own AI and how to verify and protect it, operating models, roles, decision rights, regulation and measurement, and the careers and wellbeing of 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 and AI Boss.

Who should read this

Chief information security officers, heads of security operations, SOC managers, analysts, detection engineers 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 11: Learn: Post-Incident Review, Purple Teaming and Detection Debt in AI Blue gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “The Craft” and is one of 32 drawn from the manuscript.