An incident ends when service is restored. Learning from it ends much later, and often not at all. This chapter concerns the part of operations that determines whether the next incident of the same kind happens: the problem record that collects what several incidents have in common, the post-incident review that establishes what was true, the actions that change the estate, and the knowledge (runbooks, articles, service records) that carries the change to the people and agents who work next. It concerns O5 Sustain, because learning is how an estate and the people who run it stay fit over time, and O2 Diagnose, because a review is a diagnosis carried out with the time and the evidence that an incident never allows.
The chapter makes four claims. A review that is blameless and evidence-based finds contributing conditions, and does not look for a single guilty cause or a single guilty person. A draft written by an AI system is a useful timeline and a poor analysis, and the way to keep it useful is to separate the two artefacts and to keep the people's own account independent of the draft. An action closes when its re-test passes, not when the review is signed, the ticket is moved or the change is merged. And knowledge that nobody owns decays into a hazard, which an assistant that retrieves it at machine speed makes worse. The chapter closes with what DORA Article 13 and NIS 2 Article 23 ask of the organisation after an incident, framed as architectural implications and not as legal advice.
Chapters 5 to 11 treated the loop in the present tense: observe, diagnose, change, restore, and keep the estate fit. This chapter treats the loop in the past tense. Three records carry an event from the moment it happens to the moment it is no longer a risk, and keeping them apart is the first discipline.
Primary topics explored
- From incident to problem to change
- The blameless, evidence-based review
- AI-drafted reviews
- Action closure
- Knowledge hygiene
- Regulatory follow-up
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 12: Sustain: Problem Management, Post-Incident Learning and Knowledge 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.