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

Most outages begin with a change, and most of the changes that operators now review begin as a draft written by a machine. This chapter concerns O3 Change: altering the estate safely, through releases, configuration and infrastructure as code, with provenance, policy checks and a way back. It touches O1 Observe where drift between declared and actual state is detected, and it leaves staged rollout, freezes and blast-radius budgets to Chapter 9, runbook execution to Chapter 10 and change authority to Chapter 22. Its subject is what the pipeline looks like when agents write much of the change, what a reviewer needs to know about a draft that no person wrote, how policy checks are made independent of the author, how review stays real when drafting is cheap, how declared and actual state are kept together by state engines such as GitOps controllers, and what standard, normal and emergency change mean when most change is machine-authored.

Figure 8.1: The change pipeline: policy point and named reviewer outside the author, release in a window, and drift detector, verification probe and stop path outside the pipeline.

The chapter builds on the earlier volumes. Architecture as Code (Chapters 10, 11, 13 and 20) established policy as code, tests in the pipeline and the rule that agents draft and humans approve (F3, F7, F12, F13) (295, Nordqvist, 2025). AI Platform and Security, Chapter 4, gave the control plane in which the declarative model can be checked against the running estate (F37) (297, Nordqvist, 2026), and AI Governance, Chapter 24, concluded that a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities (F29) (296, Nordqvist, 2026). The Transformed Security Architect, Chapter 13, set the mandate manifest and the accountable verifier (F75) (300, Nordqvist, 2026). AI Purple, Chapter 10, concluded that when AI drafts every kind of change the bottleneck is review, so that caps on open drafts, a named reviewer who is not the drafter and seeded errors are design requirements (F126) (304, Nordqvist, 2026).

The change pipeline

A change pipeline carries an intention to production as code. The intention is a request that says what should be different and why. It becomes a diff against declared state held in version control, passes checks that do not depend on its author, is approved by a person whose standing is independent of the requester, is released by a pipeline identity inside a window, is verified by something other than the releaser, and ends in a record. The sequence is old. What changes with AI is who sits at the authoring step and how many changes enter it per day.

Six properties make the pipeline a control and not only a convenience. Every change is a diff in a repository, so that there is one place where the intended state of the estate is written. Every diff carries the identity of its author, whether a person or an agent, and the authority under which the author acted. Every diff meets checks that are computed by a policy decision point which the author cannot edit. Every release is executed by a pipeline credential that no person or agent holds in an interactive session. Every release has a verification step performed by a probe independent of the pipeline, and a rollback plan that was tested before it was needed. And the whole path leaves a change record from which a person who was not there can reconstruct what was intended, who approved it, what the checks said and what happened.

What the instruments ask of the pipeline

European instruments ask for these properties in different words. DORA requires financial entities to implement documented policies, procedures and controls for ICT change management, covering changes to software, hardware, firmware components, systems or security parameters, based on a risk assessment, so that all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner, with the process approved by appropriate lines of management (Article 9(4), point (e), and the paragraph that follows) (2, European Union, 2022). Delegated Regulation (EU) 2024/1774 turns this into elements of the procedure in Article 17: verification that ICT security requirements are met, mechanisms that keep the functions approving changes independent of those requesting and implementing them, defined roles, documentation of purpose, scope, timeline and expected outcome, fall-back procedures including for aborting a change, procedures for emergency changes with adequate safeguards, after-the-fact assessment and approval of emergency changes, and an assessment of the effect of the change on existing security measures (8, European Commission, 2024). The independence element is the one that agents press hardest, and the chapter returns to it under review load.

NIS 2 Article 21(2) lists security in the acquisition, development and maintenance of network and information systems (point (e)) and supply chain security (point (d)) among the measures that essential and important entities must take (3, European Union, 2022). For the provider categories named in Article 21(5), among them cloud computing, data centre, managed service and DNS service providers, Commission Implementing Regulation (EU) 2024/2690 is more specific. Its annex requires change management procedures for releases, modifications and emergency changes of software and hardware in operation and for changes to configuration, with changes documented and, on the basis of a risk assessment, tested and assessed for potential impact before implementation, and a documented explanation where an emergency prevented the regular procedure (points 6.4.1 to 6.4.3) (4, European Commission, 2024). Nordvik Region is not in a listed provider category, so for the Region the regulation is a requirement it can write into its contract with SamDrift. NIST SP 800-53 Rev. 5 supplies the control vocabulary: CM-3 asks the organisation to determine which changes are configuration-controlled, to approve or disapprove them with explicit consideration of security and privacy impact and to document and retain the decisions, and CM-5 asks for documented and enforced access restrictions associated with change (53, NIST, 2020). The statements are architectural implications, not legal advice.

AI-authored change

What agents write is wider than application code. In operations the output of an agent that has been asked for a change is infrastructure code, configuration, pipeline definitions, runbooks, alert and dashboard definitions, policy files and the tests that accompany them. Some of these are low in consequence. Others are the files that decide what every other change may do, and they belong to a separate class discussed below.

What is observable

The evidence that AI authors a large share of change is partial. In October 2024 Google's chief executive reported that more than a quarter of all new code at Google was generated by AI and then reviewed and accepted by engineers (140, Pichai, 2024). The statement concerns application code at one company, not infrastructure change, and it records the pattern the chapter assumes: generation by a system, review and acceptance by a person. The software delivery research programme run by Google Cloud reported in 2024, from its annual survey, that as AI adoption increased it was accompanied by an estimated decrease in delivery throughput of 1.5 per cent and an estimated reduction in delivery stability of 7.2 per cent (251, Harvey & DeBellis, 2024). These are survey-based associations with estimated effects, and they do not show that any one AI-authored change is more likely to fail. In 2025 the programme reported, from nearly 5,000 respondents, that AI adoption among software professionals had reached 90 per cent and was now linked to higher delivery throughput, and described AI as a mirror and a multiplier that exposes weaknesses in fragmented organisations (138, Salva, 2025). The post gives no stability figure, so the two years cannot be compared on that dimension. The book reads the pair as a caution that the effect of AI on change depends on the pipeline around it, which is a reading and not a finding of either report.

Studies of what the drafts contain are narrower and older than the models in use, so they are quoted for what they measured. IaC-Eval, a benchmark for infrastructure as code of 458 human-curated scenarios covering popular AWS services, reported in 2024 that the best model tested, GPT-4, reached a pass@1 accuracy of 19.36 per cent against a specification of the intended infrastructure (100, Kon et al., 2024); the figure describes functional correctness for the models of the time and says nothing about security. Perry, Srivastava, Kumar and Boneh, in a user study at CCS 2023, found that participants with an AI assistant wrote significantly less secure code than those without, and were more likely to believe their code was secure (101, Perry et al., 2023). Spracklen and colleagues analysed 576,000 code samples in two programming languages from 16 models and found that package hallucination, the recommendation of dependencies that do not exist, averaged at least 5.2 per cent for commercial models and 21.7 per cent for open-source models (102, Spracklen et al., 2025). None of these studies measured operations changes in production. The inference to the pipeline is the book's own: a draft can be fluent, plausible and wrong, and its authority must come from the checks and the reviewer, not from its form.

