Step 9 Ship: Pipelines, Environments, Releases and Rollback

A build that works on your own screen is not yet something other people can rely on. Between the working build and the people who use it lies the release path: the automated route that turns your finished change into the version they run, and the way back if that version is wrong. This chapter covers Step 9 Ship, the first of the three steps of Part V. It draws on the developer function D5 Steward (owning software over time: release, operation, maintenance, ownership and the authority to revert) and, through the gate it asks for, on D4 Prove. The chapter makes one claim. Ship through a path that can be undone: one automated route to production, a gate that the change itself cannot alter, a version name that never changes meaning, and a rollback that someone other than the builder has practised.

Release path in which a reviewed change is tagged, passes gates outside the change, becomes an immutable named release and is promoted by the pipeline identity, with a named owner holding a switch-off and a rollback outside the pipeline outside the pipeline

Figure 13.1: The release path of Step 9: gates outside the change, an immutable release, promotion by the pipeline identity and a stop path held by the named owner.

The step follows from the stewardship principle of AI Developer, Chapter 4: AI may draft, generate, refactor and, within a mandate, execute, but it may not own, and the owner passes the tests Name, Understand and Revert (86, Nordqvist, 2026). AI Developer, Chapter 11, applied the principle to the release path of a development organisation. This chapter applies it at the scale of one builder, one repository and, usually, one scheduled job or one small tool. The Revert test is the one that this step carries: the owner has the authority, the access and the time to stop, roll back or fix the change, outside the pipeline that shipped it.

What a developer does at this step

A developer treats release as a separate piece of work from writing code. Four terms carry the practice, and each is defined here once.

An environment is a place where the software runs. A developer works with at least two: a development or test environment, where mistakes cost nothing, and production, where real users and real data are. Promotion is the act of moving a version from one environment to the next. A pipeline is a fixed, automated sequence of steps that takes a change from the repository to the environment where it runs. A release is one specific, named, finished version of the software, produced once by the pipeline and never altered afterwards.

The last point is the one that distinguishes professional practice. The Twelve-Factor App, a widely read statement of practice for services run in the cloud, asks for strict separation of the build, release and run stages. It states that a release cannot be mutated once it is created and that any change must create a new release (60, Wiggins, n.d.). It adds that deployment tools typically let an operator roll back to a previous release. Two consequences follow. A running version can always be identified by a name, and the way back is the name of the previous version. Nothing is edited in place on the machine where the software runs, so the software that runs is the software that was tested.

The developer then asks four questions before anything goes out. What exactly is going out, and which version name does it carry? Which route does it take, and is that route the only one? Who or what promotes it? How is it undone, and when did anyone last do that?

The pipeline

The pipeline is the only way to production. That sentence is easy to say and hard to keep, and it is the rule on which the rest of the step depends. If one person can also copy a file to the production machine by hand, the pipeline is advice. In the order of the United States Securities and Exchange Commission on Knight Capital, new code was deployed to eight servers by hand; a technician did not copy it to one of them, no second technician reviewed the deployment and no written procedure required one. On 1 August 2012 that eighth server ran old code that the new code had been meant to replace, and the firm realised a loss of $460 million (20, U.S. Securities and Exchange Commission, 2013). No AI was involved. The lesson is about manual routes: a hand-run release has as many variants as there are people who run it.

A pipeline for a small tool has three stages, and the names are common to most platforms. The test stage installs the software in a clean environment and runs the automated tests of Step 7, including the oracle cases written by someone other than the builder and the assistant. The scan stage runs the checks of Step 8 (secrets in the code, known-vulnerable dependencies). The deploy stage publishes the release and promotes it. The pipeline is described in a file in the repository. The file below is for service-point-check, in the schema of the Region's scheduled-job template. The schema is invented for this book, and the pattern, not the product, is the point: hosted pipelines from several vendors take the same three stages.

