Steward the Release: CI/CD, Change and Operating What You Build

A change that has been written, reviewed and tested has still not been released. Between the merged pull request and the citizen or policyholder who meets the result lies the release path: the pipeline, the gates, the rollout and the person who can undo it. This chapter treats that path as the place where D5 Steward is exercised hardest, because it is where the volume of generated code meets the organisation's capacity to absorb change. It draws on D4 Prove, because a gate is only worth the independence of its oracle, and on D3 Build, because the number and size of the changes that arrive are set by how code is made.

The chapter makes one claim. When AI takes part in a change, the release path must contain at least one gate that the change cannot alter, and a named owner who can revert the change from outside the pipeline that shipped it. The first half is the corollary of the stewardship principle of Chapter 4 (the test oracle must be independent of the generator) applied to the last step before production; the second is its Revert test. The chapter then asks what the key metrics of the DevOps Research and Assessment (DORA) programme (four in the 2014-2023 formulation, five in the current guide) can say under AI, how "you build it, you run it" survives a rise in change volume, and what a change record CHG-* looks like when it carries its own evidence. "DORA" without qualification means Regulation (EU) 2022/2554, as everywhere in this book.

The release path with gates inside and outside the reach of the change, progressive delivery rings, a named owner and a stop path outside the pipeline

Figure 11.1: The release path. The gate policy, the independent oracle and the hardened build sit outside the reach of the change; the owner holds a stop path that does not depend on the pipeline.

AI Operations treated the operations side of the same events: O3 Change (Chapters 8 and 9), the observer principle (Chapter 17) and change authority (Chapter 22) (170, Nordqvist, 2026). This chapter does not repeat them. It asks what the developer owes the release path, which is a different question from what the operator owes the service.

Release practice when the diffs multiply

Pipelines and trunk-based development

A delivery pipeline is the automated sequence that turns a commit into a running change. Architecture as Code (Chapters 10, 13 and 15A) made it the place where policy as code, tests and evidence as code are enforced, so that a failing control fails the build (161, Nordqvist, 2025). AI Platform and Security, Chapter 19, added that containment keeps control artefacts outside an agent's reach, with a stop path outside the system it stops (163, Nordqvist, 2026). Both conclusions concern where a control lives, which is the subject of this chapter.

Trunk-based development is the branching practice most associated with fast, safe release. The DevOps Research and Assessment (DORA) programme describes it as merging small batches into the main line at least daily, with three or fewer active branches, branches that last no more than a few hours, and no code freezes (224, Google Cloud, n.d.). Small batches are the safety mechanism: a small change has a small blast radius and is easy to review and revert. The practice also assumes that a person can hold the change in mind, and feature flags, which let unfinished work reach the trunk without reaching users, make it workable.

What AI changes in volume and size

Generative AI changes the input to the path before it changes the path, and the evidence is mixed and young.

The DORA programme's 2025 report, drawing on nearly 5,000 survey respondents and over 100 hours of qualitative data, reports a positive relationship between AI adoption and delivery throughput and a continuing negative one with delivery stability; the authors read this as acceleration exposing weaknesses downstream (42, Harvey & DeBellis, 2025). The 2024 report's page states that AI adoption negatively affected delivery stability and throughput, with no magnitudes on the page read here (216, Google Cloud, 2024). These are survey associations from successive years, and the direction of the throughput finding changed between them.

Telemetry points the same way on volume. A vendor study of more than 10,000 developers in 1,255 teams, with data as of June 2025, compared each team's quarters of lowest and highest AI adoption and reported that teams with high AI adoption merged 98 per cent more pull requests, that review time rose 91 per cent and average pull request size 154 per cent, and that no significant company-level correlation between AI adoption and throughput, DORA metrics or quality indicators appeared (225, Faros Research, 2025); it reports associations, not causal effects, and is vendor research. Field experiments with 4,867 developers reported a 26.08 per cent increase in completed tasks, in the SSRN abstract (176, Cui et al., 2024). A randomised trial of 16 experienced open-source developers on 246 tasks found that allowing early-2025 AI tools lengthened completion time by 19 per cent, against an expected 24 per cent reduction (63, Becker et al., 2025). None of these studies measured a release path. Together they support something narrow: more and larger changes reach review, perceived and measured effects can diverge, and review is where the pressure shows.

The book's first conclusion follows. A release path designed for a given number and size of changes has to be re-examined when either changes, and the controls that rely on a person reading the change are the first to need it. As an illustration, a reviewer who reads five pull requests a day carefully cannot read ten larger ones with the same care. Chapter 9 treats review under volume; the consequence here is that the release path must not rely on review alone and needs gates whose strength does not fall as the diffs multiply.

Progressive delivery

Progressive delivery exposes a change to a growing share of users or systems while measuring its effect, with the ability to stop and revert at each step. It has three parts: flags, rings and a way back.

Feature flags

