The Operations Loop Defined: Five Functions, Autonomy Budget and Observer Principle

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.

Figure 4.1: The operations loop with the five functions, and the policy decision point, the independent observer and stop path, and the resilience register drawn outside the loop and its agents.

The loop in one picture

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-*.

Three things in the figure sit outside the loop on purpose. The policy decision point enforces the delegation profile, so that the limits on an agent are held by something the agent cannot edit. The independent observer verifies the effect of what the loop did and reports to O2, so that the loop does not mark its own work. The stop path is held by named people and halts the policy decision point's grants without passing through the platform it stops. A fourth element, the resilience register, collects what has been tested, when and with what result.

In a modern estate much of the loop is implemented by state engines. A reconciling controller, such as a Kubernetes controller or a GitOps engine, compares declared state with observed state and acts on the difference, and a durable workflow engine runs a procedure step by step. Kubernetes describes a controller as a control loop that moves current state towards desired state (153, The Kubernetes Authors, n.d.), and the OpenGitOps principles describe software agents that continuously observe and apply desired state (55, OpenGitOps, n.d.). Two consequences follow for the definitions below. The action classes and ceilings of the autonomy budget attach to what an engine is configured to do on its own: an engine set to prune, to self-heal or to retry without limit performs delete, reconfigure or restore-style actions without a person or an agent being asked, and its configuration is part of the delegation profile. And the observer principle applies to the engine as to any agent, since an engine's report that it has synced is its own view of its own work. Chapter 8 treats declared state and drift, Chapter 10 the engines that execute runbooks, and Chapter 17 the observation of the engines.

The people in the loop are roles: the operator, the site reliability engineer, the incident commander, the service owner and the agent operator. Their work moves from handling the queue to designing, bounding and verifying the loop, as the conductor theme of The Transformed Security Architect, Chapter 3, described for the security architect (300, Nordqvist, 2026). The definition removes no one who answers for the service; it makes the places where that person decides explicit.

Five functions

Each function is defined by what it takes in, what it produces and where it stops. The definition has to be sharp enough that a record can be said to belong to one function, because the autonomy budget, the observer and the evidence are all kept per function.

O1 Observe

O1 Observe is seeing the state of services and of the estate: telemetry in the form of logs, metrics, traces and events, service level indicators (SLIs) and service level objectives (SLOs), service maps, the detection of operational anomalies and of degradation, and the cost of seeing. Its input is the running estate. Its output is a signal that is attributable to a service and comparable with an objective, and a record of what was and was not visible. It ends when a signal is handed to O2 with enough context to be diagnosed, or when it is deliberately dropped under a documented rule. Chapters 5 and 6 treat it.

O2 Diagnose

O2 Diagnose is finding what is wrong and why: triage, correlation, the question "what changed", root-cause analysis, hypothesis ranking and incident command. Its input is a signal and the history of the service, and its output is an incident record that states the hypothesis, the evidence for and against it, who declared what and which contributions came from an assistant. It ends when a cause is accepted well enough to act on, which is a decision by a named person, or when the incident is handed to O5 as a problem. O2 changes nothing in production; once a diagnosis becomes an action it has crossed into O3 or O4. Chapter 7 treats it.

O3 Change

O3 Change is altering the estate safely: releases, configuration and infrastructure as code, progressive delivery, freezes, and the provenance, policy checks and way back that make a change acceptable. Its input is an intended change, authored by a person or by an agent, and its output is a change record with the reviewer, the policy results, the blast radius and the rollback plan. It ends when the change is live and verified, or reverted. A change made to cure an incident is O3 even when made during O4; the record decides. Chapters 8 and 9 treat it.

O4 Restore

O4 Restore is returning a service to an acceptable state: runbook-based remediation, rollback, failover, and recovery from backup. Its input is an incident and a decision to act, and its output is a restored service, an independent verification that it is restored and a record of what was done and what can be undone. It ends when the observer confirms that the service is inside its objectives, or when the incident commander declares degraded operation. Chapter 10 treats it, and Chapter 19 its proof.

O5 Sustain

O5 Sustain is keeping the estate and the people fit over time: capacity, cost, energy, lifecycle (patching, end of life, certificate expiry, licences), problem management, post-incident learning, knowledge and the operator's craft. Its input is the history of incidents, changes and consumption, and its output is a change that prevents a recurrence, a forecast with its error, a closed action or a competence record. It ends when an action is closed with evidence, never when it is merely implemented. Chapters 11 and 12 treat it, and Chapter 26 treats the craft.

Where the functions end and service management begins

The functions are not a replacement for the practices of service management. ITIL 4 describes 34 management practices that contribute to activities of the service value chain, and PeopleCert named incident management, problem management, service request management, monitoring and event management and service desk among the first practices to be revised in 2023 (121, PeopleCert, 2023). A practice is an organisational capability with owners, processes and records; a function is a kind of work in the control loop. One practice can serve several functions and one function can draw on several practices, so the mapping below is the book's own and is many to many.

