# Reliability Boundary

**Status:** Approved target-state boundary; operationally parked  
**Activation:** I9 external/enterprise productization  
**Priority:** lowest current dogfood priority (R5).

## Target State

AWP eventually represents service reliability explicitly without making SLO machinery a prerequisite for dogfooding.

```text
Service / user journey
  -> ReliabilityPlan
       -> SLI definitions
       -> SLO targets/windows
       -> error-budget policy
       -> release/incident consequences
  -> telemetry provider queries/rules
```

OpenSLO is the preferred portable representation. If Prometheus-compatible metrics are selected, Sloth or Pyrra should generate operational rules rather than AWP building a bespoke SLO engine.

## Invariants From Day 1

Even before I9:

- telemetry and health data have stable correlation to product/runtime identities;
- Deployment/Incident models do not assume every failure is an SLO breach;
- reliability targets are policy, not raw metrics;
- telemetry backend does not become the product authority;
- no I0–I8 feature is blocked solely because formal SLO/error-budget semantics are not implemented;
- architecture must not make future service/journey SLIs impossible to derive.

## ReliabilityPlan Target

Conceptually:

```text
ReliabilityPlan
  scope: service | project | journey
  sli[]
  slo[]
  errorBudgetPolicy?
  evidence/source
  owner
  revision
```

An SLI defines what is measured and how it maps to user-visible success. An SLO defines target/window. Error-budget policy may influence release pace, incident escalation or approval requirements.

## Relationship to Health

Operational health exists from I0 as current status/failure visibility. `ReliabilityPlan` is a later governance layer over measured user/service performance.

```text
health/readiness signal   immediate operational state
SLI/SLO                   measured reliability objective over time
error budget              policy consequence of SLO performance
```

Do not conflate them.

## Relationship to Release/Incident

I6 Deployment can record health evaluation without formal SLOs. I8 Incident tracks failures/resolution. I9 may add policies such as:

- block automatic production promotion when budget is exhausted;
- increase human approval requirements;
- prioritize reliability work;
- link incident impact to SLO burn.

These are later policy decisions, not dogfood requirements.

## Increment Realization

| Increment | Reliability realization |
|---|---|
| I0 | useful telemetry/health/failure visibility only. |
| I1–I8 | preserve IDs/events needed for future reliability analysis; no formal SLO subsystem required. |
| I9 | activate ReliabilityPlan, OpenSLO mapping, SLI/SLO evaluation and optional error-budget policy. |

## Current Implementation State

Parked. No formal reliability product work should consume dogfood priority now.

## Deferred Realization

Exact SLO percentages, windows, burn-rate thresholds, dashboards and enterprise retention are intentionally evidence-dependent and specified/selected when external operation begins.

## Temporary Dogfood Behavior

Use direct health/telemetry indicators and explicit incidents. Do not create fake SLO targets merely to make the model look complete.

## Decisions / ADRs

R5 is accepted but parked. Moving it earlier requires a Decision justified by real dogfood/customer operational need.