A feature flag, or toggle, is a runtime switch that decides whether a code path is active. Hodgson distinguishes release toggles, which let incomplete code ship as latent code and should be short-lived; experiment toggles; ops toggles, including long-lived kill switches; and permissioning toggles (128, Hodgson, 2017). He warns that flags multiply and advises a removal task when a release toggle is created, expiry dates and a limit on their number.

Three consequences follow when AI generates code. A flag is a production change in its own right, so its state belongs in a change record with an owner. A flag generated beside a feature adds a branch the reviewer must reason about in two states. A release toggle without an expiry is latent code nobody owns.

Hodgson cites the Knight Capital loss as a warning. In the order of the US Securities and Exchange Commission, Knight deployed new code to its order-routing servers in stages from 27 July 2012, reusing a flag that had once activated an obsolete function. A technician did not copy the new code to one of eight servers, no second technician reviewed the deployment, and no written procedure required one. On 1 August the eighth server read the repurposed flag and activated the old code; in approximately 45 minutes it sent orders resulting in 4 million executions of more than 397 million shares, and Knight realised a $460 million loss. Responding, Knight uninstalled the new code from the seven correct servers, which worsened the problem (29, U.S. Securities and Exchange Commission, 2013). No AI was involved, and AI sharpens the lessons: a repurposed flag is a change without a change record, a deployment checked by its maker is not checked, and a rollback not rehearsed can make things worse.

Canaries and rings

A canary is, in the words of the Google site reliability engineers, a partial and time-limited deployment of a change and its evaluation, with the rest of the service as the control; it should be representative, use metrics attributable to the change, and pair relative comparison with absolute measures such as service level objectives (129, Warner et al., 2018). Rings extend the idea: the change is promoted through successively larger populations, with bake-in time at each step.

The CrowdStrike incident of July 2024 shows what a missing ring costs. Its root cause analysis lists a parameter count mismatch that evaded several layers of build validation and testing, a logic error in the Content Validator, and no staged deployment for template instances; the mitigations include rings with canary testing, bake-in time and customer control over when updates deploy (28, CrowdStrike, 2024). No AI was involved. A validator is itself code and can be wrong, so a gate needs its own tests; and when every check has passed, what limits harm is exposure management.

Hansa Mutual has the same experience in miniature: a configuration push to the AI gateway routing in September 2027 broke the claims assistant in four markets for 47 minutes because the canary stage was skipped on a change classified as standard (INC-HM-2027-0833; AI Operations). The ring sequence is a property of the path, not of the change; a change cannot declare itself standard and skip it.

Rollback, and what cannot be rolled back

Rollback is the third part, and the one most often assumed. A change to code and configuration can be reverted by redeploying the previous version; a change to data, schemas or contracts cannot always be. Sato's parallel change pattern keeps backward-incompatible changes reversible: expand the interface to support old and new versions, migrate clients, and contract only when all have moved (130, Sato, 2014). Until the contract phase, the way back exists.

When the way back does not exist, the consequences are measured in days. In April 2022 a script at Atlassian received site identifiers instead of app identifiers; the deletion interface accepted both, peer review and staging did not catch it because the identifiers did not exist in staging, and 883 sites of 775 customers were deleted within 23 minutes. Atlassian could not at the time restore a large set of sites and their inter-connected products from backups, and all sites were restored by 18 April, up to 14 days for some customers (76, Atlassian, 2022). A destructive action on production data is what the Level 4 prohibition exists for.

The AI Incident Database catalogues, from five press reports and no primary post-incident report, an allegation that an AI development assistant at Replit deleted a live production database during a code freeze despite instructions not to (33, AI Incident Database, 2025). The events are allegations, and the lesson does not depend on them: an instruction is not a control. A freeze enforced by a message to an agent is a request; one enforced by a credential the agent does not hold is a boundary.

The gate a change cannot alter

A gate is a check that a change must pass before the next stage. A gate that the change can alter is a suggestion. This section defines the property, shows where it fails and gives a guide to adding one.

Four properties of a gate the change cannot alter

The Level 4 prohibition of Chapter 4 is that no change reaches production without a gate that the change itself cannot alter. A gate qualifies when it has four properties, which are the book's own conclusions from the stewardship principle and the independence and observer principles of AI Purple, Chapter 15, and AI Operations, Chapter 17 (169, Nordqvist, 2026) (170, Nordqvist, 2026).

  1. Out of reach. The definition of the gate (policy, thresholds, required checks, who must approve) is stored where the change and its author, human or agent, have no write access: a separate repository with different owners, or organisation-level settings. A pull request that touches the pipeline or the gate configuration is routed to the gate's owners and never merged on the strength of its own checks.
  2. Out of band execution. The gate runs on infrastructure the change cannot influence, and its secrets are not available to the steps the change defines. The SLSA build track expresses this at the build platform: at its third level, runs are prevented from influencing one another and signing secrets are kept from user-defined build steps (231, OpenSSF, n.d.).
  3. Independent oracle. The tests that decide whether the change is correct are not written by its generator (Chapter 9). Errors among capable models are correlated: in a study of over 350 models, larger and more accurate models had highly correlated errors, and on one leaderboard dataset models agreed 60 per cent of the time when both erred (35, Kim et al., 2025); and a model used as evaluator can distinguish its own outputs from others' with non-trivial accuracy and tends to score them higher (36, Panickssery et al., 2024). A second model reviewing the first is a partial remedy at best.
  4. Shown to work. The gate is tested like the code it protects, with dated seeded faults that it must catch, so that its strength is a record and not an assumption (AI Operations, Chapter 17).

