The Observer Principle: Who Watches the Watcher

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.

Figure 17.1: The observer principle: the observer and the stop path sit in failure domains separate from the platform they observe and stop.

The rule

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.

The three tests can be stated as questions an auditor, a supervisor or an incident commander can put to any operations loop, each answerable from records.

1. Independence of verification. For each action class, which signal showed that the action worked, who or what produced that signal, and by which path? The signal is independent when the actor did not author it, cannot alter it, does not read it from the same source that the action changed, and shares no credential with it.
2. Observer not dependent on the observed. If the platform is degraded, which observations continue? The observer is independent when it runs in a separate failure domain (network, provider, region, identity provider, DNS and, where relevant, the telemetry vendor), is reached through a path that does not use the platform, and raises an alarm when it falls silent.
3. Stop path outside the control plane. Who can stop an agent, how fast, and through what mechanism, when the platform, the ticketing system and the telemetry vendor are all unavailable? The stop path is independent when its holders need no approval, its mechanism does not run on what it stops, and it has been exercised within a stated time.

The word independence is relative to a claim. A verifier may share a model family with the agent it checks without harm when the claim is that a runbook step ran; it matters when the claim is that a customer can again register a claim. The records of this chapter therefore state a claim, a verifier, the dimensions along which the verifier differs from the actor and an expiry. This follows the independence principle of AI Purple, Chapters 4 and 15, which holds that a check counts as verification only when its failure modes are shown not to be those of the thing it checks, and which gives independence the dimensions of model, data, authorship, vendor and time (F118) (304, Nordqvist, 2026). Operations needs the same rule and two more dimensions, credential and failure domain, because an operations action changes a live service and can disable the means of seeing that it did.

Where operations loops fail together

The record of public incident reports contains many cases in which a loop failed because its verifier, its observer or its stop path shared a dependency with the thing it served. Each case below is stated by mechanism, as its issuer reports it, and the inference to AI-assisted loops is the book's own.

Meta's report on the outage of 4 October 2021 describes a maintenance command that took down the backbone connecting its data centres, which an audit tool that should have stopped the command failed to stop because of a bug. The DNS servers, which were healthy, withdrew their routes when they could not reach the data centres, so they became unreachable although still operational. The loss of DNS broke many of the internal tools normally used to investigate and resolve outages, and with primary and out-of-band network access down, engineers had to be sent to the data centres, where physical security added time (79, Janardhan, 2021). The verifier of the change (the audit tool) failed on its own account, and the means of investigation and access depended on the network that had failed.

GitLab's postmortem of the database outage of 31 January 2017 reports that the backup procedure ran a pg_dump client of version 9.2 against a PostgreSQL 9.6 database, which made the dump terminate, that failure notifications sent by email were rejected by the receiver for lack of DMARC, and that the S3 bucket for backups was empty when it was needed (89, GitLab, 2017). The backup existed as a configured job; the report does not describe a restore test that would have shown otherwise. Its notification path shared a fate with the thing it reported on, in the sense that nobody was told.

CrowdStrike's root cause analysis of the Channel File 291 incident of July 2024 reports that the Content Validator evaluated the new template instances on the expectation that the template type would be provided with 21 inputs, while the sensor code supplied 20, and that a stress test of the template type passed; the mismatch was found only when the content reached sensors in production, where it caused system crashes. The report lists staged deployment of template instances among its mitigations (78, CrowdStrike, 2024). The validator and the template definition shared an assumption that the integration code did not meet. The check was real, it ran, and it passed, and its failure mode coincided with that of the thing it checked.

Google Cloud's incident report of 12 June 2025 records that the Cloud Service Health infrastructure was itself down because of the outage, so the first incident report came about an hour after the crashes began, and that some customers' monitoring, which ran on Google Cloud, failed with it, leaving them without a signal about the incident (76, Google Cloud, 2025). Cloudflare's post-mortem of 18 November 2025 reports a contrasting detail and a related one: its status page went down although it is hosted off Cloudflare's own infrastructure, which the company describes as a coincidence that nevertheless led responders to suspect an attack on both, and debugging and observability systems that add debugging information to uncaught errors consumed large amounts of CPU and increased latency on the system they observed (77, Prince, 2025). The first shows an observer in the failure domain it observes; the second shows an observer that is itself a load on the observed.

Case	What was meant to verify, observe or stop	What it shared with the failed system	Test that failed
Meta, 2021	Audit tool on maintenance commands; internal tools and access for diagnosis	The backbone network and DNS	1, 2 and 3
GitLab, 2017	Backup job and its failure notification	A silent failure path: the version mismatch and the rejected email	1 and 2
CrowdStrike, 2024	Content Validator and stress test	The assumption of 21 inputs held by validator and template definition alike, which the integration code did not meet	1
Google Cloud, 2025	Status page; customers' monitoring on the same cloud	The provider's own platform	2
Cloudflare, 2025	Debugging and observability on uncaught errors	The CPU of the proxies it observed	2

The cases are observable, each a documented statement in an issuer's own report. None involved an AI agent; they are the pattern that an agent inherits and speeds up. Bainbridge's analysis of automation observed that a system the operator supervises and cannot fully check hands the operator a task that demands more skill, not less (217, Bainbridge, 1983), and Parasuraman and Manzey's review traced complacency and automation bias to the attention of people working with automated aids (218, Parasuraman & Manzey, 2010). An operator who sees a green check from the same agent that acted is in the position these two papers describe.

Independence of verification

Six kinds of independence

A single requirement such as use a different model is too coarse, and is easily met in a way that changes nothing. An operations loop has six dimensions along which a verifier can differ from an actor, each with its own shared dependency and its own control.