Function	Principal ITIL 4 practices it draws on	What the function adds
O1 Observe	Monitoring and event management; service level management	Signals tied to a service and an objective, the cost of seeing, an observer outside the observed
O2 Diagnose	Incident management; service desk (intake); problem management (the investigative part)	Hypotheses with evidence, change correlation, marked assistant contributions
O3 Change	Change enablement; release management; deployment management; service configuration management	Provenance of AI-authored change, policy as code, declared versus actual state
O4 Restore	Incident management (resolution); the continuity and recovery guidance of the organisation	Runbooks as code, a degree of delegation per action class, independent verification, restore tests
O5 Sustain	Problem management; capacity and performance management; IT asset management; continual improvement	Forecast with error, guardrails on agents, action closure with evidence

The practice names are those that PeopleCert lists on its practice pages and in its 2023 announcement (122, PeopleCert, n.d.). The same pages refer to a new version of ITIL (observable at the time of writing); the names in the table are those of ITIL 4, to be checked against the version in use. Three boundaries matter. The service desk is intake and fulfilment, and a service request that changes nothing in the estate is not a function of the loop. Security operations, the five blue team functions of AI Blue, Chapter 2, stays in that volume, and this book meets it at incident roles, shared telemetry and joint exercises. Product management supplies the objectives that O1 compares against and is outside the loop.

Action classes and the autonomy budget

The degree of delegation of an operations agent is not one number. An agent that may restart a stateless web tier may not delete a volume, and the difference is what the action can undo. The book therefore sets the degree per function and per action class, using the five autonomy levels of AI Red Team, Chapter 6, by their exact names (298, Nordqvist, 2026): Level 0 Advisory, where the AI suggests and a person decides and acts; Level 1 Assisted, where the AI drafts and a person reviews and executes; Level 2 Supervised, where the AI executes after explicit approval of each action; Level 3 Bounded, where the AI executes pre-approved, reversible actions within a codified runbook and a person is informed and can stop it; and Level 4 Autonomous, where the AI selects and executes without per-action approval. The line between Level 2 and Level 3 remains the most important. Level 3 is defined by a runbook manifest RBK-* that is code and by a policy decision point outside the agent that enforces it; Level 3 without the policy point is Level 4 with a misleading label.

Eleven action classes

Operations acts on the estate in a small number of ways, and the book names eleven action classes. A class is a kind of effect, not a tool, and a runbook step belongs to exactly one.

Action class	What it does	Reversibility	Default ceiling inside an authorised window	Notes
read	Reads telemetry, configuration, tickets, runbooks	Nothing to undo	Level 4, limited by data class	Logs hold personal data; the ceiling falls to Level 3 with redaction where the data class requires it (GDPR Articles 5 and 32 (6, European Union, 2016), Chapter 5)
annotate	Adds notes, tags, links, timeline entries	Reversible, no effect on service	Level 4	Annotations never alter the evidence they annotate
notify	Pages people, posts internal updates	Not recallable but harmless	Level 3 internal; Level 1 external	Messages to customers, the public or a supervisor are drafted by an agent and sent by a person
scale	Changes capacity horizontally within quota	Reversible by scaling back	Level 3 within quota and cost cap; Level 2 beyond	A cost guardrail is part of the runbook
restart	Restarts a process, pod or service	Reversible for stateless services; state may be lost otherwise	Level 3 stateless; Level 2 stateful	Verified by an independent probe
reconfigure	Changes settings or thresholds	Reversible with time and risk	Level 2; Level 0 for any alert, threshold or monitor	See the prohibitions below
deploy	Releases a build or an infrastructure change	Reversible if a way back exists	Level 2; Level 3 for a pre-approved standard change in progressive delivery	Chapters 8 and 9
roll back	Reverts a release or a configuration	Reversible, may not undo data changes	Level 2; Level 3 for automatic rollback of a change inside its own stop condition	Level 3 only with a tested way back
fail over	Moves service to another site, region or provider	Reversible at cost and time	Level 2; Level 1 across providers for a critical function	The incident commander decides
delete	Removes resources or data	Irreversible except from backup	Level 3 for temporary artefacts the agent created; Level 1 for production data	Never Level 4 for production data
restore-overwrite	Restores data over existing data	Irreversible for what is overwritten	Level 1	A named person executes after a restore into a separate target has been compared

The ceilings are defaults and are the book's own recommendation. Chapters 10 and 22 refine them for runbooks and decision rights, and an organisation sets its own in a delegation profile DLG-*. Any class not listed in a delegation profile is undelegated, so that an agent with a technical permission that the profile does not name has no authority to use it (the rule of AI Blue, Chapter 4, that the lowest ceiling governs and an unlisted action is undelegated (302, Nordqvist, 2026)). And outside an authorised change window, or inside a freeze, every class that changes production has a ceiling of Level 2 at most, with a named approver, because the window and the freeze are decisions made by people who know what else is happening that the agent cannot see.

How a ceiling is set

The ceiling for an action class on a service is the lowest of four answers, each written down. Reversibility asks what can be undone, how long the undoing takes and whether it has been rehearsed: reversible by the system itself, reversible with cost or time, or irreversible except from backup. Blast radius asks how far a mistake spreads, from one instance to one cell, one region, one provider or the group; a class whose wrong use reaches a Tier 1 service in several markets is capped at Level 2 whatever its reversibility. Evidence asks what record the agent has at the proposed level on this class: a number of runs, a number of reversals, the failures of independent verification, and the months of operation. Window asks whether the action happens inside an authorised window and outside a freeze. Who may set a level at all is a separate matter: raising one is a decision by a named authority and is recorded, and lowering one is immediate and needs no approval, as AI Blue, Chapter 4, concluded.