The class that governs the others

Four kinds of file decide what a change may do: the pipeline definitions, the policy files, the lists of who may review what, and the mandate manifests of agents. Together they are the change system's own configuration. An agent may draft a change to any of them, because a draft is a proposal, but the policy decision point cannot be evaluated by rules that the same change edits, and the reviewer must be a person with authority over the control plane. The rule applies the observer principle (Chapter 4): what verifies a change must be independent of what proposed it. These are the protected paths of this chapter, and Level 4 Autonomous is never used for a change to them, because such a change disables the observation or the stop path itself.

Provenance

A reviewer who is asked to approve a diff needs to know where it came from. For a person's change the author's name and the ticket are usually enough. For an agent's change they are not, because the reviewer must judge not only the diff but the process that produced it, and the process differs in ways that bear on trust.

What the provenance record contains

The provenance of a change, in the book's usage, is the record of its origin: the identity of the author and whether it is a person or an agent; for an agent, the identity under which it ran, the mandate and level, the model and version, the versions of the skills and instructions loaded, the inputs it read, the tools it called and the tests it ran; and, for every change, what was not tested. Two properties matter most. The inputs are listed by reference, because an agent that read an alert text, a ticket or a log line has read content that anyone who can write to those systems can influence, and the reviewer must be able to see what was read (Chapter 18 treats the mechanism). And the record states what the author did not test, because an agent that reports only what it checked invites the reviewer to assume the rest was covered.

Provenance of change is a different thing from provenance of build. The Supply-chain Levels for Software Artifacts (SLSA) specification defines provenance as an attestation that a particular build platform produced a set of software artefacts; at Build L1 provenance exists and identifies the output by digest, at Build L2 it carries a signature that consumers can verify, and at Build L3 it is resistant to forgery by the tenants of the build platform, because the signing secrets are held by the build service and not by user-defined build steps (54, SLSA, n.d.). Build provenance answers the question of what produced this artefact. Change provenance answers the question of who or what wrote this diff and under what authority. A mature pipeline holds both, and a reviewer needs the second as much as the verifier of the artefact needs the first.

Provenance and the people who write the changes

A provenance record that captures how an engineer used an agent can also be used to watch the engineer. At Nordvik Region the agreement MBL-NR-IT-2027-01 makes any tool that logs engineers' queries or commands a matter for negotiation before it is switched on and forbids reporting by name. At Hansa Mutual clause KBV-IT-2024-OPS-03 requires that AI operations tools that log engineers' commands are agreed before use, and clause -02 limits metrics to teams and services with a minimum group size of five. The design response is to record what a reviewer needs and to leave out what only a supervisor would want: references to inputs, tool-call summaries, versions and test results, and not the engineer's typed instructions, and nothing aggregated per person. Retaining prompts is a matter for the representatives first, and the personal data that prompts can contain brings the GDPR into the decision.

Policy as code in the path

A check that depends on the author's good faith is a convention. The checks in the path of a change are rules evaluated by a policy decision point that the author does not control, on the diff, on the plan that the diff would produce and on metadata about the change. The pattern is established in the earlier volumes (F3, F7, F37). What AI adds is the volume and the need to assume that a draft may be wrong in ways that look right.

What the checks evaluate

Five groups of checks do most of the work. Schema checks reject changes that do not parse or conform. Policy checks evaluate the plan: how many resources are created, changed and destroyed; whether a resource of a sensitive type is touched, such as role bindings, identity configuration, network policy, keys, backup targets or retention settings; whether data or workloads leave the approved regions; and whether every resource carries an owner and a service identifier. Blast-radius checks compute how many services, cells and users the change can reach, using the service records and the dependency map of Chapter 3, and compare the result with the declared class. Supply chain checks evaluate the components the change introduces. Window and freeze checks compare the release time with the authorised window and any freeze on the services concerned (Chapter 9).

The mechanism is not tied to a product. The Open Policy Agent documentation describes the pattern for infrastructure: produce a plan, convert it to JSON, and evaluate it against policies written in Rego to give an allow or deny decision, for example by counting creates, updates and deletes per resource type, weighting them and refusing the plan if the score exceeds a threshold or if identity resources change (56, Open Policy Agent, n.d.). The same page notes that some values, such as unknown values, dynamic blocks and the results of function calls, may not be available in the plan JSON. The limit has a design consequence. A policy that evaluates the plan cannot see what the plan does not contain, so a check on the resulting state after release, performed by something other than the pipeline, is part of the control and not an optional extra.

Worked example: a change gate in Rego

The policy below is illustrative. It shows a gate that computes the change class from the plan instead of accepting the author's declaration, requires a named human approver who is neither the requester nor the author for agent-authored changes, and refuses a release outside the window.

package change.gate

import rego.v1

default allow := false

sensitive_types := {"kubernetes_cluster_role_binding", "vault_policy", "backup_target"}

destroys contains rc.address if {
    some rc in input.plan.resource_changes
    "delete" in rc.change.actions
}

sensitive contains rc.address if {
    some rc in input.plan.resource_changes
    rc.type in sensitive_types
}

# The class is computed from the diff; the author's declaration is a claim.
is_standard if {
    count(destroys) == 0
    count(sensitive) == 0
    input.change.catalogue_match
}

human_approvers contains a.id if {
    some a in input.change.approvers
    a.kind == "person"
    a.id != input.change.requested_by
    a.id != input.change.author.id
}

deny contains "declared class is lower than computed class" if {
    input.change.declared_class == "standard"
    not is_standard
}

deny contains "agent-authored change has no independent human approver" if {
    input.change.author.kind == "agent"
    count(human_approvers) == 0
}

deny contains "release is outside the authorised window" if {
    not input.release.window_open
}

deny contains "no tested rollback plan" if {
    not input.change.rollback.tested_on
}

allow if count(deny) == 0

The gate is itself a protected path. Changes to change.gate are drafted by anyone and approved only by the holders of the control plane, and the gate is tested with seeded bad changes in the way that AI Purple, Chapter 15, tested its own verification: a known-bad plan is submitted and the test passes only if the gate denies it (304, Nordqvist, 2026). A gate that has never been shown to deny anything has not been shown to work.

Review load

