Book Blueprint and Chapter Briefs

This blueprint records the editorial intent of AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities, Book 10 of The Transformed Architecture. The authoritative design is DISPOSITION.md; the chapter briefs below are generated from scripts/outline_data.py by scripts/generate_outlines.py.

Premise

The series has so far treated operations from the outside. AI Platform and Security described how an AI platform is built and run, AI Red Team put AI to work in cyber defence including recovery, AI Blue described the team that defends and AI Purple the loop that verifies the defence. None took as its subject the function that keeps services running every day: IT operations, in its modern forms of site reliability engineering, platform engineering, service management and managed operations.

Operations is where AI is arriving fastest and with the least ceremony: observability platforms correlate events and propose root causes, incident assistants summarise and draft, coding agents author the infrastructure change that operations must approve, remediation agents restart, scale, roll back and fail over, and service-desk assistants resolve requests. At the same time operations has become the place where AI systems themselves are run: models are updated by their providers without notice, prompts and retrieval indexes change like configuration, and an AI incident is an operations incident with legal consequences.

Three things make this a book and not a chapter. Operations holds the most powerful credentials in the estate. Operations is where loops are closed without a person in them, so the lessons of delegation can be tested against decades of experience of automated operations. And European regulation treats operations as a duty of the management body: DORA, NIS 2, the AI Act, the GDPR and the Data Act decide what must be logged, who may act, how fast an incident is reported and what happens when a provider fails.

Thesis

The working thesis has five parts, tested in Parts II to V and judged in Chapters 27 and 31.

Operations is transformed, not abolished: from the queue to the control loop. The work moves from handling tickets and alerts to designing, bounding and verifying closed loops. The operator becomes the accountable conductor of an operations loop.
Autonomy is matched to reversibility and blast radius, and has a budget. Every action class has a degree of delegation, Level 0 Advisory to Level 4 Autonomous, consumed by errors in the way an error budget is, with a stop path outside the system it stops. Level 4 is never used for an irreversible action on production data, for an action outside an authorised window or freeze on a critical function, for an action that disables the observation or the stop path, or for an action that decides about a named person's access to work.
The operator's AI is part of the estate it operates. Remediation agents, observability pipelines, runbook libraries and configuration maps are Tier 0 assets.
A loop closed by machines alone can hide its own failure: the observer principle. 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.
Resilience is a claim that needs evidence. "Recoverable" has a scope, a measured recovery time and point, a date and a result. The same holds for the operator's competence, which decays unless exercised.

The thesis would be shown wrong by independent incident data over several years showing that fully autonomous remediation, with no manual practice and no independent verification, yields fewer and shorter customer-impacting incidents and less severe tail events; or that operators who do not practise manual recovery handle novel failures as well as those who do.

Audience

CIOs and heads of IT operations; SRE and platform leads; incident commanders and on-call engineers; service-desk and service-management leads; FinOps and capacity managers; architects; CISOs and heads of resilience, business continuity and third-party risk; boards and management bodies with duties under DORA Article 5 and NIS 2 Article 20; procurement and vendor managers; supervisors and auditors; works councils, unions and data protection officers; public-sector leaders. Chapter 1 gives reading paths.

Boundaries

The book builds only on Books 1 to 9 and never refers to a later volume. It takes their conclusions as given and does not repeat them.

Not a second Architecture as Code. The pipeline chapters stay there; this book takes operations as the subject and applies "as code" to runbooks, objectives, mandates and restore tests.
Not a second AI Platform and Security or AI Red Team. Platform design stays in Book 3; recovery and chaos engineering are inputs from Book 4, extended here to the whole of operations.
Not a second AI Blue. Security operations stays there; this book meets it at the boundary (incident roles, shared telemetry, joint exercises).
Not a second AI Purple. Its independence principle becomes the observer principle here, and coverage as a claim becomes resilience as a claim.
Not a second AI Boss or AI Threat. Algorithmic management of staff and the evidence ladder are applied, not repeated.
Defensive only. Failures are described by mechanism and outcome at the level needed to design controls and tests. Legal content is attributed to the instrument and article, verified against the live text, and framed as architectural implication, not legal advice. On-call, monitoring and performance measurement are discussed by what studies measured.
Naming. "DORA" means Regulation (EU) 2022/2554; the research programme is "the DevOps Research and Assessment (DORA) programme" at first use in Chapter 20 and "the four key metrics" thereafter.

Red threads

The five operations functions. O1 Observe, O2 Diagnose, O3 Change, O4 Restore, O5 Sustain (Chapter 4). Every chapter in Parts II to V names, in its opening and Summary, the functions it concerns.
The autonomy budget. Every narrative chapter has an ### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table, with the Level 4 prohibitions and a stop path outside the system it stops.
The observer principle (Chapters 4 and 17) recurs wherever a machine verifies a machine.
Resilience and competence as claims with evidence. No chapter says that something is recoverable, covered or competent without saying what was tested, when and with what result.
Observable, expected, speculation. Every outlook carries one of the three labels; the author's projections stay in Chapters 27 and 31.
Constructive debate. Chapters 10, 17, 26 and 27 stage a debate in four steps before a verdict.
Two organisations. Nordvik Region and Hansa Mutual in every narrative chapter, in a short ### Nordvik Region and Hansa Mutual subsection before the Summary.
Artefacts. Service records SVC-*, service level objectives SLO-*, runbook manifests RBK-*, incident records INC-*, change records CHG-*, problem records PRB-*, post-incident reviews PIR-*, restore-test records RST-*, capacity records CAP-*, observer manifests OBS-*, mandate manifests MND-* (operations agents MND-NR-OPS-*, MND-HM-OPS-*), delegation profiles DLG-*, role charters ROLE-*, competence records CMP-*, AI Decision Records AIDR-0900 to AIDR-0999 (Nordvik Region AIDR-0900 to AIDR-0949, Hansa Mutual AIDR-0950 to AIDR-0999) and Architecture Decision Records.

Status

The repository was bootstrapped on 2026-11-10 from the engine of AI Purple. The table of contents (scripts/toc_definition.py) and the chapter briefs (scripts/outline_data.py) exist; all 31 chapters are written out following docs/CHAPTER_AUTHORING_GUIDE.md and carry the status draft in scripts/outline_data.py; the status complete is set once a chapter has been reviewed for sources, continuity and the red threads.

Length and weighting

Narrative chapters run 3,600 to 6,500 words, with the planned range stated in each brief. Parts II and V are the book's weight; Chapters 4, 10, 16, 17 and 19 are load-bearing. A chapter that grows beyond about 6,500 words, or a section beyond about 2,500 words that treats a distinct subject, is split into a companion chapter. A reader with an hour reads Chapters 1, 4, 10, 17, 19 and 31.

Chapter briefs

Part I: The Operations in Question

Chapter 1: Introduction: Operations with AI