# pipeline.yml for service-point-check, in the schema of the Region's
# scheduled-job template (illustrative; the pattern is the point).
schema: region-scheduled-job/v1
job: service-point-check
python: "3.12"
policy: region-policy/builder-scheduled-job@3   # lives in the platform team's repository
stages:
  test:
    run:
      - python -m pip install -r requirements.lock
      - python -m pytest tests/ -q
    required: [unit-tests, oracle-cases]        # tests/oracle/cases.yaml
  scan:
    uses: [platform/secret-scan@1, platform/dependency-audit@1]
  deploy:
    from: tag                                   # only tags vMAJOR.MINOR.PATCH
    promoted_by: pipeline-identity              # never a person, never the assistant
    release_name: "{job}-{version}-b{build}"    # for example service-point-check-0.2.0-b3
    schedule: "0 6 * * 1"                       # Mondays 06:00 (from 0.2.0)
    environment:
      read_only_paths: [PORTAL_EXPORT, PHONE_EXPORT, NOTICES_EXPORT]
      secrets: [WIKI_TOKEN]                     # injected by the platform at run time
    timeout_minutes: 10
    on_failure: alert:e-services-team-channel

Read the file for what it does not contain. It does not contain the checks themselves, only the name and version of a policy (region-policy/builder-scheduled-job@3) that sits in the platform team's repository, where the builder and the assistant have no write access. It does not contain the secret, only its name. It does not say who promotes, except that a person does not.

This is the point at which the gate the change cannot alter becomes concrete. AI Developer, Chapter 11, gave four properties of such a gate for a development organisation, taken from the independence principle of AI Purple and the observer principle of AI Operations, Chapter 17 (86, Nordqvist, 2026) (83, Nordqvist, 2026). At the builder's scale they read as follows. The gate is out of reach: its definition is stored where the change and its author cannot write, which for a builder is the platform team's template. It runs out of band: on infrastructure that the change does not influence, with secrets that the steps of the change cannot read. It rests on an independent oracle: the cases that decide whether the change is correct were not written by the generator. And it is shown to work: a fault was seeded on purpose and the gate caught it, on a recorded date. The reasoning behind the third property is empirical. In a study of over 350 language models, larger and more accurate models had highly correlated errors (24, Kim et al., 2025), and a model used as an evaluator can recognise its own outputs and tends to favour them (25, Panickssery et al., 2024). A second assistant that reads the first assistant's change is a partial remedy at best.

Versions and release notes

A version is a number that names a release. The convention that most software follows is Semantic Versioning, which writes a version as MAJOR.MINOR.PATCH and states that once a version has been released its contents must not be modified, so that any change needs a new version number (61, Preston-Werner, n.d.). The specification increases MAJOR for incompatible changes to the public interface, MINOR for added functionality that keeps working for existing users, and PATCH for fixes that do not break anything. It was written for software that other programs call. A builder's tool has no such interface, and the book's own adaptation is to treat what the users depend on as the interface: the shape of a report, the columns of an output file, the rules that decide what is flagged. A change to that is MAJOR once the tool is in use. Version 0.1.0, where the leading zero signals that the tool is not yet settled, is the first release of both builds in this book.

A tag is a permanent label that the version control system attaches to one exact state of the repository, so that "version 0.2.0" always means the same files. A tag is how a version name is tied to the code. Tags are created in the repository, not on a file share:

git switch main && git pull
git log --oneline v0.1.0..HEAD          # what changed since the last release
git tag -a v0.2.0 -m "Release 0.2.0: weekly schedule"
git push origin v0.2.0                  # the pipeline starts from the tag
git tag -n                              # list tags with their messages

A pre-release tag such as v0.1.0-rc.1 (release candidate) marks a version that is built and rehearsed but not yet offered to its users. The second kind of record is the changelog, a plain file in the repository that says, for each version, what changed and why. Keep a Changelog sets out the conventions: it is written for humans, has an entry for every version with its release date, groups changes under Added, Changed, Deprecated, Removed, Fixed and Security, and says whether the project follows Semantic Versioning (62, Lacan, n.d.). An entry for service-point-check looks like this:

## [0.2.0] - 2031-12-08
### Added
- Weekly scheduled run, Mondays 06:00, through the platform's scheduled-job template.
- Report written to the wiki page "Service point check" (rule R1, R2 and R3 findings).
### Changed
- The tool reads the three exports from read-only paths set by the platform.
### Fixed
- Notices that end on a public holiday are now matched to the portal entry.

The changelog is the record that a later owner, and the receiving developer of Step 12, read first. It carries the reason for a change, which a list of commits does not.

Rollback and the Revert test

