{
  "schema_version": 1,
  "skill_name": "production-excellence",
  "evals": [
    {
      "id": "normal-release-safe-launch",
      "prompt": "We are launching a new user-facing API service to production. The readiness review is complete with all 11 evidence categories sourced: ownership is assigned to the API platform team, SLOs are defined (99.9% availability, p99 latency < 200ms), security review passed, rollback plan uses blue-green deployment, capacity model shows 3x headroom at launch, restore test passed yesterday, and QA verification confirms all acceptance criteria pass at the integration boundary. The risk class is Standard. Run the production-excellence gate model and produce the operational handoff record.",
      "expected_output": "The gate model produces a Go outcome. The operational handoff record includes the service name (API service), risk class (Standard), outcome (Go), the accountable service owner (API platform team lead), evidence summary for all domains (readiness, migration: none, resilience: restore test dated yesterday, capacity/cost: 3x headroom, incident learning: no prior incidents, security: passed, release: blue-green plan, QA: integration-boundary verification), no gaps, and post-launch learning paths routed to incident-learning and product-lifecycle-learning with a review cadence.",
      "assertions": [
        "gate outcome is Go",
        "all evidence domains are sourced with named references",
        "no gaps exist in the evidence packet",
        "operational handoff record names the service owner",
        "post-launch learning paths reference incident-learning and product-lifecycle-learning",
        "risk class is Standard"
      ]
    },
    {
      "id": "blocked-launch-untested-rollback",
      "prompt": "We are launching a database schema migration for our payment service — a High-risk change because it crosses a trust boundary and is irreversible without a verified rollback. The migration plan expands the schema with a new column, backfills data, and then drops the old column. The readiness review is otherwise complete (ownership, SLOs, security, QA all pass). However, the rollback procedure has never been tested — the team wrote a rollback script but has not run it against a production-like snapshot. The migration-engineering specialist confirms the step is irreversible without the tested rollback. Run the production-excellence gate model.",
      "expected_output": "The gate model produces a No-go outcome. The blocking reason is: the rollback procedure has never been tested and the migration step is irreversible without it. The evidence packet records the gap in the migration domain (no tested rollback). The handoff record records the No-go with the gap owner (the migration team lead), the gap description (untested rollback for irreversible schema migration), and the condition for re-evaluation (successful rollback rehearsal against a production-like snapshot). The risk class (High) prohibits exceptions — no exception is offered without escalation. Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "gate outcome is No-go or blocked",
        "blocking reason explicitly references untested rollback",
        "evidence packet records the migration-domain gap",
        "gap owner is named",
        "no exception is granted for a High-risk irreversible migration without tested rollback",
        "the handoff record is populated even for the No-go outcome",
        "risk class High prevents exception without escalation"
      ]
    },
    {
      "id": "data-migration-routes-to-migration-engineering",
      "prompt": "We are migrating 200M customer records from an on-premises PostgreSQL database to a cloud-hosted database. The migration-engineering specialist has produced a plan: dual-write for 30 days, backfill the historical data with checksum verification, run reconciliation queries daily, and cut over with a 5-minute maintenance window. A rollback path exists: keep the on-premises database in read-only mode for 14 days post-cutover. The readiness review is complete, capacity model shows the cloud instance can handle 2x peak load, and QA has verified reconciliation correctness. The risk class is High. Run the production-excellence gate model and produce the operational handoff record.",
      "expected_output": "The gate model produces a Go outcome because: the migration plan from migration-engineering includes dual-write, backfill, reconciliation, cutover, and a rollback path (14-day read-only window). The evidence packet references the migration-engineering artifacts explicitly. The handoff record captures the migration type (data migration), recovery path (rollback via 14-day read-only window), verification method (daily reconciliation queries + checksum), and cutover window (5 minutes). Post-launch learning routes to incident-learning for any reconciliation failures and to product-lifecycle-learning for expected-vs-observed data integrity comparison.",
      "assertions": [
        "gate outcome is Go",
        "migration domain evidence references migration-engineering artifacts",
        "recovery path is explicit: 14-day read-only rollback window",
        "cutover window is specified",
        "reconciliation and checksum verification are cited",
        "handoff record routes post-launch to incident-learning and product-lifecycle-learning",
        "risk class is High but all evidence domains are sourced"
      ]
    },
    {
      "id": "integrated-migration-reconciliation-failure",
      "prompt": "We are migrating 200M customer records from an on-premises PostgreSQL database to a cloud-hosted database, with a 30-day dual-write window and a 14-day read-only rollback path already planned by migration-engineering. Mid-migration, the daily reconciliation job detects a mismatch: 0.4% of migrated rows have an amount-column divergence between source and target (800,000 rows affected). The migration owner asks whether we can proceed with the planned cutover and fix the mismatches after launch, since the mismatch rate is 'small.' Run the production-excellence gate model and decide how the launch should proceed.",
      "expected_output": "The gate model produces a No-go outcome: the cutover must not proceed while reconciliation is failing. The reconciliation failure is recorded as evidence in the production evidence packet with the mismatch rate (0.4%), the affected population (800,000 rows), and the affected column (amount). The trajectory routes to migration-engineering's reconciliation-failure handling — it does not paper over the mismatch. The gate records a recovery decision (rollback to the dual-write state or roll-forward after the root cause is fixed and reconciliation re-passes) with an accountable owner named. Re-evaluation is conditioned on reconciliation passing for 100% of the population; no launch or successful production-readiness verdict is issued while the mismatch exists. The handoff record is populated for the No-go outcome: it captures the reconciliation failure, the recovery decision, the owner, and the re-evaluation condition, and it does NOT route to post-launch learning because no launch occurred. Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "gate outcome is No-go or blocked — the launch does not proceed",
        "reconciliation failure evidence is recorded in the evidence packet with mismatch rate, affected population, and affected column",
        "the trajectory routes to migration-engineering reconciliation-failure handling rather than proceeding",
        "a rollback or roll-forward recovery decision is recorded with an accountable owner",
        "no launch or successful production-readiness verdict is issued while the mismatch exists",
        "re-evaluation is conditioned on reconciliation passing for the full population",
        "the handoff record is populated for the No-go outcome with the failure, decision, owner, and re-evaluation condition"
      ]
    },
    {
      "id": "dependency-outage-routes-to-resilience",
      "prompt": "We are launching a mobile notification service that depends on an upstream push-notification provider. The resilience-and-recovery assessment reveals that the upstream provider had a 45-minute outage last month affecting 30% of notifications, and the provider's SLA is 99.5% (below our service's 99.9% SLO target). The resilience specialist recommends a circuit-breaker with a fallback queue and a degraded-mode UX that shows 'delayed delivery' instead of silent failure. However, the circuit-breaker has not been exercised in a game day — the team has the code but has not run a dependency-failure simulation. All other domains are sourced. The risk class is Standard. Run the production-excellence gate model.",
      "expected_output": "The gate model produces a Defer outcome (or No-go, depending on whether the untested circuit-breaker is considered a blocking gap for Standard risk). The resilience domain has a gap: the circuit-breaker has not been exercised. The evidence packet records this gap with the resilience owner and a due date for the game-day exercise. If Defer: the condition for re-evaluation is a successful dependency-failure simulation. If No-go: the blocking reason is that the upstream dependency's SLA (99.5%) conflicts with the service's SLO (99.9%) and the mitigation (circuit-breaker) has not been tested. In either case, the handoff record records the resilience gap explicitly and routes post-launch dependency monitoring to incident-learning.",
      "assertions": [
        "gate outcome is Defer or No-go",
        "resilience domain gap is explicitly recorded: untested circuit-breaker or dependency-failure simulation",
        "upstream provider SLA vs service SLO conflict is cited",
        "degraded-mode UX is referenced as part of the resilience plan",
        "handoff record captures the gap with owner and resolution condition",
        "post-launch learning references incident-learning for dependency monitoring"
      ]
    },
    {
      "id": "cost-slo-conflict",
      "prompt": "We are scaling our data-processing pipeline to handle 10x daily volume. The capacity-and-cost-engineering specialist has produced a model: at current unit cost, scaling to 10x would increase monthly infrastructure spend from $50K to $420K. The budget constraint is $300K/month. Two options exist: (A) scale to 8x within budget but relax the SLO from p99 < 500ms to p99 < 2s during peak hours, or (B) scale to 10x with a budget increase to $420K requiring VP approval. The SRE team confirms the SLO relaxation (option A) would still meet user expectations. The readiness review is otherwise complete, and the risk class is Standard. Run the production-excellence gate model to resolve this cost/SLO conflict.",
      "expected_output": "The gate model identifies a cost/SLO conflict and produces either: (1) Go with option A (scale to 8x, relaxed SLO) if the SRE and capacity evidence supports it, recording the tradeoff decision with the accountable owner; or (2) Exception if option B is chosen and VP approval is granted for the budget increase; or (3) Escalation if the choice between A and B cannot be resolved at the service-owner level. In any outcome, the decision is explicitly anchored to: service ownership (who owns the cost/SLO tradeoff), risk (the risk of relaxing the SLO vs the risk of budget overrun), evidence (the capacity model with explicit assumptions, the SRE SLO assessment), and verification (how the scaled system's latency will be verified post-launch). The handoff record captures the capacity/cost domain evidence, the SLO decision, and routes post-launch cost and latency monitoring to product-lifecycle-learning for expected-vs-observed comparison.",
      "assertions": [
        "cost/SLO conflict is explicitly identified",
        "capacity-and-cost-engineering model is cited with unit cost and budget constraint",
        "at least two options are compared with tradeoffs",
        "the decision is anchored to service ownership, risk, evidence, and verification",
        "handoff record captures the capacity/cost evidence and the SLO decision",
        "post-launch learning routes to product-lifecycle-learning for expected-vs-observed comparison",
        "outcome is Go, Exception, or Escalation — not No-go without exploring the tradeoff"
      ]
    }
  ]
}