Table 11.1 sorts typical release-path controls by whether the change can alter them.

Control Can the change alter it? Why
Pipeline definition file in the same repository Yes The change can edit the file that defines the checks
Tests added in the same pull request by the same author or agent Yes, as oracle The oracle shares an author with the code
Required status checks and branch rules set at organisation level No, for contributors Configuration lies outside the repository and its write permissions
Policy as code in a separate repository with its own owners No Different owners, a different review route
A second human approver who is not the submitter No, if independence is enforced The DORA delegated regulation asks for independence of the functions that approve changes (Article 17(1)(b)) (15, European Commission, 2024)
An AI review comment Not applicable It is advice; it never counts as the human review
Canary analysis against service level objectives defined by the platform team No Thresholds and telemetry are outside the change
Synthetic journeys owned by the quality function No The oracle is maintained by someone other than the author
A deployment credential held by the pipeline, not the agent No The agent cannot deploy except through the gate

Table 11.1: Release-path controls sorted by whether the change can alter them.

Because a change to the gate is itself a change, a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates is never delegated at Level 4. In both delegation profiles the class is unlisted, and an unlisted class is undelegated. An agent may draft a change to a gate for a person to review; it may not merge it.

Where gates fail

Gates fail in three recurring ways.

The approver is not independent. In June 2029 a quarter-end change to the COBOL settlement module of Hansa Mutual's policy administration platform was approved by one reviewer who was also the only other person who knew the module; it paid 312 claims twice, and the duplicates were recovered within two days (INC-HM-2029-0207; no AI was involved). Two approvers are required on such changes, yet the number of approvers was not the control. The control is a second approver who can read the change, is not its author and does not share its blind spot. Where twelve people maintain the code, the gate cannot be a person alone: it needs an oracle, such as a settlement reconciliation against an independent calculation.

The check was run by the thing it checks. A test that an assistant wrote to pass its own implementation verifies less than it appears to. This is why Saga Edvardsson of Nordvik Region asks who writes the oracle for the portal's regression pack, which a generator that can edit it in the same pull request would no longer leave hers.

The gate was itself wrong. The CrowdStrike validator contained a logic error, and the Knight deployment had no second pair of eyes. A gate that has never failed a seeded fault has not shown that it can.

Practical guide: Adding a generator-independent gate and a rollback rehearsal to a release path

Purpose. Give one service's release path a gate that the change cannot alter and a revert that has been practised, and record both, before the delegation profile lets AI-assisted change reach the service above Level 0.

Roles. The tech lead of the owning team (the named owner), a platform engineer who owns the pipeline, the quality engineer who owns the oracle, the architect and the engineering manager who allots the time; at Hansa Mutual also the second-line risk function. Where the rehearsal changes on-call practice, the works council or union is informed as the applicable agreement requires.

Inputs. The service record SVC-*, the pipeline definition, the branch and approval rules, the delegation profile DLG-*, the code-ownership record OWN-*, the last ten changes with outcomes, and the runbooks RBK-*.

Steps.

  1. Draw the release path from commit to production and mark each control as inside or outside the reach of a change, using Table 11.1.
  2. Move the gate definition out of the change's reach: a separate repository or organisation setting, with owners who are not the team's authors, and a rule routing any change to the pipeline or gate to them.
  3. Name the oracle for the change class (regression pack, contract tests, synthetic journeys, reconciliation) and its owner, and confirm that the generator cannot edit it in the same change.
  4. Seed three faults the gate must catch (a failing contract, a boundary case, a policy violation), run the gate and record which were caught. Repeat after any change to the gate.
  5. Define the rings, bake-in time and promotion conditions from the service level objectives, and declare that a change cannot skip a ring by its own classification.
  6. Write the revert in two forms: through the pipeline, and a stop path outside it (a kill switch, a re-pin of the previous release through a break-glass role). Name who may use it without approval and how they are reached out of hours.
  7. Rehearse the revert in staging, record minutes to restore against a target and the date, and set an expiry for the evidence.
  8. For a change to data, schemas or contracts, apply expand, migrate and contract, or mark it as having no revert and require a human decision at a higher class.
  9. Record the AI Decision Record that adopts the rule and review it when the gate, profile or service changes.

Result. A change record CHG-* carrying the gate, the oracle, the approvals, the rings, the revert and the rehearsal, as in the worked example below.

Change risk and approval

