Your car won't start. You don't think about every possible problem. Instead, you think backward: "The car won't start, so the engine isn't turning. For the engine to turn, the battery must have charge. Is the battery charged?" That's backward chaining—reasoning from goal to facts. It's more efficient than forward chaining for targeted problems.
The Core Idea
Backward chaining asks: "Can I prove this goal?"
You start with a desired conclusion. You ask: "What would need to be true for this to happen?" You find rules that support it, then recursively check if their conditions are met.
It's detective work: start with the crime (goal), find the evidence (facts) that proves it.
How It Works (Step by Step)
Example: Troubleshooting a Computer That Won't Start
Goal: Determine why the computer won't start
Rules:
- Rule 1: IF power_button_works AND motherboard_powers_on THEN computer_starts
- Rule 2: IF power_supply_working AND power_reaches_motherboard THEN motherboard_powers_on
- Rule 3: IF outlet_has_power AND power_cord_intact THEN power_supply_working
Backward Chaining Process:
Goal: computer_starts = true
Step 1: Check Rule 1
"For computer_starts to be true, I need:
- power_button_works AND
- motherboard_powers_on"
Check: power_button_works?
Yes (we tested it)
Check: motherboard_powers_on?
Unknown. Make it a new sub-goal.
Step 2: Sub-goal: motherboard_powers_on = true
Check Rule 2:
"For motherboard_powers_on, I need:
- power_supply_working AND
- power_reaches_motherboard"
Check: power_supply_working?
Unknown. New sub-goal.
Check: power_reaches_motherboard?
Unknown. New sub-goal.
Step 3: Sub-goal: power_supply_working = true
Check Rule 3:
"For power_supply_working, I need:
- outlet_has_power AND
- power_cord_intact"
Test outlet with multimeter: outlet_has_power = true
Visually inspect cord: power_cord_intact = true
→ Conclusion: power_supply_working = true
Step 4: Back to Step 2
Now power_supply_working = true
Still need to check: power_reaches_motherboard?
(Test with multimeter) = true
→ Conclusion: motherboard_powers_on = true
Step 5: Back to Step 1
Now both conditions met:
- power_button_works = true ✓
- motherboard_powers_on = true ✓
→ Conclusion: computer_starts = true
Wait, it's already broken. What went wrong?
Hmm, let's check the power button more carefully...
(More testing reveals power button is stuck)
→ Real diagnosis: power_button_works = false
Back to Step 1: Goal still fails because power_button_works = false
→ Final answer: Power button is broken
That's backward chaining: start with goal, recursively verify preconditions, pinpoint the failure.
Forward vs. Backward Chaining (Clear Comparison)
| Aspect | Forward | Backward |
|---|---|---|
| Start | Known facts | Desired goal |
| Question | "What can I conclude?" | "Can I prove this?" |
| Direction | Facts → Goal | Goal → Facts |
| Search Style | Breadth-first (explore all) | Depth-first (focus on goal) |
| Efficient for | Many facts, explore all | Specific goal, direct proof |
| Real-world use | Monitoring, notifications | Diagnosis, troubleshooting |
| Example | "fever+cough → flu" | "Is this pneumonia?" |
When to Use Backward Chaining
1. Diagnosis Problems
You have symptoms. You want to identify the disease.
Example: Medical diagnosis
Goal: patient_has_pneumonia = ?
Need: high_fever AND productive_cough AND chest_xray_shows_infiltrate
Check each: Can I verify this fact?
Result: pneumonia confirmed or ruled out
2. Troubleshooting
Something's broken. You want to find the root cause.
Example: Network connectivity
Goal: internet_working = ?
Need: router_connected AND ISP_online AND DNS_responding
Check each: Where's the break?
Result: "ISP is down" or "DNS misconfigured"
3. Goal-Oriented Planning
You want to achieve X. Work backward to find steps.
Example: Trip planning
Goal: arrive_at_destination = true
Need: have_ticket AND transport_available AND leave_on_time
Check: Which of these is failing? Fix that.
4. Constraint Satisfaction
Multiple conditions must be true. Work backward from goal to find satisfying solution.
Example: Loan approval
Goal: approve_loan = true
Need: good_credit AND sufficient_income AND low_debt
Check each applicant: Do they satisfy all?
The Five-Step Backward Chaining Algorithm
Step 1: Define Your Goal
Be specific. "Is the patient sick?" is vague. "Does the patient have influenza?" is clear.
Step 2: List Conditions Supporting the Goal
What must be true for your goal to hold?
For "patient has influenza":
- High fever (>100°F)
- Cough
- Fatigue
- Negative strep test (rules out strep throat)
Step 3: Find Rules Connecting Conditions to Goal
Look for if-then rules that produce your goal.
Rule: IF high_fever AND cough AND fatigue AND not_strep THEN influenza
Step 4: Check Known Facts
Do the conditions match facts you already know?
Fact: fever = 101°F ✓ (matches high_fever)
Fact: cough = true ✓
Fact: fatigue = true ✓
Fact: strep_test = negative ✓
Step 5: Recursively Check Unsupported Conditions
If a condition isn't in your fact base, treat it as a new goal. Go back to Step 1.
Fact: high_fever = true (we have this)
Fact: chest_xray_shows_infiltrate = unknown (need to check)
Sub-goal: Get chest X-ray
Condition: Patient must be referred to imaging
Condition: Patient must consent
... recursively work through each
Real Backward Chaining Examples
Medical Diagnosis Example
Goal: Does patient have appendicitis?
Working backward:
├─ Need: acute_abdominal_pain
│ ├─ Check: Patient reports severe pain in lower right abdomen? ✓
│ └─ Fact confirmed
├─ Need: elevated_white_blood_cells
│ ├─ Check: WBC count? → 12,000 (high) ✓
│ └─ Fact confirmed
├─ Need: imaging_shows_inflammation
│ ├─ Check: CT scan available? → Book imaging
│ ├─ Check: Results show appendix inflammation? → Yes ✓
│ └─ Fact confirmed
├─ Need: no_other_cause
│ ├─ Check: Could be Crohn's? → No
│ ├─ Check: Could be ovarian cyst? → No
│ └─ Other conditions ruled out ✓
Conclusion: All conditions met → appendicitis confirmed
Recommendation: Surgery recommended
Software Debugging Example
Goal: Why is the website slow?
Working backward:
├─ Possible cause: database queries too slow
│ ├─ Check: Query logs show 500ms average? → Yes
│ ├─ Sub-goal: Which query?
│ │ └─ Result: User search query is unindexed
│ └─ Likely culprit found
├─ Possible cause: too much traffic
│ ├─ Check: Traffic spike in logs? → Yes, but not extreme
│ └─ Contributing factor, not main cause
├─ Possible cause: memory leak
│ ├─ Check: Memory usage over time? → Stable
│ └─ Not the cause
Conclusion: Unindexed database query is primary cause
Fix: Add index to user search table
Implementing Backward Chaining
Pseudocode
function prove(goal):
if goal in known_facts:
return TRUE
for each rule that concludes goal:
if all conditions of rule can be proven:
return TRUE
else if any condition is unknown:
recursively ask user for that condition
return FALSE
Simple Python Example
class BackwardChainer:
def __init__(self, facts, rules):
self.facts = facts
self.rules = rules
def prove(self, goal):
# Base case: if goal is already known
if goal in self.facts:
return self.facts[goal]
# Search for rule that could prove goal
for rule in self.rules:
if rule.conclusion == goal:
# Check if all conditions can be proven
conditions_met = all(
self.prove(condition)
for condition in rule.conditions
)
if conditions_met:
self.facts[goal] = True
return True
return False
# Usage
facts = {"fever": True, "cough": True}
rules = [
Rule(
conditions=["fever", "cough", "fatigue"],
conclusion="likely_influenza"
)
]
chainer = BackwardChainer(facts, rules)
result = chainer.prove("likely_influenza")
# Returns: Unknown (fatigue unknown)
Advantages of Backward Chaining
Goal-Focused
Only explores relevant facts. If you want to prove one thing, you investigate only that path. Efficient.
Efficient Resource Use
Doesn't compute unnecessary conclusions. Only tests what's needed.
Great for Specific Diagnosis
"Do I have disease X?" → backward chain answers it directly without exploring unrelated possibilities.
Natural Problem-Solving
Mirrors how humans troubleshoot: "Why is this broken?" Work backward to root cause.
Disadvantages of Backward Chaining
Depends on Correct Goal
If goal is wrong, entire search is wasted. "Is this pneumonia?" → spends time proving pneumonia when really it's asthma.
Can Miss Alternative Explanations
Focused on one goal means you might miss that multiple things could be true. (Forward chaining finds all implications.)
Harder with Deep Rule Chains
If you need 10 levels of sub-goals to prove something, backward chaining gets complex. Debugging recursive reasoning is hard.
Can Request Unknown Facts
"Is the patient's temperature > 100°F?" If you don't know, system asks you (interactive). Some applications can't ask.
Backward Chaining in Modern Systems
Not common in pure form anymore, but the idea appears everywhere:
Symbolic AI & Expert Systems: MYCIN, XCON used backward chaining
Prolog Language: Default reasoning strategy is backward chaining
Constraint Solvers: Work backward from goal to find satisfying solution
Theorem Provers: Backward chaining through logical rules
Modern AI (Limited): Neural networks don't really backward chain, but hybrid systems combining learning + rules do
When Backward Chaining Fails
Too many possible explanations: Patient has 50 possible diagnoses. Backward chaining would need to test each one. Forward chaining (observe symptoms → narrow to likely ones) is better.
Rules are circular:
Rule A: If X then Y
Rule B: If Y then X
Backward chaining: Prove X → Need Y → Need X → Loop
Missing facts can't be obtained: "To diagnose, I need a brain scan." → Patient refuses. → Can't complete proof. System stuck.
Backward vs. Forward: Choosing
Use Backward Chaining if:
- You have a specific goal to prove
- Rules form chains (not just networks)
- You can afford to ask for unknown facts
- You want to trace the reasoning path
Use Forward Chaining if:
- You have many facts and want to derive all implications
- You want to monitor and alert (reactive)
- Rules are independent
- You need to explain "everything that's true"
FAQs
Can I combine forward and backward chaining? Yes! Many systems do: forward chain to gather likely conclusions, then backward chain to verify. Called "bidirectional chaining."
Why is backward chaining recursive? Because sub-goals become new goals. To prove A, you need B. To prove B, you need C. Recursion naturally expresses this.
How do I handle multiple rules for same goal? Try each rule. If any succeeds, goal is proven. If all fail, goal can't be proven.
What if a fact is unknown? Ask the user, look it up in a database, or mark as "cannot determine." Different systems handle this differently.
Is backward chaining used in modern AI? Rarely in pure form. Mostly replaced by neural networks. But hybrid systems combining learning + rules use backward chaining concepts.
Next up: Explore Heuristics—the mental shortcuts that make quick decisions possible without complete information.