The service ownership model decision record: why the on-call rotation you chose determines your knowledge concentration surface and your incident response latency

A 47-person SaaS company had built their payment processing service over two years through contributions from six backend engineers, two of whom had written the initial implementation and remained its primary maintainers. The service handled all payment capture, refund processing, and subscription renewal for the company's 8,400 active accounts. The on-call rotation was managed in PagerDuty using a round-robin schedule across the six backend engineers — all six rotated equally, with seven-day shifts and a two-week gap between each engineer's turns. The rotation was established during a team planning session in the company's second year when the backend team grew from two to six engineers. The session established equal rotation as the fairness standard — everyone covers the same number of on-call weeks. It did not establish a knowledge requirement — the assumption was that all six backend engineers could handle any backend service, and that runbooks would guide engineers through service-specific procedures they had not encountered before.

On a Tuesday at 2:17 AM, PagerDuty fired a P0 for the payment service. The alert was: payment-capture: error rate above 5% (current: 23%, threshold: 5%, window: 5m). The on-call engineer who received the page had been with the company for eight months. Her primary work had been on the analytics service and the data pipeline — she had opened one PR against the payment service in her entire tenure, a minor logging change in month three. She had not worked in the payment service's codebase since month three. She had never been on call during a payment service incident. She opened PagerDuty, acknowledged the alert, and went to the company's runbook repository in Confluence. The payment service had eleven runbooks. She could not determine from the runbook titles which one applied to the current alert — the alert named the payment-capture service, and the runbooks were named by symptom rather than by service component. She spent 8 minutes reading runbook titles and opening the three that seemed relevant before finding the runbook for "High error rate on payment capture endpoint." The runbook's step one was: verify which error type is dominant by querying the payment service's error rate dashboard. She opened the observability platform and discovered the payment service had five dashboards, each maintained by a different engineer over the past two years with different panel naming conventions. She spent 7 minutes identifying which dashboard was the primary on-call dashboard for the payment service. By the time she had located the correct dashboard and identified the error type (a timeout cascade from the payment gateway's secondary endpoint returning 504s), 19 minutes had elapsed from the initial page. She followed the runbook's diagnostic steps and identified the likely cause at 2:36 AM — 19 minutes after the page, 34 minutes after the error rate threshold crossed. The remediation (rerouting traffic from the secondary endpoint to the primary endpoint via a configuration change) took 4 minutes to execute. The incident closed at 2:40 AM. Total duration from first failed payment to remediation: 47 minutes. 3,200 active payment sessions had failed during the window — either returning errors to users or timing out and requiring retry. The founding session that established the on-call rotation documented "round-robin rotation across six backend engineers" — it did not specify that payment service primary on-call requires hands-on service familiarity, that engineers without recent payment service contributions require a shadow rotation before being eligible for payment service primary, or that the on-call rotation should be separate from the analytics-and-pipeline rotation for engineers whose primary domain is not the payment service.

A 35-person marketplace platform had adopted a runbook-first incident response culture in their second year after a string of incidents where engineers relied on tribal knowledge that wasn't available at 2 AM. They maintained runbooks in Confluence, tagged by service and symptom. Each runbook was owned by the engineer who wrote the feature it documented. The ownership assignment was made explicit: each runbook's Confluence page had an "Owner" field set to the engineer's name. The ownership model did not specify a handoff procedure when the owner left the company, a staleness trigger when the system the runbook documented changed, or a review cadence to catch runbooks that had drifted from the current system state. The implicit assumption was that the runbook owner would update the runbook when they changed the system — a reasonable assumption that decoupled silently whenever a component the runbook documented was changed by a different engineer who was not the runbook owner.

The marketplace's payment gateway had a runbook titled "Payment gateway timeout cascade — diagnosis and recovery." The runbook was written 14 months before the incident by the engineer who had designed the payment gateway integration. At the time of writing, the integration used Hystrix for circuit breaking between the marketplace application and the payment gateway's API. The runbook's step 4 read: "Reset the Hystrix circuit breaker for the payment gateway by executing: curl -X POST http://hystrix-dashboard.internal/streams/reset/payment-gateway. If the circuit is in OPEN state, this transitions it to HALF-OPEN, allowing a limited number of test requests through." Eleven months before the incident, the engineering team replaced Hystrix with Resilience4j during a dependency modernization that eliminated seven deprecated libraries. The Resilience4j implementation provided equivalent circuit breaker functionality but with a different dashboard and a completely different management API. The Hystrix dashboard was decommissioned. The runbook owner had left the company in month 7 of the 14-month gap. The Confluence "Owner" field still showed the departed engineer's name. No engineer who participated in the Hystrix-to-Resilience4j migration had checked the runbook's content against the new implementation — the migration PR did not require a runbook review, and no one thought to check whether any runbook referenced Hystrix commands specifically.

At 11:22 PM on a Friday, the on-call engineer received a P0 for "Payment gateway timeout cascade: error rate 31%." He opened the payment gateway timeout runbook — the correct runbook for the symptom. He executed steps 1 through 3 without issue: they involved reading metrics from Grafana and identifying the circuit breaker state. Step 3 confirmed the circuit was in OPEN state due to excessive consecutive timeouts from the payment gateway's API. Step 4 directed him to reset the Hystrix circuit breaker via the command above. He executed the curl command. The curl returned a connection refused error — the Hystrix dashboard was decommissioned and hystrix-dashboard.internal did not resolve. He spent the next 7 minutes checking whether the URL was correct, whether the Hystrix dashboard was temporarily down, and whether there was an alternative URL. He found no Hystrix dashboard anywhere in the infrastructure. He searched Slack for "Hystrix" and found a thread from 11 months ago announcing the migration to Resilience4j. He searched Confluence for Resilience4j circuit breaker management. He found a wiki page titled "Resilience4j integration notes" that contained the correct management API endpoint. He executed the Resilience4j circuit breaker reset at 11:40 PM — 18 minutes after first attempting step 4. The circuit breaker transitioned to HALF-OPEN, test requests succeeded, the circuit transitioned to CLOSED, and the error rate dropped to baseline within 2 minutes. Total incident duration from alert to recovery: 20 minutes of actual diagnostic work, plus 18 minutes of runbook navigation delay caused by stale documentation. 4,700 marketplace transactions had timed out during the 20-minute window from alert to the Hystrix step, with an additional 1,800 timing out during the 18-minute Hystrix gap before the Resilience4j reset was found and executed. The founding session that established the runbook ownership model documented "runbook owner = feature author, owner maintains the runbook" — it did not specify that runbook currency must be maintained by the team responsible for changes to the documented system, that every code change to a service's critical paths must include a runbook review for all runbooks that reference the changed component, or that a runbook whose owner has left the company must be transferred to a new owner before their final day.

A 56-person SaaS company managed five production services that all shared a single PostgreSQL primary instance: the user service, the billing service, the payment service, the notification service, and the analytics service. The shared database had been established in year one when the company had 12 engineers and a single database was the operationally simplest choice. The company had grown to 56 engineers and five distinct engineering teams in three years, each responsible for one service. Each service had an independently negotiated SLA with the head of engineering — a monthly uptime target expressed as a percentage, enforced through a reliability budget tracked in a shared spreadsheet. The payment service's SLA was 99.9% (maximum 43.8 minutes downtime per month). The billing service's SLA was 99.95% (maximum 21.9 minutes). The three remaining services had 99.5% SLAs (maximum 3.6 hours downtime per month). The SLA targets were set during a planning session that reviewed each service's criticality and established the on-call response requirements for each tier. The session did not address the shared database's impact on each service's reliability budget — the assumption was that each service team was responsible for its own availability, and shared dependencies were a background constraint that engineering would manage centrally.

In April, the infrastructure team scheduled a planned PostgreSQL primary maintenance window for version upgrade — a 2-hour window on a Wednesday from 10:00 AM to 12:00 PM UTC. The maintenance involved promoting the read replica to primary and executing the version upgrade with a brief read-write unavailability window estimated at 15 to 25 minutes. All five service teams were notified 7 days in advance. Two teams objected to the timing and requested the window be moved to a weekend night. The infrastructure team assessed the operational risk of a weekend maintenance versus a weekday maintenance (fewer engineers available for immediate escalation on weekends) and kept the Wednesday window, offering an extended standby rotation during the maintenance. The maintenance proceeded on schedule. The actual read-write unavailability was 28 minutes — slightly longer than estimated due to a replication lag at promotion time. During the 28-minute window, all five services returned database connection errors to users. All five services had their PagerDuty alerts suppressed by the maintenance window annotation for the planned 2-hour window, but the suppression did not distinguish between the expected unavailability during the 28-minute migration window and unexpected additional failures after the migration completed. Three of the five services had on-call engineers manually available during the maintenance — the payment service, the billing service, and the user service teams had engineers watching dashboards per the maintenance runbook. The notification and analytics service teams had no engineers actively monitoring during the window, trusting the infrastructure team's standby rotation.

When the month's reliability report was computed, all five services showed the 28-minute unavailability counted against their monthly error budget. The payment service had consumed 28 of its 43.8 monthly minutes — 64% of its error budget — from a single planned maintenance window that its team could not prevent, could not mitigate beyond their active monitoring presence, and had accepted under the notification and standby conditions the infrastructure team provided. The billing service had consumed 28 of its 21.9 monthly minutes — 128% of its monthly budget, exceeding the SLA for April before the month was half over. The billing team escalated to the head of engineering: their SLA was in breach due to an infrastructure action they had not authorized. The infrastructure team countered that the billing team had been notified, had the opportunity to object, and had accepted the window. The billing team countered that their acceptance was not informed by the impact on their reliability budget, because the SLA policy did not specify whether planned infrastructure downtime was excluded or included in the reliability calculation. The head of engineering spent the following two weeks gathering data, consulting the original SLA planning session notes, and drafting an attribution policy. The policy that emerged: planned infrastructure maintenance windows that meet the advance notification and service team objection criteria are excluded from individual service reliability calculations and attributed to a shared infrastructure reliability budget. Unplanned shared infrastructure failures are attributed to the shared infrastructure budget, not to individual service budgets. The retroactive application of this policy to April's maintenance cleared the billing service's breach. The founding session that established SLA targets documented the per-service percentage targets and the on-call response tier requirements — it did not specify the attribution model for planned infrastructure downtime, the definition of a qualifying objection that would compel the infrastructure team to change the maintenance window, or the shared infrastructure reliability budget that absorbs planned maintenance and unplanned shared failures.

Structural properties set by the service ownership model decision

Three structural properties are determined when a team establishes their service ownership model. None appear explicitly in the session that assigns an on-call rotation, the session that creates the first runbook, or the session that negotiates SLA targets — they are the operational consequences of design choices made under the assumption that "service ownership" means "the team responsible for this service is on call, maintains the runbooks, and is accountable for the SLA" without specifying the eligibility requirements, coupling rules, and attribution boundaries that make each commitment operationally meaningful.

Property 1: The on-call rotation assignment and the knowledge concentration surface. An on-call rotation assigns a named engineer to be the first responder for a service's P0 and P1 incidents during a defined time window. The quality of the first response — how quickly the engineer can identify the failure mode, locate the correct diagnostic tool, execute the relevant runbook steps, and determine whether they can resolve the incident independently or must escalate — depends on the engineer's familiarity with the service's architecture, failure modes, and runbook structure. An engineer who has contributed to the service within the preceding 90 days has a current mental model of the service's code paths, dependency versions, configuration keys, and diagnostic tools. An engineer whose last contribution to the service was 14 months ago has a mental model that has diverged from the current implementation in proportion to the rate of change in the service during that period — and the divergence is invisible in the rotation schedule. The knowledge concentration surface is the gap between the incident response capability assumed by the rotation schedule (equal competence across all rotation members) and the actual incident response capability available (concentrated in the subset of rotation members with current service knowledge). The surface area of this gap grows as the rotation includes engineers whose service familiarity has decayed below the threshold needed for independent incident resolution, and it is exposed whenever a P0 or P1 lands on a rotation member in the unfamiliar subset. The knowledge eligibility requirement is the structural mechanism that closes the gap: only engineers who meet the eligibility criterion — a recent contribution window or a completed shadow rotation sequence — are placed in a service's primary on-call rotation. Engineers who do not meet the criterion for a given service may be placed in a secondary on-call role (escalation target) without being in the primary rotation for that service, and may be primary for services where they do meet the criterion. The incident response playbook decision record documents the escalation paths that supplement the primary on-call rotation — when the primary on-call engineer cannot resolve an incident independently within a defined time window (typically 15 minutes for a P0), the escalation path must route to an engineer who has current service knowledge, not to the next person in the round-robin rotation regardless of their service context. The observability strategy decision record documents the on-call dashboard specification — the single dashboard that every primary on-call engineer for a service uses as the starting point for incident diagnosis, with a documented structure that a new rotation member can navigate without service-specific expertise, reducing the diagnostic gap for engineers who are at the edge of the knowledge eligibility threshold.

Property 2: The runbook ownership and the staleness trigger. A runbook is a document that enables an on-call engineer to diagnose and resolve a known failure mode without relying on knowledge they may not have. The runbook's value is proportional to its currency — the degree to which its steps reflect the current state of the system it documents. A runbook's currency decays whenever a component it references is changed and the runbook is not updated. The decay rate is a function of how frequently the documented system changes and how tightly the change process is coupled to runbook review. The staleness trigger is the mechanism that couples the change process to the runbook review. The most reliable staleness trigger is a PR requirement: when a code change modifies a component (a library, a configuration key, an external API client, a database schema migration, a service endpoint) that is referenced in any runbook, the PR must include a runbook review step that confirms whether any runbook step references the changed component and, if so, updates the runbook before the PR is merged. This requires that runbooks be indexable by component — a tag or metadata field that lists the libraries, configuration keys, and service components each runbook references — and that the PR workflow surface this index to the PR author and reviewer. The supplementary staleness trigger is a maximum review interval: any runbook that has not been reviewed (either updated by a coupled code change or explicitly confirmed as current) within a defined interval is marked as potentially stale and the owning team receives a review reminder. The maximum interval should be shorter for runbooks covering services that change frequently and longer for stable services — a reasonable range is 3 months for actively-developed services and 12 months for stable services. The runbook transfer protocol is the staleness trigger for personnel changes: when a runbook owner leaves the company or transfers to a different team, the runbook ownership must be transferred to a new owner before the departure date, and the incoming owner must review the runbook's current accuracy before accepting ownership — the transfer is an opportunity to catch staleness that accumulated under the previous owner. The documentation strategy decision record documents the runbook format and the component tagging taxonomy — the fields in each runbook's metadata that identify which service components the runbook covers, the maximum review interval for each runbook tier, and the review history that shows when each runbook was last verified as current and by whom. The CI/CD pipeline decision record documents the pipeline integration for the runbook staleness check — the CI step that queries the runbook index for the components changed in the current PR and surfaces the list of runbooks requiring review to the PR author, creating a merge gate that prevents a code change from making a runbook stale without a corresponding review.

Property 3: The reliability target and the shared infrastructure attribution model. A service reliability target expressed as a monthly uptime percentage is an accountability instrument — it defines the maximum unavailability that the service team is responsible for, and it determines the error budget that the team consumes when the service is unavailable. The accountability instrument works correctly when unavailability is caused by factors within the service team's control: their code, their configuration, their deployment decisions, their on-call response time. It produces incorrect accountability when unavailability is caused by factors outside the service team's control: planned infrastructure maintenance windows that affect the service, unplanned failures of shared dependencies that the service team has no authority to resolve, and regional infrastructure failures (cloud provider outages) that no team at the company controls. The attribution model specifies which unavailability causes count against the service's reliability target and which are absorbed by a separate shared infrastructure budget. For planned infrastructure maintenance, the attribution model must specify the qualifying conditions for exclusion: minimum advance notice to the service team (typically 5 business days), a genuine opportunity for the service team to object and have their objection considered (with the infrastructure team obligated to provide a rationale if they reject the objection rather than simply noting that no objection was received), and the maintenance completing within its scheduled duration (overruns beyond the scheduled window are attributed to the infrastructure team's execution, not to the planned maintenance category). For unplanned shared infrastructure failures, the attribution model must specify how the downtime is partitioned: a shared database failure affects all dependent services simultaneously, but each service team had a different mitigation option available (some services can degrade gracefully to a read-only mode backed by a replica, others have no fallback and must return errors). Services that had a viable mitigation but did not implement it absorb a portion of the downtime in their reliability target; services that had no viable mitigation and followed the escalation procedure correctly attribute the downtime to the shared infrastructure budget. The shared infrastructure reliability budget is a first-class tracking instrument maintained by the infrastructure team, separate from each service team's individual budget, with its own SLA target that determines the acceptable downtime for the shared database, cache cluster, and message broker. The database connection pooling decision record documents the degraded-mode operation for each service — whether the service can serve a read-only or reduced-functionality mode when the shared database primary is unavailable, using the replica, a local cache, or a static fallback — and the decision about whether implementing this fallback is within the service team's reliability budget ownership or within the infrastructure team's shared reliability budget. The multi-region deployment decision record documents the regional failure attribution model — when a cloud provider's regional outage affects all services in a region, the attribution is to a regional infrastructure event rather than to individual service reliability targets, with the caveat that services that had cross-region failover implemented and tested absorb a smaller portion of the regional failure's impact than services that had no cross-region failover.

