Architects, Platform Engineers and Site Reliability Engineers

A developer rarely works alone on a change that reaches production. Before the first line is written, an architect has set constraints that the design must respect. While it is written, a platform team has decided which template, pipeline, scanner and package registry the code passes through, and, increasingly, which AI tools may touch it. After release, a site reliability engineer holds a number, the error budget, that says whether the next change may go out. These three neighbours do not write the application, but each one holds a decision that shapes what the developer and the developer's tools may do. When AI generates change at a higher volume than before, those decisions stop being background and become the places where the organisation's control over AI-assisted development actually sits. This chapter concerns D2 Design and D5 Steward: how the architect's role, the platform team's golden paths and the reliability engineer's error budget change when AI takes part in development, and where the boundaries and handovers between them and the developer must be written down.

The chapter builds on conclusions of earlier volumes. In Architecture as Code (Chapter 4), architectural decisions are kept as short, numbered, immutable records beside the code, and in Architecture as Code (Chapter 17) platform teams act as internal service providers that own common toolchains and guardrails (161, Nordqvist, 2025). AI Platform and Security, Chapter 4, set out a reference architecture in which every model call and tool call passes a policy point outside the model, carried by the AI gateway, with every tool registered and its credentials held by the platform, and Chapter 19 added that containment must not depend on intent (163, Nordqvist, 2026). The Transformed Security Architect, Chapters 4, 7, 16 and 17, described the architect's role as a charter with decision rights, as the designer of boundaries that hold whatever anyone intends, and as one voice in a role map and a design authority that works through gates instead of meetings (166, Nordqvist, 2026). AI Operations, Chapter 4, gave the autonomy budget and the observer principle, and its Chapters 21 and 22 gave operating models and decision rights (170, Nordqvist, 2026). This chapter does not repeat them. It asks what a developer needs from these neighbours, and what they need from the developer, when the volume and the origin of change have shifted.

Figure 16.1: The architect sets constraints and owns the seams, the golden path and the gateway carry the defaults for AI tooling, the developer team owns the change, and the error budget feeds back into the level of delegation.

Three neighbours, one problem

The three roles are defined in different traditions and are staffed differently in the two organisations of this book. Nordvik Region has an enterprise architect and an AI architect, a platform team of seven, and no site reliability function. Hansa Mutual has about 25 architects and designers in Group Application Development beside the enterprise and security architects counted elsewhere, an internal developer platform called Hansa Forge with 24 people, and a site reliability function of about 95. The problem they share is that each of them decides something about development without writing the code, and that the decision is now exercised against a stream of change that includes machine-generated proposals.

The shared problem has a common form. Conway observed in 1968 that organisations that design systems produce designs that copy their own communication structure (77, Conway, 1968), and AI Governance, Chapter 12, used the observation to argue that organisational design is architecture by other means (162, Nordqvist, 2026). The seams between architect, platform team, reliability engineer and developer are therefore where the system's seams will appear. If nobody owns the seam between the golden path and the coding assistant, the coding assistant will sit outside the golden path, which is the situation at Nordvik Region at the start of the year: the platform team runs the Region's AI gateway for the Mode 4 services, and the Mode 2 pilot of the IDE assistant NR-DEV-001 calls the self-hosted model directly. The tool works, the pilot is useful to its users, and the one team whose job is to put logging, allow-lists and cost control in front of AI tools has not been asked to.

The rest of the chapter takes the three neighbours in turn, then draws the handovers, and ends with a specification a platform team can adopt.

The architect (D2 Design)

The architect's role in a world of AI-assisted development has two parts, and this chapter takes only the part that touches the developer. The architect's own transformation, from author of documents to designer of executable boundaries and decision rights, is the subject of The Transformed Security Architect (Chapters 3 to 5 and 7), and the enterprise and AI architect's seams are the subject of AI Governance, Chapter 14, where the AI architect owns the seams between the architecture roles (166, Nordqvist, 2026) (162, Nordqvist, 2026). The question here is narrower: who decides the design when a tool proposes it, and what does the developer's team decide for itself?

What the architect keeps

