Introduction
Every estate eventually has a bad day: a service goes down, data looks wrong, a secret leaks, or an entire cloud region disappears. What separates a bad day from a crisis is whether the response was already written down, rehearsed, and followed - or improvised under pressure. Cogitave keeps that response as code, in one tree: ops/.
ops/ is the operational-resilience half of the estate: how Cogitave detects, responds to, communicates about, and recovers from anything that goes wrong, authored and reviewed the same way as any other code. It sits next to the proactive reliability standard (SLOs, error budgets, on-call) - reliability is what keeps most days from becoming bad days; ops/ is what happens once one does.
IMPORTANT
Day 0 caveat. ops/ is authoring only: plans, schemas, runbooks, and templates - not a running on-call rotation. The ops index is explicit that these plans turn on after cutover, sequenced by the Day-1 operate runbook. This module teaches the plan you would follow, not a live system you can page.
ops/README.md names exactly two areas, and this module teaches both:
- Incident response (
ops/incident-response/) - the plan, the severity model, roles, runbooks, communications, and the blameless postmortem. This is what fires the moment something breaks. - Business continuity (
ops/business-continuity/) - the BIA, service tiers, backup strategy, and disaster-recovery plan that keep the estate's critical activities running through a bigger disruption, like a region loss or a destructive attack.
What you will get from this module
Not a summary to memorize - a working command of the flow: how a signal becomes a declared incident, who commands the response, how a runbook contains and recovers a specific incident class, and how business continuity escalates from that same response when the disruption is bigger than one incident. Every claim in this module traces back to a document under ops/; read this module to learn how to use those documents, not as a replacement for them.