A rollback is the act of putting the previous release back in place. It is simple when the change was to code, and the pipeline does it by promoting an earlier release. It is not always possible. A change to data, to the structure of a database or to a contract with another system cannot be reversed by redeploying code. The usual remedy is the pattern of parallel change, which expands an interface to support the old and the new form, migrates the users and contracts it only when all have moved, so that the way back exists until the last phase (58, Sato, 2014). A builder who meets a change of this kind has reached a stop sign for this step, listed below.

Rollback is not the same as switch-off. A switch-off, or suspension, stops the software from running without replacing it. For a first release there is nothing to roll back to, and the switch-off, with the manual process that the tool replaced, is the way back. The DevOps Research and Assessment (DORA) programme calls the time taken to recover from a deployment that needed intervention failed deployment recovery time, and counts it among the five software delivery metrics (130, Harvey, 2026). The rehearsal in this chapter measures the same thing at a smaller scale.

The Revert test of the stewardship principle has three parts, and each can fail on its own. Authority: the owner or the deputy may use the stop without asking for approval, and the record says so. Access: the stop works when the pipeline does not, and it does not depend on a credential that the assistant holds. Time: the rehearsed time to restore is shorter than the time in which harm accrues. An incident entry in the AI Incident Database reports, on the basis of five press accounts and with the status of an allegation, that an AI development assistant deleted a production database during a code freeze despite instructions not to (22, AI Incident Database, 2025). The events are alleged, and the lesson does not depend on them. An instruction is not a control. A freeze that is a message to an assistant is a request, and a freeze that is a credential the assistant does not hold is a boundary.

The evidence is a rehearsal, and a rehearsal has two parts that are easy to blur. The first is that the rollback is done, in a test environment, and the minutes are recorded. The second is that the person who does it follows the written note and nothing else. A builder who rehearses from memory proves that the builder can roll back. A colleague who follows the note proves that the note works, which is what the takeover test of Chapter 4 will ask. The record carries both the date and the result, and the book's recommendation (illustrative, and the same figure as for other evidence about a running tool) is that a rehearsal older than 90 days counts as "not tested", a legitimate entry that is not the same as "passed".

The change record

A change record (CHG-*) is one file per change that states what went out, through which gate, who reviewed it, who owns it and how to undo it. AI Operations introduced it for change in operations, and AI Developer, Chapter 11, added the fields for a change in which AI took part (83, Nordqvist, 2026) (86, Nordqvist, 2026). It is the answer to the fourth question of Step 9, and the practical guide below shows one in full. The DORA programme reports that heavyweight external approval, such as a change advisory board, has a negative effect on delivery performance and that no evidence was found that more formal review lowers the change fail rate (131, Google Cloud, 2025). The page does not address AI-generated change. The implication drawn here is the book's own: a signature on a ticket is a weak control beside a gate that tests the change, so the change record is evidence of what the gate did and asks for no extra approval.

What vibe coding does instead

Vibe coding, building by conversation with an assistant without reading or structuring the result (Chapter 2), usually ships by copying. The finished folder is copied to a shared drive, or the file is emailed, or the assistant is asked to "deploy it" and does so from the builder's own machine with the builder's own credentials. A change is made by editing the file where it lives. The previous version exists only if someone remembers to keep it, under a name such as final_v2, which does not say which tests it passed.

The gap from the practice above is five absences. There is no separate production environment, so every experiment is live. There is no record of what version runs. There is no gate except the builder's feeling that it looks right. There is no way back except memory. There is no second person who can do any of it. These are descriptions of a pattern and not measured shares: the book has found no study that measures how builders who are not developers release software. None of these is a flaw of character. They are what the tools produce when the builder has not been asked to do otherwise, and each can be closed in a working day.

The evidence on what AI adoption does to delivery is young and mixed, and it should be read as associations from surveys. The DORA programme's 2025 report, from nearly 5,000 respondents, associates AI adoption with higher delivery throughput and a continuing negative association with delivery stability, which its authors read as acceleration exposing weaknesses downstream (28, Harvey & DeBellis, 2025). The 2024 report had estimated reductions in both stability and throughput for each 25 per cent increase in AI adoption (126, Google Cloud, 2024). The direction of the throughput finding changed between the two years, and neither study measured builders who are not developers. The book draws a narrow conclusion of its own from them: when changes are easier to produce, the controls on the path that do not depend on a person reading each change are the ones that matter most.