Change approval has a history of being heavy and of being mistaken for the gate. The DORA programme reports that heavyweight external approval, such as a change advisory board or senior sign-off, has a negative impact on delivery performance, that it found no evidence that more formal external review lowers the change fail rate, and that such processes lead to larger batches released less often; the page keeps a coordinating role for the board (223, Google Cloud, 2025). The page does not address AI-generated change, and it does not say that approval is unnecessary. It says that a signature on a ticket is a weak control beside a gate that tests the change.

For the financial sector the regulatory floor runs the same way. DORA Article 9(4)(e) requires documented policies, procedures and controls for ICT change management, based on a risk assessment, so that all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner (2, European Union, 2022). Delegated Regulation (EU) 2024/1774 Article 17(1) adds verification that ICT security requirements are met, mechanisms to ensure the independence of the functions that approve changes, fall-back procedures and responsibilities, and safeguards and later approval for emergency changes (15, European Commission, 2024). The implication for design, not legal advice, is that the change record is the evidence artefact, with an independent approver and a fall-back. It applies to Hansa Mutual's EU entities as financial entities and does not bind Nordvik Region.

Three rules follow for generated change, applying the change authority of AI Operations, Chapter 22: class approval, a small forum for exceptions and an emergency right whose approver is never the requester (170, Nordqvist, 2026).

  1. Approve classes, not items. A class that is low in blast radius, reversible and covered by a strong gate, such as a patch-level dependency update outside the security-critical path, is approved once with an owner and an expiry, and the pipeline merges within it. AI Governance, Chapter 24, concluded the same of patching: a weekly board cannot sit in the path of known-exploited vulnerabilities (162, Nordqvist, 2026). Hansa Mutual's Level 3 Bounded class under MND-HM-DEV-01 is this rule.
  2. Reserve human judgement for what is irreversible or security-critical. Changes to authentication, authorisation, cryptography or payment logic, to the gate, to an agent's mandate, or to production data in a way that cannot be undone go to a named developer and are never delegated at Level 4.
  3. Let a model score, not approve. A change-risk reviewer such as HM-OPS-003 at Level 0 Advisory is an input to a person's decision. A high score routes to review; a low score never removes the gate.

The key metrics and their limits

What they measure

The DORA programme names five software delivery metrics. Throughput is measured by change lead time (commit to production), deployment frequency and failed deployment recovery time; instability by change fail rate (the share of deployments needing immediate intervention, such as a rollback or hotfix) and deployment rework rate (the share of deployments that are unplanned and result from a production incident) (222, Harvey, 2026). The programme's original four key metrics, the 2014-2023 formulation that AI Operations, Chapter 20, calls "the four key metrics" (170, Nordqvist, 2026), have become five in the current guide, which renamed time to restore as failed deployment recovery time and added deployment rework rate. Here "the key metrics" means the current five. The page says the metrics apply at the level of an application or service, that comparing unlike applications can mislead, that several metrics should be used so that they create tension, and that mandating outcomes such as many deployments a day invites gaming.

What they do not measure, and what AI does to them

They do not measure value, the quality of the decision to build, review depth or the health of the people who build. They are open to Goodhart's law (in Strathern's phrasing, that a measure which becomes a target ceases to be a good measure), whose variants Manheim and Garrabrant categorise (61, Manheim & Garrabrant, 2019), and to the metric fixation that Muller documents across institutions (100, Muller, 2018). AI sharpens each metric in a specific way; the reading is the book's own, drawn from the definitions.

  • Deployment frequency rises when a team ships many small generated changes, whether or not they matter.
  • Change lead time falls when review is shortened or skipped, and rises when the review queue grows with volume.
  • Change fail rate depends on what counts as needing immediate intervention. An agent or a pipeline that repairs forward silently can hide a failure from the metric.
  • Failed deployment recovery time improves with a rehearsed revert and worsens when the person who must repair a change did not write it and cannot reconstruct it. This is the Understand test, measured in minutes.
  • Deployment rework rate is the most direct measure of unplanned work that generated change creates downstream, and the metric where the instability the 2025 report associates with AI adoption should become visible.

The Nordvik pilot shows the risk. Its note to the executive committee said "a third faster" on an acceptance rate and a survey of nine of twelve pilot developers; nobody had measured delivery time (AVR-NR-2030-01). The release path can supply a better measurement: change lead time and change fail rate at team level, with a baseline taken before the pilot is extended, and a date. It cannot and must not supply it per developer, and the agreements point the same way: Hansa Mutual's draft annex KBV-IT-2024-DEV-01 reports telemetry by team with a minimum group size of five and excludes acceptance rates from appraisal and pay, and Nordvik Region's MBL-NR-IT-2027-01 keeps operations measures from being reported by name. Chapters 20 and 22 develop adoption measurement and telemetry rights.

Table 11.2 lists measures that sit beside the five metrics. They are suggestions of the book, not findings.

Measure What it shows Evidence age
Share of production changes with gate evidence in the change record Whether the gate is used or bypassed Weekly
Median age of the oldest open pull request in the review queue Whether review keeps up with volume Weekly
Seeded faults caught by the gate, of those seeded Whether the gate is as strong as claimed At each seeding, expires after 90 days
Minutes to restore in the last rehearsal against target Whether the Revert test is passed Expires after 90 days
Share of repositories deployed with an active named owner Whether the Name test is passed Monthly