When drafting becomes cheap, the cost of a change moves to the person who must read it. The reviewer's task has not become easier because the author is fluent, and the human-factors literature explains why it may have become harder. Parasuraman and Manzey reviewed the evidence on complacency and automation bias and traced them to the attention of people working with automated aids (218, Parasuraman & Manzey, 2010). Bainbridge observed that supervising automation demands skill that automation leaves little occasion to practise (217, Bainbridge, 1983). Perry and colleagues found that assistant users were more confident in code that was less secure (101, Perry et al., 2023). The AI Act names the same concern for high-risk systems, requiring that persons assigned to oversight remain aware of the tendency to rely automatically on the output (Article 14(4), point (b)); change agents are not in general high-risk systems, but the article describes what real oversight must defend against (1, European Union, 2024). The risk is rubber-stamping: an approval that is given because the draft is plausible and the queue is long.

Controls that keep review real

Five controls follow from F126 and from the independence requirement of Article 17(1)(b) of the delegated regulation. First, the reviewer is a named person who is neither the requester nor the drafter, and for a change to a Tier 1 service or to a protected path the reviewer comes from a different team from the implementer. Second, the number of open agent-drafted changes per reviewer is capped; the default in this book is five, because a cap makes the cost of drafting visible and gives the agent's operator a reason to prioritise. Third, review is tiered by computed class (the standard, normal and emergency classes below), so that reviewer attention goes where blast radius is largest and a human is not asked to read a hundred identical certificate renewals. Fourth, errors are seeded: a share of drafts, by default one in twenty of the drafts that need review, contains a known defect introduced by a person who is not the reviewer, and the catch rate is measured. Fifth, a change that was approved in seconds is sampled; a re-review of a random 10 per cent of approvals, drawn by someone other than the reviewer, is a default that the works agreement may change.

The oversight-quality measure

The measures below describe the review, not the reviewer. They are reported for the platform team and never for a named engineer, in line with the agreements named above, and the group size must meet the agreed minimum.

Measure	What it shows	Default	When to act
Seeded-error catch rate	Whether reviewers find a known defect	At least 0.85 per quarter	Below the floor, freeze the class at its current level and review why
Review time against diff size	Whether large diffs are read	Median at least 2 minutes per 100 changed lines for classes needing review	Sample re-review of the fast approvals
Rejection and rework rate	Whether review ever changes anything	Between 5 and 30 per cent of drafts	Near zero for a quarter signals rubber-stamping; above the range signals poor drafts or poor instructions
Open drafts per reviewer	Whether load is humane	At most 5	Pause drafting by the agent for that reviewer's queue
Change-correlated incident rate	Whether the whole path works	Tracked per class per quarter	Two correlated incidents suspend the class

The threshold of 0.85 for the seeded-error catch rate is the one The Transformed Security Architect, Chapter 26, set for extending a further Level 3 class at Hansa Mutual, and it is used here as a starting value, to be adapted to the organisation's appetite and to the works agreement (300, Nordqvist, 2026). The review-time default is the book's own and has no external source; it is a signal that prompts a sample, not a target. A target on review time would reward speed, and a target on rejection rate would reward rejection. Chapter 20 treats metrics that mislead.

Review load is a humane design question

A reviewer who is asked to read more than they can read will approve more than they can check. The cap on open drafts protects the people as well as the control, and review time is protected in the rota in the way that on-call time is. In a small team, such as Nordvik's seven platform engineers, the people who hold the permission to draft with an agent must not be the only people able to review, because the independence requirement then has no one to apply to. AI Boss, Chapter 26, made the related point that an approval given in seconds is a signal of failure and not of efficiency (F84) (301, Nordqvist, 2026).

State engines and reconciliation

Declared state is what the repository says the estate should be. Actual state is what is running. The two diverge for ordinary reasons: an engineer edits a setting in a console during an incident and does not back-port it, a provider changes a default, an apply fails part-way, an autoscaler legitimately alters a count, or an agent with a mandate to reconfigure changes a running system directly. Drift matters for O3 Change because a declared state that does not describe the estate makes every plan misleading, and it matters for O4 Restore because a recovery rebuilt from the declaration restores the declaration, not the estate that was running. Behind the pipeline sits a second actor, the state engine, which holds a declared state and acts on the gap between it and what it observes. The design question is what it may do without a person.

The control loop and the engines that use it

Kubernetes describes its controllers as control loops that "watch the state of your cluster, then make or request changes where needed", each trying to move the current state closer to the desired state (153, The Kubernetes Authors, n.d.). The GitOps controllers run the same loop. The OpenGitOps principles state it in four sentences: desired state is expressed declaratively; it is stored in a way that enforces immutability and versioning and retains a complete version history; software agents automatically pull the desired state from the source; and software agents continuously observe actual state and attempt to apply the desired state (55, OpenGitOps, n.d.). Argo CD and Flux are the two GitOps engines among the graduated projects of the Cloud Native Computing Foundation, Argo since 6 December 2022 and Flux since 30 November 2022 (167, Cloud Native Computing Foundation, n.d.) (168, Cloud Native Computing Foundation, n.d.). Argo CD can sync an application automatically when the live state differs from the manifests in Git (154, Argo Project, n.d.); Flux reconciles at an interval and corrects any drift in the process (160, Flux project, n.d.).

Infrastructure engines have other shapes. Terraform, and OpenTofu, the fork created in response to HashiCorp's change of licence (164, OpenTofu, n.d.), keep a state whose primary purpose is to store the bindings between remote objects and the declared resource instances, and refresh it against the real infrastructure before an operation (162, HashiCorp, n.d.). The loop runs when a person or pipeline runs it, so between runs nothing compares. Crossplane and the cloud-provider controllers run continuously: Crossplane's documentation (a vendor statement) says the control plane corrects drift from the desired state (165, Crossplane Authors, n.d.), and Google's Config Connector reconciles objects against Google Cloud APIs asynchronously (166, Google Cloud, n.d.).

Push and pull differ in who holds the credentials. A push pipeline holds them and applies at release; between releases it does not compare. A pull engine holds them and acts continuously. Argo CD presents it as a benefit that pipelines then need no direct access to its API server (154, Argo Project, n.d.), a vendor claim. The book's reading is that neither model is safer by itself: the actor must be named, narrow and stoppable.

The reconciler is a change actor

A reconciler that applies is an actor in the change system, and its apply is a change like any other. Its identity is its reach. By default Argo CD uses a cluster-admin level role that its documentation says can be narrowed to the namespaces and resources it should manage (157, Argo Project, n.d.). Flux's controllers run under cluster-admin by default, and tenants are restricted by service-account impersonation and lockdown flags (161, Flux project, n.d.). Config Connector reconciles with its own service account and not the submitter's, so the ability to create its objects is the authority to change cloud resources (166, Google Cloud, n.d.). Argo CD's security documentation draws the same line for Git: write access to a trusted repository lets an attacker deploy altered manifests or delete resources so that they are pruned (157, Argo Project, n.d.).

The conclusion is the book's own. The reconciler, its credentials, its repository and the objects that hold its policy (the Argo CD project, the Flux Kustomization) are Tier 0 and protected paths, and Level 4 Autonomous is never used to change them. An agent reaches the estate by a commit through the gate of this chapter and not by a call to a sync interface: a token that may trigger a sync carries the reconciler's reach, whatever the agent's mandate says.

