Skip to content
Better Decision Making
Module 5 of 5

Plan the Failure Branch Before Launch

9 minutes · Intermediate

Learning objective

By the end of this lesson, you can turn a possible problem into an executable contingency with a trigger, owner and recovery route.

Why it matters

“We will monitor closely” is not a plan. When a new workflow fails, teams need to know what signal appears, who may act, which fallback is available and how a trustworthy state is restored.

Core concept: every branch needs an operating response

Extend each material activity with:

  1. a specific possible problem;
  2. evidence that makes it plausible;
  3. prevention where practical;
  4. an observable trigger;
  5. an authorised response owner;
  6. hold, fallback, rollback or recovery action;
  7. response time and verification.

Visual explanation

Text alternative: a planned activity can follow the expected path or a possible-problem branch. An observable trigger activates an owned countermeasure and recovery route.

Worked example

An AI assistant proposes and applies CRM-stage updates. If evidence is ambiguous, it must abstain. If a transaction times out, the system checks the idempotency key before retrying. If reversal exceeds the pilot threshold, the operations owner pauses live updates and returns to proposal-only mode.

The response is executable because signals, authority and recovery are defined before launch.

Common mistake

Mistake: listing “AI error” as a possible problem.

It is not observable or actionable. Replace it with a specific state such as “no cited passage supports the proposed stage” or “a retry creates a duplicate pending update.”

Quick check

What turns a risk statement into an operational PDPC branch?

A. A higher risk score.
B. A trigger, monitoring source, authorised owner and executable countermeasure.
C. A longer prompt.
D. A promise that failure is unlikely.

Answer: B. The branch must connect detection to action.

Practical prompt

Take three steps from a planned AI pilot. For each, write one possible problem, trigger, prevention, response, owner and rollback or recovery test.

Summary

  • Start from the chosen implementation path.
  • Write specific possible problems.
  • Separate prevention from response.
  • Attach triggers and authorised owners.
  • Test fallback and recovery before scale.

Next lesson

Complete the path by translating the selected decision and safeguards into measurable outcome evidence with Objectives and Key Results.

Next step

Apply this path in a practice case

Continue