Table 11.2: Release-path measures that sit beside the five delivery metrics.

You build it, you run it

The phrase comes from Amazon: in a 2006 interview with Jim Gray Werner Vogels put the practice as "You build it, you run it" (120, Gray, 2006). The argument is one of feedback, since a team paged for its own failures designs differently, and of ownership, which the stewardship principle tests.

Ownership with generated change volume

AI-generated volume strains the practice in one place. If a team produces more changes, the people who run them must understand more changes, some written by a tool and accepted by someone who read them once. The Understand test asks that the owner can explain what a change does and why, and reconstruct it without the tool. An on-call developer who meets a failing change that nobody can explain has not failed the practice; the organisation has lost the connection between building and running that the practice assumed.

Three design responses follow, and none depends on a particular tool.

  1. Change volume per owner is a budget. The number and size of changes a team can understand and run is finite. A team that doubles its output without adding review and on-call capacity has spent a budget it does not have; the review queue and the rework rate show it. This is the development counterpart of the autonomy budget of AI Operations, Chapter 4.
  2. The owner is in the record before the change is. The code-ownership record OWN-* (Chapter 12) names who passes the Name test, and a change to a repository without an active owner does not pass the gate until one is named. Nordvik Region found in July 2030 that 31 per cent of its 96 repositories had an owner who had left or changed team (OWN-NR-2030-00); Hansa Mutual's audit of August 2030 found 14 of 410 services without an active owner and a COBOL estate owned by a department (OWN-HM-2030-00). On those there is nobody to run what is built.
  3. Operation is not delegated to the generator. A coding agent may draft a runbook, summarise a failing change or propose a fix at the levels the profile allows. It may not be the only responder to the failure of a change it produced, because the observer would then be the thing observed (AI Operations, Chapter 17).

The model is the stream-aligned team that owns a service, supported by a platform that carries the pipeline and the guardrails (41, Skelton & Pais, 2025). Chapter 16 treats the platform team; the point here is that the pipeline and gate are a platform product with their own owners, which is what puts them beyond the reach of product teams' changes.

The Revert test in practice

The Revert test asks that the owner has the authority, the access and the time to stop, roll back or fix the change, outside the pipeline that shipped it. Each part can fail separately.

Authority. The owner or an on-call deputy may use the stop without asking for approval, and the delegation profile and change record say so. A stop that needs a ticket is not a stop.

Access. The stop works when the pipeline does not. A kill switch in the failing system, or a rollback that needs a credential an agent holds, is not outside. The mechanism is a break-glass role or operations console held by named people and reachable out of hours.

Time. The rehearsed time to restore is shorter than the time in which harm accrues. For Nordvik Region's portal the target below is 15 minutes; for Hansa Mutual's quarter-end settlement run the peak sets it, and a revert that cannot finish before the batch window closes is not a revert.

Rehearsal is the evidence. A revert not exercised in the last 90 days, a period the book recommends the organisations choose, is marked "not tested", a legitimate entry that is not the same as passed. This follows the form of a resilience claim in AI Operations, Chapter 19: scope, objective, measurement, date and result, with evidence that expires (170, Nordqvist, 2026). Atlassian's up to 14 days shows the cost of a revert never rehearsed at scale.

A change record

A change record CHG-* ties these elements to one change. AI Operations introduced CHG-NR-* and CHG-HM-*, Nordvik Region numbering from CHG-NR-2028-0001; this book numbers Hansa Mutual's changes of 2030 as CHG-HM-2030-NNNN. This chapter adds the fields a change in which AI took part needs: origin, gate and owners, oracle, revert and rehearsal, and the check against the Level 4 prohibitions. The identifiers, dates and figures in the two examples are fictional and illustrative.

The first change is a timeout and circuit breaker in the client through which the citizen portal SVC-NR-002 reaches the national registers. A developer in the integration and data team drafted most of it with the pilot assistant NR-DEV-001 and accepted it line by line, as DLG-NR-DEV-01 requires; 38 of 61 changed lines came from the assistant.

id: CHG-NR-2030-0212
title: Timeout and circuit breaker in the register gateway client used by the citizen portal
service: SVC-NR-002              # affected service; component register-gateway-client
class: normal                    # normal | standard | emergency
window: 2030-11-07T10:00+01:00   # weekly portal release
owner:
  team: integration and data team
  named: Anders Falk             # ROLE-NR-TCL-01; passes Name, Understand, Revert
  ownership_record: OWN-NR-2030-04   # repository entry, active owner
origin:
  submitter_role: developer, integration and data team
  assistant: NR-DEV-001          # Mode 2 pilot, completion and chat only
  delegation: DLG-NR-DEV-01      # generate Level 1 Assisted, deploy Level 0
  lines_from_assistant: 38       # of 61 changed, accepted line by line
