An operations organisation says many things about recovery: that the database can be restored from backup, that the portal fails over to the second site, that the service degrades to manual routing within fifteen minutes. This chapter treats each of those sentences as a claim, and a claim has a scope, a measured result, a date and an expiry. It concerns O4 Restore, where services are returned to an acceptable state by remediation, rollback, failover and recovery from backup, and O5 Sustain, where the estate and the people are kept fit over time and where problem management and learning turn a failed test into a change. The rule it carries from Chapter 4 is short: untested is not recoverable, and evidence expires as the estate changes.
The chapter follows the pattern that AI Purple, Chapter 17, set for security coverage. There, a coverage statement was a claim with five parts, computed into a status by rule, and a heat map without age and evidence was not a statement. Resilience takes the same form. The chapter defines the parts of a recoverability claim, shows how restore tests and game days produce the evidence, explains why that evidence ages and how the age is computed, and sets out the register in which every claim carries its latest result. It then reads the regulatory demand (DORA Articles 11, 12, 24 and 25 and NIS 2 Article 21(2)(c)) as a requirement for exactly this evidence, and ends with the part AI may play: it plans and analyses, and it does not certify.
Operations documents are full of objectives. The service records of Chapter 4 give each service a recovery time objective (RTO), the longest time the organisation accepts between the start of an outage and the return of an acceptable service, and a recovery point objective (RPO), the longest span of data it accepts to lose. An objective is a target. It becomes a statement about the world only when something shows that the target is met, and the book's rule is that the something is a test with a date and a result.
Primary topics explored
- 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
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 19: Resilience as a Claim: Restore Tests, Game Days and Evidence Age in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Operations in the Organisation” and is one of 35 drawn from the manuscript.