Does adding information always remove a conclusion?

No. Nonmonotonicity means that this can happen, not that every update must reverse something.

Is a withdrawn conclusion automatically false?

No. It may simply lack sufficient support under the revised knowledge and rules.

Does classical logic become nonmonotonic when contradictory facts are added?

No. Classical entailment remains monotonic; handling contradiction through revision or alternative semantics is a separate choice.

AI Glossary / Graphs and symbolic AI / Intermediate

Nonmonotonicity

Definition

Nonmonotonicity is the property of a reasoning system in which adding information can invalidate a previously supported conclusion. It allows conclusions based on defaults or incomplete knowledge to be withdrawn when an exception becomes known. The term contrasts with monotonic inference, where conclusions already entailed remain entailed after additional premises are added.

What it means

An intelligent system often needs to make provisional assumptions. A room may normally be treated as available when the booking register contains no reservation, or a delivery may normally follow its standard route unless a closure is known. New evidence can defeat those assumptions without making the reasoning arbitrary.

The key is that a conclusion depends on more than explicit positive facts: it may also depend on the absence of an exception or on a preferred interpretation. Nonmonotonicity describes this relationship between knowledge and conclusions. It is not simply another word for changing one's mind or correcting a typing error.

How it works

In monotonic logic, if knowledge base K entails statement P, then adding premises to K does not remove that entailment. A nonmonotonic consequence relation can fail this condition: K supports P, but an expanded knowledge base no longer supports P.

One common approach uses a default such as “if A holds and no exception B is established, conclude C.” Learning B blocks the default. The system must track or recompute dependent conclusions so that downstream results do not remain based on defeated assumptions.

Different formal systems implement these ideas differently, including default logic, circumscription, and forms of negation-as-failure. Conflicting defaults may require priorities or a semantics for alternative acceptable interpretations. Withdrawing C does not necessarily establish its explicit negation; the revised state may simply leave C undecided.

Three practical examples

Scheduling support: provisionally treat a resource as usable unless an applicable unavailability exception is known.
Knowledge-based assistants: apply ordinary-case rules while revising conclusions when a specific exception arrives.
Configuration reasoning: maintain explanations showing which defaults support a recommendation and what new facts would defeat it.

Think of it this way

Think of writing a plan in pencil because some steps depend on assumptions that have not yet been contradicted. New information can erase a penciled conclusion while leaving confirmed facts intact.

The analogy has limits: a formal nonmonotonic system needs explicit rules for what can be assumed and when revision is justified. It is not permission to discard inconvenient evidence or to change conclusions without a traceable reason.

Worked example

Consider a small room-allocation model. A default says: if a room is listed for use and no maintenance exception is known, infer that it is provisionally usable. A second rule says: if a room is provisionally usable and has sufficient capacity, infer that it is a candidate for a workshop.

Initially, the facts are Listed(Room7) and SufficientCapacity(Room7). There is no known Maintenance(Room7). Under the stated default policy, the system derives ProvisionallyUsable(Room7), then Candidate(Room7).

Now add Maintenance(Room7), without deleting either original fact. The default's condition is defeated. ProvisionallyUsable(Room7) is no longer supported by that default, and Candidate(Room7) loses its support through the second rule, assuming no other rule independently establishes it.

This is nonmonotonic because adding a fact reduces the supported conclusions. It does not require asserting that the room has insufficient capacity, nor does it automatically derive an explicit NotCandidate statement. If another independent rule supported Candidate(Room7), the system would need to consider that support separately. The example is a rule trace under an explicitly chosen default semantics, not a universal interpretation of missing maintenance records.

Illustrative case study

Fictional case: a venue assistant recommends rooms using ordinary availability defaults. After maintenance updates arrive, the interface changes the status flag but continues displaying an earlier recommendation cached elsewhere.

The team links recommendations to their supporting facts and assumptions, so a defeated default triggers reevaluation of dependent conclusions. It also explains that “no longer supported” may differ from “explicitly prohibited.” The fictional case illustrates dependency maintenance, not a measured operational improvement or a complete implementation of a particular nonmonotonic logic.

Common misconceptions and mistakes

Nonmonotonicity is not the same as ordinary deletion from a database. Any system can lose conclusions when supporting premises are removed. The distinctive feature here is losing a conclusion when information is added under the reasoning system's rules.

It also differs from numerical nonmonotonicity, where a function may rise and then fall. This entry concerns logical consequence and knowledge representation, not the shape of a plotted curve.

Do not use “normally” as though it were an unconditional classical implication. If every A is asserted to imply C, later discovering an A that is not C creates a conflict with that universal claim. A defeasible default has different semantics from the beginning.

Business use

Nonmonotonic reasoning can make rule-based products more useful when complete information is unavailable and ordinary cases have exceptions. The design must specify which missing facts justify assumptions, who maintains exception data, and how changes propagate.

Show users the assumptions behind consequential recommendations. A statement such as “candidate because no maintenance exception is recorded” communicates more than an unexplained definitive label. Teams should also test conflicting defaults, delayed updates, and multiple independent supports for the same conclusion.

Check your understanding

A default-supported recommendation disappears after an exception fact is added, while the original facts remain. Which property does this illustrate?

Answer: Nonmonotonicity, because additional knowledge defeats a previously supported conclusion.

Related terms

Circumscription
Closed-world assumption
Belief revision
default reasoning
defeasible inference
negation as failure
truth maintenance
exception

Learn next

mark each conclusion in a small rule system with its supporting facts and defaults. Add an exception and trace which conclusions lose support, then compare that process with ordinary classical implication.

Sources

Poole and Mackworth explain nonmonotonic reasoning and defaults: https://artint.info/html1e/ArtInt_129.html

John McCarthy discusses the need for nonmonotonic reasoning in the development of circumscription: https://www-formal.stanford.edu/jmc/circumscription/node2.html

The room-allocation trace and fictional venue assistant are original illustrations. Their missing-information policy is explicit and should not be assumed appropriate for every application.

Previous: Nonmetric multidimensional scaling Next: Nonparametric density estimation