File: 01_introduction.md
Status: draft
Purpose: Introduce the book on its own terms. The earlier volumes treated operations from the outside: the platform (AI Platform and Security), recovery as a CSF Function (AI Red Team), the defending team (AI Blue) and the loop that verifies the defence (AI Purple). None took the function that keeps services running every day as its subject. State what operations is, why AI is arriving in it faster and with less ceremony than anywhere else, the five-part thesis and what would refute it, and how each audience should read the book.
Builds on: F15, F48, F49, F70, F115, F118, F119, AI Platform and Security, Chapter 17, AI Purple, Chapter 4
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Two nights, one outage; Operations with AI in 2026; Why a book on operations; The working thesis; Five functions and five degrees; Usage modes and degrees of delegation; Rules of the book; Two organisations and the series; How to read this book
Practical guides: A one-page inventory of every place where AI already takes part in operating a service, including vendor AI in managed services and observability tools
Worked examples: A one-page operations mandate summary for one service, with function, action class, level and stop owner
Nordvik Region and Hansa Mutual: Nordvik Region's CIO is asked by the regional board what an assistant in the service desk may do on its own (AIDR-0900); Hansa Mutual's head of SRE is asked by the management body how many production actions are already taken by agents (AIDR-0950).
Usage modes and degrees of delegation: Introduces the usage modes as the series uses them: AI that assists a person under that person's identity (Modes 1 to 3), AI built or procured to perform an operations function (Mode 4) and agents with identities of their own (Mode 5).
Observable, expected, speculation: AI in observability, incident assistance and AI-authored change is observable; delegated remediation in routine classes is expected; unattended operations of whole estates is speculation, treated in Chapter 27. The thesis is the book's own claim, judged in Chapters 27 and 31.
Figure: The operations loop at the centre: five functions, the observer outside it and the chapters that treat each function
Planned length: 4,500-6,500 words of prose
Expected existing sources: 1, 2, 3, 63, 64, 75, 81

Chapter 2: What Operations Did Before: Runbooks, ITIL, DevOps, SRE and AIOps

File: 02_what_operations_did_before.md
Status: draft
Purpose: Describe how operations organised itself before AI, as the baseline for Chapters 5 to 12: sysadmins and runbooks, ITIL and ISO/IEC 20000-1 service management, DevOps and its research, SRE with error budgets, toil and blameless review, platform engineering, and first-generation AIOps. For each, say what it got right and which scarcity it answered. Draw on the lessons of automation in aviation and the process industry.
Builds on: F5, F9, F10, F59, F66, F117, AI Red Team, Chapter 22
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: A lineage of operating models; What each got right; The scarcity behind the shape; First-generation AIOps; Lessons from other domains; A ticket-era and a code-era change record
Practical guides: Classifying the operating practices a team has by lineage, scarcity answered and what remains of it
Worked examples: A ticket-era change record contrasted with a code-era one for the same change
Nordvik Region and Hansa Mutual: Nordvik Region runs ITIL-shaped service management with a change advisory board and an outsourced night service; Hansa Mutual has SRE teams for its claims platform and a weekly board for the rest.
Usage modes and degrees of delegation: Pre-AI baseline; marks where Mode 0 features already sit in monitoring and service-management products.
Observable, expected, speculation: The history is observable; the claim that each model answered a scarcity is the book's own reading, stated as such.
Figure: The lineage of operating models, with the scarcity each answered
Planned length: 3,600-6,500 words of prose
Expected existing sources: 61, 75, 76

Chapter 3: The Pressure on Operations: Complexity, Dependency, Cost and Machine-Speed Change

File: 03_the_pressure_on_operations.md
Status: draft
Purpose: Explain why the old shape of operations strains: microservice and multi-cloud complexity, concentration on a handful of providers, change volume rising with AI-authored code, telemetry volume and cost, scarce skills and on-call fatigue, GPU and energy cost, regulatory duty and adversaries working at the same speed. Place each claim on the evidence ladder and say what is measured and what is practitioner opinion.
Builds on: F35, F36, F47, F58, F94, F110, F117, AI Red Team, Chapter 2, AI Threat, Chapter 4
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Complexity and dependency; Change volume; Telemetry volume and cost; People; Compute, energy and cost; Duty and adversaries; The evidence for each claim
Practical guides: Drawing a dependency-and-blast-radius map for one service in an afternoon
Worked examples: A dependency-and-blast-radius map for the Hansa Mutual claims platform and for the Nordvik e-service
Nordvik Region and Hansa Mutual: Nordvik Region depends on one sovereign regional cloud and a national identity provider; Hansa Mutual depends on two hyperscalers, a payment network and a managed observability service.
Usage modes and degrees of delegation: Notes where AI on both sides raises the pace (assistants authoring change, agents remediating) and where Mode 0 hides dependence.
Observable, expected, speculation: Outage concentration and rising change volume are observable; sustained review overload is expected; any claim of a collapse of the operator role is speculation.
Figure: Pressure points on the operations loop: complexity, change, telemetry, people, compute and duty
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 3, 29, 39, 73, 74

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

File: 04_the_operations_loop_defined.md
Status: draft
Purpose: Define the book's frame. The five functions O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain with scope and boundaries towards service management practices; the autonomy budget with action classes (read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete, restore-overwrite) and the Level 4 prohibitions; the observer principle with its three tests; resilience as a claim with evidence age; the operator's AI as Tier 0. Map the loop to NIST CSF 2.0 Respond and Recover and to DORA Articles 8 to 13.
Builds on: F34, F50, F51, F82, F93, F98, F115, F116, F118, F122, AI Purple, Chapter 4, AI Purple, Chapter 15
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: The loop in one picture; Five functions; Action classes and the autonomy budget; The Level 4 prohibitions; The observer principle; Resilience as a claim; The operator's AI as Tier 0; Mapping to CSF 2.0 and DORA
Practical guides: Writing a delegation profile for one service: action classes, ceilings, stop owner and evidence
Worked examples: A delegation profile DLG-HM-* with an action-class table for the Hansa claims platform
Nordvik Region and Hansa Mutual: Nordvik Region's delegation profile caps every production action at Level 2 outside a window, with the regional operations centre holding the stop; Hansa Mutual allows Level 3 for restart and scale on named services and forbids it for restore-overwrite.
Usage modes and degrees of delegation: Defines the degrees of delegation per function and action class and sets the table of usage modes against the five functions.
Observable, expected, speculation: The frame is the book's own design and is labelled so; the cited sources support its parts, not the whole.
Figure: The operations loop with the observer and the stop path outside it
Planned length: 5,000-6,500 words of prose
Expected existing sources: 2, 17, 20, 21, 63, 64, 81

Part II: The Craft

Chapter 5: Observe: Telemetry, Observability and Service Level Objectives