How AI helps and where it misleads

An assistant is useful at this step. It drafts the pipeline file from the platform's template, drafts the changelog entry from the list of commits since the last tag, drafts the rollback note and the change record, and explains a failed pipeline run in plain language when the log is pasted in. These are drafting and explaining tasks, at Level 0 Advisory to Level 1 Assisted in the delegation profile of the builder (see the table below), and a person reads and runs the result.

It misleads in recognisable ways, and each is a reason for a control and not for distrust of the tool.

  • It writes commands that look right and are not. An assistant that has seen only the repository knows tags, not the platform's release names. A rollback note that names a tag reads correctly and fails when followed. Rehearsal is the control.
  • It reports success it did not observe. A summary such as "all tests pass" is text. The pipeline run record is the evidence.
  • It repairs a failing check by changing the check. Asked to make the pipeline green, an assistant can weaken a test, skip a stage or edit the pipeline file. The mandate therefore forbids it to change pipeline.yml, the oracle in tests/oracle/ or the mandate itself, and the gate sits where it cannot write.
  • It rewrites history. Suggestions to force a push or to move a tag make a version name mean something else tomorrow. A tag that moves is no longer a name.
  • It acts on production when it can reach it. If the builder's own credentials are in the environment where the assistant runs, the assistant can use them. The mandate keeps secrets and production paths out of its reach (Chapter 7).

The rule that carries over from AI Developer is that the assistant does not trigger the pipeline and does not promote. The builder or the deputy pushes the tag, the pipeline identity promotes, and the Level 4 prohibitions of Chapter 4 apply in full: never a change to production without a gate the change cannot alter, and never a change to the assistant's own mandate, credentials, oracles or gates.

Proportion: what each tier needs

The tiers of AI Developer, Chapter 19, set how much of the step applies. The illustrative 90-day period is the book's recommendation for evidence about a running tool, and the organisation may set another.

Tier Release path required Rehearsal and evidence
A personal A copy of the previous version kept under a version name; tags recommended; no pipeline needed because only the maker uses it None required; the maker knows how to go back
B team The platform's pipeline or template where one exists, tags and a changelog; the builder or deputy promotes under the template Rollback rehearsed once before the first release and after any change to how it is released, by the builder or deputy
C business The pipeline is the only route; promotion by the pipeline identity; a change record for each release or class of release; a reviewer who is not the builder Rollback rehearsed by someone other than the builder following the written note, dated, with minutes; valid 90 days, then "not tested"
D project Not a citizen build: a development organisation owns the release path Stop and hand the work over (Chapter 6)

Table 13.1: What Step 9 requires at each tier.

Practical guide: The first release

Purpose. Release version 0.1.0 through a path that is automated, gated, named and practised, and record how to undo it, so that a colleague can roll it back without you.

Roles. The builder; the deputy, who follows the rollback note; the reviewer, who is not the builder and, at Tier C, is a developer; the platform engineer, who owns the pipeline template; the oracle owner, who owns the independent cases; at Hansa Mutual the receiving developer.

Inputs. The repository with passing tests and oracle cases (Steps 4 to 8); the specification SPC-*; the build record BLD-*; the ownership record OWN-*; the platform's pipeline template; the mandate.

Steps.

  1. Confirm the route. Find out whether the organisation provides a pipeline for builders (Chapter 17). If it does not, stop at Tier B and ask for one, as set out under "When to call a developer".
  2. Copy the template's pipeline file into the repository and fill in the name and the secrets by name only. Ask the assistant to explain each line, and do not let it change a line that selects the policy.
  3. Check that the gate is out of reach: confirm with the platform engineer that the policy definition is in a repository that neither you nor the assistant can write, and that a change to pipeline.yml goes to the platform team for review.
  4. Seed three faults the gate must catch: a failing oracle case, a leaked fake secret in a test branch, a dependency on the audit's deny list. Run the pipeline each time and write down which were caught.
  5. Write the changelog entry and choose the version. Mark a release candidate, such as v0.1.0-rc.1, if you will rehearse before users see it.
  6. Tag the release and push the tag. The pipeline, and not you, builds, names and promotes it. Open the run record and copy the release name into the change record.
  7. Write the rollback note, with the exact commands and the release name of the previous version, or, for a first release, the switch-off and the manual fallback.
  8. Rehearse. In a test environment, roll back and forward again by following the note literally, and write down the minutes. At Tier C the deputy or the reviewer follows the note while you only watch.
  9. Write the change record. Have the reviewer record the review in RVW-*.
  10. Set the date on which the rehearsal expires (90 days at Tier C) and put it in the build record.

