Postmortem → Guardrail

The problem When software breaks in production, teams write a postmortem: what happened, why, and what must change. Postmortems are where engineering teams learn the most, and where that learning most often dies. The action item "prevent this class of bug" goes into a backlog, gets outranked by feature work, and months later the same mistake ships again in a different file. The fix covered one line; the lesson was never enforced. Our solution Postmortem → Guardrail turns a postmortem into enforced code. A developer drops the incident write-up (Markdown or PDF) into the repo and asks IBM Bob to close it out. A team of Bob specialists then delivers four things, each with proof: 1. The root cause, pinned to the exact file and line. 2. A regression test that fails on the buggy code, built from the postmortem's own numbers. 3. The smallest correct fix, which turns that test green. 4. A guardrail: an automatic check that runs in CI on every change and blocks the whole bug class anywhere in the codebase, with a message that names the incident it came from. The result is a Guardrail Report per incident and a public Guardrail Ledger, so every lesson the team has learned is visible and enforced. Who it's for and how they use it It's for on-call engineers, SREs and engineering leads who own incident follow-up. They don't learn a new tool: they open IBM Bob, pick the Guardrail Orchestrator mode, and type "close out the open postmortems". Managers and non-engineers read the plain-English site to see what broke, what was found and what now stops it. Why it's new AI tools today help you fix the bug in front of you. Postmortem → Guardrail starts from the document teams already write and turns its lesson into a permanent rule, so the fix protects code that hasn't been written yet. The guardrail is proven, not assumed: Bob runs every new rule against the original buggy code to show it fires, then against the fix to show it stays quiet. Each Bob specialist has least-privilege access (investigators can only write tests, authors can only write rules), so the process is safe to trust. Results We ran it on a sample shop backend with three expensive, real-world bug classes: - A Black Friday promo that ended six hours early (a dropped time zone). - 1,870 invoices off by one cent (money stored as floats). - 245 customers charged twice after payment timeouts (retries without an idempotency key). Bob closed all three postmortems in one task, at 18, 22 and 20 minutes each (about 20 on average). Passing tests grew from 9 to 18, all three guardrails fired on the original code with 3 violations and 0 after the fixes, and the whole run cost 9.32 Bobcoins. When one rule came back too broad, the Orchestrator caught it and had it tightened before signing off. Postmortem → Guardrail makes every incident a one-time cost.