File: 05_observe.md
Status: draft
Purpose: Treat O1 Observe without AI first: telemetry (logs, metrics, traces, events), OpenTelemetry, service level indicators and objectives, error budgets, service maps, the cost and retention of telemetry and the personal data that logs carry. The chapter sets the baseline that Chapter 6 then changes.
Builds on: F4, F20, F37, F41, F95, F119, F125, AI Platform and Security, Chapter 21
Operations functions: O1 Observe
Sections: What observing is for; Signals; Indicators, objectives and error budgets; Burn-rate alerting; Service maps and ownership; Cost, retention and personal data; Observability as code
Practical guides: Writing an SLO from a user journey, with a burn-rate alert and an owner
Worked examples: An SLO-HM-* record in YAML for the payment-claims service with burn-rate alerts and SLO-NR-* for the citizen e-service
Nordvik Region and Hansa Mutual: Nordvik Region sets an objective for the citizen-facing e-service around availability in office hours and the submission success rate; Hansa Mutual sets objectives for the payment-claims service around end-to-end processing time.
Usage modes and degrees of delegation: Without AI first; the closing section notes which signals Mode 0 features in observability products already summarise or filter.
Observable, expected, speculation: OpenTelemetry convergence and objective-based alerting are observable; the claim that objectives replace threshold alerts widely is expected.
Figure: From signals to objectives: telemetry, indicators, error budget and burn-rate alert
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 3, 8, 61

Chapter 6: Observe with AI: Correlation, Anomaly Detection and Alert Noise

File: 06_observe_with_ai.md
Status: draft
Purpose: Show what AI adds to the detection of operational anomalies: seasonality-aware baselines, event correlation, topology-aware grouping and language-model summaries of alerts. Set the failure modes beside the gains: suppression of a true alert, baselines that drift to the new broken normal, and dependence on the very data that fails. Show how to evaluate, with golden incident sets, precision and recall per alert class and a noise budget.
Builds on: F54, F76, F95, F96, F99, F105, F118, F125, AI Blue, Chapter 6, AI Purple, Chapter 9
Operations functions: O1 Observe; O2 Diagnose
Sections: What AI adds to observing; Alert noise and its cost; Failure modes; Evaluation; What the evidence shows; A correlation policy
Practical guides: Drawing up an alert-correlation policy with a suppression ceiling and a sampling rate
Worked examples: An alert-correlation policy and evaluation record for the Hansa Mutual claims platform, with a noise budget and a seeded fault
Nordvik Region and Hansa Mutual: Hansa Mutual turns on correlation across two observability tools and sets a rule that no alert on a customer-facing objective may be suppressed above Level 1; Nordvik Region accepts the summaries of its managed provider only after it has measured them against its own golden set.
Usage modes and degrees of delegation: Table of usage modes against O1 and O2: assisted reading (Mode 1 to 3), vendor correlation inside a platform (Mode 0 and 4), agents that suppress or page (Mode 5).
Observable, expected, speculation: Correlation and summarisation in products are observable; routine closure of low-risk alert classes is expected; autonomous tuning of an estate's alerting without review is speculation.
Figure: Alert flow with AI: signals, correlation, suppression ceiling, sampling and the human page
Planned length: 3,600-6,500 words of prose
Expected existing sources: 69, 72, 74, 76

Chapter 7: Diagnose: Triage, Root-Cause Analysis and the Incident Assistant

File: 07_diagnose.md
Status: draft
Purpose: Describe the incident assistant in O2 Diagnose: retrieval over past incidents and runbooks, hypothesis ranking, change correlation (what changed), and drafting of status updates. Show why published accuracy figures must be read with their conditions, how the human incident commander stays in command, and what the record must contain. Treat automation bias and the risk that the assistant's first hypothesis becomes the team's only one.
Builds on: F21, F76, F84, F99, F100, F125, F127, AI Blue, Chapter 8
Operations functions: O2 Diagnose
Sections: Diagnosis before AI; The incident assistant; What the benchmarks say; Automation bias and anchoring; The human decision points; The record
Practical guides: Running an incident with an assistant: roles, the second hypothesis rule and the record
Worked examples: An INC-HM-* incident record with assistant contributions marked and evidence links
Nordvik Region and Hansa Mutual: At Hansa Mutual the assistant proposes a database change as the cause of a claims delay; the incident commander's second-hypothesis rule finds a queue configuration pushed an hour earlier. Nordvik Region's night service uses the assistant only for retrieval.
Usage modes and degrees of delegation: Table of usage modes against O2: retrieval at Level 0 or 1, ranked hypotheses and drafted updates at Level 1 or 2, no autonomous declaration of an incident above Level 2.
Observable, expected, speculation: Assistants in incident tooling are observable; benchmark gains in controlled settings are reported with caveats; a fully autonomous diagnosis of novel failures is speculation.
Figure: The diagnosis flow with the assistant and the human decision points
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 19, 75, 76

Chapter 8: Change: Releases, Infrastructure as Code and AI-Authored Change

File: 08_change.md
Status: draft
Purpose: Treat O3 Change when much of the change is authored by agents: provenance of change, review load, policy as code, drift between declared and actual state, change records as code, and standard, normal and emergency change. Connect to supply-chain duties (the Cyber Resilience Act and NIS 2 Article 21) and to the architecture of change authority that Chapter 22 completes.
Builds on: F3, F7, F12, F13, F29, F37, F75, F126, AI Platform and Security, Chapter 8
Operations functions: O3 Change
Sections: The change pipeline; AI-authored change; Provenance; Policy as code in the path; Review load; Drift; Standard, normal and emergency change; Supply chain
Practical guides: Defining standard change classes that an agent may author and a pipeline may release
Worked examples: A CHG-NR-* change record for an AI-authored infrastructure change with reviewer, policy results and rollback plan
Nordvik Region and Hansa Mutual: Nordvik Region lets an agent draft infrastructure changes for review by a platform engineer and releases only in a window; Hansa Mutual lets standard classes flow to production when policy checks pass.
Usage modes and degrees of delegation: Table of usage modes against O3: drafting (Level 1), authoring with review (Level 2), release of standard classes (Level 3), never Level 4 for deploy outside a window on a critical function.
Observable, expected, speculation: AI-authored change in pipelines is observable; the replacement of the change advisory board by policy gates is expected; fully autonomous release of non-standard change is speculation.
Figure: The change pipeline with provenance, policy gates and rollback plan
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 3, 5, 21, 61, 63

Chapter 9: Change Safely: Progressive Delivery, Freezes and Blast Radius

File: 09_change_safely.md
Status: draft
Purpose: Show how to change safely: canary and staged rollout, feature flags, configuration pushes as the dangerous change, automatic rollback, freezes, blast-radius budgets and cell-based architecture, and the change-correlated incident rate. Use real cases verified in Chapter 28's set, only where a primary post-incident report exists.
Builds on: F19, F29, F45, F59, F63, F121, F124, AI Red Team, Chapter 25, AI Purple, Chapter 7
Operations functions: O3 Change; O4 Restore
Sections: Why most incidents follow a change; Progressive delivery; Configuration as the dangerous change; Stop conditions and automatic rollback; Freezes; Blast-radius budgets
Practical guides: Setting stop conditions for a staged rollout and having a second system evaluate them
Worked examples: A progressive-delivery policy in YAML and Rego with stop conditions evaluated by an independent verifier
Nordvik Region and Hansa Mutual: Hansa Mutual keeps a freeze calendar around quarter-end and regulatory reporting and lets agents release only to the first cell; Nordvik Region freezes around elections and the tax-filing window.
Usage modes and degrees of delegation: Table of usage modes against O3 and O4: who may widen a rollout, who may roll back, at which level.
Observable, expected, speculation: Progressive delivery and automatic rollback are observable practice; blast-radius budgets as management information are expected.
Figure: Staged rollout with an independent verifier, stop conditions and rollback
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 54, 60, 61

