docs: define matchmaking launch SLOs

docs/MATCHMAKING-SLOs.md

@@ -0,0 +1,39 @@
+# Matchmaking launch SLOs
+
+These are the measurable release gates for the Phase 8 control plane. All
+latency measurements use server-side monotonic timestamps and are labelled by
+region, playlist, build, transport and warm/cold capacity. A request or match
+is counted only after the corresponding terminal event is durably recorded.
+
+| SLO | Metric and denominator | Window / target | Owner | Alert threshold |
+| --- | --- | --- | --- | --- |
+| Placement eligibility | `max(predicted_rtt_ms)` across all accepted players in a candidate | Every candidate; `<=100 ms` | Matcher | Any eligible candidate over 100 ms pages immediately and is rejected |
+| Regional observed RTT | p95 of server-observed handshake/game RTT for connected assigned players | Rolling 1 h, per region; `<=80 ms` | Game-server + networking | 15 min above 80 ms, or any region p95 above 100 ms for 5 min |
+| Acceptance → assignment-ready | `assignment_ready - unanimous_accept` for accepted proposals with warm capacity | Rolling 1 h; p95 `<=5 s`, p99 `<=10 s` | Allocator | p95 >5 s for 10 min or p99 >10 s for 5 min |
+| Assignment → successful connection | `connected - assignment_published` for assignments not cancelled by policy | Rolling 1 h; p95 `<=5 s` | Game-server lifecycle | p95 >5 s for 10 min or connection success <99% for 5 min |
+| Allocation + durable result | completed matches with both successful allocation and durable result / matches requiring allocation | Rolling 24 h; `>=99.9%` | Allocator + maintenance | <99.95% warning; <99.9% pages and blocks release |
+| Server tick health | Physics ticks completed without backlog / expected physics ticks; resource headroom is measured independently | Every live match; zero backlog and `>=30%` CPU/RSS headroom | Game-server | Any sustained backlog, or headroom <30% for 5 min |
+| Control-plane API | p95 request latency for non-streaming authenticated API requests, excluding client cancellation | Rolling 5 min, by route; `<=250 ms` | API | p95 >250 ms for 5 min or 5xx >1% |
+
+## Measurement rules
+
+- Do not combine EU and NA into one percentile; a healthy region must not hide
+  an unhealthy one.
+- Exclude explicitly rejected requests from success denominators, but count
+  accepted work that later expires, fails allocation, or loses result delivery.
+- Preserve queue, proposal, match, server and request IDs on every metric and
+  trace. Never attach Steam auth tickets, SDR relay tickets, publisher keys or
+  other credentials to labels, logs or traces.
+- Warm-capacity SLOs are evaluated only when the region has the declared Ready
+  floor. Cold-start and capacity-exhaustion outcomes are separate dashboards,
+  not silently removed from availability accounting.
+- Alert thresholds page the owning role; the release gate is the stricter
+  target in the table, not the warning threshold.
+
+## Release evidence
+
+A release candidate must provide one complete 24-hour report, route-level API
+histograms, regional RTT histograms, allocation/connection cohort counts,
+tick-health samples, and an incident review for every SLO breach. Load and
+chaos tests must retain the same event IDs so the report can distinguish
+retryable control-plane delay, player no-show, and match-integrity failure.

docs/MATCHMAKING.md

@@ -418,6 +418,9 @@ Minimum controls:
 
 ## 8. SLOs, observability, and release gates
 
+The operational definitions, owners, windows and alert thresholds for these
+targets are maintained in [`MATCHMAKING-SLOs.md`](MATCHMAKING-SLOs.md).
+
 Launch SLOs:
 
 | Measure | Target |