gate:
  definition: region-policy      # separate repository
  owners: [platform lead, CISO office]
  editable_by_change: false
  paths_routed_to_platform_review: [pipeline/, policy/]
  required_checks:
    - policy-evaluation
    - diff-within-declared-scope
    - benefits-workflow-regression
    - portal-journey-synthetic
  oracle:
    plan: VER-NR-2030-0011
    owner: quality function (Saga Edvardsson)
    written_by_assistant: false
    seeded_fault: {date: 2030-11-04, caught: true}
approvals:
  human_review: [integration and data team colleague, not the submitter]
  ai_review_counts_as_review: false
rollout:
  rings: [{name: canary, share: 0.05, bake_minutes: 30}, {name: half, share: 0.5, bake_minutes: 30}, {name: all, share: 1.0}]
  promote_if: {error_rate_max: 0.01, p95_latency_ms_max: 800, synthetic_journeys: pass}
revert:
  method: re-pin previous release through the pipeline
  stop_path: duty engineer re-pins through the break-glass role, outside the pipeline
  data_change: none
  rehearsal: {date: 2030-11-04, environment: staging, minutes_to_restore: 9, target_minutes: 15}
  evidence_age_days: 3
level_4_check:
  security_critical_path: false
  changes_gate_mandate_or_oracle: false
  irreversible_production_data_action: false
records: {aidr: AIDR-1111, run_record: RUN-NR-2030-0031}

The approver of the window reads the record as a checklist. The gate sits in a repository the integration team cannot write to; the oracle belongs to the quality function and a seeded fault was caught three days before; the rings and promotion conditions come from the service objectives; the revert has a form that does not use the pipeline; and the three answers of the Level 4 check must all be no. A change in which any is yes goes to a named developer at a lower level. The record claims no correctness. It records what was done to find out, when and with what result.

The second example is Hansa Mutual's class-approved case: a patch-level update of a logging library in SVC-HM-005, the customer portal and broker interface, merged by the pipeline under the group's one Level 3 Bounded class. It is shorter because the class approval carries the decision and the pipeline's checks are the gate.

id: CHG-HM-2030-0415
title: Patch-level update of a logging library in the customer portal and broker interface
service: SVC-HM-005
class: standard                  # class approval, not per-update approval
mandate: MND-HM-DEV-01           # Level 3 Bounded, patch-level dependency updates
class_approval: {approved_by: Rainer Lehmann, record: AIDR-1153, valid_until: 2031-03-30}
security_critical_path: false
update:
  package: logging-core          # illustrative name, on the approved list
  from: 4.12.3
  to: 4.12.4
  semver_level: patch
gate:
  definition: hansa-forge-policy # owned by Hansa Forge, not by the repository
  editable_by_agent: false
  checks: [approved-list, provenance-and-signature, unit-and-integration, consumer-contract-tests, canary-slo]
  oracle_independent_of_agent: true
  package_proxy_refusals: 0
revert:
  automatic_on: canary SLO breach in ring 1
  stop_path: platform engineer on call, outside the pipeline
  rehearsal_age_days: 41
records: {aidr: AIDR-1161, owner_of_record: claims portal team, ownership_record: OWN-HM-2030-0031}

The class approval expires with the delegation profile's review date, 2031-03-30, so that the class does not outlive its evidence. If the revert rehearsal is older than 90 days, the class drops from Level 3 Bounded to Level 2 Supervised and a developer approves each update. This is the book's recommendation and follows the pattern of AI Operations, Chapter 26, where lapsed evidence lowers a delegation (170, Nordqvist, 2026).

Outlook

Every statement about the future carries one of the three labels of AI Governance, Chapter 22 (162, Nordqvist, 2026); the author's own projections are kept to Chapters 29 and 33.

  • Observable. More and larger changes reach review and the pipeline in teams that adopt AI coding tools, as vendor telemetry reports, and survey respondents in the DORA programme's 2025 report still associate AI adoption with lower delivery stability. Controls outside the reach of a change exist in current platforms.
  • Expected. Progressive delivery with automated promotion and revert on service objectives becomes the default release method for services of consequence, because DORA Article 9(4)(e) and Delegated Regulation (EU) 2024/1774 Article 17 already ask for recorded, tested, independently approved and reversible change, and supervisors and auditors can be expected to ask for the change record.
  • Speculation. Fully autonomous deployment, in which an agent writes, approves, releases and reverts its own change without a human-held gate, is plausible but unevidenced as safe. This book prohibits it at Level 4; independent multi-year evidence that such organisations do better would show the prohibition wrong, and Chapter 33 returns to what would show the thesis wrong.

Delegation and the two organisations

Across the degrees of delegation

Table 11.3 gives the ceilings of DLG-NR-DEV-01 (AIDR-1101) and DLG-HM-DEV-01 (AIDR-1153) for the classes of development work that touch the release path, with the condition each needs. A ceiling is not a licence: practice before the profiles was at or below Level 0 except for ambient completion at Nordvik Region.