Chapter 10: Restore: Runbooks, Auto-Remediation and Recovery

File: 10_restore.md
Status: draft
Purpose: State the case for and against letting AI remediate production. Show the runbook as code (RBK manifests), auto-remediation tiers, the first ten actions an agent may take and the ones it may not, idempotency, dry-run, verification by an independent probe, rollback of the remediation, human approval for irreversible actions, and backup and restore as the last line (immutability, 3-2-1-1-0 patterns). The chapter stages a debate and ends in a verdict with labels.
Builds on: F50, F58, F67, F69, F98, F121, F122, F127, AI Blue, Chapter 10, AI Red Team, Chapter 22
Operations functions: O4 Restore
Sections: The runbook as code; Remediation tiers; The first ten actions; Safe execution; Verification; The last line; The debate; Verdict
Constructive debate: Concern: Remediation agents hold broad credentials, act at machine speed, can mask the cause of a fault and can compound a mistake faster than a person can read it; operators supervising automation lose the skill to take over (Bainbridge, 1983). Calm: Restarts, scaling and rollbacks have been automated for years with good results; the rate of repeated, low-risk pages is high and the people paged are tired; a bounded agent with verification and rollback is safer than a tired person at three in the morning. Where they meet: Both accept that class, reversibility and verification decide, that the verifier must be independent and that a stop path outside the platform is required. What can be done: Set ceilings per action class; keep dry-run and rollback mandatory; budget errors; keep manual recovery drilled; report consumption of the autonomy budget.
Practical guides: Writing a runbook so that a machine may run it: preconditions, level, verification, stop
Worked examples: An RBK-HM-* runbook manifest with level, preconditions, verification and stop path for a restart of a stateless service
Nordvik Region and Hansa Mutual: Hansa Mutual allows restart and scale of stateless services at Level 3 on named services and keeps restore-overwrite at Level 1; Nordvik Region allows the same at Level 2 with a duty officer's approval.
Usage modes and degrees of delegation: Table of the action classes against levels and usage modes; the Level 4 prohibitions applied to remediation.
Observable, expected, speculation: Auto-remediation of defined classes is observable; widening to reconfiguration and failover with evidence is expected; unattended recovery of whole estates is speculation.
Figure: Remediation loop: trigger, runbook, action, independent verification, stop path
Planned length: 5,000-6,500 words of prose
Expected existing sources: 2, 20, 59, 63, 64, 75

Chapter 11: Sustain: Capacity, Cost, Energy and Lifecycle

File: 11_sustain_capacity_cost_energy.md
Status: draft
Purpose: Treat O5 Sustain in its steady-state parts: capacity planning with forecasting models, FinOps rightsizing and scheduling by agents (and the risk of agents optimising availability away), energy and carbon reporting, and lifecycle work: patching, end of life, certificate expiry, licences and vulnerability remediation windows. Verify the energy reporting duties against the live text.
Builds on: F29, F47, F69, F105, F111, F132, AI Governance, Chapter 16A
Operations functions: O5 Sustain
Sections: Capacity planning; Cost and FinOps; Agents that optimise; Energy and carbon; Lifecycle; Remediation windows for vulnerabilities
Practical guides: Setting guardrails for a rightsizing agent: floors, windows and a veto for the service owner
Worked examples: A CAP-* record with forecast, error and guardrail for a scaling decision
Nordvik Region and Hansa Mutual: Nordvik Region reports energy for its regional data centre under public-sector duties; Hansa Mutual runs a FinOps agent at Level 2 with a floor on redundancy for regulated services.
Usage modes and degrees of delegation: Table of usage modes against O5 actions: forecast, recommend, schedule, rightsize, delete.
Observable, expected, speculation: Forecasting in capacity tools is observable; agent-run FinOps within guardrails is expected; self-optimising estates without a floor are speculation.
Figure: Capacity and cost loop with guardrails: forecast, decision, floor, review
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 3, 23, 24, 25, 26

Chapter 12: Sustain: Problem Management, Post-Incident Learning and Knowledge

File: 12_sustain_problems_and_learning.md
Status: draft
Purpose: Treat problem management and post-incident learning. Blameless, evidence-based reviews, AI-drafted reviews and their risks (plausible but wrong narratives, hindsight), knowledge-base hygiene, action tracking to closure, and regulatory follow-up of incidents (DORA Article 13 on learning). A finding closes when its re-test passes, not when the review is signed.
Builds on: F2, F14, F102, F103, F116, F126, F140, AI Governance, Chapter 21, AI Purple, Chapter 10
Operations functions: O2 Diagnose; O5 Sustain
Sections: From incident to problem to change; The blameless, evidence-based review; AI-drafted reviews; Action closure; Knowledge hygiene; Regulatory follow-up
Practical guides: Running a review with an AI-drafted timeline and a human-written analysis
Worked examples: PIR-* and PRB-* records with an action closure rule
Nordvik Region and Hansa Mutual: Hansa Mutual closes a review action only when a game-day re-test passes; Nordvik Region reviews incidents in a monthly forum and tracks actions in the service-management system.
Usage modes and degrees of delegation: Table of usage modes against O5 learning tasks: drafting, clustering, trend, proposal of actions, closure.
Observable, expected, speculation: AI-drafted timelines are observable; AI-proposed problem records inside a workflow are expected; automated closure of actions on its own evidence is speculation.
Figure: From incident to problem to change to verified closure
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 3, 19, 67, 81

Part III: Operating AI Systems

Chapter 13: Operating AI Systems: Drift, Model Updates and Provider Change

File: 13_operating_ai_systems.md
Status: draft
Purpose: Treat the operation of AI systems themselves in Modes 2 to 5: model and prompt versions as configuration, silent model updates by providers, evaluation gates in release, retrieval-index freshness, drift and quality objectives for AI services, canarying a model, pinning and fallbacks, deployer duties under AI Act Article 26 (including logs) and post-market monitoring at the interface with Article 72. Verify the article numbers against the live text.
Builds on: F15, F16, F44, F46, F57, F97, F111, F128, F129, AI Platform and Security, Chapters 20 to 22
Operations functions: O1 Observe; O3 Change; O5 Sustain
Sections: What is different about an AI service; Versions as configuration; Provider-side change; Quality objectives; Canarying a model; Deployer duties
Practical guides: Defining quality objectives and a rollback for an AI service
Worked examples: A change record for a model update with quality gates, canary result and rollback
Nordvik Region and Hansa Mutual: Hansa Mutual pins model versions behind a gateway and canaries every update on 5 per cent of claims triage; Nordvik Region consumes a provider's model through a sovereign gateway and treats a provider notice as a change request.
Usage modes and degrees of delegation: Table of usage modes against O1, O3 and O5: what is versioned, who may update, at which level.
Observable, expected, speculation: Silent provider-side model change and drift are observable; contractual notice duties for model change are expected; self-updating production models without gates are speculation.
Figure: AI service release path: evaluation gate, canary, quality objective and fallback
Planned length: 3,600-6,500 words of prose
Expected existing sources: 1, 2, 8, 15, 63