An architect keeps the constraints that cross team boundaries: the interfaces other teams depend on, the data location and classification rules, the security boundaries, the choice of platform and the dependencies that would be hard to reverse. These are the decisions that Architecture as Code (Chapter 20) named as staying with people whatever the agents propose, namely commitments with long-term consequences such as platform lock-in, data residency and operational dependencies (161, Nordqvist, 2025). They are also the decisions for which a coding assistant is least able to help, because the consequence lies outside the repository the assistant can see. A tool that proposes a message queue, a caching layer or a new managed service in a pull request has proposed an architectural commitment in the guise of an implementation detail.

The practical consequence is a rule about where such proposals stop. A change that adds a dependency on a new platform service, a new external endpoint, a new data store or a new class of credential is an architectural change whoever or whatever proposed it, and it is routed to the design decision that the architect's forum owns. The routing is done by the code, not by the goodwill of the author: a code-ownership rule on the files that declare dependencies, endpoints and permissions sends the change to the architect's review, in the way that AI Platform and Security, Chapter 17, routes changes that trigger security review (163, Nordqvist, 2026). Chapter 6 treats design with AI in detail, including how AI involvement is recorded in the decision record. Here it is enough to say that the record of a decision names the human who made it, and that a decision for which a tool drafted the options says so.

What the developer keeps

The developer's team keeps the design inside the constraints: the structure of the service, the choice of library within the approved set, the data model, the test strategy. The boundary is not new, but AI makes it easier to cross by accident in both directions. A developer with an assistant can produce a plausible architecture sketch in a minute, and that is useful input, but it is not a design decision of the organisation. An architect with an assistant can produce a plausible reference implementation in an hour, and that is useful input, but the architect has then become an author of code whose ownership falls to a team that did not ask for it. The remedy in both cases is the stewardship principle of Chapter 4: whoever commits the result must be able to Name the owner, Understand the change and Revert it, and the architect who drafts code hands it over with an ownership record as any other contributor would.

Observable, expected, speculation

It is observable that both organisations record design decisions as ADRs of the Architecture as Code kind and that neither has a rule that says which decisions need the architect. It is expected, on the evidence that a coding assistant proposes structure as easily as syntax, that the number of unreviewed architectural commitments grows unless dependency and permission changes are routed by ownership rules. Whether the architect role will thin as design is drafted by tools is speculation, and Chapter 29 treats it; no source consulted for this chapter measured it.

The platform team (D5 Steward, D2 Design)

The platform team is the neighbour whose decisions a developer meets every day. Team Topologies describes a platform team as a grouping of other team types that provides an internal product to accelerate delivery by stream-aligned teams, and an enabling team as one that helps a stream-aligned team overcome obstacles and then moves on; it names three interaction modes, collaboration, X-as-a-Service and facilitating (41, Skelton & Pais, 2025). The thesis of this section is that the platform team, in the X-as-a-Service mode, is the right place to govern AI tooling for development, because it is the one team that already owns the common toolchain and sits in the path of every change.

Golden paths

Spotify's engineering organisation defined the golden path as the opinionated and supported path to build something, and stated that the purpose was not to limit or stifle engineers: it reduces the number of decisions a team faces and spares it from rebuilding solutions. Engineers can leave the path, with less support (133, Niemen, 2020). The definition carries two properties that matter for AI tooling. A golden path is a default, and a default can carry decisions that nobody has to take again. A golden path is also not a prohibition, so it needs an exit that is visible rather than a quiet divergence.

A golden path for a service therefore holds more than a template. It holds the build and test pipeline, the scanners, the logging and deployment configuration, the registries from which packages may be drawn, and, once AI tools are in the picture, the AI tooling defaults: which assistants may be used with code from this path, by which route, with which classification of code, and with what logging. Both organisations already have the first half. Nordvik Region's platform team offers two golden paths, a Spring service and a TypeScript front end, with a package proxy that serves only approved registries. Hansa Forge offers golden paths, CI/CD, a package proxy, scanning and the gateway through which coding tools reach models.

Evidence about platforms

The research programme on software delivery, the DevOps Research and Assessment (DORA) programme, reported in 2024 that internal developer platforms improve individual productivity and team performance, that they are more common in larger organisations, and that implementing one may lead to a temporary decrease in performance before improvements appear as the platform matures; it advised user-centred design, developer independence and a product orientation (216, Google Cloud, 2024) (221, Google Cloud, 2024). The same report is cautionary on AI: the announcement states 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, and says that improving the development process does not automatically improve software delivery without basics such as small batch sizes and robust testing (221, Google Cloud, 2024). The page states no respondent count, the figures are estimates from an annual survey, and they describe association and not cause. Read with that limit, the finding is a reason for the platform team to keep the basics in the golden path where a faster generator would otherwise erode them. It does not say that AI lowers stability in either organisation; neither has measured it (Chapter 20).

