A runbook is read by a tired person at 03:00 who did not write it and does not know this service. That single constraint rules out most of what people put in runbooks: architecture background, rationale, and anything written in prose when it could have been a command.
Most SLOs are picked because 99.9% sounds respectable, then never referenced again. An SLO is only useful if a specific number of bad minutes triggers a specific decision, so this worksheet makes you write the error budget policy before you pick the target.
Services reach production without on-call ownership, alerts, or runbooks because nothing blocks them. A readiness review is only useful if it is a gate with an owner who can say no, not a form filled in afterwards.
Observability gaps are discovered during incidents, which is the worst time and the most expensive. This matrix finds them in advance by asking a simple question per service: if this broke right now, would we know, and could we tell why?
A pipeline has production credentials and the authority to ship code, which makes it one of the most privileged systems you run, and usually one of the least reviewed.
The question that wastes most time at the start of an incident is who owns this. A register answering that in one lookup (with the on-call route, the runbook, and the dashboard) is worth more than most tooling.