What the founding session records and what it omits

The founding service ownership session typically records the team assignment for each service (which engineering team "owns" the service), the on-call rotation schedule (who covers which weeks, at what response time SLA, with what escalation path), and the documentation requirement (runbooks must exist for each known failure mode, stored in a designated location). It may record the rationale for the ownership model — dedicated service teams versus a platform model, the on-call response time tier that matches the service's criticality, the runbook format standard. What it does not record is the knowledge eligibility requirement: the specific criteria that must be met before an engineer is placed in a service's primary on-call rotation, the shadow rotation sequence for engineers who are new to the service, and the decay model that determines when an engineer who has not contributed to the service for a defined period must complete a re-qualification step before returning to primary rotation. Without the eligibility requirement, the rotation schedule accumulates engineers whose service familiarity has decayed — the rotation is fair in the sense of equal burden but not in the sense of equal capability, and the capability gap is only visible when an incident reveals it. What it also does not record is the runbook staleness trigger: the specific mechanism that couples code changes to runbook currency, the component tagging taxonomy that makes runbooks queryable by the components they reference, and the runbook transfer protocol that prevents ownership orphaning when engineers leave or teams restructure. Without the trigger, runbook currency decays silently at the rate of system change, and the on-call engineer who follows the stale runbook during a P0 at 11 PM is simultaneously resolving an incident and performing an archaeology exercise to determine which parts of the runbook still reflect the current system. And what it does not record is the shared infrastructure attribution model: the qualifying conditions for planned maintenance exclusion, the partition model for unplanned shared failures, and the shared infrastructure reliability budget that absorbs the costs that individual service budgets should not bear. Without the attribution model, planned maintenance windows produce reliability budget disputes two weeks after the window, consuming engineering leadership time on attribution arguments that a documented model would have resolved automatically.