AI tooling as a platform service

The platform team's contribution is to turn four decisions about AI tooling from team choices into defaults.

1. Allow-list. Which coding assistants and agents may be used, in which usage mode and with code of which classification. The list is a register, in the sense of AI Platform and Security, Chapter 4: every tool is registered and its credentials are held by the platform, not by the developer (163, Nordqvist, 2026). A tool that is not on the list is shadow AI, and Chapter 21 treats how to handle it without turning it into a disciplinary matter.
2. Route. Tool traffic passes the AI gateway, which is a policy point outside the model. The route is what makes the other three defaults enforceable, because a tool that calls a model directly cannot be logged, budgeted or stopped by the platform. The OWASP list of risks for LLM applications names excessive agency and supply chain among its ten, which are the two risks that a route and an allow-list reduce (230, OWASP, 2025).
3. Logging and cost. The gateway records which team used which tool and model, and how much. What it records about the content of prompts is a separate matter with a legal and a labour dimension, and the record is kept by team and never per named developer unless a representative agreement says otherwise (Chapter 22). Cost is reported by team so that the cost of AI in development is visible next to the cost of the cloud.
4. Supply chain. The package proxy refuses names that are not in approved registries. At Hansa Mutual in March 2030 a coding agent in the Mode 3 pilot proposed a dependency whose name did not exist in the registry, and the proxy refused it (FND-HM-2030-0012). The review of agent runs afterwards found two further non-existent names proposed and rejected in the previous month, and that nobody had been told. The control worked and its output went nowhere. The golden path therefore needs a second half to the rule: an unknown package name is refused and reported to the owning team, so that the refusal is evidence and not only a block. Chapter 10 treats the toolchain as an attack surface. SLSA gives a vocabulary for levels of supply-chain assurance for build artefacts, and the NIST community profile for the Secure Software Development Framework adds practices for producers and acquirers of generative AI models and of the systems built on them (231, OpenSSF, n.d.) (233, Booth et al., 2024); the golden path is where a platform team can make a subset of those practices the default.

The gate that a change cannot alter

The Level 4 prohibitions of this book include a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, and a change to production without a gate that the change itself cannot alter. The platform team is the party that makes the second half of that sentence true in practice. A gate that lives in the repository it gates, editable by the same pull request, is not a gate that the change cannot alter. The golden path therefore places the definitions of the pipeline's gates in a repository or a protected configuration that the team's pull requests cannot change, with a code-ownership rule that names the platform lead, and the mandate of every coding agent states that it has no write access to them. This is the pattern of AI Platform and Security, Chapter 19, in which control artefacts sit outside the agent's reach (163, Nordqvist, 2026), applied to the pipeline. It follows that the platform team's own agent-drafted infrastructure code is subject to the same rule: Nordvik Region's platform engineers draft infrastructure code with agentic tools and never apply it, and Joakim Wester reviews most of it. Chapter 11 treats the release path in full.

What the platform team must not do

Three failures are common. The first is to make the golden path mandatory without an exception route, so that teams with a real need leave quietly, which is the situation the golden path was meant to prevent. The second is to put telemetry on the gateway and use it as a measure of named developers, which crosses a line that works councils and unions will draw (Chapter 22) and which would make the platform a surveillance instrument by default. The third is for the platform team to act as the test oracle for the services it hosts. The platform provides the scanner and the pipeline, and the oracle for a change (Chapter 9) must be independent of the generator and belongs to the team that owns the behaviour, with a tester where there is one.

Site reliability engineering (D5 Steward)

The site reliability engineer holds the budget that decides whether change may continue. The Google site reliability book describes the error budget as the allowance of unreliability that a service level objective leaves: while the measured service is within its objective, new releases can be pushed, and when violations use up the budget, releases are temporarily halted while the team improves the system's resilience (134, Alvidrez, 2017). The mechanism gives the developer and the reliability engineer a shared number and a rule agreed in advance, which is a better basis than an argument after an incident.