# Production-Excellence Bundle — Bounded Discovery Brief

## Purpose

This brief records the pre-implementation survey of existing production and release
skills in the `magnus919/agent-skills` repository. It establishes what the
production-excellence bundle owns, what it routes to, and what it must not duplicate.
It satisfies acceptance criterion "A bounded discovery brief compares the bundle with
existing production and release skills" (issue #195).

## Surveyed skills

Each skill below was inspected before the bundle was authored. For every skill the
conclusion is the same: it owns a deep specialist domain and does **not** own the
cross-domain acceptance and handoff layer that assembles evidence into a launch or
operational decision.

| Skill | What it owns | What the bundle does NOT duplicate |
|---|---|---|
| [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | SLO definition, error budgets, incident response, operational recovery, capacity planning, toil reduction | Incident command, on-call procedures, SLO math, error-budget policy, toil automation |
| [release-engineering](../../release-engineering/SKILL.md) | Release pipelines, versioning, promotion, rollout, rollback mechanics, deployment strategies | CI/CD pipeline design, artifact promotion, canary/blue-green mechanics, release-please configuration |
| [platform-engineering](../../platform-engineering/SKILL.md) | Internal developer platforms, paved roads, service catalogs, infrastructure APIs, Golden Paths | Platform architecture, IDP design, service catalog implementation, infrastructure-as-code |
| [secure-software-engineering](../../secure-software-engineering/SKILL.md) | Threat modeling, secure design, security review, vulnerability assessment, trust boundaries | STRIDE/OWASP methodology, security-review procedure, threat-model facilitation |
| [data-engineering](../../data-engineering/SKILL.md) | Database operations, ETL/ELT pipelines, data quality, schema migration, storage infrastructure | Pipeline design, dbt patterns, SQL analytical patterns, storage architecture |
| [qa-methodology](../../qa-methodology/SKILL.md) | Test strategy, regression coverage, CI quality gates, verification planning, test-level taxonomy | Test-case design, regression-suite management, test-automation framework design |
| [verification-methodology](../../verification-methodology/SKILL.md) | Verification verdicts, boundary labeling, evidence standards, gap declaration | Verification-protocol design, evidence-boundary classification |
| [production-readiness](../../production-readiness/SKILL.md) | Risk-scaled evidence packet, go/no-go/defer/exception launch decisions with accountable owners | The 11-category evidence checklist, risk-class assignment, accountable-owner identification |
| [migration-engineering](../../migration-engineering/SKILL.md) | Safe cross-system migrations — expand/contract, compatibility windows, dual-running, backfills, reconciliation, cutover, deprecation, recovery paths | Migration-strategy design, compatibility-window management, cutover sequencing |
| [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) | Failure modes, degradation choices, RTO/RPO, restore testing, DR, game days, failover, data integrity, recovery communication | Game-day design, DR-runbook authoring, failover-procedure definition |
| [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) | Demand/capacity/scaling/utilization models, unit-cost connection to SLO decisions, cost-constrained scenario analysis | Capacity-model construction, cost-attribution accounting, quota/rate-limit engineering |
| [incident-learning](../../incident-learning/SKILL.md) | Observed facts, causal hypotheses, contributing conditions, follow-up work mapping, verified closure | Incident-analysis facilitation, causal-hypothesis testing, follow-up-ticket management |
| [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) | Expected-vs-observed outcome comparison, assumption/decision updates, continue/improve/harvest/pivot/pause/retire choices | Lifecycle-review facilitation, outcome-comparison analysis |

## Boundary statement

The production-excellence bundle owns the **acceptance and handoff layer**:

- Assembling cross-domain evidence (readiness, migration, recovery, capacity/cost,
  incident-learning) into a single production decision record.
- Running the gate model: go, no-go, defer, exception, escalation — each with
  conditions, evidence, and accountable owners.
- Producing the operational handoff record for the team that will own the service
  in production.
- Routing post-launch outcomes into incident-learning and product-lifecycle-learning
  so that production evidence flows back into decisions.

It does **not** own any specialist's runbook. It does not own incident command
(SRE), release pipeline mechanics (release-engineering), platform architecture
(platform-engineering), threat modeling (secure-software-engineering), data
pipeline design (data-engineering), or test-strategy design (qa-methodology). It
composes them — it never re-derives their methods.

## What existing bundles do NOT cover

The four pre-existing bundles were also surveyed:

- **neckbeard** owns the issue-to-PR delivery journey (9-phase SDLC). It does not
  own the production acceptance and handoff that happens after delivery.
- **workflow-architect** owns workflow discovery and skill-bundle generation. It
  does not own production decision-making.
- **tailscale** owns the Headscale/Tailscale VPN ecosystem. It is domain-specific
  networking, not production governance.
- **research-and-vault** owns the research-to-notes sequence. It is a knowledge
  workflow, not a production workflow.

None of them fill the gap this bundle fills: the cross-domain evidence assembly and
launch/operational decision layer that sits between delivery (neckbeard's phase 9)
and ongoing production operations.

## Decision: bundle owns the acceptance layer, not the specialists' runbooks

The production-excellence bundle is the thin composition layer that:

1. Reads evidence from the five production-domain specialists (production-readiness,
   migration-engineering, resilience-and-recovery, capacity-and-cost-engineering,
   incident-learning).
2. Reads applicable evidence from the existing production specialists (SRE, release,
   platform, security, data, QA).
3. Assembles that evidence into a gate decision (go/no-go/defer/exception/escalation).
4. Produces an operational handoff record.
5. Routes post-launch learning back into incident-learning and product-lifecycle-learning.

It is deliberately thin. It adds no new methodology beyond the acceptance and handoff
contract. Every specialist skill remains the authoritative source for its domain.

# Production Evidence Packet

The production evidence packet assembles cross-domain evidence into a single
decision-ready record. It is the shared input to the gate model
([gates.md](gates.md)) and feeds the operational handoff record
([handoff-record.md](handoff-record.md)).

## Applicability

This packet is used for **both**:

- **New services** — a service that has never been in production. Every evidence
  domain is assessed; domains that are not applicable are explicitly marked as such
  with a reason (not silently omitted).
- **Changes to existing systems** — a feature, migration, or configuration change
  to a service already in production. Only the domains affected by the change are
  assessed; unaffected domains are marked "no change" with a reference to the
  existing evidence.

## Evidence domains

### 1. Readiness

| Field | Requirement |
|---|---|
| **Risk class** | Low / Standard / High per [production-readiness](../../production-readiness/SKILL.md) |
| **Evidence source** | Readiness record or explicit gap statement |
| **Owner** | Named accountable owner for the readiness assessment |
| **Decision** | Go / No-go / Defer / Exception from the readiness review |

For a **change to an existing system**, cite the delta: what changed since the
last readiness review.

### 2. Migration

| Field | Requirement |
|---|---|
| **Migration type** | Schema / data / API / infrastructure / service (or "none") |
| **Evidence source** | Migration plan per [migration-engineering](../../migration-engineering/SKILL.md) |
| **Recovery path** | Rollback / roll-forward / restore / irreversible (explicit) |
| **Verification** | How migration correctness was verified (reconciliation, checksum, smoke) |

For a **new service**, migrations may not apply; state "no migration — new service."

### 3. Resilience and recovery

| Field | Requirement |
|---|---|
| **Failure modes assessed** | Dependency outage, data corruption, zone/region loss, overload |
| **Evidence source** | Recovery exercise results per [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) |
| **RTO/RPO** | Stated targets (context-dependent, not universal) |
| **Degradation behavior** | What degrades and how (graceful degradation, not binary up/down) |
| **Recovery verified** | Date of last restore test, game-day, or failover exercise |

For a **change to an existing system**, state whether the change introduces new
failure modes or alters existing ones.

### 4. Capacity and cost

| Field | Requirement |
|---|---|
| **Demand model** | Expected load, peak, growth rate |
| **Capacity model** | Scaling limits, quotas, rate limits |
| **Cost model** | Unit cost, budget constraint, cost attribution |
| **SLO interaction** | Any cost/SLO tradeoff decisions per [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) |
| **Assumptions** | Explicit: all demand/capacity/cost assumptions stated |

### 5. Incident learning

| Field | Requirement |
|---|---|
| **Pre-existing incidents** | Any incidents from this service or its dependencies relevant to this change |
| **Evidence source** | Incident records per [incident-learning](../../incident-learning/SKILL.md) |
| **Follow-up status** | Verified closure of prior incident follow-up items relevant to this change |
| **New risk register** | Risks identified during readiness that should feed incident-learning post-launch |

For a **new service**, pre-existing incidents may not apply; state "no prior
incidents — new service." The new-risk register is always populated.

## Cross-domain entry evidence

Before a production decision can be made, the following must exist as **entry
evidence** (the bundle does not gather it; it requires it):

| Evidence | Owned by | Required for |
|---|---|---|
| Readiness record with risk class and accountable owner | [production-readiness](../../production-readiness/SKILL.md) | All launches |
| Migration plan (when a migration is in scope) | [migration-engineering](../../migration-engineering/SKILL.md) | Migrations |
| Recovery exercise evidence (game-day, restore test) | [resilience-and-recovery](../../resilience-and-recovery/SKILL.md) | High-risk launches |
| Capacity and cost model with explicit assumptions | [capacity-and-cost-engineering](../../capacity-and-cost-engineering/SKILL.md) | SLO-bearing services |
| Incident-learning record for relevant prior incidents | [incident-learning](../../incident-learning/SKILL.md) | Changes to services with incident history |
| Security review evidence | [secure-software-engineering](../../secure-software-engineering/SKILL.md) | Trust-boundary changes |
| Release plan | [release-engineering](../../release-engineering/SKILL.md) | All launches |
| SLO / error-budget status | [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | SLO-bearing services |
| Platform/service-catalog entry | [platform-engineering](../../platform-engineering/SKILL.md) | New services |
| Data quality / pipeline evidence | [data-engineering](../../data-engineering/SKILL.md) | Data-path changes |
| QA verification evidence | [qa-methodology](../../qa-methodology/SKILL.md) | All launches |

## Missing-evidence handling

Any evidence domain without a named source is recorded as an **explicit gap**:

- The gap is named (e.g., "no restore test performed").
- An owner is assigned.
- A due date or condition is stated (e.g., "before next launch," "within 7 days post-launch").
- The gap feeds the gate model: missing evidence in a required domain may produce
  a no-go, defer, or exception outcome, depending on risk class and domain.

A gap is never silently omitted. Every domain in the packet is either sourced or
gapped.

# Gate and Exception Model

The production-excellence gate model defines five discrete outcomes for every
production change. Each outcome requires specific conditions and evidence;
no outcome is reachable on a bare checklist.

## Guiding principles

- **Service ownership**: every gate decision names the service owner accountable
  for the outcome.
- **Risk**: the risk class (Low / Standard / High per
  [production-readiness](../../production-readiness/SKILL.md)) determines which
  evidence domains are required and which gates are applicable.
- **Evidence**: no gate passes without evidence from the production evidence
  packet ([evidence-packet.md](evidence-packet.md)). A missing-evidence gap is
  acceptable only when the risk class permits it and the gap is explicitly
  recorded with an owner and due date.
- **Verification**: evidence must be verified at the declared boundary (component,
  integration, end-to-end, or production per
  [verification-methodology](../../verification-methodology/SKILL.md)). An
  unverified claim does not satisfy an evidence requirement.

## Outcomes

### Go

**Meaning**: the change is authorized to proceed to production.

**Conditions**:

- All evidence domains required for the risk class are sourced (not gapped).
- The readiness decision from [production-readiness](../../production-readiness/SKILL.md)
  is "Go."
- Migration evidence (if applicable) confirms a verified recovery path.
- Resilience evidence (if required by risk class) includes a recent exercise result.
- Capacity and cost model (if required) shows the change is within budget and
  capacity constraints, with explicit assumptions.
- Incident-learning review (if applicable) confirms no unclosed follow-up items
  relevant to this change.
- Security review (if trust-boundary change) is complete.
- Release plan is documented and approved.
- QA verification evidence is present.

**Evidence required**: the complete production evidence packet with all domains
sourced or explicitly marked not-applicable.

**Accountable owner**: the service owner, who signs off on the Go decision.

### No-go

**Meaning**: the change is blocked and must not proceed.

**Conditions** (any one is sufficient):

- A required evidence domain has a blocking gap (e.g., no restore test for a
  High-risk launch, no security review for a trust-boundary change).
- The readiness decision is "No-go."
- A migration has no verified recovery path and the step is irreversible.
- An incident-learning review reveals an unclosed follow-up item that would be
  exacerbated by this change.
- A cost/SLO conflict cannot be resolved (the change would violate an SLO, and
  no budget increase or SLO relaxation is authorized).
- A dependency outage assessment shows the change would create an unacceptable
  blast radius.

**Evidence required**: the gap or condition that triggered the No-go, recorded
with the specific domain, the missing evidence, and the accountable owner who
can resolve it.

**Accountable owner**: the service owner records the No-go; the owner of the
blocking gap is named as the resolver.

### Defer

**Meaning**: the change is postponed to a later date with explicit conditions
for re-evaluation.

**Conditions**:

- The change is not blocked permanently (it is not a No-go), but:
  - A required evidence domain has a non-blocking gap with a committed due date.
  - A dependency (e.g., an upstream service's readiness, a platform capability)
    is not yet available but has a committed delivery date.
  - A cost/SLO conflict requires a budget or SLO decision that is in progress
    but not yet authorized.
  - The risk window (e.g., a holiday freeze, a peak-traffic period) makes the
    current timing unsuitable.

**Evidence required**: the deferral reason, the condition for re-evaluation, the
committed date or trigger event, and the owner responsible for meeting the
condition.

**Accountable owner**: the service owner records the Defer; the owner of the
deferral condition is named with the committed resolution date.

### Exception

**Meaning**: the change proceeds despite a gap, under an explicit waiver with
named approval authority.

**Conditions**:

- A required evidence domain has a gap that would normally produce a No-go, but:
  - An explicit human authority (not the service owner, not the agent) approves
    the exception.
  - The exception is time-bounded (an expiration date or post-launch condition).
  - The exception is risk-bounded (what specifically is waived, and what is not).
  - The exception is recorded with the approving authority's name and the date
    of approval.
- The exception does not waive security review for trust-boundary changes
  (a hard constraint — see Escalation).

**Evidence required**: the exception record with the waived domain, the
approving authority, the approval date, the expiration or post-launch
condition, and the accountable service owner.

**Accountable owner**: the approving authority (the human who granted the
exception). The service owner records the exception and tracks the post-launch
condition.

### Escalation

**Meaning**: the decision cannot be made within the bundle's authority and must
be escalated to a higher decision body.

**Conditions** (any one is sufficient):

- A security review for a trust-boundary change cannot be completed and no
  exception is authorized (security is a hard constraint — never waived without
  a security authority).
- Two or more gate outcomes are in irreconcilable conflict (e.g., the readiness
  review says Go but the capacity model shows an SLO violation with no
  authorized budget increase).
- The service owner and the readiness reviewer disagree on the outcome and
  neither has the authority to resolve the disagreement.
- A cross-team dependency blocks the change and the dependency owner is not
  accountable to the service owner (organizational escalation).
- The change crosses a regulatory or compliance boundary and the bundle lacks
  the domain expertise to assess it.

**Evidence required**: the escalation record with the specific conflict or gap,
the parties involved, the decision body being escalated to, and the accountable
owner who initiated the escalation.

**Accountable owner**: the initiator of the escalation (service owner or
readiness reviewer). The escalation itself names the target decision body.

## Gate applicability by risk class

| Outcome | Low risk | Standard risk | High risk |
|---|---|---|---|
| **Go** | Lightweight: readiness + release + QA evidence sufficient | All applicable domains sourced | All domains sourced; no gaps permitted |
| **No-go** | Blocking gap in any required domain | Blocking gap; irreversible migration without recovery; unresolved incident | Any gap in any domain; no exceptions for High risk without escalation |
| **Defer** | Non-blocking gap with due date | Dependency or timing constraint | Only timing constraints (e.g., freeze window); no evidence gaps deferrable |
| **Exception** | Service owner may self-approve with recorded rationale | Explicit human authority required; time-bounded | Escalation required (High-risk exceptions are escalated, not granted locally) |
| **Escalation** | Security hard-constraint, cross-team authority gap, regulatory boundary | Same as Low, plus irreconcilable gate conflict | Same as Standard; any High-risk exception is escalated |

## Post-gate: operational handoff

After a gate outcome is reached, the operational handoff record
([handoff-record.md](handoff-record.md)) is populated. For Go and Exception
outcomes, the handoff includes the launch evidence and the post-launch learning
path. For No-go, Defer, and Escalation outcomes, the handoff records the
blocking condition and the follow-up path.

# Operational Handoff Record

The operational handoff record is the durable artifact that transfers a production
change from the launch decision to the team that will own it in production. It is
the final output of the production-excellence gate model
([gates.md](gates.md)) and the production evidence packet
([evidence-packet.md](evidence-packet.md)).

## Handoff fields

### Service and change identification

| Field | Description |
|---|---|
| **Service name** | The service or system being launched or changed |
| **Change identifier** | Issue, ticket, or change-request ID |
| **Change description** | One-paragraph summary of what changed and why |
| **Risk class** | Low / Standard / High |
| **Service owner** | Named individual accountable for the service in production |
| **Launch coordinator** | Named individual who ran the readiness review and gate model |

### Gate outcome

| Field | Description |
|---|---|
| **Outcome** | Go / No-go / Defer / Exception / Escalation |
| **Outcome date** | Date the gate decision was reached |
| **Outcome authority** | Who approved the outcome (service owner, exception authority, escalation body) |
| **Conditions** | Any conditions attached to the outcome (deferral triggers, exception expiration, post-launch requirements) |

### Evidence summary

| Field | Description |
|---|---|
| **Readiness** | Risk class, accountable owner, decision summary — reference to readiness record |
| **Migration** | Migration type, recovery path, verification — reference to migration plan (or "none") |
| **Resilience** | Failure modes assessed, RTO/RPO, last exercise date — reference to recovery evidence |
| **Capacity/cost** | Demand model summary, budget constraint, SLO interaction — reference to capacity model |
| **Incident learning** | Relevant prior incidents, follow-up status — reference to incident records |
| **Security** | Review status, trust-boundary assessment — reference to security review (or "not applicable") |
| **Release** | Release plan summary — reference to release plan |
| **Platform** | Service-catalog entry, paved-road status — reference to platform entry |
| **Data** | Data-path assessment — reference to data-quality evidence |
| **QA** | Verification summary, boundary exercised — reference to QA evidence |

### Gap register (for any missing evidence)

| Field | Description |
|---|---|
| **Domain** | Which evidence domain has a gap |
| **Gap description** | What evidence is missing |
| **Owner** | Who is accountable for closing the gap |
| **Due date** | When the gap must be closed |
| **Risk of non-closure** | What happens if the gap is not closed by the due date |

### Post-launch learning path

| Field | Description |
|---|---|
| **Incident-learning route** | Whether launch outcomes and any post-launch incidents should feed [incident-learning](../../incident-learning/SKILL.md) |
| **Lifecycle-learning route** | Whether launch outcomes should feed [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) for expected-vs-observed comparison |
| **Review cadence** | When the service owner should revisit the handoff record (e.g., 7 days post-launch, 30 days post-launch) |
| **Escalation path** | Who to contact if post-launch issues exceed the service owner's authority |

### Sign-off

| Field | Description |
|---|---|
| **Service owner signature** | Name and date |
| **Launch coordinator signature** | Name and date |
| **Exception authority signature** | Name and date (only for Exception outcomes) |
| **Escalation body acknowledgement** | Name and date (only for Escalation outcomes) |

## Post-launch learning: routing launch outcomes

After launch, the handoff record feeds two learning paths:

### Incident-learning route

Post-launch incidents (degraded SLOs, unexpected failures, dependency outages,
capacity breaches) are routed to [incident-learning](../../incident-learning/SKILL.md)
with a reference to this handoff record. The incident-learning skill's verified-closure
requirement ensures that follow-up items traced to launch decisions are tracked to
completion.

For a **Go** outcome: incidents are unexpected and trigger the standard
incident-learning flow.

For an **Exception** outcome: incidents related to the waived domain are
expected to be elevated; the exception's post-launch condition defines the
threshold for re-escalation.

### Lifecycle-learning route

The expected outcomes recorded in the handoff (SLO targets, capacity assumptions,
cost projections, migration-success criteria) are routed to
[product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) for
expected-vs-observed comparison at the review cadence. The lifecycle-learning
skill's continue/improve/harvest/pivot/pause/retire decisions are informed by
the gap between what the handoff predicted and what production observed.

## Handoff for non-Go outcomes

The handoff record is populated even when the outcome is not Go:

- **No-go**: the handoff records the blocking gap and routes it to the gap owner.
  The record is retained as evidence of the decision and its rationale.
- **Defer**: the handoff records the deferral condition and the re-evaluation
  trigger. At the trigger date, the service owner re-opens the gate model with
  updated evidence.
- **Exception**: the handoff records the waiver and its post-launch condition.
  The exception authority is named; the condition is tracked.
- **Escalation**: the handoff records the escalation target and the specific
  conflict. The escalation body's decision (when reached) is recorded in a
  follow-up handoff.