Does backward chaining require Prolog?

No. Prolog is a well-known related setting, but the inference strategy can be implemented in other systems.

Can it ask users for missing facts?

Yes, if the application includes that interaction; the inference method itself does not require it.

Can it work with forward chaining?

Yes. A system may precompute useful consequences and then use goal-directed reasoning for specific queries.

AI Glossary / Graphs and symbolic AI / Intermediate

Backward-chaining

Definition

Backward chaining is a goal-directed inference method that starts with a question and works backward through rules that could establish its answer. It tries to prove the conditions of those rules, continuing until it reaches known facts or cannot support the required subgoals.

What it means

Suppose a system needs to establish whether an item is ready for collection. Instead of deriving every possible consequence of every stored fact, it looks for rules whose conclusion is that the item is ready. Their conditions become the next questions to answer.

This contrasts with forward chaining, which begins with available facts and applies rules to derive further facts. Both can use the same domain knowledge, but they organize the work differently. Backward chaining is particularly natural when a user asks a specific question.

The procedure is not reasoning backward in physical time or assuming that an effect proves its cause. A rule is used as a possible route to establish a goal, and its conditions still need to be checked.

How it works

The inference engine first checks whether the goal matches a known fact. Otherwise, it finds rules with conclusions that can match the goal, potentially binding variables to specific objects. Each selected rule introduces the conditions that must be established.

If a rule requires several conditions, all must succeed for that rule to support the goal. Different rules can provide alternative routes. A failed route can lead the engine to try another rule or different variable bindings. This creates an AND/OR search structure: conditions within one rule act like AND, while alternative rules act like OR.

Cycles and repeated subgoals require care. A rule that eventually asks for the original goal again can create an unproductive loop. Implementations may use ordering, cycle detection or tabling to manage such behavior. Whether failure means “false” or merely “not established” depends on the logic and assumptions used.

Three practical examples

A customer-support assistant checks which conditions establish eligibility for a replacement under explicitly encoded service rules.
A maintenance expert system starts from a proposed diagnosis and asks which observations would support the relevant diagnostic rule.
A course-planning tool checks whether a learner satisfies a prerequisite by examining completed courses and permitted equivalence rules.

Think of it this way

Think of assembling evidence for a checklist item. You begin with the desired conclusion, identify what would justify it and gather those supporting pieces.

The analogy has a limit: wanting a conclusion does not make its evidence true. A backward-chaining system must establish the required conditions, and one failed route does not rule out every other possible justification.

Worked example

Proving one collection request

Consider a rule stating that Ready(order) follows when Packed(order) and Paid(order) are both true. A second rule states that Paid(order) follows when CardCleared(order) is true. The known facts are Packed(Order9) and CardCleared(Order9).

The query is Ready(Order9). Matching the first rule creates two subgoals: Packed(Order9) and Paid(Order9). The first is already a fact. To establish the second, the engine uses the card-cleared rule and creates CardCleared(Order9), which is also a fact. Both required conditions therefore succeed, supporting Ready(Order9).

Now remove CardCleared(Order9) without adding any other payment evidence. This proof route no longer establishes readiness. It does not automatically establish that the order is unpaid in every possible interpretation. The application must state whether missing payment evidence is treated as unknown, false or a reason to request verification.

Illustrative case study

Fictional case: Elm Learning checks whether students may enter an advanced workshop. Its rules accept either a completed introductory course or an approved equivalent. The first implementation stops when the introductory-course fact is absent and incorrectly rejects learners with an approved equivalent.

The developers ensure that the engine explores the alternative rule and preserves the corresponding explanation. They also distinguish a confirmed unmet prerequisite from an unresolved record that needs review.

The lesson is that a goal may have several legitimate proof paths. A useful system must respect the rule structure and the meaning of missing information, rather than turning the first unsuccessful lookup into a final decision.

Common misconceptions and mistakes

It proves a cause whenever an effect is observed. It searches rules that could establish the requested conclusion; it does not reverse implications indiscriminately.
Every condition in every rule must hold. All conditions within a selected rule must hold, but alternative rules can supply other proofs.
Failure always proves the opposite. That depends on the formalism and completeness assumptions.
Goal-directed search never repeats work. Recursive rules can revisit the same subgoals.
A successful proof validates the rule itself. Incorrect domain rules can support incorrect real-world decisions.

Business use

Backward chaining supports question-driven expert systems and rule-based decision services. It can produce a useful explanation showing which facts and rules supported an answer.

Define the rule owners, the source of each fact and the treatment of missing or contradictory records. Test alternative proof routes and recursive relationships, not only straightforward successful examples. If users can change information during an interaction, ensure that previously established subgoals are reconsidered when their evidence changes. The operational benefit depends on trustworthy knowledge as well as an effective inference procedure.

Check your understanding

Two rules can establish Approved(x). The first requires A(x), and the second requires B(x). A(x) fails, but B(x) is a known fact. Should the goal necessarily fail?

Answer: No. The second rule provides an alternative proof route. The engine should consider it according to the system's search and inference semantics.

Related terms

Forward-chaining
Inference
Goal
Unification
subgoal
rule-based system
logic programming
tabling

Learn next

Write a goal with two alternative supporting rules, one of which requires two conditions. Draw its AND/OR proof tree and mark which leaves are known facts. Remove one fact and identify which proof routes remain. Study unification next to see how the same rule can answer queries about different objects.

Sources

AIMA glossary, backward-chaining, defines the goal-directed procedure: https://github.com/aimacode/aima-glossary/blob/master/glossary.md?plain=1

AIMA Logic subsystem documentation provides a concrete Horn-clause backward-chaining reference: https://aima.cs.berkeley.edu/lisp/doc/overview-LOGIC.html

The order and fictional learning examples are original illustrations of proof paths and missing evidence.

Previous: Backus-Naur form Next: Backward elimination