What generated change volume does to the budget

An assistant that makes it cheaper to write a change makes it cheaper to write a large change. The DORA programme's own reading of its 2024 finding on AI and stability is that the basics, small batch sizes and robust testing, are what carry delivery, and that a faster way of producing code does not replace them (221, Google Cloud, 2024). The conclusion this book draws, and which is its own, is that the error budget is the natural place to meet the consequence. If generated change raises the rate of failed or reverted changes, the budget is spent faster, the release halt applies, and the team's practice has to change. If it does not, the budget is the evidence that nothing needed to change, which is better than an opinion.

The step the book adds is to connect the budget to the delegation ladder. AI Operations, Chapter 4, gave the autonomy budget: the degree of delegation is set by the lowest of reversibility, blast radius, evidence and window, and errors consume the budget in the way an error budget is consumed (170, Nordqvist, 2026). For development, the rule is a policy of the service owner and the reliability engineer: when the service's error budget is spent, the degree of delegation for AI-originated change in that service drops by one level until the budget is restored, and any Level 3 Bounded class is suspended. This does not punish the tool or the team. It prevents a service that is already unreliable from receiving its change at the fastest and least examined route. The policy is recorded, has a named owner, and is itself a change to a delegation profile, so it is decided by the owner of the profile and not by the agent it constrains.

Who runs what was built

"You build it, you run it" is the subject of Chapter 11, which treats operating what a team builds when generated change volume has risen. Here the point is the handover between developer and reliability engineer. A service that is handed over for operation by a site reliability function should arrive with an owner who passes the Name test, a restore test or a stated absence of one, and a record of which parts of the service were generated. The reliability engineer may decline a handover and may hand a service back. That right is the reliability engineer's equivalent of the developer's right to Revert, and it needs to be written down in the operating model of AI Operations, Chapter 21, to be real.

Nordvik Region has no site reliability function. The platform team's seven engineers carry what a reliability function would carry, plus the golden paths, plus the AI gateway. The conclusion for Nordvik is not that it should create a function it cannot staff. It is that the platform lead's decision rights must be listed so that the error-budget rule, the exception route and the gate ownership have a holder, two deputies and a response time (AI Operations, Chapter 22), and that the team's capacity is stated as a constraint in the plan.

Boundaries and handovers

Who decides, who builds and who runs can be written as a table of decisions with a holder for each. The decisions below are the ones that recur between the developer and the three neighbours. The holder column gives the role, not the person, and each decision is recorded as an AI Decision Record or an ADR where it is consequential.

Decision	Decides	Builds	Runs or stops	Constraint
A cross-team interface, data location or irreversible platform commitment	Architect, in the design forum	Developer team	Platform team provisions, developer team owns	Routed by code-ownership rule on dependency, endpoint and permission files
Design within the constraints	Developer team	Developer team	Developer team	An architect is consulted on request, not by default
The default golden path and its AI tooling defaults	Platform lead, with the head of development accountable for use	Platform team	Platform team	Changes recorded; versions dated
An exception to the golden path	Platform lead and the head of development	The requesting team	The requesting team, with the platform team informed	Named approver and expiry date
Which assistant or agent may touch which code	Owner of the delegation profile	Platform team (registration, route)	Platform team can disable the route; owner can withdraw the mandate	A tool outside the register is not used; Level 4 never for changes to its own mandate
Definition of a pipeline gate	Platform lead	Platform team	Platform team	Not editable by the change it gates; no agent has write access
Error-budget policy and the level drop	Service owner with the reliability engineer	Reliability engineer	Reliability engineer	Recorded; applies to AI-originated change in the service
Stop and revert of a change in production	Named steward of the change	Developer team	Roles reachable out of hours, through a mechanism outside the pipeline	Revert tested; no penalty for exercising the right

The handovers between roles carry a small number of things, whichever organisation is concerned. A change leaves the developer team with an ownership record that names a person or team who can Name, Understand and Revert it. A request for an exception leaves the developer team with a reason and a proposed expiry, and returns with an answer and a date. A service arrives with the site reliability function with its objective, its restore evidence, and a statement of where generated code is present. An incident returns to the developer team with a post-incident review that treats the question of AI involvement as a fact to establish and not a reason to assign blame (Chapter 23).