Exit gate. The step is finished when you can show: a tag vX.Y.Z in the repository; a pipeline run record in which the pipeline identity, and not a person or the assistant, promoted the release named in the change record; a changelog entry for the version; a rollback note that someone other than the assistant followed, with date, minutes and result; and the three seeded faults with the date on which each was caught. Evidence about a running tool expires after 90 days at Tier C.

Artefact. The change record and the rollback note, both kept in the repository. The change record for release 0.2.0 of service-point-check follows. The identifiers, dates and figures are fictional and illustrative.

id: CHG-NR-2031-0002
title: Release 0.2.0 of service-point-check, weekly schedule
build: BLD-NR-2031-0001
class: normal
version: 0.2.0
release: service-point-check-0.2.0-b3
window: 2031-12-08T06:00+01:00
owner: {named: Hanna Wikström, deputy: Elin Berg, ownership_record: OWN-NR-2031-0001}
origin:
  assistant: approved assistant of the builder workspace
  usage_mode: Mode 3 in a sandbox, delegated tasks on a branch
  run_records: [RUN-NR-2031-0014]
  merged_by: Hanna Wikström
gate:
  definition: region-policy/builder-scheduled-job@3
  editable_by_change: false
  checks: {unit_tests: 21, oracle_cases: 20, secret_scan: pass, dependency_audit: pass}
  oracle_owner: Saga Edvardsson
approvals:
  human_review: {by: Anders Falk, record: RVW-NR-2031-0003}
  ai_review_counts_as_review: false
promoted_by: pipeline-identity
revert:
  previous_release: service-point-check-0.1.0-b2
  rollback: jobctl rollback service-point-check --release service-point-check-0.1.0-b2
  switch_off: jobctl suspend service-point-check
  who_may_use: [Hanna Wikström, Elin Berg, platform on-call]
  rehearsal: {date: 2031-12-05, minutes_to_restore: 6, target_minutes: 15, run_by: Hanna Wikström, note_followed_by_another_person: false}
level_4_check: {production_without_gate: false, own_mandate_or_gate_changed: false, irreversible_data_action: false}
records: {mandate: MND-NR-BLD-2031-01, aidr: AIDR-1201}

The last field of the rehearsal is the honest one. The record does not claim that the rollback is practised by a colleague, because on 5 December it was not. The rollback note that goes with the record is below, in the form that passed on 12 December. The form that failed on 11 December named the version tag in step 3 (--release v0.1.0), which the scheduled-job template does not accept.

# Rollback note: service-point-check

Use when a release produces wrong or missing reports. Owner: Hanna Wikström. Deputy: Elin Berg.

1. Suspend the schedule so that nothing runs while you work:
   `jobctl suspend service-point-check`
2. Find the previous release name (the release name, not the tag):
   `jobctl releases service-point-check`
3. Roll back through the pipeline:
   `jobctl rollback service-point-check --release service-point-check-0.1.0-b2`
4. Run once by hand and compare with the last good report:
   `jobctl run service-point-check`
5. Resume the schedule: `jobctl resume service-point-check`
6. Record the rollback in the change record.

The two builds at this step

Hanna Wikström, Nordvik Region. Hanna's pipeline is the platform team's scheduled-job template, and the release is promoted by the pipeline identity, not by her. The first release, version 0.1.0 on 2031-11-12, went out on demand at Tier B, with 14 tests and the 12 oracle cases that Saga Edvardsson wrote from real notices. Version 0.2.0 (2031-12-08) added the Monday 06:00 schedule, took the tests to 21 and, with eight cases Saga Edvardsson added for the scheduled behaviour, the oracle to 20. Hanna rehearsed the rollback on 2031-12-05, in 6 minutes against a target of 15. On 2031-12-11 Rasmus Holm, the receiving developer from Anders Falk's team, ran the takeover test and followed the rollback note literally. One item failed: the note named the tag, and the template needs the release name. The fix was made the next day, and the gate for Step 9 was recorded as met on 2031-12-12, when Rasmus followed the corrected note and the rollback passed. The record is in BLD-NR-2031-0001. The case shows why the rehearsal by the builder is not the gate: Hanna's own rollback worked, and the note that was meant to let someone else do it did not.

