« Phase 16 · Warmup · Track Overview

Lab 01 — The Operating Model, as Code

The problem

Two people share accountability for a platform. It is going well, and then:

• The error budget hits zero on the 18th. A feature the business has committed to a customer is ready. One owner says freeze; the other says ship. Neither is wrong, and there is no rule.
• An agent is ready for production. It is "basically done" — the runbook exists, the alerts are configured, nobody has actually tested either. Somebody has to say no, and saying no to a peer with no criteria is a personality contest.
• A decision made in March, by two people who both remember it differently, is questioned in September. One of them has left.
• Six months of post-mortems, forty action items, and nobody knows how many were done.

None of these are failures of goodwill. They are missing instruments. Shared accountability without shared mechanisms is two people blaming each other after an incident.

You build the instruments: an ORR that is a gate rather than a grade, an error-budget policy signed before the first breach, a decision router that says who must sign, ADRs that are immutable, a standing design-review checklist, and an incident tracker that measures the only thing that matters.

What you build

Key concepts

Files

Run

pip install -r requirements.txt
pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v
python solution.py

Success criteria

• All 113 tests green against your lab.py.
• A mandatory criterion with a weight is rejected at construction.
• One mandatory failure fails the ORR at a 100% advisory score.
• An unanswered mandatory criterion is a failure, not a gap.
• A mandatory "yes" with no evidence fails, and the reason names what was required.
• Every tighter budget state permits a subset of the looser one.
• Freeze still permits EMERGENCY_FIX and RELIABILITY.
• An exception needs both owners, a real reason, and expires.
• An exception is consumed once and covers only its own change class.
• Exceeding the exception rate is refused, saying the policy should be renegotiated.
• An irreversible decision recorded by one owner is rejected.
• Two positions with falsifiers are factual; neither is values; one is unclear.
• An ADR with one option is refused; with no negative consequences it cannot be accepted.
• amend always raises; supersession requires both ADRs accepted.
• A design missing its blast radius, denial, degradation, artifacts or operator is blocked.
• Side-effecting tools with no idempotency or no autonomy band are blocked.
• A review rule that raises produces a blocker.
• An incident cannot be resolved before it is mitigated.
• A dropped action leaves the denominator; a completed one raises the rate.
• All five JD forums are present with wants, artifact and fails_when.

How this maps to the real stack

Honest limits. None of this replaces the conversation. The disagreement protocol classifies a disagreement; it does not resolve one, and the hard part — two people finding out they disagree about values and saying so plainly — is not code. The ORR scorer cannot tell whether the evidence link actually shows what it claims, so a determined team can pass it with plausible URLs; the defence is a human panel, which is why the real ORR has one. The error-budget policy assumes the budget number is trusted (Phase 14) and does nothing if the SLI is wrong. The design-review rules operate on a structured document, and requiring structure is itself an intervention a real organization may resist. And the completion-rate metric is gameable in the obvious way — drop the hard actions — which is why the drop reason is recorded and reviewed.

Extensions

1. Wire the ORR to the deploy pipeline. A promotion that calls score() and refuses. Then watch what happens the first time it blocks something urgent — that conversation is the real test.
2. Wire the budget policy to CI. The change class comes from a PR label; the budget comes from the SLO platform. Now the freeze is mechanical rather than an argument.
3. Render ADRs to markdown in the repo, with the supersession chain as links. Architectural memory that a new joiner can actually read.
4. Add a decision log to the disagreement protocol: every escalation, both positions, the resolution, and who committed. Then review it quarterly and see which disagreements recur.
5. Generate the design-review template from the rules, so the document's fields and the checklist cannot drift apart.
6. Track action items by age, not just completion — the oldest unresolved action is a better signal than the rate (Phase 12's break ageing, applied here).
7. Build the forum briefing generator: given a forum name, assemble the artifacts that forum wants from the other phases' systems.
8. A pairing rota for the ORR. The reviewer is never from the building team, and the rota is published — which is the same independence argument as Phase 15's validation.

Interview / resume bullets

• "Operated two-in-a-box with the Platform Product Owner under undivided accountability — shared roadmap, shared architectural decisions, shared pager — and built the instruments that make shared accountability survive a real disagreement rather than dissolve into one."
• "Signed a four-state error-budget policy before the first breach, with exceptions requiring both owners, a stated reason and an expiry — and tracked the exception rate as the health metric for the policy itself, which is what stops a policy being quietly replaced by a habit."
• "Introduced an ORR where any mandatory criterion fails the review at any advisory score, and where every criterion names the artifact that proves it — which turned 'ready for production' from a feeling into a checklist that a peer can apply without it becoming a personality contest."
• "Added six agent-specific ORR criteria a generic readiness review does not have: eval suite, red-team containment, tool-scope review, per-tenant cost ceiling, autonomy band, and evidence-pack generability."
• "Established a disagreement protocol that separates factual disagreements — resolved by measurement — from value disagreements, which are escalated with both written positions rather than averaged, because a design at the midpoint of two coherent positions is worse than either."
• "Made ADRs immutable and required negative consequences before acceptance, so architectural reasoning survived both owners and a successor could tell whether a trade-off still held."
• "Tracked post-mortem action completion as a first-class metric, with dropped items requiring an explicit reason — which is the only honest measure of whether a post-mortem culture is a process or a writing exercise."