Error Budget Policy
The written agreement about what happens when the error budget is exhausted, which is what turns an SLO from a number into a control.
An SLO without a policy is a dashboard. The policy is the part that changes behaviour, and it must be agreed in advance — during a calm week, by engineering and product together — because negotiating it during an incident produces the answer whoever is loudest wants.
A workable policy states: what happens at exhaustion (feature work pauses, reliability work takes priority), who can override it and at what cost, what happens if the budget is exhausted repeatedly (the SLO or the architecture is wrong, and that becomes a scheduled conversation), and what happens if it is never consumed — which means the target is too conservative and the organisation is buying reliability nobody asked for.
The reason this works organisationally is that it converts a recurring argument — ship faster versus make it more reliable — into a rule both sides accepted while neither was under pressure. That is the entire mechanism, and it is why copying the SLO numbers without the policy achieves nothing.