Introduction
Every service Cogitave runs will eventually fail some request. The question the reliability standard makes you answer in advance is not whether that happens, but how much of it is acceptable, and what happens the moment it isn't.
Reliability is a budgeted feature, not an absolute
The standard's thesis: 100% is the wrong target for everything. It is unaffordable, it makes change impossible, and a user cannot tell the difference between 100% and the nines their experience actually needs. So the job of SRE is not to prevent every failure - it is to spend a measured, agreed amount of unreliability on the velocity that ships value, and to stop spending the instant the budget runs out. The SLO is the number that makes that trade explicit; the error budget is the currency; the error-budget policy is the law that the currency buys real decisions, not just a dashboard.
IMPORTANT
This is why SRE is an engineering discipline, not a renamed ops rota. A service that stays up only because a human watches it around the clock is not reliable - it is unfunded debt. Cogitave is a small remote team with no 24/7 wall-of-screens shift, so automation, not headcount, is the only sustainable model.
What this standard sits on top of
The reliability standard does not redefine measurement or incident response - it consumes them. SLIs and telemetry come from observability; a burn-rate page runs as an incident under ops/incident-response; disaster scenarios and DR game-days come from ops/business-continuity. What it adds is the error-budget policy itself, sustainable on-call, the toil cap, capacity planning, and chaos engineering - the subject of this module.
What you will get from this module
A working ability to set a service's SLO, compute the error budget it buys, and say exactly what happens - to velocity, to on-call, to the roadmap - once that budget is spent.