Sync policy and the autonomy budget

A sync policy is the reconciler's mandate. Each setting maps to an action class of Chapter 4 and to a ceiling.

Setting	What the documentation says it does	Action class	Ceiling in this book
Automated sync (Argo CD); reconciliation of a new revision (Flux)	Applies Git when out of sync; one attempt per commit; no retry of a failed attempt on the same commit (154, Argo Project, n.d.)	Deploy	Level 3 Bounded for a catalogued standard class that passed the gate; otherwise a person triggers the sync (Level 2)
Self-heal (Argo CD); drift correction at each interval (Flux)	Re-syncs when live state deviates; off by default in Argo CD, 5-second default timeout (154, Argo Project, n.d.); Flux corrects at every interval (160, Flux project, n.d.)	Reconfigure	Level 3 Bounded for catalogued drift classes outside a freeze; never for the observer's own configuration
Prune	Deletes what left Git; off by default "as a safety mechanism", with an allowEmpty guard (154, Argo Project, n.d.); required in a Flux Kustomization (160, Flux project, n.d.); per-resource opt-out (158, Argo Project, n.d.)	Delete	A named person for stateful kinds; never Level 4 where it would delete data
Sync windows (Argo CD)	Cron-scheduled allow and deny windows; deny overrides allow; no matching window means all syncs allowed (155, Argo Project, n.d.)	Gate	A second line behind the policy decision point, which holds the freeze calendar; an unmatched application is open, so give each one an allow window, which blocks syncs outside it
Ignore rules	Exclude fields from comparison (159, Argo Project, n.d.) and, with RespectIgnoreDifferences, from syncing (158, Argo Project, n.d.)	Scope of drift	Expected drift only, with an owner and an expiry; a change to a rule is a protected-path change
Waves, hooks, dependencies	Order resources; a failed PreSync hook stops the sync (156, Argo Project, n.d.); Flux dependsOn waits for readiness (160, Flux project, n.d.)	Deploy	A hook is a change under the reconciler's identity; a post-sync test it runs is the releaser's check, not the independent probe (Chapter 9)
Suspend or disable automated sync	Flux suspend stops applying revisions and correcting drift (160, Flux project, n.d.); Argo CD cannot roll back while automated sync is on (154, Argo Project, n.d.)	Hold	Any named holder, no approval; the way back is a Git revert; a freeze flag and credential revocation outside the reconciler back it up

A reconciler's catalogued behaviour is a designed mechanism, like the controller's automatic rollback in Chapter 9, and not an agent action; its settings are a mandate all the same. When a person reverses a self-heal, the reversion counts against the budget of the drift class, because a reconciler that silently restores the declaration can remove a fix an engineer put in place during an incident.

Engines by function

Engine	Reconciles	Acts alone on	The book requires around it
Kubernetes controllers	Objects against their spec (153, The Kubernetes Authors, n.d.)	Scaling, restarts, replacement, continuously	Write reach declared in the service record
Argo CD, Flux	Manifests in Git against clusters	Apply, drift correction and prune as the sync policy allows	A sync policy per class; narrow identity; stop path outside
Terraform, OpenTofu	Declared resources against remote objects, through bindings in state (162, HashiCorp, n.d.)	Nothing between runs	State treated as sensitive, as it can hold secrets (162, HashiCorp, n.d.); read-only drift detection
Crossplane, cloud-provider controllers	Cloud resources through Kubernetes objects (165, Crossplane Authors, n.d.) (166, Google Cloud, n.d.)	Create, change and delete cloud resources with the controller's identity	Control of who may create the objects
Progressive-delivery controllers	A rollout against its analysis	Shift traffic, abort	Independent evaluation (Chapter 9)

The landscape in November 2026

Versions age quickly. The table is a snapshot dated 2026-11-11, taken from the projects' own release pages and documentation, and it must be refreshed before each release of the book. It names no product as a recommendation, and a line is left out where no primary source could be opened.

Engine	Line at 2026-11-11	What matters to operations
Argo CD	3.6.1 on the stable branch (190, Argo Project, 2026)	The 3.5 to 3.6 upgrade guide changes OpenTelemetry trace sampling to parent-based with a configurable root sampling ratio, and apps with ServerSideApply=true now diff by server-side dry run, which adds kube-apiserver traffic and shows validating-webhook rejections as diff errors (191, Argo Project, 2026). The source hydrator, which pushes rendered manifests to Git before sync, is documented as beta since 3.5.0 and disabled by default (192, Argo Project, 2026)
Flux	2.10, announced 26 October 2026; the three most recent minor releases are maintained (193, Capili, 2026) (194, Flux project, n.d.)	Controllers can authenticate each other with mutual TLS, with certificates issued through a SPIFFE Workload API. The default RBAC no longer grants create on serviceaccounts/token, a breaking change for some credential configurations (193, Capili, 2026)
Argo Rollouts, Flagger, Kargo	Argo Rollouts v1.10.2, 4 November 2026 (202, Argo Project, 2026)	The capabilities that Chapter 9 relies on (analysis, abort, verification after promotion) are unchanged in kind; no version is stated for Flagger and Kargo
Kubernetes	1.37, latest patch 1.37.1 of 15 September 2026; branches 1.37, 1.36 and 1.35 maintained, with about a year of patch support (195, The Kubernetes Authors, 2026)	Plan upgrades inside the window; a controller is only as current as the cluster it runs on
Crossplane	v2.4 labelled latest in its documentation (196, Crossplane Authors, 2026)	The documentation now has an Operations section with Operations, Cron Operations and Watch Operations alongside compositions; whoever may create these objects holds the controller's reach
Terraform, OpenTofu	Terraform 1.17.1, 28 October 2026 (198, HashiCorp, 2026); OpenTofu 1.13.9, 5 November 2026 (197, OpenTofu, 2026)	Terraform 1.17.0 adds a -minimal-refresh plan option and makes Terraform Policy generally available (198, HashiCorp, 2026). OpenTofu documents encryption of state and plan files at rest (188, OpenTofu, n.d.)
Temporal, Argo Workflows	Argo Workflows v4.1.6, 22 October 2026 (201, Argo Project, 2026); Temporal's server repository carries the MIT licence (200, Temporal Technologies, 2026)	Temporal describes durable execution as running code to completion across crashes, replaying the event history on another worker (199, Temporal Technologies, n.d.); Chapter 10 sets out the limits of replay

Three points follow for the design, and they are the book's own reading. First, a breaking change in a default, such as the Flux RBAC change, is a change to the reconciler's reach and goes through the gate of this chapter like any other. Second, a feature in beta, such as the source hydrator, enters a protected path only with a named owner and an exit, because the sync policy that depends on it is a mandate. Third, the line a project supports is a fact with an expiry date, so the service record states the engine and its version and the resilience register treats an unsupported line as an expired claim.