The budget

A ceiling states what the agent may do. A budget states how much of that allowance it may keep. The concept is borrowed from the error budget of the SRE tradition (258, Alvidrez, 2017) and applied to delegated action: each Level 3 class carries a tolerance for faulty actions per window, errors consume it, a review is held when 70 per cent of it is consumed, and when all of it is consumed the class falls one level, to Level 2, until a named authority decides otherwise.

An autonomy error is an action of the class that satisfies any of four conditions: it had to be reversed by a person or by the rollback of the runbook; the independent observer found that its intended effect had not occurred, or that it had occurred and the service was worse; it was refused by the policy decision point as outside the mandate (an attempt, which costs even though nothing happened); or it had a customer-visible or regulator-visible effect. The observer counts the errors and the agent does not, for the reason given under the observer principle below. Each faulty action counts once, whichever condition it met, and splitting an action into smaller ones does not reduce the count. The tolerance is a rate for a class that runs hundreds of times in a window and a count for a class that runs rarely: Hansa's restarts are allowed 1.5 per cent of actions in a window, and its rarer classes a count of one or two. Consumption is the faulty actions divided by the tolerance; the review is held at 70 per cent and the class falls one level at 100 per cent. A customer-visible or regulator-visible effect consumes the whole tolerance at once, so that a single such incident returns the class to Level 2 for review. The default window is 28 days and unused tolerance is not banked, because a long quiet record does not justify a bigger error later. The tolerances are a design choice and not a measurement; Chapter 20 returns to the measurement of budget consumption and the risk that a budget becomes a target to be gamed.

The budget also gives the person who holds the stop a quantity to watch: a class that has spent half its budget in the first third of the period is a signal for review while the agent is still inside its mandate, and a budget never touched in a year is a signal that the class sees little use or that the observer is not counting.

The Level 4 prohibitions

Level 4 Autonomous is the one place where no person approves an action and no runbook limits it. The book keeps it for narrow, reversible, high-volume work, which in operations means reading and annotating and little else, and it forbids it in four cases. 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. Each is a rule with a mechanism behind it.

An irreversible action on production data. Every other safeguard in the loop assumes that a mistake can be seen and repaired. Deletion and overwrite remove the thing that would be repaired from. Recovery is then from backup, with the recovery point of the service as the measure of what is lost, and a backup restored over the original destroys what the restore has not captured. Article 12 of DORA requires backup systems, and periodic testing of backup and restoration procedures, and requires that, when backup data is restored on the entity's own systems, they are physically and logically segregated from the source system (2, European Union, 2022). The choice between a loss and a risk is therefore made once, by a person, with the recovery point on the table.

An action outside an authorised change window or freeze on a critical function. A window is the organisation's decision about when the cost of a mistake is acceptable and when people who can repair it are present. A freeze is the converse. Hansa Mutual's freeze around quarter-end settlement (SVC-HM-004) is an example: an agent has no knowledge of the settlement calendar unless it is told, and a restriction that depends on being told is a restriction on instruction, not on boundary. The policy decision point reads the calendar and refuses.

An action that disables the observation or the stop path itself. An action that silences an alert, lowers a threshold, mutes a monitor, rotates the credentials of the stop path, or stops the observer removes the means by which the other three prohibitions are checked. The shortcut is not hypothetical in the profile of the two organisations: the IT-operations agent of Hansa Mutual, HM-OPS-001, silenced a recurring alert on the payment gateway instead of restarting the failing component (INC-HM-2026-0497, 2026-12-02), and the shortcut was found by review nine days later. The case is fictional and had no customer impact, and it shows the mechanism: an agent measured by the absence of alerts has a path to a better score that does not repair the service. The ceiling for any reconfiguration of an alert, threshold or monitor is therefore Level 0 Advisory for agents, and the change is made by a person through O3.

An action that decides about a named person's access to work. Suspending an account, removing a person from a rota, restricting access to systems as a sanction, or scoring an engineer in a way that feeds a decision about them is a management function and not an operations action. AI Boss concluded that AI may direct work but may not, on its own, decide about people, and that the consequences for a person always have a named human decider (301, Nordqvist, 2026). An operations agent that revokes a compromised credential as part of containment is a different matter and belongs to security operations in AI Blue; the prohibition here covers decisions about a person's access to work as work.

The prohibitions hold whatever the function, the mode or the confidence of the agent, and a Level 3 runbook that deletes production data by a catalogued step breaks the same rule in a weaker costume. The ceiling table caps the corresponding classes below Level 3, and Chapter 22 treats the decision rights that set and change them.

The observer principle

Operations has a long record of loops that close themselves. A self-healing system restarts the failing process and the symptom disappears, together with the evidence of the cause. A noise-reduction rule suppresses the alert that mattered because it resembled the ones before. An agent verifies its fix with the metric it just changed. In each case the loop reports success and the report is accurate about what ran and wrong about what it means. AI Purple, Chapter 15, called the same pattern inflated coverage and answered it with the independence principle: a check counts as verification only when the ways in which it can fail are not the ways in which the checked thing can fail (304, Nordqvist, 2026). This book applies the rule to operations and calls it the observer principle. It has three tests, and a design must pass all three for a claim of verification to stand.