Chapter 14: Incidents Involving AI: Detection, Triage and Reporting

File: 14_incidents_involving_ai.md
Status: draft
Purpose: Define an AI incident operationally: harmful output at scale, an agent acting outside its mandate, a provider outage, data exposure through an assistant. Give a triage tree, containment by stop path, and the reporting of serious incidents under AI Act Article 73 beside NIS 2 Article 23, DORA Articles 17 to 19 and GDPR Article 33. Show the clocks side by side. Use AI incident databases and taxonomies, and published incidents of 2025 and 2026 by mechanism.
Builds on: F28, F46, F67, F106, F135, F136, AI Red Team, Chapter 20
Operations functions: O2 Diagnose; O4 Restore
Sections: What an AI incident is; Detection; Triage tree; Containment; Reporting clocks; Published incidents
Practical guides: Building a one-page clock sheet for a service that is in scope of more than one regime
Worked examples: An INC-NR-* AI incident record with reporting clocks and decisions
Nordvik Region and Hansa Mutual: Nordvik Region has a regional reporting duty and a national CSIRT; Hansa Mutual reports to its financial supervisor and holds a DORA classification procedure.
Usage modes and degrees of delegation: Table of usage modes against O2 and O4: who detects, who may stop, who reports.
Observable, expected, speculation: Agent incidents outside mandate are observable; incident-sharing obligations for AI are expected; automatic reporting by systems on their own incidents is speculation.
Figure: AI incident triage tree with stop path and reporting clocks
Planned length: 3,600-6,500 words of prose
Expected existing sources: 1, 2, 3, 4, 8, 37, 55, 57, 79

Chapter 15: The Economics of AI Operations: Tokens, GPUs, Latency and Energy

File: 15_the_economics_of_ai_operations.md
Status: draft
Purpose: Treat the economics of running AI: unit economics of inference, capacity reservation, latency and quality objectives, fallbacks between models and providers, sovereign and on-premises capacity, energy per request, and budget guardrails for agents (runaway loops). The operator's question is what to spend, where and with which stop.
Builds on: F30, F47, F67, F69, F111, F130, AI Governance, Chapter 16A, AI Platform and Security, Chapter 22
Operations functions: O1 Observe; O5 Sustain
Sections: Unit economics; Capacity; Latency and quality objectives; Fallbacks; Energy; Guardrails for agents
Practical guides: Setting a cost-and-latency budget for an AI service with a stop condition
Worked examples: A cost-and-latency budget record for the Hansa triage service and the Nordvik citizen assistant
Nordvik Region and Hansa Mutual: Nordvik Region runs inference on a sovereign regional cloud with fixed capacity; Hansa Mutual mixes reserved capacity in two regions with a fallback provider.
Usage modes and degrees of delegation: Table of usage modes against O5 and O1: budget owner, limit and stop.
Observable, expected, speculation: Rising inference demand and capacity scarcity are observable; falling cost per request alongside rising total spend is expected.
Figure: Cost, latency and quality envelope of an AI service with fallback and stop
Planned length: 3,600-6,500 words of prose
Expected existing sources: 1, 2, 63

Part IV: The Operator's Own AI

Chapter 16: An AI Agent Team for Operations: Skills, Mandates and Containment

File: 16_an_ai_agent_team_for_operations.md
Status: draft
Purpose: Describe the operator's agent team: roles (observer, triager, change reviewer, runbook runner, capacity planner, scribe), skills as versioned files, a mandate manifest per agent, containment (identity, scoped credentials, sandboxes, rate limits, kill switch), memory and tool permissions, and evaluation before promotion. The pattern is that of The Transformed Security Architect and AI Blue, applied to operations.
Builds on: F12, F27, F45, F51, F75, F88, F98, F101, F130, AI Purple, Chapter 14
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Roles of an operations agent team; Skills as versioned files; The mandate manifest; Containment; Memory and tools; Promotion
Practical guides: Writing a mandate manifest for a runbook-runner agent
Worked examples: An MND-NR-OPS-* mandate manifest for a runbook-runner agent
Nordvik Region and Hansa Mutual: Nordvik Region starts with a scribe and a triager at Level 1; Hansa Mutual operates six agent roles, each with a manifest and a named human owner.
Usage modes and degrees of delegation: Table of the six roles against levels and usage modes; promotion and demotion rules.
Observable, expected, speculation: Agent roles in operations tooling are observable; manifests as a procurement requirement are expected.
Figure: Agent team with the policy decision point and the kill switch outside it
Planned length: 3,600-6,500 words of prose
Expected existing sources: 14, 21, 63, 66, 81

Chapter 17: The Observer Principle: Who Watches the Watcher

File: 17_the_observer_principle.md
Status: draft
Purpose: State the book's central design rule. Independence of verification (probes independent of the remediating agent), the observer not dependent on the observed (out-of-band monitoring, dead-man's switches, a separate failure domain, provider-independent status), a stop path outside the control plane, shared blind spots (the same model family writing a runbook and verifying its fix), seeded faults in game days to test the observers, and the limits set by evaluation awareness. Apply the independence principle of AI Purple to operations. The chapter stages a debate.
Builds on: F45, F62, F63, F67, F68, F76, F99, F118, F121, F129, F141, AI Purple, Chapter 15, AI Threat, Chapter 23
Operations functions: O1 Observe; O4 Restore
Sections: The rule; Independence of verification; The observer outside the observed; Shared blind spots; Seeded faults; Limits; The debate; Verdict
Constructive debate: Concern: Independence costs money and duplication; the more independent probes, the more to run, to keep and to trust; a loop with only independent verification is slow, and independent observers can themselves be wrong. Calm: Most operations incidents in the record came from correlated failure, not from a missing tool: the observer went down with the platform, the verifier shared the credential, the status page ran on the failed provider; the cost of independence is small beside an outage. Where they meet: Both accept that independence is graded by action class, and that the highest-consequence actions need the strongest independence. What can be done: Grade independence by action class; test observers with seeded faults; document failure domains; drill the stop path.
Practical guides: Specifying an observer: probes, failure domains, silence rule and stop path
Worked examples: An OBS-* observer manifest listing independent probes, failure domains and the stop path
Nordvik Region and Hansa Mutual: Nordvik Region places its observer on a different provider and a different network from the platform it watches; Hansa Mutual finds in a game day that its remediation agent and its verifier share a model family and a credential.
Usage modes and degrees of delegation: Table of the independence tests against usage modes and levels: what must differ at Level 2, 3 and 4.
Observable, expected, speculation: Correlated failure of verifier and verified is observable in incident reports; independence requirements in supervisory guidance are expected.
Figure: The operations loop with the observer in a separate failure domain and the stop path outside the control plane
Planned length: 5,000-6,500 words of prose
Expected existing sources: 2, 54, 55, 57, 60, 65