Practical guide: Writing a golden-path specification with AI tooling defaults

Purpose. Turn the platform team's implicit defaults into a versioned artefact that states what the path contains, what AI tooling is allowed on it, who owns the gates, and how a team leaves it.

Roles. The platform lead (author and holder), the head of development or the engineering manager (accountable for use), an architect (reviews the seams), a site reliability engineer or the person who carries that duty (error-budget rule), a tester or quality engineer (oracle ownership), a data protection officer (logging of prompts), the works-council or union representative where telemetry is concerned, and a public-sector IT lead where the path serves a public authority.

Inputs. The delegation profile DLG-* that governs the teams on the path; the register of AI tools and their classification limits; the gateway's logging capability; the package proxy's configuration; the service's objective and error budget; any agreement with the representatives that covers tooling telemetry.

Steps.

1. Name the path, give it a version, and name its owner, the person accountable for use and the delegation profile that applies. Record the decision that adopted it.
2. List the gates of the pipeline and say who owns their definitions. State in the specification that no coding agent has write access to them, and enforce it with a code-ownership rule and with the agent's mandate.
3. List each AI tool allowed on the path with its usage mode, its route (the gateway, or a stated alternative with a reason), the functions it may perform and the classes of code it may not see.
4. State what the gateway records and what it does not. Where an agreement with representatives is still open, say that prompt content is not recorded until it is concluded, and name the agreement.
5. State the supply-chain rule: the registries allowed, and what happens to an unknown package name, including who is told.
6. Write the exception route: who may approve, how long the exception lasts, and what happens at expiry (the exception ends or becomes a default).
7. Write the error-budget rule: what is lowered, for whom and by how much when the budget is spent, and who restores it.
8. Set a review date, no later than the review date of the delegation profile, and say what evidence will be read at the review.

Artefact. A golden-path specification in version control, next to the template it describes.

Worked example: a golden-path specification at Nordvik Region

On 2030-11-18 the CIO, Henrik Dahl, recorded AIDR-1116. The decision concerned the Mode 2 pilot NR-DEV-001, which AIDR-1102 had continued until 2030-12-31 only. It said that any continuation after that date would run through the Region's AI gateway, that the platform team would publish version 2.0 of its Spring service golden path with the AI tooling defaults, and that the gateway would record metadata only. The same record raised the ceiling for the platform team's drafting of infrastructure code, which MND-NR-DEV-01 (AIDR-1108, October 2030) had set at Level 1 Assisted, to Level 2 Supervised from 2030-11-18: drafts only, never applied, each reviewed by a named engineer. The union's IT representative, Tomas Ekblad, had asked in June 2030 to negotiate before the pilot was extended, and the negotiation record MBA-NR-2030-03 on developer tooling and telemetry was open; the decision therefore left prompt content unrecorded until it concluded, and recorded that the Region's archivist and legal counsel had still to rule on whether prompts to coding tools are records under the public-access and archives rules. The specification, owned by the platform lead Maja Lindqvist and with the head of Applications and Integration, Gunilla Roos, accountable for use, read as follows (the values are illustrative):

golden_path:
  name: nr-spring-service
  version: "2.0"
  adopted: 2030-11-18
  decision: AIDR-1116
  owner: platform-team            # lead: Maja Lindqvist
  accountable_for_use: Gunilla Roos
  delegation_profile: DLG-NR-DEV-01
  review_due: 2031-05-18
pipeline:
  gate_definitions:
    location: platform-owned configuration repository
    code_owner: platform-lead
    agent_write_access: false     # no coding agent or assistant may change a gate
  oracle:
    owner: product-team           # the platform provides the runner, not the oracle
    generated_by_same_tool_as_change: not-allowed
ai_tooling:
  register:
    - id: NR-DEV-001
      mode: "Mode 2"
      model: self-hosted open-weight coding model on reserved capacity
      route: ai-gateway
      functions: [completion, chat]
      repository_wide_edits: false
  code_not_to_be_shared:
    - special-category data
    - credentials
    - benefits-triage rules
  unlisted_tools: not-used         # shadow AI is reported to the platform lead, not to line management
gateway_record:
  fields: [timestamp, team, repository, tool_id, model, token_count]
  per_named_developer: false
  prompt_content: not-recorded-until MBA-NR-2030-03 is concluded
