Pre-Written Failure Conditions
Failure conditions are the sentences you write while you are still sane — before commitment, before sunk cost, before the project has defenders. The two templates below show what a complete set looks like. They are worked examples to copy the shape of, not the numbers.
The six design principles
Every condition you write should satisfy all six:
- Write conditions before commitment. After launch, every threshold gets negotiated downward by people invested in continuing (Klein's premortem, HBR 2007).
- Classify reversibility first. Anything one-way requires a parallel-run or rollback path by design (Bezos, 2015).
- Set floors on the tails, not just targets on the averages. Klarna's metrics measured the average while the damage concentrated in the complex-case tail.
- Bound forecast error and volatility, not just outcomes. Zillow's model didn't just miss — its error swung, and no condition existed for the swing.
- Make the kill owned, dated, and rewarded. A condition without a named owner who survives triggering it is fiction.
- Govern the capacity collision. The core and the redesign compete for the same few senior people, and the core wins every skirmish by default. Write the rule and a tripwire on borrowed senior hours before the first hard quarter.
Template A — Professional-services firm
AI-assisted engagement delivery redesign.
Illustrative template — grounded in named public cases, not client engagements. Numbers are placeholders; adjust them to match your own baseline.
- A1. IF the rework rate on AI-drafted deliverables is not below the human-baseline rework rate BY the week-10 gate, THEN freeze expansion to additional service lines and run a root-cause review before any further tooling spend.
- A2. IF fewer than 60% of in-scope engagements are actually running through the new workflow BY week 12, THEN stop buying and start fixing ownership and training — adoption failure is a governance failure, not a feature request.
- A3. IF senior-reviewer hours per deliverable have not fallen at least 20% below baseline BY the week-16 gate, THEN roll the affected service line back to the prior workflow and re-scope.
- A4. IF any AI-originated factual or calculation error reaches a client in a signed deliverable AT ANY POINT, THEN immediately revoke client-facing autonomy for that document class and return it to human-in-the-loop until two consecutive clean review cycles. (One-way door: client trust is not a reversible experiment.)
- A5. IF the named single owner changes, or ownership becomes shared or committee-held, AT ANY POINT, THEN automatic project review before the next gate — no exceptions.
- A6. IF cumulative spend exceeds 125% of the gated budget BEFORE the current gate's metric is met, THEN stop; re-approval requires re-running the premortem with the actual numbers.
- A7. IF any stage's design assumes a single vendor's current model, feature set, or roadmap and no substitution path is documented, BY that stage's entry gate, THEN the stage holds until a fallback is named and its switching cost priced in money and months.
Template B — Light-manufacturing firm
AI scheduling and vision-QC redesign.
Illustrative template — same caveat. Numbers are placeholders.
- B1 — gate-zero precondition. IF bill-of-materials and routing data accuracy is not verified at 95% or better on a sampled audit BY the readiness gate, THEN the scheduling phase does not start — data cleanup is the project until it is.
- B2. IF planners are manually overriding more than 20% of AI-generated schedules AFTER week 6, THEN stop tuning the model and audit the master data and constraint definitions it's fed — persistent overrides are a data signal, not a user-training problem.
- B3. IF on-time delivery falls below the trailing-12-month baseline for two consecutive weeks DURING parallel running, THEN revert to manual scheduling within 48 hours; parallel-run capability is maintained until three consecutive months at or above baseline.
- B4. IF the vision-QC false-reject rate exceeds 3%, OR the defect-escape rate to customers is not at or below the human-inspection baseline, BY the week-8 gate, THEN human inspection stays in line and the system is demoted to advisory mode.
- B5. IF downstream rework attributable to the new schedule rises above baseline for a full month, THEN gate review with the downstream department heads in the room — the process boundary is where drift hides.
- B6 — standing condition. The kill decision at every gate belongs to [NAMED OWNER]. Exercising a rollback at a gate is recorded as a successful outcome of the control system — not a project failure — in that owner's review.
- B7. IF the scheduling engine or vision-QC system depends on a single vendor's model or hardware such that a repricing, acquisition, or feature deprecation has no documented substitution path, BY the production-scaling gate, THEN scaling holds until a fallback is named and its switching cost priced.
The conditions above trace to named public cases — Zillow's shutdown, Klarna's reversal, the Gartner and NANDA governance findings, Bezos's doors, Klein's premortem, Teller's rewarded kills — or say plainly, in their own parentheses, what they rest on instead. That mapping, and that labelling, is your template for writing your own.
How to use it: Copy the shape, not the figures. Every condition you write should trace to a failure that has actually happened to someone — or be labelled, plainly, for what it is instead. Print this page →