Chapter 18: Defending the Operator's AI: Agents, Credentials and the Control Plane as Tier 0

File: 18_defending_the_operators_ai.md
Status: draft
Purpose: Describe the threats to operations agents by mechanism and the controls that follow: prompt injection through logs, tickets and alert text, over-broad credentials, confused deputy through tools, poisoned runbooks, the supply chain of agent skills and tools, and telemetry as a target. Controls: a separate identity per agent, just-in-time credentials, a policy decision point, signed runbooks, input provenance, break-glass and detection. Defensive only; no strings.
Builds on: F37, F39, F40, F45, F54, F56, F101, F131, AI Platform and Security, Chapter 17
Operations functions: O3 Change; O4 Restore
Sections: Why the operator's AI is a target; Threats by mechanism; Identity and credentials; The policy decision point; Signed runbooks and input provenance; Break-glass; Detection and logging
Practical guides: Writing a permission manifest and a deny-by-default policy for a remediation agent
Worked examples: A permission manifest in Rego for a remediation agent, with denied actions and the log fields
Nordvik Region and Hansa Mutual: Hansa Mutual's policy decision point denies a restore-overwrite requested after an instruction embedded in a ticket; Nordvik Region removes standing credentials from its automation account after an audit.
Usage modes and degrees of delegation: Table of threats against usage modes and levels.
Observable, expected, speculation: Prompt injection through operational text and over-broad automation credentials are observable; standard permission manifests in operations tools are expected.
Figure: Threats to an operations agent mapped to controls outside the model
Planned length: 3,600-6,500 words of prose
Expected existing sources: 9, 10, 13, 14, 15, 16, 21

Part V: Operations in the Organisation

Chapter 19: Resilience as a Claim: Restore Tests, Game Days and Evidence Age

File: 19_resilience_as_a_claim.md
Status: draft
Purpose: Make resilience a claim with evidence. Restore tests with measured recovery time and point, game days and chaos experiments, DORA Articles 11 and 12 and 24 to 25 and NIS 2 Article 21(2)(c) as the demand, TLPT at the boundary (a pointer to AI Purple), evidence age and expiry, and a resilience register in which each recoverability claim carries a date and a result. AI plans and analyses; it does not certify.
Builds on: F58, F59, F62, F116, F119, F127, F135, AI Purple, Chapter 17, AI Red Team, Chapter 25
Operations functions: O4 Restore; O5 Sustain
Sections: A claim has a scope, a result and a date; Restore tests; Game days and chaos experiments; Evidence age; The resilience register; The regulatory demand; Where AI helps
Practical guides: Running a restore test and writing the claim it supports
Worked examples: An RST-HM-* restore-test record with scope, measured times, date, result and expiry
Nordvik Region and Hansa Mutual: Hansa Mutual's restore test for the claims database misses its recovery time by two hours and the claim is withdrawn until the next pass; Nordvik Region tests restoration of its e-service before each election and tax season.
Usage modes and degrees of delegation: Table of usage modes against O4 and O5: who plans, who runs, who attests.
Observable, expected, speculation: Restore tests and game days are observable practice; continuous recovery verification is expected.
Figure: Resilience register: claim, test, result, date, expiry
Planned length: 5,000-6,500 words of prose
Expected existing sources: 2, 3, 12, 20, 58, 59, 60, 64

Chapter 20: Measuring Operations: The Four Key Metrics, SLOs, Toil and the Metrics That Mislead

File: 20_measuring_operations.md
Status: draft
Purpose: Examine how operations is measured: the four key metrics of the DevOps Research and Assessment programme and their cautions, SLO attainment, MTTR as a flawed statistic (distribution and not mean, with cited critiques), toil, autonomy-budget consumption, the false-green dashboard, gaming, and metrics about people (AI Boss). The chapter sets out which metric guides which decision and how each misleads.
Builds on: F84, F89, F103, F105, F110, F132, AI Boss, Chapters 11 to 15
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: What a metric is for; The four key metrics; SLO attainment; MTTR; Toil and the autonomy budget; False greens and gaming; Metrics about people
Practical guides: Writing a metric definition with intended use and misuse notes
Worked examples: Metric definitions with intended use and misuse notes for the four key metrics and for autonomy-budget consumption
Nordvik Region and Hansa Mutual: Hansa Mutual reports time to restore as a distribution to its management body; Nordvik Region stops publishing a mean after its tail incident shows it hid a seven-hour outage.
Usage modes and degrees of delegation: Table of usage modes against metrics: what AI changes in the measured quantity.
Observable, expected, speculation: Metric gaming is observable; replacement of means by distributions in supervisory reporting is expected.
Figure: Metrics mapped to decisions and their typical distortions
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 67, 69, 70

Chapter 21: Operating Models: Platform Teams, SRE, Managed Services and Sovereign Operations

File: 21_operating_models.md
Status: draft
Purpose: Compare operating models: in-house SRE, a platform team with a product mindset, centralised against embedded, managed service providers, follow-the-sun, sovereign and national operators for public authorities, and hybrids. Show what AI changes in team topology and in who owns what. Verify any citation of Team Topologies.
Builds on: F10, F22, F97, F104, F108, F111, F133, AI Blue, Chapter 17
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Options; What AI changes; Buying operations with AI inside; Ownership; The operations conductor; Public authorities
Practical guides: Choosing an operating model by service criticality and sovereignty
Worked examples: A ROLE-* charter for an operations conductor
Nordvik Region and Hansa Mutual: Nordvik Region buys night operations from a regional operator and keeps a small platform team; Hansa Mutual runs SRE in-house for core services and buys follow-the-sun cover for the rest.
Usage modes and degrees of delegation: Table of operating models against usage modes and levels.
Observable, expected, speculation: Managed operations with embedded AI are observable; provider AI acting across clients is expected.
Figure: Operating model options placed by criticality and sovereignty
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 62, 66, 81

Chapter 22: Decision Rights, Change Authority and the Incident Commander

File: 22_decision_rights_and_the_incident_commander.md
Status: draft
Purpose: Settle who may approve change, declare an incident, authorise a failover, stop an agent and accept risk. The incident commander and AI; delegation profiles (DLG); change authority replacing the change advisory board; evidence for supervisors; and records of delegation. Decision rights are requirements with a holder, a deputy, a response time and a record.
Builds on: F17, F18, F19, F63, F93, F100, F107, F134
Operations functions: O2 Diagnose; O3 Change; O4 Restore
Sections: Decision rights as requirements; Change authority; The incident commander; Failover and stop; Risk acceptance; Delegation profiles
Practical guides: Building a decision-right matrix for the first ten decisions of a bad night
Worked examples: A DLG-HM-* delegation profile with a decision-right matrix
Nordvik Region and Hansa Mutual: Hansa Mutual names an incident commander with two deputies and a 10-minute response time; Nordvik Region fixes a duty officer and a regional director who may stop any agent.
Usage modes and degrees of delegation: Table of decision rights against levels.
Observable, expected, speculation: Named-person duties under DORA and NIS 2 are observable; delegation profiles as supervisory evidence are expected.
Figure: Decision-right matrix across the operations loop
Planned length: 3,600-6,500 words of prose
Expected existing sources: 1, 2, 3, 66, 81