supply_chain:
  package_proxy: approved-registries-only
  unknown_package_name: refuse-and-report-to-owning-team
exceptions:
  approver: [platform-lead, head-of-applications-and-integration]
  maximum_days: 90
  at_expiry: ends-or-becomes-default
error_budget:
  rule: "when the service budget is spent, AI-originated change in that service drops one level"
  restored_by: service-owner

The record had three effects that the specification makes visible. The pilot users kept their tool, and the platform team gained a route through which cost and use by team could be seen. The question the Region could not yet answer, whether prompts are records, was recorded as open and not settled by default. And the platform's own agent-drafted infrastructure code fell under the same gate rule as everyone else's. What the specification did not do is claim a benefit: the figure of "a third faster" in the note of April 2030 (AVR-NR-2030-01) remained a claim without an independent measure, and Chapter 20 returns to it.

Worked example: an error-budget rule for AI-originated change at Hansa Mutual

At Hansa Mutual the platform and the reliability function are separate and large, and their handover is a policy rather than a conversation. On 2031-01-20 the group CIO Rainer Lehmann, as owner of DLG-HM-DEV-01, recorded AIDR-1166 on a proposal from Lukas Frey of Hansa Forge and Tobias Richter of the site reliability function. It applied the error-budget rule to the customer portal SVC-HM-005, as a pilot for one service. The Level 3 Bounded class of DLG-HM-DEV-01, patch-level dependency updates under MND-HM-DEV-01, is the class most exposed to the rule: it is merged by the pipeline after a human approval of the class, so it is exactly the kind of change that a spent budget should slow. The rule read (values illustrative):

error_budget_policy:
  service: SVC-HM-005
  decision: AIDR-1166
  recorded: 2031-01-20
  owner: Rainer Lehmann            # owner of DLG-HM-DEV-01
  reliability_lead: Tobias Richter
  platform_lead: Lukas Frey
  objective: "availability, 28-day window; value set in the service level objective record"
  when_budget_remaining: positive
  when_budget_spent:
    level_drop:
      generate: "Level 2 Supervised to Level 1 Assisted"
      refactor: "Level 2 Supervised to Level 1 Assisted"
    suspended_classes:
      - "patch-level dependency updates under MND-HM-DEV-01 (Level 3 Bounded to Level 2 Supervised)"
    unchanged:
      - "two human approvals for production change in critical or important functions"
  restored_by: reliability_lead
  restore_condition: "budget positive and two consecutive releases without revert"
  record_to: Hansa Forge catalogue
  review_due: 2031-04-20

Three features of the rule matter. It lowers delegation by class and not by person, so nobody's performance is read from it. It leaves the existing human approvals in place, which the group's change policy requires for its critical or important functions; the policy sits within the ICT risk management of DORA (2, European Union, 2022). And it is a policy of the profile's owner, not of the agent it constrains. Whether the rule changes anything is a matter for the evidence that Chapter 20 describes: how often the budget is spent, which changes spent it, and whether AI-originated change is over-represented among them. The record does not claim an effect.

Across the degrees of delegation

The delegation profiles of the two organisations cover the developer's work classes. The three neighbours work on parts of the same classes and on classes that belong to AI Operations. The table shows the ceilings that the profiles and the decisions of this chapter set for the neighbours' work, and what stays forbidden at Level 4.

Work of the neighbour	Class	Nordvik Region	Hansa Mutual	Never at Level 4 Autonomous
Architect: options and structure for a design	design	Level 0 Advisory (DLG-NR-DEV-01)	Level 0 Advisory (DLG-HM-DEV-01)	A decision that commits the organisation across teams
Platform engineer: drafting infrastructure and pipeline code	generate	Drafts only, never applied; Level 2 Supervised under AIDR-1116, reviewed by a named engineer	Level 2 Supervised outside the security-critical and payment paths; Level 1 Assisted inside them	Any change to a pipeline gate, mandate, permission or credential
Platform engineer: patch-level dependency updates	generate, deploy	Not delegated	Level 3 Bounded under MND-HM-DEV-01; Level 2 Supervised when the service budget is spent	Production change without a gate the change cannot alter
Reliability engineer: release rule and restore	deploy, operate	Level 0; the pipeline deploys, the platform team operates	Level 0 Advisory under the developer profile; operations agents under the AI Operations profiles	Disabling the observation or the stop path; irreversible action on production data
Any of the three: appraisal of a named person	(people)	Not delegated	Not delegated	Always