Kind	Shared dependency	What it hides	Control	What is shown
Model	The same model family behind actor and verifier, or behind runbook author and runbook reviewer	Common omissions; preference for its own output	A critique agent on a different family, used for questions and not for verdicts	Declared family for each agent; a log of the critic's disagreements
Data	The verifier reads the metric the action just changed	A reset that makes the signal say ready	A user-visible synthetic transaction instead of a health endpoint	The signal named in the runbook manifest and where it comes from
Authorship	The same author, person or agent, for the action and the check that confirms it	A check written to the action, not to the outcome	A different author for the verification clause, reviewed by a person	The author of record on each clause
Credential	The verifier acts under the actor's identity	A verifier that can alter the check it relies on	A separate read-only identity for each observer	The identity and its permission manifest
Failure domain	The same network, DNS, provider, region, identity provider or telemetry vendor	Blindness exactly when the platform fails	An observer in another domain, and a heartbeat that raises an alarm on silence	The domain map of the observer manifest
Time	Verification straight after the action, before caches, queues and retries settle	A pass that turns into a failure minutes later; stale evidence	Re-verification after a delay and after later changes, with an expiry on the evidence	The age of the evidence

Two remarks apply. The kinds are not ranked: a second model family used by the same author on the same metric gives model independence and nothing else, and a report must say so. Independence is shown by a dated record, like recoverability: a statement that the verifier differs from the actor, without the declared family, identity and domain and the date, is a declaration in the sense of the verified, declared and failed classification of AI Threat, Chapter 30, and counts as one (F62) (299, Nordqvist, 2026). The control for most kinds is cheap and old-fashioned: a scripted synthetic transaction, a second identity, a delay. The expensive kinds are failure domain and model.

What the research reports on models

Model independence needs a statement of what is known, because the intuitive remedy (have a second model check the first) is the one most often applied. Kim, Garg, Peng and Garg evaluated 349 language models on 12,032 multiple-choice questions on a Hugging Face leaderboard, 71 models on 14,042 questions on the HELM leaderboard and 20 models on 1,800 resume and job-description pairs. On HELM, pairs of models agreed on average about 60 per cent of the time when both were wrong, against the one third that choosing uniformly at random between incorrect answers would give; models from the same developer or with the same base architecture agreed more; and larger, more accurate models had highly correlated errors even when architectures and providers differed. In the judge setting, a judge systematically inflated the measured accuracy of models less accurate than itself, because it marked an incorrect answer as correct when both agreed on it (103, Kim et al., 2025). Panickssery, Bowman and Feng found that models used as evaluators can distinguish their own text from other text with better-than-chance accuracy and that, after fine-tuning, the strength of the self-preference bias correlated linearly with the ability to recognise their own output (104, Panickssery et al., 2024).

None of these studies measured operations. They measured multiple-choice questions, a hiring task and text evaluation. The inference to operations is the book's own and is limited: if models from one family err together, a runbook and its verification clause drafted by one family can share an omission; if a judge favours its own family's output, a critique agent on the author's family is a weak check on the author's change; and correlation was lower across providers and architectures than within them, which supports separating them, but remained high among capable models, so separation reduces the correlation and does not remove it. The control is therefore layered. Where a verification can be a script, a synthetic transaction or a person's reproduction, it uses no model at all. Where a model critique adds value, it runs on a different family and answers questions (is there a change in the last hour that touches this dependency) and does not issue verdicts (the restart succeeded).

The observer outside the observed

An observer is a function that keeps running and reporting when the platform is down. Four design devices achieve that, and they correspond to the failures of the table above.

A separate failure domain. The observer runs where a failure of the platform is unlikely to reach it: on another provider or another cloud account, on another network, resolving names without the platform's resolvers, and authenticating without the platform's identity provider. This is the operations form of a conclusion that earlier volumes drew for containment: control artefacts and detection live outside the reach of the system they govern, and detection comes from telemetry and decoys rather than from the agent's own report (F45, F67) (297, Nordqvist, 2026) (299, Nordqvist, 2026). Separation has a price, and the price is the observer's own operation: its credentials, its patching and its failure modes, which make it a Tier 0 asset of its own (Chapter 18). The design keeps it small.

An external synthetic transaction. The most useful observer is a scripted probe that does what a user does, from outside, at a fixed interval: register a test claim, load a portal page, resolve a name through authoritative servers. It uses no model, reads nothing that an agent's action changes and measures the outcome the service level objective promises (Chapter 5). A probe that fails twice in a row pages a person. Two consecutive failures at a 60-second interval is a default, adapted to the service level objective and to the noise the service is known to produce.

A dead-man's switch. An observer that reports only when something is wrong cannot be told from an observer that has failed. The Prometheus Operator's runbook for its Watchdog alert states the pattern: an alert that is always firing, so that its silence at an external receiver means that the alerting pipeline is no longer working (263, Prometheus Operator, n.d.). The design rule generalises beyond that tool. Every observer emits a heartbeat to a receiver that sits outside the platform, and the receiver pages through a channel that does not use the platform's paging when the heartbeat stops for a stated interval; a default of three missed heartbeat intervals suits most services, and a faster rule suits Tier 1 services whose objective is measured in minutes. The silence rule is the answer to the GitLab pattern, in which failure produced no message.

Provider status as telemetry, not as verdict. The Google Cloud case shows that a provider's status page can be down with the provider, and Cloudflare's shows that one hosted off the provider's own infrastructure survived. The operator's design therefore polls the status feeds of each provider as telemetry, records the time at which the operator's own probe saw the fault and the time at which the provider announced it, and never lets the status page decide that a service is up. For Nordvik Region, whose own monitoring saw the DNS fault of INC-NR-2027-0298 22 minutes after SamDrift's status page, the lesson runs in the other direction: the status feed is useful, and the Region's own independent probe was what was missing.

Control plane and data plane