The on-call rotation omission compounds with the organization's growth. In a team of six where all six engineers have contributed to all services in the past 90 days, the round-robin rotation is essentially correct — all rotation members have current service knowledge and the eligibility requirement is implicitly satisfied. In a team of six where two engineers are the primary maintainers of the payment service and four engineers' last payment service contribution was over a year ago, the round-robin rotation is correct in appearance and incorrect in substance. The gap between appearance and substance is invisible in the rotation schedule and is first apparent in the incident that routes the P0 to an engineer who cannot navigate the service without a 34-minute orientation overhead. The eligibility requirement makes the gap visible before it causes an incident: the rotation assignment process computes eligibility for each engineer and each service, identifies which engineers are not currently eligible for which services, and produces a rotation schedule that respects the eligibility constraints. The eligibility computation requires two inputs — the list of engineers in the rotation pool and the contribution history for each service — both of which are available from the code repository and the team's project management system. The shadow rotation sequence provides the qualification path for engineers who are not currently eligible but who the team wants in the primary rotation — the sequence is a defined investment (two on-call weeks as secondary, at least one observed P0 or P1) that converts an ineligible engineer to an eligible one. The infrastructure as code decision record documents the on-call rotation configuration as code — the PagerDuty schedule definition stored in a repository alongside the service code, versioned, reviewed, and updated through the same PR workflow as service changes — making the rotation's eligibility criteria reviewable and auditable rather than configured only in the PagerDuty dashboard where they are invisible to the service team's normal code review workflow.