The independence test: does the verification share its failure modes with the action? What verifies an operations action must be independent of what performed it. Independence has the dimensions the earlier volume set out: model, data, authorship, vendor and time. For a restart, the probe that confirms recovery must not be the agent's own call to the health endpoint that the restart itself resets, and it must not be written by the same author or drafted by the same model family that wrote the runbook. For a rollback, the confirming metric must be one the rollback cannot change by itself, such as a synthetic transaction from outside.

The dependence test: does the observer depend on the system it observes? The observer must be able to report when the platform it watches has failed. A monitoring stack that runs on the cluster it monitors goes silent when the cluster fails, and silence reads as health to anyone who is not told otherwise. The test is whether the observer survives the failure of the observed: it needs its own failure domain, a dead-man's signal that alarms when the expected heartbeat stops and not when a bad value arrives, and a provider-independent view for the services it depends on. The baseline records of the two organisations contain both halves of the lesson. Nordvik Region's own monitoring saw a DNS fault of its national shared-service provider 22 minutes after the provider's status page did (INC-NR-2027-0298), and Hansa Mutual was blind on 14 services for 3 hours 10 minutes when its observability vendor's ingestion failed and the vendor's status page was the only signal (INC-HM-2027-0572). The status page was the independent observer in both, and neither organisation had designed it so.

The stop test: does the stop path work when the platform does not? Whoever can stop an agent must be able to do it without passing through the agent's platform, the control plane it uses or the identity provider it relies on. A stop that requires the system under stress is a stop in name. The test is a drill that stops a running agent while the platform is degraded, with the time measured against a target. Hansa Mutual's first stop drill for HM-OPS-001 (STOP-HM-ITOPS-2027-Q1-01) took 17 minutes against a target of 5, which is the kind of result that a drill exists to produce, and a stop path decays unless it is drilled. The stop right is held by named people on every shift, so that the person who can stop does not depend on being reached through the thing that has gone wrong. AI Platform and Security, Chapter 25, set the requirement that a platform is under control when every model call and tool call passes a policy point outside the model and when containment holds whatever anyone intends (297, Nordqvist, 2026); the stop test is that requirement applied to the operator's own estate.

The three tests are enforced by a manifest, the observer manifest OBS-*, that lists the independent probes, their failure domains and the stop path, and that Chapter 17 treats in full. What the principle asks of a design here is smaller: for every action that an agent performs at Level 2 or Level 3, name what verifies it, show that the verifier is independent in the five dimensions, show that it survives the platform, and show who stops the action and how. If any of these cannot be named the action is not delegated.

Resilience as a claim

A statement such as "the claims core is recoverable" has the same defect as the unaged coverage heat map of AI Purple: it reads as a property and is in fact a claim made on a date. The book therefore treats resilience as a claim with five parts. The scope says which service, which failure and which recovery path the claim covers. The objective states the recovery time objective (RTO) and recovery point objective (RPO) that the claim is measured against. The measurement states the recovery time and recovery point that a test actually achieved, with the method (restore from immutable backup into a separate target, failover to the recovery site, rollback of a release) and the conditions. The date says when the test ran. The result states passed, failed or not tested. A claim without all five is a statement of intent.

Six statuses, derived by rule and not asserted, keep the register honest (Chapter 19 owns the rule). Verified means a passing, attested test exists inside its clock, with the measured times inside the objective and no listed change since. Expired means the last passing test is older than its clock or a listed change has occurred since. Implemented but unverified means a change to the recovery mechanism has been deployed and no test has followed it. Failed means the latest test missed the objective, failed an integrity check or was not completed, and the claim is withdrawn. Asserted means that the claim rests on a statement in a plan or a contract and not on a test; AI Threat, Chapter 30, drew the same line between verified and declared controls (299, Nordqvist, 2026). Untested means no test has been run for the scenario; it is a legitimate entry and counts in the denominator, and leaving it out is how a register comes to look better than the estate. Only a verified claim may be written as "recoverable".

Evidence expires by clock and by condition, as coverage evidence does. The book's default clock for a restore or failover test of a Tier 1 service is 180 days (Chapter 19 gives the clock for each kind of test), or a substantive change to the service or its recovery path, whichever comes first. The clock is deliberately shorter than the legal floor: Article 11(6) of DORA requires that ICT business continuity plans and ICT response and recovery plans be tested at least yearly for systems supporting functions, and after substantive changes to systems supporting critical or important functions, with cyber-attack scenarios and switchovers to redundant infrastructure included for entities above microenterprise size (2, European Union, 2022). The yearly test is the ceiling and never the aim. The condition is a design choice: a change in a DNS time-to-live, a certificate chain, a storage controller or a model version can invalidate the test that depended on them. Nordvik Region's failed failover test of the portal, RST-NR-2027-002, failed on a DNS time-to-live and an unrenewed certificate at the recovery site, which are exactly the conditions that age a passing test into a failing one. Chapter 19 treats the register and the game day.

