This chapter states the design rule on which the rest of the book depends. An operations loop in which an agent restarts a service, the same agent confirms that the restart worked, and a dashboard fed by the same platform reports green can agree with itself for as long as the platform lasts, and can fail silently at the moment the platform does not. The chapter concerns O1 Observe, where telemetry and probes establish the state of a service and where the observation itself has a cost, a failure domain and a dependency, and O4 Restore, where an action changes that state and something other than the actor has to show that the change did what it was meant to do. Its subject is what makes a verification independent of the action it verifies, how an observer is kept alive when the platform it watches is down, where an operations loop with AI in it shares blind spots that its diagrams do not show, and how far machines can verify machines before a person has to reproduce the result.
The rule, introduced in Chapter 4 as the observer principle, has three tests. What verifies an operations action must be independent of what performed it. The observer must not depend on the system observed. The stop path must work when the platform does not. The chapter turns the three tests into six kinds of independence, an observer manifest, a stop path with named holders, seeded faults that test the observers, a limit that comes from test-aware behaviour and from an agent's own reports, and a debate on whether independence is worth its cost. It builds on the conclusions F45, F62, F63, F67, F68, F76, F99, F118 and F121 of the earlier volumes, which it states where it uses them.
Operations has always verified its own work with tools that live inside the estate: the health endpoint that a restart resets, the monitoring that runs on the cluster it monitors, the email that reports a failed backup. Delegation to agents changes two things. The agent acts at a pace that leaves a person little occasion to look further, and it is increasingly the author of the check that confirms its own action. The first is the subject of the autonomy budget of Chapter 4; the second is the subject of this chapter.
Primary topics explored
- The rule
- Where operations loops fail together
- Independence of verification
- The observer outside the observed
- State engines report on themselves
- The stop path outside the control plane
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 17: The Observer Principle: Who Watches the Watcher in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Operator's Own AI” and is one of 35 drawn from the manuscript.