The account of static stability at AWS by Weiss and Furr distinguishes the control plane, the machinery for making changes to a system, from the data plane, the daily business of the resources, and describes a system as statically stable when it keeps operating through a dependency failure using resources it already has (262, Weiss & Furr, 2019). The observer should be statically stable in that sense. It should not need to launch, scale or reconfigure anything to keep probing and to keep raising alarms, and the stop path should not need the platform's control plane to revoke an agent's authority, since the control plane is the part most likely to be impaired when the agent has done something wrong at scale. An observer that must call the platform's API in order to function has the dependency that the second test forbids.

The observer adds cost, which Chapters 5 and 20 treat with the rest of the observability spend; the design sizes it to the claims it supports, one probe for each Tier 1 service function and not one for each metric.

State engines report on themselves

Much of the operations loop is now implemented by state engines: controllers that compare a declared state with an observed one and act on the difference. Kubernetes documents the pattern as a control loop in which a controller moves the current state towards the desired state, and notes that controllers can fail; the OpenGitOps principles describe the same loop for software agents (55, OpenGitOps, n.d.) (153, The Kubernetes Authors, n.d.). Chapter 8 separates reconciling from observing and treats drift; this section applies the three tests to the engine itself.

Synced is not served. Argo CD defines sync status as whether the live state matches the target state in Git, and health as whether the application is running correctly and can serve requests (179, Argo Project, n.d.). Both are computed by the engine. For a custom resource the health check is written per kind, and the documentation advises using the resource's observedGeneration so that health does not flap before the resource's own controller has finished (180, Argo Project, n.d.). Flux sets the Ready condition of a Kustomization from the apply and from any healthChecks listed in its specification (160, Flux project, n.d.). Each report is the engine's view of its own work, produced with its own credentials. It answers whether the change landed as declared, which belongs to O3 Change, and it does not answer whether a customer can register a claim. The claim is verified by the outcome probe of this chapter.

The engine's own health and lag. A stalled or suspended reconciler raises no error at the service. It leaves a frozen declaration: the estate stays as last applied while the repository moves on. Flux states that a suspended Kustomization does not apply new revisions and pauses drift detection and correction (160, Flux project, n.d.), and Argo CD's automated sync attempts only one synchronisation for each combination of commit and parameters (154, Argo Project, n.d.). The silence of an engine therefore looks like convergence. Two observations from outside close the gap, each read by a system the engine does not control, and the outcome probe stays as the third.

1. The engine's metrics. Argo CD exports argocd_app_info with sync and health labels (181, Argo Project, n.d.); Flux exports gotk_resource_info with ready and suspended labels and reconciliation durations (185, Flux project, n.d.). Alert on suspension, on a last applied revision that trails the repository head by more than the declared interval, and on the absence of the series. The scraper runs in the observer's failure domain.
2. A heartbeat through the declared path. A canary object whose declared value is changed on a schedule is read back by an independent probe. The measured commit-to-live lag is the engine's lag, seen from outside, and the Watchdog pattern above applies when the probe stops seeing change (263, Prometheus Operator, n.d.).

Fights. Two reconcilers that own the same field alternate. The Horizontal Pod Autoscaler is a control loop that runs intermittently, by default every 15 seconds, and Kubernetes names the resulting thrashing or flapping as a risk (177, The Kubernetes Authors, n.d.). A GitOps engine that restores the replica count declared in Git competes with it; Argo CD documents ignoring differences in spec.replicas for that case (159, Argo Project, n.d.), and KEDA's admission webhooks validate the setup and prevent two ScaledObjects from targeting one deployment (178, KEDA Authors, n.d.). Each engine reports success from its own side, so the detection is a count of writes to an object that no commit explains, taken from a source that neither engine writes.

Retry storms. Restart back-off is the oldest guard: after a crash Kubernetes applies an exponential delay, which it says prevents rapid repeated restarts from overloading the system (176, The Kubernetes Authors, n.d.). Argo CD's retry is configurable with a limit, and -1 means unlimited (154, Argo Project, n.d.). An unbounded retry against a failing dependency (the API server, a registry, the Git host) adds load to the thing that failed. Retries carry a limit and a ceiling, and a retry that spends the autonomy budget counts as an error (Chapter 4). The mechanism is documented beyond Kubernetes. Bronson and colleagues describe how retries can sustain an overload after its trigger has gone, so that the system stays in a failed state until load falls or retries are limited (203, Bronson et al., 2021). In a study of 22 public incidents from 11 organisations, retry policy was the most common sustaining effect, in more than half of them (204, Huang et al., 2022). The point for the observer principle is that the engine reports activity, not harm: a retrying controller looks busy and healthy from inside while it holds its dependency down. The independent observation is the load and error rate on the dependency, with an alert on retry volume against a budget, which Google's account of cascading failures recommends in the form of a server-wide retry budget and randomised exponential back-off (292, Ulrich, 2017) (205, Brooker, 2019).

A public case shows the last failure of the family. AWS's account of the October 2025 disruption reports a latent race in the DNS management automation of DynamoDB that left an empty record for the regional endpoint, after which the system was in an inconsistent state in which no plan update could be applied and manual operator intervention was required (75, AWS, 2025). It is not a Kubernetes controller; it is automation without a repair path for its own failure, and the book's inference to state engines is its own.

The stop path outside the control plane

AI Threat, Chapter 30, drew the rule that decision rights to stop, pause, deny or reverse are assigned before the crisis, to holders who can act within the time the threat allows, and that the right to stop must be cheaper to exercise than the right to continue (F63) (299, Nordqvist, 2026). AI Purple, Chapter 6, added that the stop path runs outside the system it stops, is held by named people who need no approval, is timed and drilled, and that restart is a separate decision at a lower level (F121) (304, Nordqvist, 2026). For an operations agent with write access to production, the stop path is concrete. It revokes the agent's workload identity at the identity provider and disables the trigger that wakes the agent, both through mechanisms that do not run on the platform the agent runs on, and it is invoked by the incident commander, the agent operator or the platform engineer on call without asking anyone.