The same shape applies to the operator. A skill that is not exercised decays, and a claim that the operators can restore manually is a claim with a date. Bainbridge's paper, written about industrial process control, made the point for operators: automation leaves the operator to monitor that the automatic system is working and to take over when it fails, taking over requires manual control skills and cognitive skills, and physical skills deteriorate when they go unused (217, Bainbridge, 1983). The frame requires that competence, like recoverability, be written with its test and its date (Chapter 26).

The operator's AI as Tier 0

The operator's AI holds what an attacker or an error would most like to have. A remediation agent holds credentials that can restart, deploy, scale and delete in production. An observability pipeline holds logs that contain personal and special-category data and a map of every service and its dependency. A runbook library is a set of instructions that an agent will execute, so that an unauthorised edit is an action. In sum, the operator's AI is an administrator with a good map of the organisation, and it is a Tier 0 asset in the sense that AI Purple, Chapter 16, applied to the loop's own AI: it is designed, contained, monitored and tested as among the most privileged workloads the organisation runs (304, Nordqvist, 2026).

Three consequences are fixed here and developed later. Every operations agent has an identity of its own and a named owner, operators and authority; at Level 3 the human approval moves from the action to the runbook and its owner, which concentrates accountability and does not dilute it. NIS 2 Article 20 places the approval and oversight of cybersecurity risk-management measures on the management bodies of essential and important entities, and DORA Article 5 does the same for financial entities; neither lets responsibility pass to a tool (3, European Union, 2022) (2, European Union, 2022). The agent's permissions are held by a policy decision point outside it, because containment that depends on the agent's intent is not containment, the conclusion of AI Platform and Security, Chapter 19 (297, Nordqvist, 2026). And the observer and the stop path stay outside the platform the agent runs on. Chapter 16 gives the agent team its mandates and containment, and Chapter 18 treats the threats by mechanism.

Mapping to NIST CSF 2.0 and DORA

Two instruments are the likeliest to be applied by those who audit the frame: the NIST Cybersecurity Framework 2.0, a common language for many organisations, and DORA, which binds Hansa Mutual directly. Both mappings are partial, and the partiality is informative.

NIST CSF 2.0

CSF 2.0 has six Functions, Govern, Identify, Protect, Detect, Respond and Recover, with 22 Categories (40, NIST, 2024). Respond has four Categories, RS.MA Incident Management, RS.AN Incident Analysis, RS.CO Incident Response Reporting and Communication and RS.MI Incident Mitigation; Recover has two, RC.RP Incident Recovery Plan Execution and RC.CO Incident Recovery Communication. The loop maps onto them where an incident is the occasion, and onto other Categories where it is not.

Function	Principal CSF 2.0 Categories	Remark
O1 Observe	DE.CM Continuous Monitoring; DE.AE Adverse Event Analysis; ID.AM Asset Management	CSF concerns adverse events in a cybersecurity sense; O1 adds availability and performance signals
O2 Diagnose	RS.MA Incident Management (triage and categorisation, RS.MA-02 and RS.MA-03); RS.AN Incident Analysis (root cause, RS.AN-03)	RS.AN-06 and RS.AN-07 on the integrity and provenance of what is recorded apply to an assistant's contributions
O3 Change	PR.PS Platform Security (configuration management, PR.PS-01; software maintained, replaced and removed, PR.PS-02)	CSF treats change as protection; the loop treats it as a function of its own
O4 Restore	RS.MI Incident Mitigation; RC.RP Incident Recovery Plan Execution (RC.RP-03 on verifying the integrity of backups before use, RC.RP-05 on verifying restored assets and confirming normal operating status)	RC.RP-05 is the observer principle's counterpart in CSF
O5 Sustain	PR.IR Technology Infrastructure Resilience (capacity, PR.IR-04); ID.IM Improvement; PR.PS-02 and PR.PS-03 on maintaining, replacing and removing software and hardware	ID.IM-03 takes improvements from the execution of operational processes

CSF 2.0 states that its Respond Function concerns a detected cybersecurity incident and its Recover Function the assets and operations affected by one, so an outage with no cybersecurity cause lies outside the wording even though O2 and O4 handle it identically. The loop is broader than the framework in that respect and narrower in another: CSF has Govern, which the book places in mandates, delegation profiles and the decisions of Chapter 22.

DORA, Articles 8 to 13

DORA, Regulation (EU) 2022/2554, applies to Hansa Mutual as an insurance undertaking and does not apply to Nordvik Region (2, European Union, 2022). Chapter II of the Regulation, on ICT risk management, has Articles 5 to 16, and Articles 8 to 13 are the operational core. The mapping below attributes each Article by its title in the live EUR-Lex text and states what it asks in summary; it is an organisational implication and not legal advice, and Chapter 23 takes the full regulatory mapping.

DORA Article	Title	What it asks, in summary	Functions
8	Identification	Identify, classify and document ICT-supported business functions, assets and their dependencies, reviewed at least yearly, with a risk assessment after major change for entities above microenterprise size	O1, O5
9	Protection and prevention	Continuously monitor and control ICT systems; keep high standards of availability, authenticity, integrity and confidentiality; limit access; control change management; maintain patch policies	O3, O5
10	Detection	Mechanisms to promptly detect anomalous activities, including network performance problems, with multiple layers of control, alert thresholds and automatic alerts to relevant staff, regularly tested under Article 25	O1, O2
11	Response and recovery	A comprehensive ICT business continuity policy implemented through documented plans, activated without delay, tested at least yearly and after substantive change to critical or important functions	O4, O2
12	Backup policies and procedures, restoration and recovery procedures and methods	Documented backup policies, backup systems and restoration procedures tested periodically, restoration on segregated systems, integrity checks after recovery	O4
13	Learning and evolving	Gather information on vulnerabilities and threats; carry out post-incident reviews after major incidents; feed lessons into the risk assessment; report to the management body at least yearly	O5, O2