That the engines continue to release monthly or quarterly, and that vendors add interfaces for AI agents, is observable: the Flux 2.10 announcement reports new read-only tools in the Flux MCP Server for tracing, diffing, events and logs (193, Capili, 2026), and the Argo CD interface of this kind is treated in Chapter 18. That sync policies and these interfaces will be reviewed as mandates in most large estates is expected. That a single engine will own both reconciliation and procedure for most operators is speculation.

Worked example: a sync policy for a Hansa Mutual cell

The Application below is illustrative. It is cell 1 of the claims core (ROL-HM-001, Chapter 9) at Hansa Mutual, whose GitOps pipeline uses Argo CD with per-market overlays. Each comment names the rule that the field implements. The annotation keys are this book's convention and not Argo CD fields. The sync windows belong to the Argo CD project claims-core, which is a protected path; Appendix A.21 holds the project, the ApplicationSet that generates the cells and the Flux equivalent.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: claims-core-market-no
  namespace: argocd
  annotations:
    hansa.example/service: SVC-HM-001
    hansa.example/ignore-owner: platform-engineering
    hansa.example/ignore-expires: "2029-04-30"
spec:
  project: claims-core              # repositories, destinations, kinds, sync windows
  source:
    repoURL: https://git.hansa.example/platform/claims-core.git
    targetRevision: claims-core-2028.10.2   # pinned by the pipeline controller on verifier pass
    path: overlays/market-no
  destination:
    name: cloud-a-eu-claims
    namespace: claims-core-no
  syncPolicy:
    automated:
      prune: false                  # delete is never automatic; a named person prunes
      selfHeal: true                # reconfigure to declared state, catalogued classes, Level 3
      allowEmpty: false
    syncOptions:
      - PruneLast=true              # if a person prunes, deletions come last
      - RespectIgnoreDifferences=true   # ignored fields are neither compared nor overwritten
    retry:
      limit: 3                      # bounded attempts, then a person
      backoff: {duration: 30s, factor: 2, maxDuration: 5m}
  ignoreDifferences:                # expected drift only, owner and expiry in the annotations
    - group: apps
      kind: Deployment
      jsonPointers: [/spec/replicas]   # horizontal scaling inside bounds
  revisionHistoryLimit: 10

The pipeline controller of Chapter 9 changes targetRevision when the verifier has passed a ring, so the widening decision stays outside the engine. Stateful resources carry Prune=false and Delete=false in their own manifests, and self-heal is on only because the drift classes it may revert were catalogued first.

Nordvik Region applies infrastructure through a push pipeline and has no continuous reconciler. Were it to move the portal's workloads to a pull model, the equivalent is a Flux Kustomization with prune: false, wait: true and a service account confined to the portal's namespace, with the merge to the release branch staying a person's act inside the window, because the merge is then the release.

The change record names the reconciler

The change record gains a field, reconciler: the engine, the mode (push or pull), the applying identity, the sync policy and what the engine may do alone for this change. Without it a person who was not there cannot reconstruct who applied the change. The record for CHG-NR-2028-0007 below carries it.

Classifying drift and choosing a response

Drift is classified before it is corrected. The drift detector observes with a read-only identity and compares the running estate with the declaration, not with the pipeline's own state file. Terraform's refresh-only mode updates its state to match changes made outside Terraform, for instance during an incident (163, HashiCorp, n.d.), but state is not the declaration, so adoption still needs a commit. Expected drift, such as an autoscaler's replica count, is excluded by a declared ignore rule with an owner and an expiry. Unauthorised drift, a change made outside the pipeline, is either reverted or adopted: reversion is a reconfigure action, and adoption is a new change through the pipeline whose record says it was made in the console first. Emergency drift, a change made during an incident, is adopted or reverted within a stated period, by default five working days. Provider-side drift, such as the unannounced image update that stalled Nordvik's citizen-service assistant for two hours in INC-NR-2027-0129, is a change by a party outside the pipeline and is detected only if the declaration pins the thing that moved.

Automatic reversion is permitted at Level 3 Bounded only for classes catalogued in advance, enforced by a policy decision point outside the reconciler, and never at Level 4 where it would delete data, act inside a freeze on a critical function or touch the observer's own configuration. Nordvik's failed failover test RST-NR-2027-002, whose review found a DNS time-to-live and an unrenewed certificate at the recovery site, is read here as a drift problem: both are properties that a comparison of the recovery site with its declaration can hold in view, and that nothing compared before the test. The reading is the book's, and the evidence for it is the review record, not a measurement of drift.

Standard, normal and emergency change

Service management distinguishes three kinds of change. A standard change is low-risk, well understood and pre-authorised: a catalogued kind of change that may be made without a separate approval each time. A normal change is assessed and authorised through the change authority. An emergency change cannot wait for the normal path without unacceptable risk, and is made with a shortened procedure and reviewed afterwards. The vocabulary is that of established service management practice, and the elements the law asks for are in the instruments above. Delegated Regulation 2024/1774 asks for procedures and tools to manage emergency changes with adequate safeguards and for emergency changes to be documented, re-evaluated, assessed and approved after implementation (Article 17(1), points (f) and (g)) (8, European Commission, 2024), and the annex to Implementing Regulation 2024/2690 asks that the result of an emergency change and the reason the regular procedure was not followed are documented (4, European Commission, 2024).

The change authority and the advisory board

The research programme on software delivery found in its research no evidence for the hypothesis that a more formal external review process is linked to a lower change fail rate, and found that heavyweight approvals slow delivery, which leads to larger, less frequent releases that carry more production risk. It found that change approval is best implemented through peer review during development, supported by automation, with reviews and approvals recorded in the team's platform; it still gives a central board a role in coordination and in high-level trade-offs (139, Google Cloud, n.d.). The finding concerns approval by a body distant from the change. It is compatible with the requirement of Article 17(1)(b) that approval is independent of request and implementation, because a peer in another team is independent in that sense and a distant board need not be. AI Governance, Chapter 24, drew the operational conclusion for patching (F29). Chapter 22 completes the argument by defining change authority as a set of decision rights, with the board reduced to the cases that need it.

What the classes mean when most change is machine-authored

Three points change when agents author much of the change. First, the class of a change is computed from the diff and the target, not declared by the author. A declared class is a claim, and the gate above denies a change whose declared class is lower than its computed class. The case that shows why is Hansa Mutual's INC-HM-2027-0833, in which a configuration push to the AI gateway routing was treated as a standard change, the canary stage was skipped, and the claims assistant failed in four markets for 47 minutes; the problem record PRB-HM-0019 is where the rule was written that class is decided by the pipeline. Second, standard classes are narrow and earn their place by evidence, so that a class has a history of successful changes, a bounded blast radius, an automatic rollback and a way to be withdrawn. Third, emergency is not a class that an agent may choose. An agent may draft an emergency change at Level 2 Supervised or below, a named person declares the emergency, and the independence of the approver is not waived: the approver may be the incident commander, never the requester. The record is completed after the event, and a pattern of emergency changes that mirror a standard class is a signal that the class is missing or mis-specified.

