Part I has asked what operations did before AI (Chapter 2) and why its traditional shape strains (Chapter 3). This chapter defines the frame that the rest of the book uses, and it concerns all five operations functions: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. It fixes what each function is and where it ends, how much machine action each function may take and how that allowance is spent (the autonomy budget), the four things no agent does at the highest degree of delegation, the observer principle that governs what may verify an action, the form of a resilience claim and the way its evidence ages, and the status of the operator's own AI as one of the most privileged workloads in the estate. It closes by mapping the loop to the Respond and Recover Functions of NIST CSF 2.0, to Articles 8 to 13 of DORA and to the practices of ITIL 4.
The definition is the book's own design. It builds on observable practice and on the conclusions of the earlier volumes: the autonomy levels of AI Red Team, Chapter 6, the delegation profile of AI Blue, Chapter 4, and the independence principle of AI Purple, Chapter 15. The sources cited support its parts, never the whole, and the chapter says so where it makes a recommendation that is a matter of design and not of measurement.
A service has objectives. The loop keeps the service inside them, and it has five functions that hand work to one another through records. O1 Observe turns the state of the service into signals that are compared with its objectives. O2 Diagnose turns a signal into a hypothesis about what is wrong and what changed. O3 Change alters the estate, whether to deliver a new capability, to repair a cause or to keep the estate current. O4 Restore returns a service to an acceptable state by remediation, rollback, failover or recovery from backup. O5 Sustain keeps the estate and the people fit over time through capacity, cost, energy, lifecycle, problem management and learning. The arrows between the functions are records: an SLO burn alert, an incident record INC-*, a change record CHG-*, a runbook run, a problem record PRB-*, a restore-test record RST-*.
Primary topics explored
- The loop in one picture
- Five functions
- Action classes and the autonomy budget
- The Level 4 prohibitions
- The observer principle
- Resilience as a claim
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 4: The Operations Loop Defined: Five Functions, Autonomy Budget and Observer Principle in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Operations in Question” and is one of 35 drawn from the manuscript.