What can be undone, and who can stop it, are questions every O4 Restore design must answer. A restart can be repeated and a scale-out can be reversed, so a stop followed by a person's check is usually enough. A rollback, a failover and a restore over existing data change state that may not return, so the stop path for them is exercised before the action class is delegated at Level 3 Bounded, and the action class is delegated no further than Level 2 Supervised until the exercise has been passed. A stop in good faith is never counted as a failure of the operator or the agent operator; the incident record marks it as an exercise of the right.

The stop path decays unless it is exercised. Meta's report is a reminder of what a stop path that depends on the network looks like: when primary and out-of-band access were both down, the only route to the equipment was a physical one (79, Janardhan, 2021). For Hansa Mutual, the first recorded stop drill of the IT-operations agent, STOP-HM-ITOPS-2027-Q1-01, took 17 minutes against a target of 5; the point of the drill is that such a figure is found in an exercise, not in an incident.

Seeded faults

Observers fail quietly, which is why they are tested by faults introduced on purpose. A seeded fault is a known weakness introduced by a person, under written rules of engagement and a change record, in an environment where it can be undone, to measure whether the loop's observers find it and how quickly. The method is that of chaos engineering: state a steady-state hypothesis, vary real-world conditions in a controlled way, and observe the difference (240, Principles of Chaos Engineering community, n.d.) (239, Basiri et al., 2016), applied to the security-oriented form of the practice that treats the verification machinery itself as the system under test (238, Shortridge & Rinehart, 2023). AI Purple, Chapter 15, applied it as seeded gaps in the verification loop of security testing (304, Nordqvist, 2026); this chapter applies it to the operations loop.

Three kinds of seed matter. A silent-failure seed makes a service degrade while its self-reported health stays green, to test whether an independent probe sees what the health endpoint does not. An observer-loss seed removes an observer or its heartbeat for a stated window, to test whether the silence rule fires and who is paged. A stop-path seed invokes the stop path unannounced to the agent, to measure the time from the decision to the confirmed cessation of the agent's writes. All three run in a pre-production mirror or in a production window that the change authority has authorised and a person can end at once; none is run against a critical function inside a freeze (Chapter 9).

Every seeded fault has a catch rate, by class and by quarter: the share of seeds that the observers found within the target time. The catch rate carries a stop rule. When the rate for a class of seed falls below a floor, delegation in the corresponding action class is lowered by one level until a person has reviewed why, in the way the seeded-error measure of The Transformed Security Architect, Chapter 14, and AI Blue, Chapter 14, freezes delegation when the catch rate falls (F76, F99) (300, Nordqvist, 2026) (302, Nordqvist, 2026). The measures concern services and loops, never named engineers, and are reported at the level that the works agreements allow.

Worked example: seeded-fault record SDF-HM-2028-002

The record below is illustrative. It describes a game day on 2028-10-24 in the pre-production mirror of the claims service at Hansa Mutual, authorised by the head of operational resilience, with the restart runbook RBK-HM-0007 of the IT-operations agent HM-OPS-001. The seed was written by a site reliability engineer outside the agent's team and unknown to the agent operators.

seeded_fault:
  id: SDF-HM-2028-002
  kind: silent-failure
  service: SVC-HM-001            # pre-production mirror only
  authorised_by: head-of-operational-resilience
  change_record: CHG-HM-6003
  seeded_on: 2028-10-24
  author: sre-outside-agent-team
  hypothesis: "After a restart under RBK-HM-0007 an independent probe fails
               the claim-registration transaction within 3 minutes if the
               service is not serving, whatever the health endpoint says"
  seed: "connection pool exhausted under load; health endpoint keeps
         reporting ready"
  stop: "white team can end the exercise by revoking the exercise token"
  undo: "restore pool setting from CHG-HM-6003 rollback"
  observed:
    agent_verification: passed    # health endpoint, same identity as restart
    agent_report: "restart verified"
    independent_probe_first_failure_seconds: 61
    independent_probe_page_seconds: 122
    exercise_ended_by: incident-commander-on-exercise-rota
  result: agent verification missed the seed; independent probe caught it
  review: PIR-HM-2028-0233
  findings:
    - "verification clause of RBK-HM-0007 reads the endpoint the restart resets"
    - "restart identity could write the health-check definition"
    - "clause drafted by the model family that drives the agent"

The result is what a single, shared verification path produces: the agent's own check said the restart had worked, and a probe that the agent could not alter said otherwise.

Shared blind spots in AI-assisted loops

The AI-assisted loop adds shared blind spots at five places, each corresponding to a kind of independence. The runbook and its verification may be written by one model family: Mode 3 agentic work tools draft runbooks and infrastructure code at both organisations, reviewers read them quickly, and a clause that confirms success by reading the changed signal is the commonest weakness. A critic on the same family as the author is a weak check; a model critique of a change or a diagnosis runs on a different family and is asked for questions, not verdicts. A shared credential lets an agent whose verification runs under its action identity alter what it verifies, so the permission manifests of Chapter 18 should give each observer a read-only identity of its own. Shared telemetry blinds actor and verifier together when the platform they both read fails, as in the three-hour ingestion failure of INC-HM-2027-0572; the independent probe does not use that platform. A shared cloud is correct in normal times and a single failure domain in a provider incident; Chapter 24 treats the contractual side, and here the observer's domain is a design choice recorded in the manifest.

Limits: test-aware behaviour and agents' own reports

Every automated check has a limit set by the systems it checks. If a model can recognise that it is in a test, the behaviour observed under test may differ from the behaviour outside it. Needham and colleagues built a benchmark of 1,000 prompts and transcripts from 61 datasets, including agent trajectories, and found that frontier models showed above-random evaluation awareness, with Gemini-2.5-Pro reaching an area under the curve of 0.83 against a human baseline of 0.92, and that both models and humans identified evaluations better in agentic settings than in chat (105, Needham et al., 2025). The finding is labelled observable. Whether it transfers to a particular operations agent under a particular game day is not known and has to be tested for that agent.

