An emulation produces a log of what was done. A detection pipeline produces a log of what was seen. Neither log says whether the defence worked. That statement is made only by comparing them with a third document, written before either was read: the expectation, a record of what the organisation's own coverage claims say should have happened at each step. This chapter concerns P3 Observe, the stage of the purple loop in which the comparison is made, layer by layer, from prevention through telemetry, detection, alert and triage to action, and in which a gap becomes a finding. It receives its input from P2 Emulate (Chapters 7 and 8) and hands its output to P4 Improve (Chapter 10); the finding it raises is closed only in P5 Verify (Chapter 11).
Observation is the stage in which red and blue meet. AI Red Team, Chapter 26, defined the purple team as the joint working mode between the two sides and not a third team, and AI Blue, Chapter 11, described the blue half of learning (90, Nordqvist, 2026) (94, Nordqvist, 2026). The ECB's guidance for threat-led testing under TIBER-EU takes the same view of purple teaming: a collaborative activity in which the red team and the blue team work together, with the control team (the white team of this book) that governs the test (34, ECB, 2025). What those texts leave open is the craft of the comparison itself. Which outcomes exist, what counts as ground truth, who may mark a technique as detected, and what an AI correlator may and may not do with the logs are design decisions, and a loop that leaves them to habit produces reports that two readers classify differently.
The comparison is only as honest as the expectation it is made against. If the blue team reads the emulation log first and then says what it would have expected, it will expect what it finds. The first rule of P3 Observe is therefore that the expectation is written, and sealed, before the result is shown.
Primary topics explored
- Expectation first
- Ground truth
- The outcome taxonomy
- Telemetry gaps
- Reading results together
- Raising a finding
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 9: Observe: Telemetry, Detection and Response Compared with Expectation 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.