An incident is an interval in which a service does not do what its objective promises and the organisation does not yet know why. Diagnosis is the work done inside that interval: deciding that something is wrong, deciding how much it matters, forming explanations, testing them and handing a cause to the people who will act on it. This chapter concerns O2 Diagnose, the function of the operations loop that Chapter 4 defines as finding what is wrong and why. It draws on O1 Observe, whose signals start every diagnosis (Chapters 5 and 6), and it hands over to O3 Change and O4 Restore, whose actions follow from a diagnosis and are treated in Chapters 9 and 10.
The incident assistant is the newest participant in this work. It retrieves past incidents and runbooks, lists what changed before the symptoms began, ranks candidate explanations and drafts status updates. The chapter describes what such an assistant can do, what published studies of automated root-cause analysis report and under which conditions, why the first explanation an assistant offers tends to become the only one the team considers, and how an incident commander stays in command. It ends with the record that makes the assistant's contribution inspectable afterwards.
The chapter's conclusion is the book's own, drawn from the evidence below. In diagnosis the assistant is a source of evidence and of hypotheses, and it is never the authority for an action. Its tools are read-only. The person who acts on a diagnosis records a second hypothesis and a test that could refute the first before the action is taken, and the record shows which parts of the work were the assistant's.
Primary topics explored
- Diagnosis before AI
- The incident assistant
- What the benchmarks say
- Automation bias and anchoring
- The human decision points
- The record
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), 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, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 7: Diagnose: Triage, Root-Cause Analysis and the Incident Assistant in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft” and is one of 35 drawn from the manuscript.