Every other function of the operations loop depends on this one. An operator cannot diagnose what has not been seen, cannot change a service safely without knowing its state before and after, and cannot restore a service without knowing when it is restored. This chapter concerns O1 Observe: the telemetry that a service emits, the service level objectives that say what good looks like for its users, the alerts that call a person when the objective is at risk, the map that says who owns what, and the cost and legal limits on seeing. It treats the function without AI first. Chapter 6 then changes it, and takes up O2 Diagnose as it does so, because correlation, anomaly detection and language-model summaries act on the signals, indicators and objectives described here, and an organisation that has none of these cannot say whether an AI feature has made its observation better or worse.
The chapter builds on conclusions of the earlier volumes. Evidence is machine-collected, versioned and dated (F4 and F20; Architecture as Code (Chapter 15A) and AI Governance, Chapter 11) (295, Nordqvist, 2025); (296, Nordqvist, 2026). A detection is a record with an owner and a test, and it counts only when a recent test shows that it fires (F95; AI Blue, Chapters 6 and 11). Coverage and, in this book, resilience are claims with a date and an expiry (F119; AI Purple, Chapter 17). Observation is comparison with a written expectation, with the ground truth held outside the system observed (F125; AI Purple, Chapter 9). AI Platform and Security, Chapter 21, treated observability and drift for the AI platform (297, Nordqvist, 2026); this chapter takes the general case, for every service the operator runs.
Observing serves one purpose: to know whether a service is good for the people who use it, early enough to act. A large share of the monitoring that organisations inherited was built to answer a different question, whether the machines are busy, and its natural outputs are utilisation graphs and threshold alerts on processor load, free disk and queue depth. Such signals are useful in diagnosis. As the main source of pages they have a known weakness: a machine can be at ninety per cent of its processor capacity while every user is served well, and a service can fail every request while every machine reports healthy.
Primary topics explored
- What observing is for
- Signals
- Indicators, objectives and error budgets
- Burn-rate alerting
- Service maps and ownership
- Cost, retention and personal data
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 5: Observe: Telemetry, Observability and Service Level Objectives 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.