Practical guide: defining standard change classes that an agent may author and a pipeline may release

Purpose. Define a class of change that an agent may draft and a pipeline may release without a separate human approval for each instance, and keep the class honest over time.

Roles. The service owner, the platform lead (or SRE lead), a reviewer from outside the implementing team, the CISO's delegate, and the employee representatives where the class touches monitoring or on-call. At Hansa Mutual the head of operational resilience reads the class for DORA critical or important functions.

Steps.

1. Pick a kind of change made by hand at least 20 times in the last 12 months with no change-correlated Tier 1 or Tier 2 incident.
2. Write the class as data: eligible services by tier and DORA flag, the resource types it may touch, a maximum number of resources, no deletes of stateful resources, no identity, network or key resources, and the window.
3. Define the verification, an independent probe with a pass condition, and the rollback. Test the rollback in staging before approval and record the date and result.
4. Set the level per action class: drafting at Level 1 Assisted or Level 2 Supervised; release at Level 3 Bounded only when the conditions above hold and the policy decision point is outside the agent.
5. State the budget consequence: two change-correlated incidents, or one in a Tier 1 service, within a quarter suspend the class until the change authority has read the post-incident review.
6. Sample after the event: a named person re-reviews a random 10 per cent of released instances each month, and seeded errors continue on drafts in the class that still pass through review.
7. Set an expiry of 12 months, so that the class cannot outlive the conditions that justified it.
8. Agree the class and its measures with the employee representatives where the works agreement requires it, before it is switched on.

change_classes:
  - id: HM-STD-002
    name: Certificate renewal for services outside critical functions
    approved_by: AIDR-0952              # change-risk reviewer and class rules
    eligible:
      service_tiers: [2, 3]
      dora_critical_or_important: false
    may_touch: [certificate, secret_reference]
    limits: {max_resources: 10, deletes: 0, identity_changes: 0, network_changes: 0}
    window: "daily 05:00-07:00 Europe/Berlin"
    delegation: {draft: "Level 2 Supervised", release: "Level 3 Bounded"}
    verification:
      probe: external-tls-probe          # not run by the pipeline
      pass: "chain valid and at least 30 days to expiry"
    rollback: {automatic: true, tested_on: 2028-10-04, result: passed}
    history: {instances_12m: 41, correlated_incidents: 0}
    suspend_if: "two correlated incidents or one in Tier 1 within a quarter"
    sampling: {post_release_rereview: 0.10, seeded_errors: 0.05}
    expires: 2029-10-04

Definition of done. The class exists as a file in version control with an approving decision record, the gate computes class membership from the diff, the rollback was tested with a date and a result, the probe runs outside the pipeline, the suspension rule and the expiry are in the file, and the first monthly sample has been read by a named person.

Supply chain

A change brings components into the estate: modules, providers, charts, container images, packages, and increasingly the skills and tools of agents. Each is a supplier. NIS 2 asks entities to take supply chain security into account, including the security-related aspects of the relationship with each direct supplier, to consider vulnerabilities specific to each supplier and the overall quality of their products and cybersecurity practices, including secure development procedures (Article 21(2), point (d), and Article 21(3)) (3, European Union, 2022).

The Cyber Resilience Act places its obligations on manufacturers of products with digital elements, and operators meet it mostly as acquirers. A manufacturer must exercise due diligence when integrating components sourced from third parties, so that they do not compromise the cybersecurity of the product (Article 13(5)), and must identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format that covers at least the top-level dependencies (Annex I, Part II, point (1)) (5, European Union, 2024). The Regulation applies from 11 December 2027, with the reporting obligations of Article 14 applying from 11 September 2026 (Article 71). For an operator the architectural implication is that bills of materials become something it can ask for and receive from its suppliers, and compare against what a change introduces. For an operator that builds software it places on the market the obligations apply to it directly, which is not the position of either organisation of this book.

Four checks in the gate follow. A new dependency must exist in the approved registry or mirror and have an owner; package hallucination means that a name suggested by a model may not exist and may later be registered by someone else, so a change that introduces a name unknown to the approved mirror stops until a person has looked at it (102, Spracklen et al., 2025). Versions are pinned by digest, so that a change is the change that was reviewed. The change record carries the delta of the bill of materials. And the skills, tools and instructions that an agent loads are versioned dependencies of their own, recorded in the provenance record and changed only through the same pipeline (Chapters 16 and 18).

What can be undone and who can stop it

Every change record states what can be undone. A declarative change to stateless resources is undone by reverting the commit and re-applying, and the rollback can be rehearsed in a staging environment. A change that touches data is not undone by reverting code: a schema migration, a deletion, a key rotation or a change to a retention setting acts on state that the repository does not hold. Such a change needs a data-level plan, usually a restore from a backup, and a restore over existing data is an action class that Level 4 Autonomous may not use. The record therefore holds a rollback plan with its reversibility, the date it was last tested and the result, and the book does not accept "revert" as a plan for a change that touches stateful resources.

Every change path has a stop path outside the pipeline it stops. The pipeline kill switch and the freeze flag are held by named people who need no approval: at Hansa Mutual the incident commander, the agent operator and the platform engineer on call, as for the IT-operations agent, and at Nordvik Region the duty manager and the platform engineer on call. The stop path is exercised, because a stop path that has not been drilled has not been shown to work (Chapter 17). A stop is not a failure, and the restart of releases is a separate decision made at a lower level of delegation than the release. What the change record does not say, it cannot be assumed to cover.

Worked example: a change record for an AI-authored infrastructure change

The record below is illustrative. It concerns Nordvik Region's citizen e-service portal, SVC-NR-002, a Tier 1 service. The change was drafted with an agentic work tool (Mode 3) used by a senior platform engineer, who requested it, and reviewed by two other people, one from the platform team and one from infrastructure. It automates renewal of the portal certificate on the standby environment at the recovery site, motivated by the failed failover test RST-NR-2027-002, whose review named an unrenewed certificate at that site.