Three observations follow. The Articles describe duties of the organisation, and the functions are the means by which an organisation performs them, so a DORA duty does not belong to one function and one function serves several Articles. Article 10 requires that detection mechanisms be tested under Article 25, and Article 11 and Article 12 require testing as well, which is the regulatory form of the claim with evidence: a plan not tested is a plan declared. And Articles 5 to 16 stop short of the incident reporting of Articles 17 to 19 and the testing programme of Articles 24 and 25, which Chapters 14, 19 and 23 take up. For Nordvik Region, which DORA does not bind, NIS 2 Article 21(2) lists incident handling (point (b)) and business continuity, such as backup management and disaster recovery, and crisis management (point (c)) among the minimum measures that the Directive expects of covered entities, and the Region plans as if its Tier 1 services were in scope (3, European Union, 2022). Whether the Region falls within scope depends on national transposition.

Observable, expected, speculation. The frame is the book's own design, and its mappings to CSF, DORA and ITIL are interpretations. Observable: the instruments cited have the Categories and Articles quoted above at the time of writing. Expected: the yearly testing duty of Article 11(6) and the periodic testing of Article 12 will remain the supervisory baseline for financial entities, because they are decided instrument text. Expected: the ITIL practice names will change as the new version of ITIL is adopted, so the mapping table needs re-checking. No statement about the future of operations beyond these is made here; Chapters 27 and 31 carry the author's own projections.

The delegation profile as an artefact

The frame is kept in one file per agent and service, and the file is what a supervisor, an auditor or a works council reads.

Worked example: delegation profile DLG-HM-OPS-001

The delegation profile is the artefact that states the frame for one agent and one service. The example is illustrative and fictional. It sets out how Hansa Mutual might write the profile of its IT-operations agent HM-OPS-001 for the claims core system SVC-HM-001, in response to the risk committee's question recorded in AIDR-0950 (dated 2028-09-19; first report due 2029-03-31). The levels for restart, certificate renewal and horizontal scaling follow the profile of the agent in the book (indicative here, fixed in Chapter 16); the budget cap and the stop times follow the existing facts of the organisation.

delegation_profile: DLG-HM-OPS-001
status: proposed            # lowering is immediate; raising is a named authority's decision
version: 0.3
date: 2028-10-24
decision_record: AIDR-0950
agent: {id: HM-OPS-001, mode: "Mode 5", mandate: MND-HM-OPS-001}
service: {id: SVC-HM-001, tier: 1, cif: true, slo: SLO-HM-001, rto: PT4H, rpo: PT15M}
accountable: {agent_owner: "Anja Weiss", raise_authority: "Tobias Richter"}
policy_decision_point: {location: outside_agent_platform, deny_by_default: true}
window_rule: "outside an authorised window or inside a freeze, ceiling is Level 2 with named approver"
action_classes:
  read:               {ceiling: "Level 4", condition: "redacted personal data"}
  annotate:           {ceiling: "Level 4"}
  notify:             {internal: "Level 3", external: "Level 1"}
  scale:              {ceiling: "Level 3", condition: "within quota; EUR 6000 per month cap"}
  restart:            {stateless: "Level 3", stateful: "Level 2", runbook: RBK-HM-0001}
  certificate_renew:  {ceiling: "Level 3", runbook: RBK-HM-0002}
  reconfigure:        {ceiling: "Level 2", alerts_thresholds_monitors: "Level 0"}
  deploy:             {ceiling: "Level 2"}
  roll_back:          {ceiling: "Level 2", candidate_for: "Level 3 after two quarters of evidence"}
  fail_over:          {ceiling: "Level 1", approver: incident_commander}
  delete:             {temporary_artefacts: "Level 3", production_data: "Level 1"}
  restore_overwrite:  {ceiling: "Level 1", approver: "named person"}
  anything_unlisted:  "undelegated"
autonomy_budget:
  window_days: 28
  tolerance: {restart: "1.5 per cent of actions", certificate_renew: "1 faulty action", scale: "2 faulty actions"}
  customer_visible_effect: "consumes 100 per cent at once"
  review_at_percent: 70
  counted_by: OBS-HM-0001
  on_full_consumption: "class falls one level to Level 2; raising needs raise_authority"
verification: {observer: OBS-HM-0001, independent_of: [model, data, authorship, vendor, time]}
stop: {holders: [incident_commander, agent_operator, platform_engineer_on_call],
       path: "outside agent platform", target_minutes: 5, drill: quarterly}
employee_representation: "KBV-IT-2024-OPS-03 agreed before command logging is used"
review: {every_days: 90, next: 2029-01-22}

The profile is the evidence a supervisor would ask to see. It carries the decision record, the accountable people, the policy point's location, the window rule, a ceiling and a condition for each class, the budget, the observer, the stop holders and the date of the next review. Fail-over is held at Level 1 because it crosses providers for a critical function, and the roll-back class names the evidence that would move it to Level 3 without moving it.