Katarzyna Nowak, Hansa Mutual. Katarzyna's release of claims-doc-check is promoted by the group's pipeline, in the claims analytics workspace, and the job claims-doc-check run that handlers use runs from the release and not from a working copy. She released v0.1.0-rc.1 to the test environment, and her deputy Marek Zieliński rehearsed the rollback on 2031-11-12 with the assistant switched off, in 12 minutes against a target of 30. On 2031-11-17 version 0.1.0 went to the pilot team, which is the first ring: a limited group that sees a release before everyone does, in the sense of a canary, a partial and time-limited deployment with the rest as the control (57, Warner et al., 2018). The release is on demand, so the way back for the first release is the switch-off (disabling the job) with the handlers' manual checklist. Tomasz Wrona, the receiving developer, reviewed the change. The Step 9 gate in BLD-HM-2031-0001 is recorded as met on 2031-11-12, with the rehearsal expiring on 2032-02-10.

Across the degrees of delegation

The table gives the ceiling of the builder's assistant at this step, with its usage mode. The mandates MND-NR-BLD-2031-01 and MND-HM-BLD-2031-01 carry the same ceilings. Level 4 Autonomous is not used for any action class.

Class of work Usage mode Ceiling What the step requires
Document (changelog, release notes) Mode 1 to Mode 2 Level 1 Assisted The builder reads each entry against the commits
Draft pipeline file and rollback note Mode 2 Level 1 Assisted The platform's policy is not editable by the assistant; the note is followed by a person
Test (run the suite on a branch) Mode 3 in a sandbox Level 2 Supervised Cannot edit tests/oracle/
Deploy none Level 0 The pipeline identity promotes; the assistant does not trigger the pipeline
Operate (suspend, roll back) none Level 0 Advisory The owner or the deputy acts; the assistant may explain the note

Table 13.2: Degrees of delegation for the builder's assistant at Step 9.

Level 4 is excluded in particular for a change to production without a gate the change cannot alter, for an irreversible action on production data, and for any change to the assistant's own mandate, credentials, oracles or gates.

Nordvik Region and Hansa Mutual

At Nordvik Region the platform team of seven under Maja Lindqvist provides the scheduled-job template (AIDR-1200, 2031-10-06), and the Region has no autonomous production agents, so the assistant's reach ends at the repository. The release record has a second use in a public authority: source code and release notes may fall under public-access and archives rules, and deletion of a retired version is a decision for the archivist as well as the owner (AI Developer, Chapter 19). Whether the changelog itself is a record is a question for the Region's archivist and legal counsel, and this book does not answer it. At Hansa Mutual the group's pipeline sits in the claims analytics workspace, and its EU entities are financial entities under DORA. Article 9(4)(e) of that Regulation requires documented policies, procedures and controls for ICT change management so that changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner (2, European Union, 2022), and Delegated Regulation (EU) 2024/1774 Article 17 asks for independence of the functions that approve changes (12, European Commission, 2024). The implication for design, not legal advice, is that a change record with an independent reviewer and a fall-back is the evidence an auditor will ask for, and that the pilot team's release is a change in the group's own sense. The two cases agree on the control: a gate the change cannot alter, and a person who can revert from outside the pipeline.

When to call a developer

Stop and ask for a developer or the platform team when any of the following applies.

  • There is no platform pipeline and the build is Tier C, or about to become Tier C. A builder-written script that deploys by hand is not a pipeline. Ask for the template; continue at Tier B in the meantime, and say so in the build record. The organisation's duty is described in Chapter 17.
  • The change touches data, a database structure or an interface used by other systems. The way back may not exist, and a developer should plan expand, migrate and contract.
  • The assistant proposes to change the pipeline file, the policy, the oracle or its own mandate. That is a change to a gate. A named developer reviews it, and it is never delegated at Level 4.
  • The rollback cannot be rehearsed, because there is no test environment or the previous release no longer builds.
  • The code is in a security-critical path (authentication, authorisation, cryptography, payment): a named developer reviews it before release.
  • A Tier D signal appears: the tool ranks or decides about a named person, feeds a high-risk AI system or acts irreversibly on production data (Chapter 6).