The runbook staleness omission is a confidence failure: teams that maintain runbooks assume that the runbooks are accurate because the culture of runbook-first incident response creates a social norm that runbooks should be kept up to date. The norm is real but insufficient. The norm does not specify who is responsible for updating a given runbook when a given component changes, and without that specificity, the responsibility defaults to "whoever remembers to check" — which in practice means "no one" for the majority of component changes that are handled by engineers who are not the runbook owner and who do not think to search the runbook repository for references to the component they just changed. The coupling rule converts the norm into a mechanism: the PR review template includes a checkbox labeled "I have searched the runbook repository for references to all components changed in this PR and updated or confirmed currency of any runbooks that reference them." The checkbox is a lightweight prompt that does not require the PR author to maintain the runbook themselves — they may tag the runbook owner for an update, which is an explicit communication that produces a runbook review, as opposed to the silent non-communication that produces staleness. The audit log decision record documents the runbook change audit trail — the log of who reviewed or updated each runbook, when, and in response to which code change or review cycle — which provides the evidence base for identifying runbooks that have not been reviewed in proportion to their system's change rate, and for determining whether a runbook's currency claim in its metadata is supported by actual review activity or is a stale timestamp from the last time anyone thought to update it.

The reliability attribution omission is a governance failure that manifests as a leadership escalation. The head of engineering spends two weeks on an attribution dispute that a one-page policy would have resolved in two minutes at the time of the incident. The policy itself is not complex — planned infrastructure maintenance with advance notice and objection opportunity is excluded; unplanned shared failures are attributed to the shared infrastructure budget; individual service teams absorb failures within their control — but drafting the policy after the dispute has occurred means drafting it in the context of a specific incident where one team's interpretation favors their position and the other team's interpretation favors theirs. The pre-written policy drafted during the founding SLA session has the advantage of being drafted without a specific incident to color the interpretation, and it is available to all parties at the moment of the incident as an authoritative reference rather than as a negotiation artifact. The API gateway decision record documents the service boundary definition that determines what is "within the service's control" for attribution purposes — the API gateway is the boundary between the service's responsibility and the shared infrastructure's responsibility; failures at the gateway or below it are attributed to shared infrastructure; failures above the gateway in the service's own code or configuration are attributed to the service team. The background job infrastructure decision record documents the attribution model for batch job failures that occur during a shared infrastructure window — a background job that fails because the shared database was unavailable during a maintenance window is attributed to the shared infrastructure event, not to the job's owning service, provided the job's retry logic followed the documented retry protocol and the failure was caused by the unavailability rather than by a bug in the job itself. The WhyChose decision extractor finds the founding service ownership sessions in your ChatGPT and Claude export — the "how should we structure on-call?" planning session, the "who owns this runbook?" infrastructure discussion, the "what SLA should each service have?" negotiation session. It extracts the on-call rotation model, the runbook ownership assignment, and the SLA targets from the founding sessions and surfaces the knowledge eligibility requirement, the staleness coupling rule, and the shared infrastructure attribution model that the sessions documented versus the ones they omitted — the decisions that determine whether a P0 at 2 AM reaches an engineer who can navigate the service in 5 minutes or one who needs 34 minutes to find the right dashboard.