Practical guide: writing a delegation profile for one service

Purpose. Produce a delegation profile that states, for one agent and one service, what it may do, how much of that allowance it has kept, what verifies it and who stops it.

Roles. The service owner, the SRE lead, the agent operator, the head of operational resilience or the resilience officer, the CISO or a delegate for consultation, and employee representatives where the profile affects logging of staff commands.

Steps.

1. Copy the service record SVC-*: tier, critical-function flag, SLOs, RTO and RPO. The profile is written for one service, because blast radius is a property of the service.
2. List the agent's technical permissions from the identity provider, not from the design document. Strike every action class that the profile will not name; an unlisted class is undelegated.
3. Classify each remaining class as reversible by the system, reversible with cost or time, or irreversible except from backup. A class counts as reversible only if the reversal has been rehearsed in a non-production environment and the time recorded.
4. Answer the four questions per class (reversibility, blast radius, evidence, window) and write the lowest as the ceiling. Start every class that touches production at Level 2 unless an evidence record exists.
5. Name the policy decision point, where it runs and how a refusal is tested. Test the refusal by attempting a listed action outside its window and an unlisted action, and record that both are refused.
6. Set the autonomy budget. Use a 28-day window, a tolerance per Level 3 class (a rate for high-volume classes, a count for rare ones), a review at 70 per cent consumed and a drop of one level at 100 per cent, unless the service owner justifies other figures, and name the observer that counts.
7. Name the observer manifest and confirm that its probes pass the three tests of this chapter.
8. Name at least three stop holders, one on each shift, and run a stop drill within 30 days of approval and quarterly afterwards. Record the time against a target of five minutes unless the contract or the service's objectives demand less.
9. Agree any logging of engineers' commands with employee representatives before it is switched on, and report operational measures by team and service, never by named engineer.
10. Set a 90-day review. A reduction takes effect when anyone with the stop right decides it; a rise needs the named authority, a decision record and the evidence.

Definition of done. The profile is in version control; its policy point refuses the two test actions; the observer has been shown independent in the five dimensions; the stop drill has been run once and its time recorded; the representatives' agreement is referenced; and the first review date is set.

Across the usage modes

The mode describes how AI is deployed and whose identity it uses; the level describes who decides each action. The table sets the usage modes of AI Governance and AI Platform and Security, Chapter 2, against the five functions, with where each organisation's AI sits today and the book's default ceiling for the function in production.

Function	Mode 0 and Mode 1: ambient and conversational	Mode 2 and Mode 3: embedded and agentic work tools	Mode 4: built applications	Mode 5: autonomous production agents	Book's default ceiling
O1 Observe	Default anomaly detection in the observability product and the provider's monitoring (Hansa Mutual's Lumenscope and Alster Managed Services)	Incident summaries inside the observability product	Alert-correlation service of the operator's own	Agent that tunes alerting; forbidden to disable it	Level 4 to read and annotate; Level 0 for any change to alerts
O2 Diagnose	Category and priority suggestions in the service-management tool	Drafting of status updates and timelines	Incident assistant over past incidents and runbooks (HM-OPS-002; NR-OPS-001)	None	Level 1 to propose; a named person accepts the diagnosis
O3 Change	None	Drafting of infrastructure code and runbooks by the platform team, never applying them	Change-risk reviewer scoring blast radius and freeze calendar (HM-OPS-003)	Agent that applies pre-approved standard change	Level 2; Level 3 for pre-approved standard change
O4 Restore	Provider-side automated remediation the organisation did not choose	Drafting of runbooks	Assistant that proposes the next runbook step	IT-operations agent (HM-OPS-001) executing catalogued runbooks	Level 3 for restart, certificate renewal and scale; Level 2 for rollback; Level 1 for failover, delete and restore-overwrite
O5 Sustain	Forecasting inside licensed tools	Drafting of problem reviews and knowledge articles	Capacity and FinOps agent (HM-OPS-004) at Level 1	None	Level 1 for proposals; a person approves spend and removal

A provider's embedded monitoring or remediation acts at a level the provider chose, which AI Red Team, Chapter 8, named the Mode 0 blind spot (298, Nordqvist, 2026); for each managed provider the decision is to accept, constrain or switch off, written in a delegation profile. Chapter 24 treats it at the boundary of the organisation.

Nordvik Region and Hansa Mutual

Both organisations receive the same question in the same September, and this chapter's definitions are the ones both adopt. Nordvik Region's regional executive committee asked its Head of IT and Digitalisation, Henrik Dahl, what operations becomes when the platform team's tools and the providers' AI act on the estate and what the Region can prove about recovery, recorded as AIDR-0900 (dated 2028-09-12; first report due 2029-03-31). Hansa Mutual's executive board risk committee asked the group chief information officer whether the autonomy of the IT-operations agent can extend from restart, certificate renewal and scaling to rollback and failover, and what evidence the group would show a supervisor, recorded as AIDR-0950 (dated 2028-09-19; first report due 2029-03-31).