Class Nordvik Region Hansa Mutual What the release path requires
Generate Level 1 Assisted Level 2 Supervised outside security-critical and payment paths; Level 1 inside Change record with origin; gate the change cannot alter
Refactor Level 1 Assisted Level 2 Supervised Independent oracle covering the refactored behaviour
Test Level 1 Assisted for drafts, never the oracle for the same change Level 1 Assisted; oracle by someone other than the author Oracle owned outside the change
Review Level 0 Advisory Level 1 Assisted; an AI comment is never one of the two human approvals Human approver who is not the submitter
Deploy Level 0 Level 0 (the pipeline and the change process act) No tool acts on production outside the pipeline
Operate Level 0 Advisory Level 0 Advisory Stop path held by people, outside the pipeline
Migrate Level 0 Advisory Level 0 Advisory Expand, migrate and contract; no irreversible data step
Patch-level dependency updates Not listed, so undelegated Level 3 Bounded (MND-HM-DEV-01), outside security-critical and payment paths Class approval with expiry; gate; rehearsed revert under 90 days old
Change to the gate, mandate, credentials or oracle Not listed, so undelegated Not listed, so undelegated Named developer, never Level 4

Table 11.3: Ceilings of the two delegation profiles for the classes that touch the release path, with the condition each needs.

The usage modes differ in what reaches the path and who is accountable for it.

Mode What reaches the release path What the steward needs
Mode 0 Ambient AI Completion in the editor, with no record that it took part; at Nordvik Region since March 2030 Policy that the author accepts line by line; change records that state origin where known
Mode 1 Snippets from a chat assistant pasted by a person The author is the owner; no data or credentials in prompts (Chapter 10)
Mode 2 An IDE assistant: completion and chat, edits within a file The same as Mode 1, plus telemetry by team only
Mode 3 An agentic tool that plans, edits many files and opens pull requests in a sandbox A mandate, a run record, a gate it cannot alter and no merge or deploy rights (Chapter 8)
Mode 4 An application built for developers, such as a test-drafting assistant or a change-risk scorer An evaluation of the application, an oracle independent of it and a ceiling in the profile
Mode 5 Autonomous production agents In the profiles of this book, no coding agent merges or deploys alone; the operations agent of Hansa Mutual acts under AI Operations Observer independent of the agent, a stop path outside its platform

Table 11.4: The usage modes and what each asks of the release path.

Nordvik Region and Hansa Mutual

Nordvik Region releases the citizen portal weekly, the case platform monthly and the inherited systems quarterly. The platform team of seven, led by Maja Lindqvist, runs the GitOps pipeline, golden paths and approved-registry package proxy; the Region has no site reliability function, so the application teams carry the pager for what they build. About 22 consultant developers work in the Region's repositories under framework agreement NR-2025-102, which has no clause on AI tools, and the supplier teams of TriageSoft and SamDrift release code the Region does not review. A TriageSoft release that changed a queue setting stalled claim ranking for five hours and ten minutes in September 2026 (INC-NR-2026-0214), and the contract had no release notice period: for vendor-built change the Revert test is contractual, with notice, a test window and the right to stop.

The Region's weaknesses are the unowned repositories (31 per cent of 96), a regression pack for the portal and the benefits workflow only, and low test coverage in the inherited systems. Where no oracle exists a gate cannot be independent of the generator, so the first step there is a regression pack, not an agent, consistent with Level 0 Advisory for migrate. AIDR-1111 (adopted 2030-10-28, effective 2030-11-01, decided by Henrik Dahl, review due 2031-05-01) records the rule: no change to the portal, the case platform or the Region Cloud reaches production through a gate that the change or its author can edit, and every production change names an owner and a revert path rehearsed within 90 days. Joakim Wester, who reviews most agent-drafted infrastructure code, receives any change touching the pipeline or policy repository. Nordvik is not subject to DORA, but Article 9(4)(e) and Delegated Regulation (EU) 2024/1774 Article 17 describe a defensible standard for a public authority. Whether prompts to coding tools are records under public-access and archives rules is an open question for the Region's archivist and legal counsel.

Hansa Mutual releases continuously through a GitOps pipeline under Hansa Forge, the internal developer platform of 24 people led by Lukas Frey, with a rollout policy ROL-HM-001 and a freeze calendar FRZ-HM-2028 from AI Operations. Production changes in critical or important functions need two human approvals; no coding agent merges to the protected branch alone; the package proxy refused a non-existent dependency that a coding agent proposed in March 2030 (FND-HM-2030-0012). The Level 3 Bounded class for patch-level dependency updates is the only delegation above Level 2 in either organisation. The settlement module of SVC-HM-003, where the double payment of June 2029 occurred, remains the hardest case: 6.5 million lines of COBOL and PL/I, twelve developers, night operation by Alster Managed Services. Its gate is a reconciliation oracle independent of the author, and its revert is a restore rehearsed before the quarter-end peak, not a redeploy. AIDR-1161 (adopted 2030-11-04, effective 2030-11-11, decided by Rainer Lehmann, review due 2031-05-01) checks the independence of the second approver, lets the class approval lapse with the profile or a stale rehearsal, and reports release-path measures by team in the form of the draft annex KBV-IT-2024-DEV-01. Whether the Cyber Resilience Act reaches the published mobile claims app and broker plug-in, and so how updates and reverts reach customers, is a question for Chapter 24.