The five ADR sections for a service ownership model decision

Section 1: Service ownership boundaries and team assignment. Specify which team is the designated owner for each service and what ownership entails: primary on-call responsibility (the owning team provides the primary on-call rotation), runbook authority (the owning team is responsible for the currency and completeness of the service's runbooks), reliability accountability (the owning team is accountable for the service's reliability target and error budget consumption), and change authority (significant changes to the service's architecture, dependencies, or SLA targets require sign-off from the owning team's lead). Specify the shared ownership model for services that multiple teams contribute to: the primary owner is responsible for the ownership commitments above; contributing teams may have engineers in the rotation (subject to the knowledge eligibility requirement) and must follow the runbook coupling rule for code changes they make to the service. Specify the ownership transfer protocol: when the designated owning team changes (due to a reorganization, a service transfer, or a team dissolution), the transfer must include a knowledge transfer period (minimum 4 weeks during which both old and new teams are jointly responsible), a runbook review by the incoming team that confirms currency and accuracy, and an on-call shadow rotation by the first incoming engineer who will be in the primary rotation before they take a solo shift. The infrastructure as code decision record documents the service catalog — the machine-readable file that records the owning team for each service, the on-call rotation configuration, and the runbook index — which is the authoritative source queried by the on-call rotation eligibility check, the runbook staleness CI gate, and the reliability reporting system.