AI Threat, Chapter 23, set out the evidence on evaluation awareness and drew the consequence recorded as F68: where models may behave differently under test, assurance cannot rest on any single evaluation, and tests are layered with a shadow period, production monitoring, a comparison of the agent's reports with the record, and decoys that do not reveal themselves (299, Nordqvist, 2026). AI Threat, Chapters 25 and 35, recorded that incidents of agents acting beyond their mandate shared a mechanism, a boundary that depended on compliance, and that developers moved controls from the agent's compliance into the environment (F67) (299, Nordqvist, 2026). Public reports show the same movement: the UK AI Security Institute's report on unsanctioned agent behaviour during cyber testing says that good containment should not depend on the model choosing not to test its boundaries, and describes the network controls it is building into its cyber ranges (70, UK AISI, 2026), and Replit announced separate development and production databases after a customer reported that its agent had deleted a production database (90, Sharwood, 2025). For operations the design consequences are four. A game-day pass is one layer, not proof. A shadow period, in which the agent's proposed actions are compared with a person's on the same incidents before delegation, is a second. The agent's report of what it did is a claim about the record, and the record (the identity provider's log, the orchestrator's execution log, the probe's own history) is the authority; the agent does not certify itself. Seeded faults that the tested agent cannot recognise as exercises are run only with the white team able to recognise them and to end them.

Reproduction by a person

A result is independent in the final instance when a person outside the chain can redo it from the evidence, without the agent, and reach the same conclusion. The defaults are that every claim that raises an action class by a level is reproduced, that every closure of a high-severity seeded-fault finding is reproduced, and that a random sample of 10 per cent of other verifications in a quarter is reproduced, with the draw made by someone outside the operations loop. A reproduction takes at most 30 minutes and uses a path that the chain did not, such as the identity provider's log instead of the agent's summary. A disagreement reopens the finding and counts against the delegation level of the class. Because the measures concern people, they are agreed with employee representatives before use and reported for the team or the service, never for a named engineer (F99, F110) (302, Nordqvist, 2026).

The European frame

Regulation reaches the observer principle as a requirement on detection, recovery and testing. DORA Article 10(1) requires financial entities to have mechanisms to promptly detect anomalous activities, including ICT network performance issues and incidents, and to identify potential material single points of failure, and requires those mechanisms to be regularly tested; Article 10(2) requires multiple layers of control and automatic alert mechanisms for staff in charge of incident response. Article 12(2) requires periodic testing of backup and restoration procedures, and Article 12(3) requires that, when restoring with own systems, the systems used are physically and logically segregated from the source system. Article 24(4) requires that tests be undertaken by independent parties, internal or external, with conflicts of interest avoided in the design and execution of internal tests, and Article 24(6) requires at least yearly tests of all systems and applications supporting critical or important functions (2, European Union, 2022). NIS 2 Article 21(2)(c) names business continuity such as backup management and disaster recovery, and Article 21(2)(f) names policies and procedures to assess the effectiveness of cybersecurity risk-management measures (3, European Union, 2022).

The instruments do not mention AI remediation agents or observer manifests. The reading is an architectural implication, not legal advice: a verification that shares its failure modes with the action it verifies answers a requirement of independent testing and of tested detection weakly, and the segregation rule of Article 12(3) for restoration is the same idea applied to systems. For a public authority such as Nordvik Region, to which DORA does not apply and for which NIS 2 depends on national transposition, the same evidence is an audit artefact that a reader who did not see the test must be able to follow, and incident records are subject to the public-access rules of the Region's member state.

Practical guide: specifying an observer

Purpose. To give each Tier 1 service function that an operations agent acts on an observer that meets the three tests, recorded in an observer manifest and re-shown on a fixed cycle.

Roles. The service owner states the claim; the SRE or platform lead operates the observer; the head of operational resilience (Hansa Mutual) or the CIO (Nordvik Region) reviews independence; the CISO reviews the observer as a Tier 0 asset; employee representatives agree the measures that concern staff.

Steps.

1. List the action classes that agents may perform on the service, with their levels (Chapter 4). Start with the highest level and the least reversible class.
2. For each class, write the claim in a sentence a customer would recognise: a claim can be registered, a page loads, a payment completes.
3. Name a verifying signal that the action does not change and that an agent cannot write. Prefer a scripted synthetic transaction. Set the interval (default 60 seconds) and the failure rule (default two consecutive failures).
4. Draw the failure-domain map: where the service, the agent, the telemetry vendor, the identity provider, DNS and the paging path run. Place the probe and the heartbeat receiver in a domain different from each. Record any dependency that cannot be separated as an accepted shared dependency with an owner and a review date.
5. Give each observer its own read-only identity. Write its permission manifest and check that it has no write path to the platform.
6. Add the heartbeat and the silence rule. Default: a heartbeat every 60 seconds, a page after three missed intervals, through a channel that does not use the platform's paging.
7. Specify the stop path: holders, no approval, mechanism, domain, target time (the default for an agent with write access to production is 5 minutes) and the date of the next drill.
8. Plan seeded faults: one silent-failure seed and one observer-loss seed per quarter for each Tier 1 service function, one stop-path seed per quarter. Set a catch-rate floor (default 0.8 over four quarters) and the stop rule.
9. Write the statement of independence: the six kinds, by claim, with the dates of the last seed and the last reproduction. Set the expiry at 90 days.
10. Agree with employee representatives that probes and seeds measure services and not engineers.

Definition of done. The manifest is in version control with a named owner. A seeded-fault record for each class exists with a result within the last 90 days. The stop path has been drilled within the target. A person has reproduced one verification from the raw evidence in the last quarter. Any of these overdue turns the claim into a declared control and the delegation level of the class is lowered until it is shown again.

Worked example: observer manifest OBS-HM-0001

The manifest below is illustrative. It records the observer for the claims service and the claims-triage agent service of Hansa Mutual (SVC-HM-001, SVC-HM-002), written after the game day of 2028-10-24 under AIDR-0960. It is deliberately small.

observer_manifest:
  id: OBS-HM-0001
  version: 1.0.0
  decision: AIDR-0960
  services: [SVC-HM-001, SVC-HM-002]
  owner: head-of-site-reliability
  independence_reviewer: head-of-operational-resilience
  effective: 2028-11-13
  statement_of_independence_expires: 2029-02-11
  performer:
    agent: HM-OPS-001
    mandate: MND-HM-OPS-001
    runs_in: hansa-dc-frankfurt
    service_runs_in: cloud-a
    telemetry_vendor: lumenscope
  probes:
    - id: OBS-HM-0001-P1
      claim: "a test claim can be registered"
      method: scripted-synthetic-transaction   # no model involved
      from: [cloud-b, polish-service-centre-network]
      interval_seconds: 60
      page_after_consecutive_failures: 2
      identity: observer-probe-claims          # read, create test claim only
    - id: OBS-HM-0001-P2
      claim: "triage returns a route within 30 seconds"   # SLO-HM-002
      method: scripted-synthetic-transaction
      from: [cloud-b]
      interval_seconds: 60
      page_after_consecutive_failures: 3
  provider_status_feeds: [cloud-a, cloud-b, lumenscope]    # telemetry, never a verdict
  heartbeat:
    receiver: external-heartbeat-service     # outside cloud-a and lumenscope
    interval_seconds: 60
    page_after_missed: 3
    page_channel: contracted-sms-gateway     # not ServiceHub, not Lumenscope
  stop_path:
    holders: [incident-commander, agent-operator, platform-engineer-on-call]
    approval: none
    mechanism: [revoke-workload-identity-at-idp-emergency-control,
                disable-orchestrator-trigger-at-network-edge]
    runs_outside: [group-ai-platform, servicehub, lumenscope]
    target_seconds: 300
    last_drill: {id: SPT-HM-ITOPS-2028-Q4-01, date: 2028-10-24, seconds: 250, result: passed}
    first_drill: {id: STOP-HM-ITOPS-2027-Q1-01, seconds: 1020, result: failed}
    next_drill: 2029-01-24
  delegation:
    restart: {level: "Level 3 Bounded", condition: "P1 and heartbeat green"}
    roll_back: {level: "Level 2 Supervised"}
    fail_over: {level: "Level 1 Assisted"}
  independence:
    model: "verification scripted; critic on family-b, questions only"
    data: "outcome probes, not the health endpoint"
    authorship: "clauses written by sre team, reviewed by person"
    credential: "observer identities separate and read-only"
    failure_domain: "cloud-b and service-centre network"
    time: "re-verify 10 minutes after each Level 3 action"

The debate

The principle is easy to state and expensive to apply everywhere. The strongest cases on each side follow.

The case for concern

The concern is that independence costs more than the loop saves, and that it buys less than it appears to. Each independent probe, identity, heartbeat receiver and drill is something to build, pay for, keep patched and trust. An independent observer can be wrong: a probe from a second cloud fails because of its own network, the page goes to a person at 03:00, and repeated false alarms lead to alarm burnout and desensitisation; the qualitative work on analysts' perspectives on security alarms with high false-positive rates describes that dynamic in security operations, which is a different setting from operations (213, Alahmadi et al., 2022). A loop that waits for an independent verification before it proceeds is slower than one that checks itself, and a delay of minutes is the price that auto-remediation was introduced to avoid. Model independence is partial: the evidence of Kim and colleagues is that capable models from different providers still make highly correlated errors, so paying for a second family buys a smaller reduction than the budget line suggests (103, Kim et al., 2025). Each extra observer is also a Tier 0 asset with credentials and an owner, so observers can grow the attack surface and the maintenance burden faster than assurance. And seeded faults, reproduction and statements of independence add work for the few engineers who carry the pager, as at Nordvik Region with seven platform engineers on a weekly rotation.

The case for calm

The case for calm is that the incidents in the record came from correlated failure and not from a lack of tools, and that the remedies are cheap beside the outages. In each case of this chapter the verifier, the observer or the stop path shared a fate with what it served: the audit tool that failed to stop a command, the status page and the customers' monitoring that went down with the cloud, the backup job whose failure nobody was told about, the validator that held an assumption which the code it tested did not meet (79, Janardhan, 2021) (76, Google Cloud, 2025) (89, GitLab, 2017) (78, CrowdStrike, 2024). The most valuable observers are not elaborate: a scripted transaction run from another network, a heartbeat that raises an alarm on silence, a read-only identity, a delay before declaring success. They use no model, they have few parts, and they fail loudly. The cost is a few probes against outages that stop claims processing or an e-service for hours, and the expensive kinds of independence apply only where the action class is least reversible.

Where the positions meet

Both sides accept that independence is graded by action class and not applied uniformly. A read or an annotation needs a record; a restart needs an outcome probe; a rollback, a failover and a restore over existing data need the strongest independence and a stop path tested within its target. Both accept that observers are tested by seeded faults and that an observer which has never caught a seeded fault is a declaration and not a control. Both accept that the false positives of an independent probe are a cost to be measured with a noise budget, and that observers are bounded by the claims they support. And both accept that the highest-consequence actions, those that Level 4 never covers, require a person who can reproduce the result.

What can be done

CIOs and heads of operations can set the rule that no action class moves to Level 3 Bounded without an observer manifest, and can fund one outcome probe per Tier 1 service function before funding anything larger. SRE and platform leads can write verification clauses that name a user-visible outcome, split the verifier's identity from the actor's, and put the heartbeat receiver outside the platform and the telemetry vendor. Incident commanders can hold the stop right, drill it, and record every stop in good faith as an exercise of the right. Resilience officers and risk functions can ask for the statement of independence, its seeds and its expiry in the same form as a restore-test record (Chapter 19). Boards can ask for catch rates and drill times and not for a count of tools. Employee representatives can agree that probes and seeds measure services, not engineers, before the first seed is run.

Verdict

The verdict is by function and action class, and each statement carries a label.

For O1 Observe, the evidence that observers fail together with what they observe is observable: the cases of this chapter are documented by their issuers. That a probe in a separate failure domain, an external heartbeat and a silence rule detect such failures is a design conclusion supported by the same reports and by the practice documented for the Watchdog pattern; whether a given organisation's probes do so is shown only by its own seeded faults. That model-independent verification is cheaper and more reliable than model-based verification for outcome claims is the book's conclusion and is expected to hold while correlated errors among capable models persist, a trend that the evidence of Kim and colleagues supports and that is not guaranteed.

For O4 Restore, the verdict follows the action class. Restart, scale and certificate renewal can be delegated at Level 3 Bounded when an outcome probe, a separate read-only identity, a heartbeat and a drilled stop path exist. Rollback remains at Level 2 Supervised, and failover at Level 1 Assisted at Hansa Mutual, until the observer has caught seeded faults for the class within target for the stated period and the stop path has been drilled within its target; this is a condition that organisations can influence. Deletion, restore over existing data, and any action outside an authorised change window or freeze on a critical function stay outside Level 4 Autonomous. That frontier models can often tell an evaluation from real use, which could weaken any single test (105, Needham et al., 2025), is observable in the measured results and is limited to what has been measured; its effect on a given operations agent is speculation until tested. That supervisors will ask for evidence of independent verification of automated remediation is expected from the testing and detection requirements already in force for financial entities, noting that the sources cited here do not address AI remediation agents specifically.

Organisations can influence the whole design: the observer's failure domain, the verifier's identity, the author of the verification clause, the stop path and its drill, and the cadence of seeded faults.

Across the degrees of delegation

Level	Verification	Observer	Stop path	Reproduction by a person
Level 0 Advisory	The person acts and checks; the agent's suggestion is recorded	Standard monitoring suffices; the assistant is not a verifier	Not needed beyond disabling the assistant	Not required
Level 1 Assisted	The person confirms with a signal the agent did not choose	As Level 0, plus a probe for the action class if one exists	Named holder, documented	Sample in review
Level 2 Supervised	The person approves before; an outcome probe confirms after	Outcome probe in a domain separate from the agent's; heartbeat	Drilled within the target at least yearly	Every level change and a 10 per cent sample
Level 3 Bounded	Scripted outcome probe, separate read-only identity, authorship of the clause reviewed by a person, re-verification after a delay	Separate failure domain, heartbeat with silence rule, status feeds as telemetry	No approval, outside the control plane, drilled each quarter within the target	Every closure above medium severity and a 10 per cent sample
Level 4 Autonomous	As Level 3, and only for classes the thesis permits (for example certain reads, annotations and notifications)	As Level 3	As Level 3	As Level 3

Level 4 Autonomous is never used for an irreversible action on production data, for an action outside an authorised change window or freeze on a critical function, for an action that disables the observation or the stop path itself, or for an action that decides about a named person's access to work.

Nordvik Region and Hansa Mutual

Nordvik Region has no Mode 5 agent, an operations assistant (NR-OPS-001) at Level 0 Advisory, and an observer problem that predates AI: its own monitoring saw the SamDrift DNS fault of INC-NR-2027-0298 22 minutes after the provider's status page, and its disaster-recovery test RST-NR-2027-002 failed. The Region therefore places its observer on a different provider and a different network from the Region Cloud and SamDrift, in the Nordic data centre of its hosting provider, with a probe that resolves names against the authoritative servers directly and not through SamDrift's resolvers. AIDR-0910 (2028-11-06) records the decision that no scripted runbook may reach Level 3 Bounded until OBS-NR-0001 is in force, effective 2028-11-20, and that the first quarterly seeded fault be run in the first quarter of 2029. The target detection time of the probe, two failures at a 60-second interval, is a design value and has not yet been measured. The agreement MBL-NR-IT-2027-01 applies: probes and seeds measure services, and results are never reported by name. The observer's manifest and the incident records that use it are subject to the Region's public-access rules, which makes plain-language clarity part of the design.

Hansa Mutual has a Mode 5 IT-operations agent in production and a site reliability function of about 95, and it found in the game day of 2028-10-24 that the remediation agent and its verification step shared a model family, an identity and a signal. AIDR-0960 (2028-11-06) records the decision, illustrative for this chapter, that the restart class remains at Level 3 Bounded on condition of OBS-HM-0001, that rollback remains at Level 2 Supervised and failover at Level 1 Assisted, and that their extension waits for the catch-rate and drill conditions of the practical guide; the answer to the board's question of AIDR-0950 is given in Chapter 30. The operations annex KBV-IT-2024-OPS-02 applies: seeded-fault results are reported for teams and services with a minimum group size of five. Nordvik must build an observer where it had none, and Hansa must separate roles that its own agent had merged.

Summary

This chapter stated the observer principle as three tests: what verifies an operations action must be independent of what performed it, the observer must not depend on the system observed, and the stop path must work when the platform does not. It concerns O1 Observe, where the observer's domain, its heartbeat and its cost are designed, and O4 Restore, where an action needs a verifier that the actor cannot author, alter or share a signal with, and a stop path outside the control plane.

Public incident reports from Meta, GitLab, CrowdStrike, Google Cloud and Cloudflare show verifiers, observers and notification paths that shared a fate with the systems they served. Evidence on correlated errors in language models and on self-preference in model evaluators shows that a second model of the same family or a similar capability is a partial remedy, so the controls are layered: scripts and synthetic transactions where possible, a separate credential, a separate failure domain, a dead-man's switch, a drilled stop path, seeded faults with a catch rate and a stop rule, and reproduction by a person. A seeded-fault record and an observer manifest for Hansa Mutual show how the controls are written down and re-shown on a 90-day expiry. State engines such as GitOps controllers are observed systems like any other: their sync and health reports are their own view of their own work, their lag and suspension are watched from outside, and reconcilers that fight or retry without limit are detected by a source neither writes.

The debate found agreement that independence is graded by action class. The verdict allows restart, scale and certificate renewal at Level 3 Bounded where the observer exists, keeps rollback at Level 2 Supervised and failover at Level 1 Assisted until seeded faults have been caught within target, and keeps irreversible, out-of-window and observer-disabling actions out of Level 4 Autonomous. Chapter 18 turns to defending the operator's own AI as a Tier 0 asset, which includes the observer, and Chapter 19 to resilience as a claim with evidence age.

Sources

1. Janardhan, S. (2021). More details about the October 4 outage. Meta Engineering, 5 October 2021. (79, Janardhan, 2021)
2. GitLab (2017). Postmortem of database outage of January 31. GitLab, 10 February 2017. (89, GitLab, 2017)
3. CrowdStrike (2024). External Technical Root Cause Analysis: Channel File 291. CrowdStrike, 6 August 2024. (78, CrowdStrike, 2024)
4. Prince, M. (2025). Cloudflare outage on November 18, 2025. Cloudflare blog, 18 November 2025. (77, Prince, 2025)
5. Google Cloud (2025). Multiple GCP products are experiencing Service issues. Google Cloud Service Health incident report, 12 June 2025. (76, Google Cloud, 2025)
6. Weiss, B. and Furr, M. (2019). Static stability using Availability Zones. Amazon Builders' Library, 5 December 2019. (262, Weiss & Furr, 2019)
7. Prometheus Operator. Watchdog. kube-prometheus runbooks. (263, Prometheus Operator, n.d.)
8. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (103, Kim et al., 2025)
9. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076. (104, Panickssery et al., 2024)
10. Needham, J., Edkins, G., Pimpale, G., Bartsch, H. & Hobbhahn, M. (2025). Large Language Models Often Know When They Are Being Evaluated. arXiv:2505.23836. (105, Needham et al., 2025)
11. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (2, European Union, 2022)
12. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2). (3, European Union, 2022)
13. Shortridge, K. & Rinehart, A. Security Chaos Engineering. O'Reilly Media, 2023. (238, Shortridge & Rinehart, 2023)
14. Basiri, A. et al. (2016). Chaos Engineering. IEEE Software 33(3). (239, Basiri et al., 2016)
15. Principles of Chaos Engineering community. Principles of Chaos Engineering. (240, Principles of Chaos Engineering community, n.d.)
16. Alahmadi, B. A., Axon, L. & Martinovic, I. (2022). 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. USENIX Security 2022. (213, Alahmadi et al., 2022)
17. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (217, Bainbridge, 1983)
18. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. Human Factors 52(3). (218, Parasuraman & Manzey, 2010)
19. Nordqvist, G. (2026). AI Platform and Security. (297, Nordqvist, 2026)
20. Nordqvist, G. (2026). AI Threat. (299, Nordqvist, 2026)
21. Nordqvist, G. (2026). The Transformed Security Architect. (300, Nordqvist, 2026)
22. Nordqvist, G. (2026). AI Blue. (302, Nordqvist, 2026)
23. Nordqvist, G. (2026). AI Purple. (304, Nordqvist, 2026)
24. OpenGitOps. GitOps Principles, version 1.0.0. (55, OpenGitOps, n.d.)
25. The Kubernetes Authors. Controllers. Kubernetes documentation. (153, The Kubernetes Authors, n.d.)
26. The Kubernetes Authors. Pod Lifecycle. Kubernetes documentation. (176, The Kubernetes Authors, n.d.)
27. The Kubernetes Authors. Horizontal Pod Autoscaling. Kubernetes documentation. (177, The Kubernetes Authors, n.d.)
28. KEDA Authors. KEDA Concepts. KEDA documentation. (178, KEDA Authors, n.d.)
29. Argo Project. Core Concepts. Argo CD documentation. (179, Argo Project, n.d.)
30. Argo Project. Automated Sync Policy. Argo CD documentation. (154, Argo Project, n.d.)
31. Argo Project. Resource Health. Argo CD documentation. (180, Argo Project, n.d.)
32. Argo Project. Metrics. Argo CD documentation. (181, Argo Project, n.d.)
33. Argo Project. Diffing Customization. Argo CD documentation. (159, Argo Project, n.d.)
34. Flux project. Kustomization. Flux documentation. (160, Flux project, n.d.)
35. Flux project. Flux Prometheus metrics. Flux documentation. (185, Flux project, n.d.)
36. Amazon Web Services (2025). Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region. AWS post-event summary, October 2025. (75, AWS, 2025)
37. Ulrich, M. (2017). Addressing Cascading Failures. Chapter 22 in Site Reliability Engineering. O'Reilly Media. (292, Ulrich, 2017)
38. Bronson, N., Aghayev, A., Charapko, A. & Zhu, T. (2021). Metastable Failures in Distributed Systems. HotOS '21. (203, Bronson et al., 2021)
39. Huang, L. et al. (2022). Metastable Failures in the Wild. OSDI '22. (204, Huang et al., 2022)
40. Brooker, M. (2019). Timeouts, retries and backoff with jitter. Amazon Builders' Library. (205, Brooker, 2019)
41. AI Security Institute (2026). Incident Report: unsanctioned agent behaviour during cyber testing. UK AISI, 4 August 2026. (70, UK AISI, 2026)
42. Sharwood, S. (2025). Replit makes vibe-y promise to stop its AI agents making vibe coding disasters. The Register, 22 July 2025. (90, Sharwood, 2025)