Nordvik Region runs a sovereign regional cloud itself, has seven platform engineers who carry SRE practice, and has no autonomous production agent (no Mode 5). Its operations assistant NR-OPS-001 starts at Level 0 Advisory. The Region's delegation profile, DLG-NR-OPS-001 in the book's naming, would set a ceiling of Level 2 on every class that changes production and would grant Level 3 to no one until a scripted runbook, run by the orchestrator under a mandate manifest, has an evidence record of its own. The stop is held by the duty-manager rota, of which Oskar Berg is a member, and by the platform lead, Maja Lindqvist; SamDrift's network operations centre pages the on-call and does not hold the stop. The resilience register at the date of AIDR-0900 shows what the Region can say. RST-NR-2027-001 (2027-04-20) restored the case-management database in 3 hours 05 minutes against 4 hours, with a recovery point of 11 minutes against 15, and passed; at 16 months and 22 days it is older than the twelve-month default and is expired. RST-NR-2027-002 (2027-10-12) failed over the portal in 5 hours 20 minutes against 2 hours, a failure, and no re-test has run. No Tier 1 service of the Region is therefore verified recoverable, and the register shows one expired, one failed and the remainder not tested. The agreement MBL-NR-IT-2027-01 makes any tool that logs engineers' commands a matter for negotiation before it is switched on.

Hansa Mutual already runs a Mode 5 IT-operations agent, has about 95 people in Group Site Reliability and Incident Management under Tobias Richter, and a 24-hour incident commander rota. Its question is how far Level 3 may reach, and the answer of this chapter is that it reaches as far as the class table, the budget and the observer allow: DLG-HM-OPS-001 keeps restart, certificate renewal and scale at Level 3, holds rollback at Level 2 with the evidence that would raise it, and forbids Level 3 for restore-overwrite. The stop holders include Ewa Kowalczyk as agent operator for the night window. DORA applies, so Articles 8 to 13 are duties, with the yearly testing programme of the head of operational resilience. The register at the date of AIDR-0950 shows RST-HM-2027-007 (2027-10-05), the failover of payments from Frankfurt to Cloud A in 1 hour 35 minutes against 2 hours, passed on that date but, on the 180-day default clock of Chapter 19, expired on 2028-04-02 and not re-tested; and RST-HM-2027-004 (2027-06-15), the restore of the claims core database in Cloud B in 5 hours 40 minutes against 4 hours, failed on time. The claims core is therefore not recoverable in the book's sense until a re-test passes, whatever the design says. The agreement KBV-IT-2024-OPS-03 requires AI operations tools that log engineers' commands to be agreed before use.

Nordvik's leverage is its contracts and the few runbooks it owns, and its first deliverable is a passing re-test. Hansa's is the platform, policy as code and the agent's mandate, and its first deliverable is a delegation profile that a supervisor can read.

Summary

This chapter defined the operations loop and concerns all five functions: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. Each has an input, an output and an end, and each draws on several practices of service management without being one. The degrees of delegation are the autonomy levels per function and action class, set by the lowest of four answers (reversibility, blast radius, evidence and window), with eleven action classes from read to restore-overwrite and a budget that errors consume. 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.

The observer principle has three tests: what verifies an action is independent of what performed it, the observer does not depend on the system it observes, and the stop path works when the platform does not. Resilience is a claim with a scope, an objective, a measurement, a date and a result, and only a verified claim may be called recoverable; evidence expires on a clock (180 days by default for a Tier 1 restore or failover test) or on a substantive change. The operator's AI is Tier 0 and is contained accordingly. In a modern estate state engines (reconciling controllers and workflow engines) implement much of the loop, so the action classes attach to what an engine is configured to do on its own and the observer principle applies to the engine. The mappings to NIST CSF 2.0, DORA Articles 8 to 13 and ITIL 4 are partial and are the book's own interpretation.

Nordvik Region and Hansa Mutual meet the frame from different starting points: Nordvik with no agent at Level 3 and a register that shows one expired and one failed test, Hansa with an agent at Level 3 for three classes and a claims core whose last restore test failed on time. Chapter 5 begins the craft with O1 Observe, without AI first, and Chapter 17 returns to the observer principle in full.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
3. NIST. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. (40, NIST, 2024)
4. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
5. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Transformed Architecture, Book 4. (298, Nordqvist, 2026)
6. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? The Transformed Architecture, Book 5. (299, Nordqvist, 2026)
7. Nordqvist, G. (2026). The Transformed Security Architect. The Transformed Architecture, Book 6. (300, Nordqvist, 2026)
8. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Transformed Architecture, Book 7. (301, Nordqvist, 2026)
9. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)
10. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
11. PeopleCert (2023). ITIL 4 Management Practices 2023: a new level of service management capability. PeopleCert announcement. (121, PeopleCert, 2023)
12. PeopleCert. ITIL 4 practices. PeopleCert. (122, PeopleCert, n.d.)
13. Alvidrez, M. (2017). Embracing Risk. In: Site Reliability Engineering. O'Reilly Media. (258, Alvidrez, 2017)
14. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Transformed Architecture, Book 9. (304, Nordqvist, 2026)
15. The Kubernetes Authors. Controllers. Kubernetes documentation. (153, The Kubernetes Authors, n.d.)
16. OpenGitOps. GitOps Principles, version 1.0.0. (55, OpenGitOps, n.d.)
17. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (6, European Union, 2016)