change_record:
  id: CHG-NR-2028-0007
  service: SVC-NR-002                       # Tier 1
  title: Automatic renewal of the portal certificate at the recovery site
  motivated_by: [RST-NR-2027-002]
  requested_by: joakim.wester
  author:
    kind: agent
    tool: agentic-work-tool                 # Mode 3, platform team permission
    identity: wl-nr-platform-draft
    model: nr-reserved/open-weight-coder@2028-09-03
    instructions_version: skills/cert-renewal@3f9a1c2
    inputs: [ticket:CHG-REQ-0412, repo:infra/recovery-site@b7e41d0, runbook:RBK-NR-0003]
    tests_run: [terraform-validate, plan-review, staging-apply]
    not_tested: [renewal against the production certificate authority]
  provenance_stored: references_only        # no typed prompts (MBL-NR-IT-2027-01)
  reconciler:
    mode: push                              # applied by the pipeline credential; no continuous reconciler
    engine: terraform-pipeline
    identity: wl-nr-pipeline-apply
    sync_policy: "apply on merge inside the window; no automatic re-apply; drift detector read-only"
  declared_class: normal
  computed_class: normal                    # Tier 1 service, no catalogue match
  plan: {add: 3, change: 1, destroy: 0, sensitive_types: []}
  policy_results: {gate: allow, supply_chain: "chart pinned by digest, no new dependency",
                   sbom_delta: 0, window_check: pass}
  approvers:
    - {id: maja.lindqvist, kind: person, team: platform}
    - {id: oskar.berg, kind: person, team: infrastructure}
  window: "2028-10-17 20:00-22:00"
  rollback:
    plan: "revert commit, destroy 3 added resources, no data touched"
    reversibility: full
    tested_on: 2028-10-12
    result: passed
  stop_path: "duty manager and platform engineer on call, pipeline kill switch"
  verification:
    probe: external-tls-probe               # run by monitoring, not by the pipeline
    result: "chain valid, renewal object present, 89 days to expiry"
    checked_at: 2028-10-17T21:12
  claim_not_made: "failover of SVC-NR-002 is not shown to be recoverable; re-test open (Chapter 19)"

The record also shows what it does not claim. The change closes one cause named in a failed test, and the failover remains unverified until a re-test passes with a date and a result.

Outlook

The labels follow AI Governance, Chapter 22. That AI authors a substantial share of change, with review and acceptance by engineers, is observable (140, Pichai, 2024) (138, Salva, 2025). That policy gates and peer review replace the weekly change advisory board for most change is expected, supported by the delivery research on external approval (139, Google Cloud, n.d.) and by the independence rule of Article 17(1)(b) of the delegated regulation, which asks for independence and not for a board. That the sync policies of reconcilers are reviewed as mandate-like artefacts, with the engine named in the change record, is expected, because the reach of an engine is its identity and the protected-path rule already covers the files that set it. That non-standard change is authored, approved and released with no person in the path is speculation: no evidence reviewed here shows it, and the Level 4 prohibitions would not permit it for the cases that matter most.

Across the degrees of delegation

The table sets out the degrees of delegation for O3 Change activities. The action classes are those of Chapter 4: read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete and restore over existing data. The usage mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.