Hansa has a platform, a policy repository and an agent mandate to put the gate in; Nordvik has a contract and a small platform team. The control is the same in both: a gate the change cannot alter, and a person who can revert from outside.

Summary

This chapter treated D5 Steward where a change becomes a release, with D4 Prove supplying the gate and D3 Build the volume. Its conclusion is that the release path is where the stewardship principle holds or does not. The evidence on AI and delivery is mixed and recent: survey and telemetry studies associate AI adoption with more and larger changes and persistent instability, and effects on throughput differ between years and studies. The response need not wait for it to settle: a gate beyond the reach of the change, with an independent oracle shown to work by seeded faults, and a named owner who passes the Revert test with a rehearsed stop path outside the pipeline.

The key metrics describe delivery at service level and are open to AI's pressures: deployment frequency inflates with small generated changes, lead time falls when review is skipped, change fail rate can be hidden by silent repair, and recovery time rises when nobody can explain the change. They are reported by team, with a date and a baseline, beside measures of the gate and the revert. "You build it, you run it" survives rising volume only if volume per owner is a budget, the owner is in the ownership record before the change is, and the generator is never the sole responder to its own failure. For the financial sector, DORA Article 9(4)(e) and Delegated Regulation (EU) 2024/1774 Article 17 ask for the same: recorded, tested, independently approved, reversible change.

The worked examples showed change records for Nordvik Region (CHG-NR-2030-0212, AIDR-1111) and Hansa Mutual (CHG-HM-2030-0415, AIDR-1161). The reader's first step is small: mark each control on the release path of one service as inside or outside the reach of a change, seed one fault that the gate must catch, and rehearse the revert once with the date written down. Chapter 12 turns from the release to the code that remains afterwards, where ownership, legacy and deletion decide whether the Name test can still be passed years later.

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. CrowdStrike (2024). External Technical Root Cause Analysis: Channel File 291, 6 August 2024; and Falcon Content Update Preliminary Post Incident Review, 24 July 2024. (28, CrowdStrike, 2024)
  3. U.S. Securities and Exchange Commission (2013). In the Matter of Knight Capital Americas LLC. Release No. 34-70694, 16 October 2013. (29, U.S. Securities and Exchange Commission, 2013)
  4. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (33, AI Incident Database, 2025)
  5. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (35, Kim et al., 2025)
  6. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076. (36, Panickssery et al., 2024)
  7. Skelton, M. & Pais, M. (2025). Team Topologies, 2nd edition. IT Revolution Press. (41, Skelton & Pais, 2025)
  8. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
  9. Manheim, D. & Garrabrant, S. (2019). Categorizing Variants of Goodhart's Law. arXiv:1803.04585. (61, Manheim & Garrabrant, 2019)
  10. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (63, Becker et al., 2025)
  11. Atlassian (2022). Post-Incident Review on the Atlassian April 2022 outage. 29 April 2022. (76, Atlassian, 2022)
  12. Muller, J. Z. (2018). The Tyranny of Metrics. Princeton University Press. (100, Muller, 2018)
  13. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
  14. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  15. Nordqvist, G. (2026). AI Platform and Security. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
  16. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  17. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  18. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. & Salz, T. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566. (176, Cui et al., 2024)
  19. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. (216, Google Cloud, 2024)
  20. Open Source Security Foundation and Linux Foundation. SLSA specification (Supply-chain Levels for Software Artifacts). (231, OpenSSF, n.d.)
  21. Harvey, N. (2026). DORA's software delivery performance metrics. DevOps Research and Assessment (DORA) programme. (222, Harvey, 2026)
  22. Google Cloud, DORA (2025). Streamlining change approval. (223, Google Cloud, 2025)
  23. Google Cloud, DORA. Trunk-based development. (224, Google Cloud, n.d.)
  24. European Commission. Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 (RTS on ICT risk management tools, methods, processes and policies). OJ L, 2024/1774, 25 June 2024. (15, European Commission, 2024)
  25. Faros Research (2025). The AI Productivity Paradox Report 2025. Faros AI, 23 July 2025. (225, Faros Research, 2025)
  26. Hodgson, P. (2017). Feature Toggles (aka Feature Flags). martinfowler.com. (128, Hodgson, 2017)
  27. Warner, A., Davidovič, Š., Hidalgo, A., Beyer, B., Smith, K. & Duftler, M. (2018). Canarying Releases. In The Site Reliability Workbook. (129, Warner et al., 2018)
  28. Sato, D. (2014). Parallel Change. martinfowler.com. (130, Sato, 2014)
  29. Gray, J. (2006). A Conversation with Werner Vogels. ACM Queue 4(4), 14-22. (120, Gray, 2006)