File: 23_regulation_as_constraint.md
Status: draft
Purpose: Map regulation to operations at article level: DORA Articles 5 to 16 (ICT risk), 17 to 23 (incidents), 24 to 27 (testing), 28 to 44 (third parties) and 45 (information sharing); NIS 2 Articles 20, 21, 23, 24; the CER Directive; AI Act Articles 4, 12, 14, 26, 72, 73; GDPR Articles 22 and 32 to 34; Data Act Chapter VI; the Cyber Solidarity Act at the edge; works-council rights over on-call and monitoring. Every article is verified against the live text.
Builds on: F25, F46, F78, F86, F106, F135
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: How to read the mapping; DORA; NIS 2 and CER; The AI Act; GDPR and Data Act; Cyber Solidarity Act; Staff rights; Who is in scope
Practical guides: Turning an article into a control with an owner and evidence
Worked examples: A regulation-to-control mapping table for the five functions
Nordvik Region and Hansa Mutual: DORA applies to Hansa Mutual as a financial entity; NIS 2 applies to Nordvik Region through national transposition.
Usage modes and degrees of delegation: Notes which duties differ by usage mode.
Observable, expected, speculation: Instruments in force are observable; timelines for application and delegated acts are labelled expected.
Figure: Instruments mapped to the five functions
Planned length: 3,600-6,500 words of prose
Expected existing sources: 1, 2, 3, 4, 5, 7, 8, 79, 80

Chapter 24: Across Boundaries: Cloud Providers, Managed Providers, Outages and Exit

File: 24_across_boundaries.md
Status: draft
Purpose: Treat dependence on providers: concentration risk, shared responsibility in an outage, provider status pages as telemetry, contracts (DORA Article 30 key provisions), registers of information, exit plans and switching under the Data Act, multi-region against multi-cloud, sovereignty frameworks, and joint exercises. Use verified outage reports.
Builds on: F30, F47, F57, F97, F111, F136, AI Governance, Chapter 7
Operations functions: O1 Observe; O4 Restore; O5 Sustain
Sections: Concentration; In an outage; Provider status as telemetry; Contracts and registers; Exit and switching; Multi-region and multi-cloud; Sovereignty; Joint exercises
Practical guides: Writing the operational transparency and exit-test annex to a cloud or managed contract
Worked examples: A contract annex for operational transparency and exit test
Nordvik Region and Hansa Mutual: Nordvik Region tests exit from its sovereign cloud to a second regional provider for one service; Hansa Mutual keeps a register of information for its ICT providers.
Usage modes and degrees of delegation: Table of provider AI at Level 3 across clients against clauses.
Observable, expected, speculation: Concentration and cascading outages are observable; exit rights under the Data Act are expected to be exercised; fully portable estates are speculation.
Figure: Provider dependencies, failure domains and exit paths
Planned length: 3,600-6,500 words of prose
Expected existing sources: 2, 3, 8, 62, 80

Part VI: People and Career

Chapter 25: Operators as People: On-Call, Toil, Trust and Wellbeing

File: 25_operators_as_people.md
Status: draft
Purpose: Treat operators as people: on-call burden, alert fatigue, how automation affects vigilance and responsibility (the moral crumple zone), blameless culture, working-time law on on-call time, co-determination over on-call schedules and monitoring (German BetrVG section 87; Swedish MBL sections 11 and 12), psychological safety and incentives. Describe by what studies measured; verify law and case law.
Builds on: F52, F53, F66, F84, F86, F89, F90, F110, F137, AI Boss, Chapters 11 to 15
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: The on-call burden; Alert fatigue; Automation and the operator; Blameless culture; Working time; Co-determination; Incentives
Practical guides: Drafting an on-call charter with the works council
Worked examples: An on-call charter
Nordvik Region and Hansa Mutual: Nordvik Region agrees an on-call charter with its trade unions; Hansa Mutual caps pages per shift and reviews them monthly.
Usage modes and degrees of delegation: Table of usage modes against load and responsibility.
Observable, expected, speculation: Alert fatigue is observable; whether AI relieves or intensifies load is open and labelled so.
Figure: On-call load, automation and responsibility
Planned length: 3,600-6,500 words of prose
Expected existing sources: 67, 70, 72, 73, 75, 76

Chapter 26: Competences and Keeping the Operator's Craft

File: 26_competences_and_keeping_the_craft.md
Status: draft
Purpose: Describe the competences an operator needs now: systems thinking, verifying an agent's proposal, manual operation, prompt and skill authorship and judgement under uncertainty; how skill decays and how to prevent it (manual drills, game days with agents off, dark days); the early-career route when entry tasks are automated; ECSF and SFIA mapping. The chapter stages a debate: will automation deskill operators?
Builds on: F11, F26, F66, F77, F79, F108, F109, F138, AI Purple, Chapter 24
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Competences; Skill decay; Keeping the craft; The early-career route; Frameworks; The debate; Verdict
Constructive debate: Concern: Automation takes the routine tasks that taught operators, leaves the hardest to people who no longer practise, and removes the entry route; Bainbridge's ironies describe this. Calm: Each wave of tooling changed the craft without destroying it; operators move up to design and verification; drills and simulations can replace some on-the-job learning. Where they meet: Both accept that skill must be exercised on purpose and that the entry route needs design. What can be done: Run dark days and drills; record competence; protect an apprenticeship route; measure manual recovery time yearly.
Practical guides: Planning a drill year with agents off
Worked examples: A CMP-* competence record and a drill plan
Nordvik Region and Hansa Mutual: Hansa Mutual holds a quarterly dark day; Nordvik Region runs an apprenticeship rotation through its night service.
Usage modes and degrees of delegation: Table of usage modes against skill exercised and drilled.
Observable, expected, speculation: Skill decay under automation is observable in other domains; effects in operations are expected; wholesale deskilling is speculation.
Figure: Competence, drill and evidence across a career
Planned length: 5,000-6,500 words of prose
Expected existing sources: 66, 67, 75, 76, 77, 78, 81

Chapter 27: The Future of Operations: Will Anyone Be on Call in 2036?