Level	O3 activity	Typical usage mode	Who decides	Required outside the agent
Level 0 Advisory	Scores a proposed change for blast radius and freeze conflict; reads and annotates	Mode 4 Built AI applications (Hansa's change-risk reviewer HM-OPS-003)	The person who reads the score	Read-only identity; the score is not an approval
Level 1 Assisted	Drafts a change, a runbook or a policy at a person's request	Mode 3 Agentic work tools (Nordvik's platform team)	The requester and the reviewer	Draft only, no write to the release branch; provenance record
Level 2 Supervised	Authors a change and opens a pull request under a mandate; may apply to non-production	Mode 3, Mode 5 Autonomous production agents	A named reviewer who is not the requester or the drafter	Gate on the pull request; cap on open drafts; seeded errors
Level 3 Bounded	Releases a catalogued standard class in a window; reverts catalogued drift (automated sync and self-heal of a catalogued class)	Mode 5 (Hansa's IT-operations agent for configuration change inside defined classes, indicatively)	The class, approved in advance by the change authority	Policy decision point outside the agent; independent probe; tested rollback; suspension rule
Level 4 Autonomous	Not used for an irreversible action on production data, for a deploy outside a window or inside a freeze on a critical function, for an edit to a protected path, or for any action that disables the observer or the stop path	None	Not applicable	Not applicable

Nordvik Region and Hansa Mutual

Nordvik Region lets an agent draft infrastructure changes and does not let it apply them. Four of the seven platform engineers hold the permission to use the agentic work tool, which runs on open-weight models on the Region's reserved capacity, and every draft goes to a pull request reviewed by a platform engineer and, for a Tier 1 service, by a second person from infrastructure. Releases happen in windows and by push: the platform team's pipeline applies, no continuous reconciler holds credentials to production, and a drift detector with a read-only identity compares the estate with the declaration. No standard class exists yet that a pipeline releases alone; certificate renewal and horizontal scaling inside bounds are the first candidates, and CHG-NR-2028-0007 is a normal change because no class exists. The operations assistant NR-OPS-001 (Level 0 Advisory) reads and explains but does not author. The provenance record stores references and not typed instructions because the agreement with the unions requires negotiation before engineers' queries are logged. With seven engineers on a weekly rota the same people draft and review, so the Region keeps the cap on open drafts low and uses the infrastructure team as second reviewer. NIS 2 as transposed nationally frames the duty, and the change management requirements of the implementing regulation are one the Region can ask SamDrift to meet by contract.

Hansa Mutual lets standard classes flow to production when the policy checks pass. Its GitOps pipeline, policy as code and per-market overlays give it the machinery, with Argo CD as the engine and a sync policy per class and per cell (the worked example above), and the IT-operations agent HM-OPS-001 acts at Level 3 Bounded inside catalogued runbooks and at Level 2 for configuration change, so that a change of the kind that broke the AI gateway routing in INC-HM-2027-0833 is authored at Level 2 and reviewed by a named person. The change-risk reviewer HM-OPS-003 scores proposed changes against blast radius and the freeze calendar at Level 0 Advisory (AIDR-0952), and its score informs the human decision without replacing it. DORA applies directly: Article 9(4)(e) and Article 17 of the delegated regulation shape the change procedure, and the head of operational resilience reads the classes that touch critical or important functions. KBV-IT-2024-OPS-02 keeps review metrics at team level with a minimum group size of five. The difference lies in where the work is. Nordvik's problem is reviewers, and its answer is few reviewed changes and a contract. Hansa's problem is class discipline across seven jurisdictions and a pipeline fast enough that a wrong class travels far.

Summary

This chapter concerned O3 Change, with O1 Observe at the point where drift between declared and actual state is detected. The change pipeline is a control when six properties hold: the diff is the only route, the author is identified, checks are computed by a policy decision point outside the author, release is by a pipeline credential, verification is independent of the releaser and a record is kept. DORA Article 9(4)(e), Article 17 of Delegated Regulation 2024/1774, NIS 2 Article 21 and the annex to Implementing Regulation 2024/2690 ask for the same properties, and the chapter reads them as architectural implications.

AI changes who writes the draft and how many drafts arrive. The evidence on its effect on delivery is survey-based and mixed, and the book's conclusion is that a draft's authority comes from provenance, policy and review and never from its form. The provenance record holds the author's identity, mandate, level, model, instructions, inputs and what was not tested, as references and not the engineer's typed words. The gate computes the class from the diff and denies a lower declared class; the gate and the files that govern it are protected paths, and Level 4 Autonomous is never used for an edit to them.

Review is where the cost of cheap drafting lands, so it is designed: a named reviewer who is neither requester nor drafter, a cap of five open drafts, tiering by class, seeded errors, sampled fast approvals and measures reported for teams. State engines (Kubernetes controllers, Argo CD and Flux, Terraform and OpenTofu, Crossplane and the cloud-provider controllers) keep declared and actual state together, and each is a change actor whose identity is its reach: a sync policy maps to action classes, with automated sync and self-heal at Level 3 Bounded for catalogued classes only, prune never at Level 4 where it deletes data, and the engine, its credentials and its policy objects protected paths. A drift detector with a read-only identity observes, and the change record names the reconciler. A dated snapshot of the engines' release lines, to be refreshed before each release of the book, shows that a changed default or a beta feature is a change to a reconciler's reach. Standard changes are narrow classes with a history, a probe, a tested rollback, a suspension rule and an expiry, and emergency is declared by a person, never chosen by an agent. Every record says what can be undone and who can stop the change without approval. Chapter 9 takes the change into production in stages, with freezes and blast-radius budgets, and Chapter 10 turns to restoring the estate when a change has gone wrong.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
4. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (4, European Commission, 2024)
5. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). (5, European Union, 2024)
6. Nordqvist, G. (2025). Architecture as Code. (295, Nordqvist, 2025)
7. Nordqvist, G. (2026). AI Governance. (296, Nordqvist, 2026)
8. Nordqvist, G. (2026). AI Platform and Security. (297, Nordqvist, 2026)
9. Nordqvist, G. (2026). The Transformed Security Architect. (300, Nordqvist, 2026)
10. Nordqvist, G. (2026). AI Boss. (301, Nordqvist, 2026)
11. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (217, Bainbridge, 1983)
12. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. Human Factors 52(3). (218, Parasuraman & Manzey, 2010)
13. Nordqvist, G. (2026). AI Purple. (304, Nordqvist, 2026)
14. European Commission. Commission Delegated Regulation (EU) 2024/1774 (ICT risk management tools, methods, processes and policies). (8, European Commission, 2024)
15. National Institute of Standards and Technology. Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5. (53, NIST, 2020)
16. Harvey, N. & DeBellis, D. (2024). Highlights from the 10th DORA report. Google Cloud Blog. (251, Harvey & DeBellis, 2024)
17. Salva, R. J. (2025). How are developers using AI? Inside our 2025 DORA report. Google blog. (138, Salva, 2025)
18. Google Cloud. Capabilities: Streamlining change approval. DevOps Research and Assessment programme. (139, Google Cloud, n.d.)
19. Pichai, S. (2024). Q3 earnings call: CEO's remarks. Google. (140, Pichai, 2024)
20. Kon, P. T. J. et al. (2024). IaC-Eval: A Code Generation Benchmark for Cloud Infrastructure-as-Code Programs. NeurIPS 2024. (100, Kon et al., 2024)
21. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023. (101, Perry et al., 2023)
22. Spracklen, J. et al. (2025). We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. (102, Spracklen et al., 2025)
23. SLSA. Supply-chain Levels for Software Artifacts (SLSA) specification, version 1.2: Build requirements and Build provenance. (54, SLSA, n.d.)
24. OpenGitOps. GitOps Principles, version 1.0.0. (55, OpenGitOps, n.d.)
25. Open Policy Agent. Terraform. OPA documentation. (56, Open Policy Agent, n.d.)
26. The Kubernetes Authors. Controllers. Kubernetes documentation. (153, The Kubernetes Authors, n.d.)
27. Argo Project. Automated Sync Policy. Argo CD documentation. (154, Argo Project, n.d.)
28. Argo Project. Sync Windows. Argo CD documentation. (155, Argo Project, n.d.)
29. Argo Project. Sync Phases and Waves. Argo CD documentation. (156, Argo Project, n.d.)
30. Argo Project. Security. Argo CD operator manual. (157, Argo Project, n.d.)
31. Argo Project. Sync Options. Argo CD documentation. (158, Argo Project, n.d.)
32. Argo Project. Diffing Customization. Argo CD documentation. (159, Argo Project, n.d.)
33. Flux project. Kustomization. Flux documentation. (160, Flux project, n.d.)
34. Flux project. Flux multi-tenancy. Flux documentation. (161, Flux project, n.d.)
35. HashiCorp. State. Terraform documentation. (162, HashiCorp, n.d.)
36. HashiCorp. terraform plan command reference. Terraform documentation. (163, HashiCorp, n.d.)
37. OpenTofu. Frequently asked questions. OpenTofu documentation. (164, OpenTofu, n.d.)
38. Crossplane Authors. What's Crossplane? Crossplane documentation. (165, Crossplane Authors, n.d.)
39. Google Cloud. Config Connector overview. Google Cloud documentation. (166, Google Cloud, n.d.)
40. Cloud Native Computing Foundation. Argo. CNCF project page. (167, Cloud Native Computing Foundation, n.d.)
41. Cloud Native Computing Foundation. Flux. CNCF project page. (168, Cloud Native Computing Foundation, n.d.)
42. Argo Project. VERSION file, stable branch. Argo CD repository. (190, Argo Project, 2026)
43. Argo Project. Upgrading from 3.5 to 3.6. Argo CD operator manual, stable branch. (191, Argo Project, 2026)
44. Argo Project. Source Hydrator. Argo CD documentation, stable branch. (192, Argo Project, 2026)
45. Capili. Announcing Flux 2.10 GA. Flux blog, 26 October 2026. (193, Capili, 2026)
46. Flux project. Flux releases. Flux documentation. (194, Flux project, n.d.)
47. The Kubernetes Authors. Releases. Kubernetes documentation. (195, The Kubernetes Authors, 2026)
48. Crossplane Authors. Crossplane documentation (latest).. (196, Crossplane Authors, 2026)
49. OpenTofu. OpenTofu releases. GitHub. (197, OpenTofu, 2026)
50. HashiCorp. Terraform releases. GitHub. (198, HashiCorp, 2026)
51. Temporal Technologies. Why Temporal? Temporal documentation. (199, Temporal Technologies, n.d.)
52. Temporal Technologies. LICENSE. Temporal server repository. (200, Temporal Technologies, 2026)
53. Argo Project. Argo Workflows releases. GitHub. (201, Argo Project, 2026)
54. Argo Project. Argo Rollouts releases. GitHub. (202, Argo Project, 2026)
55. OpenTofu. State and Plan Encryption. OpenTofu documentation. (188, OpenTofu, n.d.)