Working Backward
TL;DR
Working backward starts at the required end state and asks, repeatedly, “what must be true immediately before this?” — chaining prerequisites in reverse until the chain touches something already true today. As a graph, each backward step is a node, and the grounding gate enforces the whole point: a chain that never reaches the present is a wish, not a plan. Reach for it when the end state is fixed and dated — a statutory deadline, an exam, a filing — and one caution is built in: it plans requirements, never conclusions. Working backward from “what must the file show” is planning; working backward from “the answer we want” is the failure mode the forward graph exists to prevent.
The calendar that only works in reverse
Day 30 is the filing deadline, and planned forward the work always fits — on paper. Investigate for a while, write it up, review, file. Six weeks later the team is somehow at day 26 with the narrative in draft, the reviewer traveling, and a system that needs three days’ notice to produce the transaction detail everyone assumed was one click away.
The veteran BSA officer plans the same case in the other direction. To file day 30, the narrative must be final day 27. Final day 27 means review starts day 24; review needs the investigation closed day 20; closing it needs the transaction detail, which takes three days to pull — so the request goes in by day 17, which means the alert must be worked by day 15. The forward plan listed tasks. The backward plan discovered the deadline hiding inside day 17 — while there was still time to hit it.
An unguided model narrates a plausible path forward from now. The backward graph starts at the obligation and refuses to call anything a plan until the prerequisite chain actually touches the present.
How the graph works, step by step
Fix the end state. The graph begins at the destination, stated as verifiable conditions with their date: filed by day 30, evidenced by exam day, effective by the statute’s clock. Vague end states are rejected here — a chain cannot be anchored to “be ready.”
Chain prerequisites in reverse. Each node asks one question of the state after it: what must already be true for this to happen? Every answer becomes the next node’s target, and each link carries its lead time — the three-day data pull, the reviewer’s calendar — because lead times are where backward planning finds the deadlines nobody wrote down.
Verify grounding. The chain must terminate in the present: conditions that are already true, resources already in hand, on dates that have not passed. A chain whose earliest step lands last Tuesday is not a plan with a problem; it is an infeasibility finding, discovered while it can still be escalated.
Gate and hand forward. The grounding gate records the full chain — every prerequisite, lead time, and owner — as the plan artifact. Execution then runs forward along it, typically as a means-ends loop with the chain as its difference list: working backward finds the path; working forward walks it.
The gates, operationally
| Gate | What it checks | Fails when |
|---|---|---|
| End-state gate | The destination is stated as verifiable conditions with a date, from an authority (statute, order, commitment) | The goal is aspirational (“be exam-ready”) with no conditions a verifier could check |
| Link gate (per step) | Each prerequisite is genuinely necessary for the step after it, and carries its real lead time | A link is a task that merely helps, or lead times are wished down to fit the calendar |
| Grounding gate | The chain terminates in conditions already true, on dates still ahead; otherwise it reports infeasibility with the earliest breach named | The chain bottoms out in an assumption nobody verified — the “one click away” data pull that takes three days |
Where it fits — three use cases
1. Statutory clocks
SAR filing windows, Reg E resolution deadlines, adverse-action notice periods — anywhere the end date is law. Backward chaining converts the statutory date into the internal dates it silently implies, which is where these deadlines are actually lost or saved.
2. Exam and audit readiness
“Evidenced by exam day” works backward through: the artifact exists → the control ran → the control was implemented → the owner was assigned. Each link is checkable now, months early — readiness becomes a grounded chain instead of a countdown with hope in the middle.
3. Evidence-sufficiency planning
Before adjudicating, work backward from the requirements of a defensible determination — either determination: what would the file need to contain to support a grant, and what to support a denial? The output is an evidence-collection plan, and the caution above is the design: the backward pass plans what must be gathered; the forward graph, on the gathered record, decides. Requirements are planned. Conclusions are earned.
When to reach for it
Reach for working backward whenever the end state is fixed, dated, and non-negotiable, and the real question is whether today connects to it — deadlines, readiness, delivery. Its sharpest value is early infeasibility: the chain that cannot ground surfaces now, while escalation is a choice rather than an apology. And keep its boundary bright: it is a planner of requirements, never a chooser of outcomes.
- Grounding
- A backward chain is a plan only when it terminates in conditions already true on dates still ahead; anything else is a wish with structure.
- Implied deadlines
- Lead times propagated backward reveal the internal dates a statutory date silently contains — the day-17 hiding inside day 30.
- Requirements, not conclusions
- Working backward from what a defensible file must contain is planning; working backward from a desired answer is the corruption the forward graph exists to prevent.