Appendix D · Chapter 9 · AI That Rebuilds the Business

Pre-Written Failure Conditions: Two Illustrative Templates

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:

1. Write conditions before commitment. After launch, every threshold gets negotiated downward by people invested in continuing (Klein’s premortem, HBR 2007).
2. Classify reversibility first. Anything one-way requires a parallel-run or rollback path by design (Bezos, 2015).
3. 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.
4. 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.
5. Make the kill owned, dated, and rewarded. A condition without a named owner who survives triggering it is fiction (Teller’s practice at X of bonusing teams that killed their own projects).
6. Govern the capacity collision — decide in advance whose calendar wins. 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 (my field pattern, offered as such — this failure never makes the public record, it just makes roadmaps late).

Template A — Professional-services firm

AI-assisted engagement delivery redesign.

• Condition A1. IF the rework rate on AI-drafted deliverables (partner or senior edits requiring substantive correction) 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. (Klarna principle: a quality floor, not just a speed gain.)
• Condition 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. (Gartner / MIT NANDA principle.)
• Condition 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. (Zillow principle: the economic thesis has a number and a date.)
• Condition 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 condition: client trust is not a reversible experiment.)
• Condition 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. (The most common gap in the field, converted into a tripwire.)
• Condition 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 — the exercise of imagining the project already failed and working out why — with the actual numbers. (Klein plus Gartner’s cost-escalation finding.)
• Condition 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 at the gate until a fallback is named and its switching cost priced in money and months — and a named owner re-reviews the vendor’s terms, including data use, before every renewal. (Chapter 9’s vendor door: substitutability is a design discipline, not a negotiating posture.)

Template B — Light-manufacturing firm

AI scheduling and vision-QC redesign.

• Condition 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. (The condition most drifted companies skip; only 12% of organizations report AI-ready data — Informatica, 2025.)
• Condition 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.
• Condition B3. IF on-time delivery falls below the trailing-12-month baseline for two consecutive weeks DURING parallel running (keeping the old system running alongside the new one), THEN revert to manual scheduling within 48 hours; parallel-run capability is maintained until three consecutive months at or above baseline. (Bezos principle: keep the door two-way by design.)
• Condition B4. IF the vision-QC (AI that visually inspects products for defects) 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. (Klarna principle: the tail — escapes to customers — outranks the average.)
• Condition B5. IF downstream rework attributable to the new schedule (expedites, shipping re-plans, purchasing churn) 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.
• Condition 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. (Teller principle: reward the kill or the conditions are fiction.)
• Condition 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 in money and months — the manual parallel-run capability in B3 counts toward the fallback only while it is actually maintained. (Chapter 9’s vendor door: substitutability is a design discipline, not a negotiating posture.)

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: A7 and B7 trace to Chapter 9’s vendor-door argument — structural reasoning about multi-year vendor dependence, offered as reasoning, not as an autopsy — and the operational tells behind A5, B2, and B5 are field patterns, labeled as such where they appear. That mapping, and that labeling, is your guarantee these aren’t disguised client work — and your template for writing your own: every condition you write should trace to a failure that has actually happened to someone — or be labeled, plainly, for what it is instead, the way A7, B7, and principle 6 are here.