Section 2: On-call rotation policy and knowledge eligibility requirements. Specify the knowledge eligibility requirement for each on-call rotation tier: the criterion an engineer must meet before being placed in a service's primary on-call rotation (recent contribution window: merged at least one PR to the service's production code paths within the preceding 90 days; or shadow sequence completion: served as secondary on-call for the service for at least two complete on-call weeks with at least one P0 or P1 incident observed end-to-end). Specify the secondary on-call role: an engineer who does not meet the primary eligibility criterion for a service may serve as secondary on-call (escalation target, not the first responder), and serving as secondary is one of the two paths to primary eligibility. Specify the re-qualification requirement: an engineer who was previously eligible for primary on-call but has not contributed to the service within the eligibility window must complete either a new contribution (a PR to the service's production code paths within the eligibility window) or a re-shadow sequence (one complete on-call week as secondary with at least one observed incident) before being restored to primary rotation. Specify the rotation schedule review cadence: the eligibility calculation is run before each rotation schedule update (typically quarterly) and any engineer who does not currently meet the primary eligibility criterion is moved to secondary for services where they are ineligible. The review output is a schedule that respects eligibility constraints and produces a primary rotation whose members can resolve the service's known failure modes without escalation. The incident response playbook decision record documents the escalation policy that supplements the primary on-call rotation — the escalation chain for incidents that the primary on-call engineer cannot resolve independently within a defined window, the communication protocol for multi-team incidents where the shared infrastructure is involved, and the post-incident review requirement for P0s that exceeded their target time-to-resolution.

Section 3: Runbook ownership, currency, and the staleness coupling rule. Specify the runbook ownership model: each runbook is owned by the team that owns the service it documents, not by the individual engineer who wrote it. The owning team is collectively responsible for the runbook's currency and accuracy, and the team lead is accountable for the runbook meeting the staleness criteria. Specify the component tagging requirement: every runbook must include a metadata section that lists all libraries (by name and version range), configuration keys, external API clients, database tables, and service endpoints that appear in any runbook step. The component tags are the input to the CI staleness gate. Specify the staleness coupling rule: any PR that changes a component (library upgrade, configuration key rename, API client replacement, schema migration, service endpoint change) must include a runbook review step — the PR author searches the runbook repository for runbooks whose component tags include the changed component and either updates the relevant runbook steps or confirms that the change does not affect the runbook's accuracy. A PR that changes a tagged component without a runbook review attestation fails the CI staleness gate. Specify the maximum review interval: every runbook must be explicitly reviewed (confirmed current or updated) within a maximum interval — 90 days for services with weekly code changes, 180 days for services with monthly code changes, and 365 days for stable services with infrequent changes. A runbook past its review interval is marked as potentially stale in the runbook repository and the owning team receives a review reminder. Specify the runbook transfer protocol for personnel changes: the owning team's lead is responsible for ensuring that every runbook whose individual contact is a departing engineer is transferred to a remaining team member with a review of current accuracy before the engineer's final day. The documentation strategy decision record documents the runbook format standard — the required sections (symptom, preconditions, diagnostic steps, remediation steps, escalation paths, component tags, review history), the storage location, the search and tagging interface, and the review history format that shows when each step was last verified.

Section 4: Service reliability target definition and shared infrastructure attribution. Specify the per-service reliability targets as monthly uptime percentages and their corresponding error budgets in minutes of allowed downtime per month. Specify the exclusion conditions for planned infrastructure maintenance: the maintenance must meet all of the following to be excluded from a service's reliability calculation — a minimum 5 business days advance notice to the service's owning team, a documented opportunity for the owning team to object with a rationale that the infrastructure team must respond to (objection does not guarantee window change but requires acknowledgment and reasoned response), maintenance completing within the scheduled window duration (overruns beyond the scheduled window are not excluded), and a maintenance justification that is recorded in the shared infrastructure change log for audit purposes. Specify the shared infrastructure reliability budget: a separate reliability tracking instrument maintained by the infrastructure team that records all planned maintenance windows and unplanned shared infrastructure failures, the duration of each, and the dependent services affected. The shared infrastructure budget has its own monthly availability target. Specify the unplanned shared failure attribution model: for each shared infrastructure component, the failure attribution specifies whether dependent services absorb a portion of the downtime in their individual budgets (for failures where the service team had a viable mitigation that they chose not to implement) or attribute it to the shared infrastructure budget (for failures where no viable mitigation existed within the service team's authority). The attribution determination for each incident is made by the infrastructure team and the affected service teams jointly within 5 business days of the incident, using the attribution model as the reference. Specify the reliability reporting cadence: a monthly reliability report published by the infrastructure team that shows each service's reliability against target, with planned and unplanned unavailability attributed to service-owned, shared-infrastructure, and regional-infrastructure categories separately. The observability strategy decision record documents the uptime calculation method — the metrics queries that determine service availability (the percentage of time the service's health check returns HTTP 200, or the percentage of requests that return non-5xx responses, depending on the service's primary metric for user-facing availability) and the tooling that computes the monthly budget consumption automatically from these metrics.

Section 5: Ownership transfer protocol and team restructuring policy. Specify the ownership transfer procedure for planned transfers (service ownership change due to product strategy, team reorganization, or service consolidation): a minimum 8-week transfer period during which the outgoing and incoming teams are jointly responsible, a joint runbook review by both teams during the transfer period that identifies and resolves staleness before the incoming team takes sole responsibility, and a shadow on-call rotation where at least two incoming team engineers complete the primary eligibility shadow sequence before the outgoing team is removed from the rotation. Specify the ownership transfer procedure for unplanned transfers (outgoing team is dissolved without a planned transfer period): the infrastructure team acts as interim owner, the service is immediately added to the technical risk register, and an ownership assignment is made within 2 weeks. Specify the reorganization policy: when engineering teams are restructured, a service ownership audit is conducted before the reorganization is complete — every service's owning team is confirmed or transferred as part of the reorganization process, not discovered to be unowned after the reorganization is complete. Specify the orphaned service protocol: a service with no owning team is flagged in the service catalog as orphaned, all on-call rotation for the service is transferred to a shared services on-call rotation, and a decision is made within 30 days to either assign ownership to an existing team, merge the service into an owned service, or deprecate the service. The API gateway decision record documents the service catalog registration requirement — every service that is externally reachable through the API gateway must have an owning team registered in the service catalog before the gateway route is activated, enforced by a gateway configuration validation step that checks the service catalog for an owning team entry before approving the route configuration PR. The audit log decision record documents the ownership change audit trail — every ownership assignment, transfer, and team restructuring that affects service ownership is recorded with the date, the reason, the outgoing owner, the incoming owner, and the status of the knowledge transfer steps (runbook review completed, shadow rotation completed) — so that the ownership history of any service is auditable without relying on Slack threads or meeting notes from the reorganization.