Nordvik Region and Hansa Mutual

The two organisations show two shapes of the same neighbourhood. Nordvik Region has a platform team of seven that carries the golden paths, the gateway, the package proxy and, in effect, the reliability duties, with an enterprise architect and an AI architect who are few. The risk is concentration: the same small group writes the gates, reviews the agent-drafted infrastructure code, runs the gateway and carries the error-budget rule. What the Region can do is to put the decisions in writing (AIDR-1116), to put the pilot behind the gateway it already runs, and to keep prompt content out of the logs until the negotiation with the union and the archival question are settled. Hansa Mutual has the capacity to separate the roles, and the risk is the reverse: with 24 people in Hansa Forge, a separate AI platform team and a reliability function of about 95, the question is whether the decisions are made once. Its rule of AIDR-1166 is an attempt to connect three functions with one number, and it applies at first to a single service.

Neither organisation has yet measured whether its golden path, its gateway or its error-budget rule changes delivery. Both can say what the path contains and who owns it. That is a smaller claim than "the platform governs AI tooling", and it is the claim this chapter can support.

Summary

This chapter concerned D2 Design and D5 Steward and the three neighbours whose decisions bound the developer's work. The architect keeps the constraints that cross team boundaries and the commitments that are hard to reverse, and the developer keeps design inside them; a tool that proposes a dependency, an endpoint or a permission has proposed an architectural change, and a code-ownership rule on those files routes it to the architect's forum. The platform team, in the X-as-a-Service mode, is the right place to turn the decisions about AI tooling into defaults: an allow-list, a route through the gateway, logging by team, a supply-chain rule that reports a refusal as well as making it, and gate definitions that the change cannot alter. The reliability engineer holds the error budget, and the book's own conclusion is that the budget should be connected to the delegation ladder, so that a spent budget lowers the level for AI-originated change in that service.

The evidence is thin and the chapter has said so. The research programme's 2024 report associates AI adoption with estimated decreases of 1.5 per cent in throughput and 7.2 per cent in stability, with the basics of small batches and robust testing as the stated remedy, and associates internal developer platforms with improved productivity and a possible temporary dip; neither organisation has measured its own. The golden-path specification of Nordvik Region (AIDR-1116) and the error-budget policy of Hansa Mutual (AIDR-1166) are artefacts a reader can adopt, not evidence that they work.

The stewardship principle applies at every handover: a change leaves the developer team with a named owner who can Name, Understand and Revert it, an exception expires, and a service reaches the reliability function with its restore evidence and a statement of where code was generated. Chapter 17 turns from the neighbours who build and run to those who test and shape: testers, quality engineers, product owners and designers, and the question of who owns the oracle when everyone can build a prototype.

Sources

1. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
2. Skelton, M. & Pais, M. (2025). Team Topologies: Organizing Business and Technology for Fast Flow of Value, 2nd edition. IT Revolution Press. (41, Skelton & Pais, 2025)
3. Conway, M. E. (1968). How Do Committees Invent? Datamation, April 1968. (77, Conway, 1968)
4. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
5. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
6. Nordqvist, G. (2026). AI Platform and Security. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
7. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
8. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
9. Google Cloud, DORA (2024). Accelerate State of DevOps Report 2024. DevOps Research and Assessment (DORA) programme. (216, Google Cloud, 2024)
10. OWASP Gen AI Security Project (2025). OWASP Top 10 for LLM Applications 2025. (230, OWASP, 2025)
11. Open Source Security Foundation and Linux Foundation. SLSA specification. (231, OpenSSF, n.d.)
12. Booth, H., Souppaya, M., Vassilev, A., Ogata, M., Stanley, M. & Scarfone, K. (2024). Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile. NIST SP 800-218A. (233, Booth et al., 2024)
13. Google Cloud (2024). Announcing the 2024 DORA report. (221, Google Cloud, 2024)
14. Niemen, G. (2020). How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem. Spotify Engineering. (133, Niemen, 2020)
15. Alvidrez, M. (2017). Embracing Risk. Chapter 3 in Site Reliability Engineering: How Google Runs Production Systems. (134, Alvidrez, 2017)