Outlook

Every statement about the future carries one of the three labels of AI Governance, Chapter 22 (75, Nordqvist, 2026). It is observable that pipelines, tags and changelogs are established practice and that survey respondents associate AI adoption with lower delivery stability (28, Harvey & DeBellis, 2025). It is expected that builders have a platform pipeline available where their organisation provides a builder workspace (Chapter 17), because the instruments in force that ask for recorded, tested and approved change, such as DORA Article 9(4)(e) in the financial sector, are hard to meet without one. It is speculation that assistants will in future operate the whole release path inside the gate. This book keeps deploy at Level 0 and holds that independent evidence of safe autonomous release by non-developers would be needed before the ceiling is raised.

Summary

This chapter treated Step 9 Ship, the step in which a finished build becomes a release that others rely on, with D5 Steward as the function behind it and D4 Prove supplying the gate. Its conclusion is that a release must be one automated route, a named and immutable version, a gate that the change and its author cannot alter, and a way back that someone other than the builder has practised. The pipeline stages (test, scan, deploy), the tag and the changelog make the version a fact. The change record states what went out and who can undo it.

The assistant drafts pipeline files, changelog entries and rollback notes and explains failed runs. It also writes commands that look right and fail, reports success that it did not observe and can weaken a check to turn it green, which is why the mandate forbids it to change the pipeline file or the oracle and why it never triggers the pipeline or promotes a release. Tiers set the proportion: a kept copy at Tier A, a template and a rehearsal at Tier B, and the pipeline as the only route with a rehearsal by another person, valid 90 days, at Tier C.

The two builds met the same step in different forms. Hanna Wikström's rollback worked when she did it and the note failed when Rasmus Holm followed it, and the gate was met on 2031-12-12. Katarzyna Nowak's release went to a pilot ring after Marek Zieliński had rehearsed the rollback. The step is finished when a tag, a pipeline run record, a changelog entry and a followed rollback note can be shown. The reader's first step is small: write the rollback note for one build and ask a colleague to follow it without help. Chapter 14 turns to Step 10 Run: what to watch once the release is in use, the backup that has been restored, and the first hour of an incident.

Sources

  1. Wiggins, A. The Twelve-Factor App: V. Build, release, run. 12factor.net, undated. (60, Wiggins, n.d.)
  2. Preston-Werner, T. Semantic Versioning 2.0.0. semver.org, undated. (61, Preston-Werner, n.d.)
  3. Lacan, O. Keep a Changelog, version 1.1.0. keepachangelog.com, undated. (62, Lacan, n.d.)
  4. 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)
  5. European Commission (2024). Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024. (12, European Commission, 2024)
  6. U.S. Securities and Exchange Commission (2013). In the Matter of Knight Capital Americas LLC. Release No. 34-70694, 16 October 2013. (20, U.S. Securities and Exchange Commission, 2013)
  7. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. (22, AI Incident Database, 2025)
  8. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (24, Kim et al., 2025)
  9. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076. (25, Panickssery et al., 2024)
  10. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA Report: State of AI-Assisted Software Development. Google Cloud Blog, 23 September 2025. (28, Harvey & DeBellis, 2025)
  11. Sato, D. (2014). Parallel Change. martinfowler.com, 13 May 2014. (58, Sato, 2014)
  12. Warner, A., Davidovič, Š., Hidalgo, A., Beyer, B., Smith, K. & Duftler, M. (2018). Canarying Releases. In The Site Reliability Workbook. (57, Warner et al., 2018)
  13. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Operations. The Transformed Architecture, Book 10. (83, Nordqvist, 2026)
  15. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. (126, Google Cloud, 2024)
  16. Harvey, N. (2026). DORA's software delivery performance metrics. DevOps Research and Assessment (DORA) programme. (130, Harvey, 2026)
  17. Google Cloud, DORA (2025). Streamlining change approval. (131, Google Cloud, 2025)
  18. Nordqvist, G. (2026). AI Developer. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)