File: 27_the_future_of_operations.md
Status: draft
Purpose: Give the book's outlook with labels. Trajectories: agentic SRE, self-driving infrastructure, provider-run autonomous operations, regulation (AI Act timelines, DORA maturity), compute and energy limits. The chapter stages a debate and carries the author's own projections, labelled, ending in a verdict.
Builds on: F32, F33, F80, F113, F124, F139, AI Purple, Chapter 25
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Observable; Expected; Speculation; Limits; The debate; The author's projection; Verdict
Constructive debate: Concern: Agentic operations will reach most routine work; the operator becomes a rare specialist; concentration in a few providers' autonomous operations creates a single point of failure with no human who can take over. Calm: Operations has repeatedly absorbed automation; regulation requires named people; incidents keep needing judgement; on-call changes in form, not in kind. Where they meet: Both agree that a stop path and a trained person are the safety net. What can be done: Keep a horizon register; test claims against incident data; keep manual capability.
Practical guides: Keeping a horizon register for operations
Worked examples: A horizon register with labels for twelve trends
Nordvik Region and Hansa Mutual: Both organisations revisit their autonomy ceilings in 2030 and 2033 against evidence.
Usage modes and degrees of delegation: Table of expected ceilings per function over time.
Observable, expected, speculation: Each statement carries observable, expected or speculation; the author's projections are labelled.
Figure: Trajectories to 2036 labelled by evidence
Planned length: 5,000-6,500 words of prose
Expected existing sources: 1, 2, 32, 38

Part VII: Experience and Conclusions

Chapter 28: Case Studies and Anti-Patterns

File: 28_case_studies_and_anti_patterns.md
Status: draft
Purpose: Analyse verified public cases by mechanism with the book's lenses: the CrowdStrike content update (July 2024), the Facebook configuration change (October 2021), Knight Capital (2012), GitLab.com data loss (2017), the Atlassian deletion incident (2022), the OVHcloud Strasbourg fire (2021), the AWS us-east-1 outage (October 2025), the Google Cloud Service Control outage (June 2025), Cloudflare outages (2025) and agent-in-production incidents (Replit database deletion, 2025). Verify each against primary post-incident reports; drop any that cannot be verified. Add the anti-pattern catalogue.
Builds on: F28, F67, F114, F140, F141, AI Governance, Chapter 20
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: How the cases were chosen; Change and configuration cases; Data and recovery cases; Provider outages; Agent cases; Anti-patterns
Practical guides: Reading a post-incident report with the five functions
Worked examples: A case table: mechanism, function, observer failure, lesson
Nordvik Region and Hansa Mutual: Each case is replayed against Nordvik and Hansa to ask what each would have done.
Usage modes and degrees of delegation: Table of cases against usage modes where relevant.
Observable, expected, speculation: Cases are observable; lessons are the book's interpretation and labelled so.
Figure: Anti-patterns placed on the operations loop
Planned length: 5,000-6,500 words of prose
Expected existing sources: 2, 37, 55, 63

Chapter 29: A Year in Operations: Nordvik Region and Hansa Mutual

File: 29_a_year_in_operations.md
Status: draft
Purpose: Narrate a year with named people in both organisations, month by month: the introduction of the assistant, the first autonomy-budget breach, a provider outage, a failed restore test, an AI incident, a works-council agreement and a game day with agents off.
Builds on: F102, F114, F141, AI Purple, Chapter 27, AI Blue, Chapter 26
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Months 1 to 3; Months 4 to 6; Months 7 to 9; Months 10 to 12; What the year showed
Practical guides: A monthly review template
Worked examples: A year ledger of records across both organisations
Nordvik Region and Hansa Mutual: Characters are defined in the operations profiles of the two organisations.
Usage modes and degrees of delegation: Records show levels per month.
Observable, expected, speculation: The narrative is illustrative and labelled so.
Figure: A year timeline with the five functions
Planned length: 5,000-6,500 words of prose
Expected existing sources: 2, 3

Chapter 30: Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

File: 30_conclusions_for_nordvik_and_hansa.md
Status: draft
Purpose: Draw conclusions for each organisation: a 12-month plan, decisions for the board, indicators of the book's own claims and risks.
Builds on: F70, F112, AI Purple, Chapter 28
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: Nordvik Region; Hansa Mutual; Decisions for the board; Indicators; Risks
Practical guides: A board paper outline
Worked examples: Two 12-month plans
Nordvik Region and Hansa Mutual: Both organisations are revisited at the end of the plan.
Usage modes and degrees of delegation: Plans set target levels per function.
Observable, expected, speculation: Plans are the author's projections for illustrative organisations and are labelled so.
Figure: Two organisations' operations maturity today and in a year
Planned length: 4,000-5,500 words of prose
Expected existing sources: 2, 3

Chapter 31: Conclusions: Operations with AI

File: 31_conclusion.md
Status: draft
Purpose: Judge the thesis against the evidence: what is established, what is expected, what remains speculation; the author's projections, labelled; five things a reader does on Monday.
Builds on: F70, F91, F112, F113, F139, AI Purple, Chapter 29
Operations functions: O1 Observe; O2 Diagnose; O3 Change; O4 Restore; O5 Sustain
Sections: The five-part thesis judged; The observer principle; Open questions; The author's projections; What to do on Monday
Practical guides: A first-week plan
Worked examples: A one-page operations charter
Nordvik Region and Hansa Mutual: Both organisations are revisited.
Usage modes and degrees of delegation: The verdict states the delegation ceilings the author recommends.
Observable, expected, speculation: The author's projections are labelled as such.
Figure: The five functions with the verdict on each part of the thesis
Planned length: 4,000-5,500 words of prose
Expected existing sources: 1, 2

Appendices

32_glossary.md: Defines the vocabulary of operations with AI: the five functions (O1 Observe to O5 Sustain), the degrees of delegation and usage modes, the book's artefacts (service record, service level objective, runbook manifest, incident record, change record, problem record, post-incident review, restore-test record, capacity record, observer manifest, mandate manifest, delegation profile, role charter, competence record), the observer principle, and the terms of DORA, NIS 2, the AI Act, the GDPR and the Data Act.
33_appendix_a_code_examples.md: Appendix A: complete versions of the artefacts in the chapters: service level objective record, runbook manifest, mandate manifest for an operations agent, observer manifest, restore-test record, change record, incident record, delegation profile, on-call charter and permission manifest. No attack tooling. Each artefact is a complete, valid file that the chapters show in part, with the field names, the identifier scheme (SVC, SLO, RBK, INC, CHG, PRB, PIR, RST, CAP, OBS, MND, DLG, ROLE, CMP) and the checks that the tests and pipelines apply to it.
appendix_templates_and_tools.md: Appendix B: templates and tools: operations mandate summary, delegation-profile template, observer checklist, restore-test template and decision-right matrix.
34_references.md: The only bibliography of the book: European instruments on resilience, cybersecurity, data protection and AI, frameworks and taxonomies, threat assessments, published operations, chaos and automation literature and the earlier volumes of the series. Only verified sources are listed.
35_about_the_author.md: About the author of The Transformed Architecture, placed at the very end of the book. The chapter carries the author's professional background, the lineage from Architecture as Code to this book, a note on Kvadrat, the Swedish terminology reference and the note on how the book was made: the design of the book, the review and approval of every change, the judgement and the answer for the sources remain the author's, whatever the agents drafted. It is carried over from the previous volume and updated for the tenth volume when the manuscript is finalised.