Is a justification always a complete proof?

No. It may record one local inference or assumption-dependent reason; a complete proof can require following a larger chain.

Can one conclusion have many justifications?

Yes. Independent routes of support are common and matter when information changes.

Does an inactive justification have to be deleted?

Not necessarily. Keeping it can allow the system to reactivate the conclusion if its conditions later become satisfied, depending on the implementation.

AI Glossary / Graphs and symbolic AI / Intermediate

Justification

Definition

A justification is an explicit record of the reasons or conditions supporting a conclusion. In symbolic AI and truth-maintenance systems, it connects a proposition to supporting propositions, assumptions or an inference step so that the conclusion can be explained and reconsidered when its support changes.

What it means

A conclusion and its justification are different objects. The conclusion states what the system accepts; the justification records why it is accepted within the reasoning model. A conclusion may have several independent justifications.

In a simple rule-based setting, a justification identifies a consequent and the antecedents needed to support it. A rule identifier or other origin information can help explain where that relationship came from.

This technical meaning is narrower than any persuasive explanation. A fluent account written after a decision is not necessarily a faithful record of the reasoning that produced it. Likewise, a support record can be internally well-formed while relying on an incorrect rule or unreliable input.

How it works

When a reasoner applies a rule, it can record the instantiated supporting facts and the resulting conclusion. For a positive justification, every required antecedent must be accepted for that justification to be active.

The system tracks which conclusions depend on each supporting item. If an assumption is withdrawn, it checks affected justifications and updates conclusions that no longer have support. Alternative justifications can preserve a conclusion even when one route fails.

Different reasoning frameworks use different conditions. A nonmonotonic justification may depend on some proposition not being currently accepted, which is distinct from a classical proof of its negation. The framework must also distinguish premises from conclusions that merely refer back to each other. A cycle of unsupported explanations does not provide an independent foundation for belief.

Three practical examples

A configuration assistant records the compatibility facts and rule that support a proposed component combination.
A symbolic diagnostic model shows which tentative observations support one candidate explanation.
A rule-based workflow identifies the remaining reason for a status after one input assumption has been withdrawn.

Think of it this way

Think of attaching supporting documents to a conclusion in a review file. One document may be essential to a particular argument, while another complete argument might independently support the same conclusion.

The analogy explains traceability and alternative support. A formal justification represents a specified dependency; it does not automatically evaluate the credibility of a document or turn a weak argument into a valid one.

Worked example

Two different ways to support one conclusion

Consider a fictional planning model for a demonstration kit. Let I mean InspectionRecorded, P mean PackagingRecorded and C mean IndependentReadinessCertificate. The target conclusion R is ReadyForDemo.

Justification J1 says that I and P together support R. Justification J2 says that C supports R. Initially I, P and C are accepted, so both justifications are active. J1 has two required antecedents; J2 has one. This is not a vote in which three supporting facts are counted as three interchangeable reasons.

Now withdraw P. J1 becomes inactive because one of its required conditions is missing. J2 remains active because C is still accepted, so R retains support. The explanation should identify the certificate route rather than claiming that inspection alone was sufficient.

Next withdraw C. Neither J1 nor J2 is active, so R is unsupported in this model. If P is later restored while I remains accepted, J1 becomes active again and supports R.

The example exposes a representation distinction. Replacing J1 with two separate rules, I supports R and P supports R, would change the logic from requiring both conditions to allowing either one. Explanations must preserve that distinction. Finally, unsupported ReadyForDemo does not by itself establish NotReadyForDemo unless the system explicitly represents a rule or fact supporting that negative conclusion.

Illustrative case study

The fictional Birch Explanations team adds an explanation panel to a symbolic configuration tool. Its first version lists all nearby facts as reasons, even when some facts were not used by an active justification.

Reviewers compare the displayed text with the actual support records. They separate mandatory antecedents within one reason from independent alternative reasons and test the display after assumptions are withdrawn. They also show the rule origin so that a reviewer can inspect the modeled dependency.

Birch treats a missing recorded reason as a gap to investigate, rather than filling it with plausible prose. This fictional case illustrates faithful explanation design and dependency review.

Common misconceptions and mistakes

A justification is the same as the conclusion. It is the support relationship, not the claim itself.
Every listed supporting item is independently sufficient. Some reasons require several antecedents together.
Removing one reason necessarily invalidates the conclusion. Another active justification may remain.
A convincing narrative is automatically a faithful justification. It must match the evidence and inference actually recorded.

Business use

Justifications can help users inspect symbolic decisions, identify brittle assumptions and understand the effect of changing an input. They are particularly useful when a conclusion must be revisited rather than merely displayed once.

A useful explanation should state the active reason, its required inputs and its origin at a level appropriate for the reviewer. Keep observed facts, assumptions and derived statements distinguishable. Also provide a way to review the rule itself: tracing a faulty rule perfectly still produces a faulty explanation of reality. Dependency transparency supports scrutiny, but it is not a substitute for checking evidence quality and model validity.

Check your understanding

Why does ReadyForDemo remain supported immediately after PackagingRecorded is withdrawn?

Answer: The inspection-and-packaging justification fails, but the independent certificate justification remains active. The conclusion therefore still has a valid recorded support in the model.

Related terms

JTMS
Antecedent
Premise
Proof
Truth maintenance system
consequent
assumption
dependency
explanation fidelity

Learn next

Draw J1 and J2 from the worked example as two separate support relationships. Mark which antecedents are required together, then trace every change after withdrawing inspection instead of packaging. Write an explanation that names only the surviving active reason.

Sources

Forbus and de Kleer's implementation explicitly represents antecedents, consequences and the origin of a justification: https://www.qrg.northwestern.edu/BPS/jtms/jtms.lisp

Their companion examples show how recorded support changes with assumptions: https://www.qrg.northwestern.edu/BPS/jtms/jtms-ex.lisp

Forbus's primary research distinguishes accepted status, well-founded support and truth-maintenance variants: https://www.qrg.northwestern.edu/papers/Files/QRG_Dist_Files/QRG_1988/Forbus_1988_QPE_journal_article.pdf

The kit rules and Birch Explanations case are original examples. Justification here has its symbolic-reasoning meaning.

Previous: Junction tree algorithm Next: k-anonymity