Is classical propositional logic monotonic?

Yes. Adding premises preserves existing entailments, including the consequences of the original premises.

Does monotonicity prevent contradictions?

No. Added premises can conflict with existing ones. Monotonicity and consistency are separate properties.

Is nonmonotonic reasoning necessarily unreliable?

No. It can be appropriate for defeasible conclusions that should change when exceptions or more specific information become available.

AI Glossary / Graphs and symbolic AI / Intermediate

Monotonicity

Definition

In logical reasoning, monotonicity is the property that adding premises cannot remove conclusions already entailed by the original premises. If a knowledge base entails a statement, a larger knowledge base containing all the original statements still entails it. This entry focuses on logical monotonicity; the same word has other meanings in mathematics, preferences, and search.

What it means

Suppose a rule and a fact establish that a document is eligible for archiving. Adding an unrelated fact about its author does not invalidate that deduction. In a monotonic logic, the original reasoning remains available because its premises have not been removed.
This is different from ordinary defeasible reasoning, where a tentative conclusion may be withdrawn after an exception is learned. “Documents normally become public” is not the same as an exceptionless rule that every document becomes public. The distinction determines whether new information extends a set of conclusions or requires revising a previous assumption.

How it works

Write KB entails P for a conclusion that holds in every model satisfying the knowledge base. If additional premises are added, the set of satisfying models can only shrink. Every remaining model already satisfied P, so P remains entailed.
In proof terms, a proof using the original premises can still use those same premises after additions. Monotonicity does not apply to deleting, replacing, or correcting premises, because those operations do not simply enlarge the knowledge base. Nor does it mean that every software system immediately computes all newly available conclusions; logical entailment and an implementation's resource-limited search are different matters.

Three practical examples

A theorem prover can retain a valid proof when additional assumptions are introduced, provided the original assumptions remain available.
A symbolic knowledge system can add classification facts without retracting previously entailed classifications under its monotonic rules.
A rule-language designer can decide whether exception handling requires nonmonotonic semantics instead of treating defaults as universal implications.

Think of it this way

Think of keeping a completed proof in a folder and adding more supporting pages. The original proof still uses the pages it used before. The analogy is limited because added pages can also create contradictions, and a corrected or removed page changes the situation. Monotonicity describes the formal consequence relation, not the reliability of everything placed in the folder.

Worked example

Use an invented knowledge base with the fact Signed(Form7) and the rule “for every document x, Signed(x) implies Recorded(x).” It entails Recorded(Form7).
Now add Archived(Form7). The original entailment remains. Add a new rule Archived(x) implies Retrievable(x), and the expanded base also entails Retrievable(Form7). No original premise was removed, so this is monotonic growth.
Next consider a different operation: replace Signed(Form7) with a correction stating NOT Signed(Form7), and remove the original signing fact. The original proof of Recorded(Form7) is no longer supported. This is not a failure of monotonicity because the revised base is not a superset of the original.
Finally, simply adding NOT Recorded(Form7) while retaining all original premises creates a contradiction in classical logic. It does not automatically cancel Recorded(Form7). Under classical entailment, an inconsistent base entails every formula because it has no satisfying model. That makes inconsistency a serious modeling issue, not a successful way to implement corrections.

Illustrative case study

In a fictional internal document system, an analyst encodes “all project notes are shareable” as a universal rule. A later confidential label appears to require retracting a shareable status. The developer discovers that the intended statement was a default with exceptions, not an exceptionless fact.
The team separates policy defaults from definitive classification rules and chooses a mechanism that supports the intended exception behavior. It also records when source facts are corrected instead of merely appending contradictory records. The scenario illustrates a knowledge-design decision; it does not report a real information leak or claim that one logic is best for every policy system.

Common misconceptions and mistakes

Do not interpret monotonicity as “the system never changes its mind” without qualification. A system may revise its knowledge base, receive corrected data, or use nonmonotonic rules alongside monotonic inference. The formal property concerns adding premises while preserving the original ones.
Do not confuse lack of proof with proof of negation. Treating an unrecorded exception as false can introduce closed-world or default assumptions that need their own semantics. Also avoid conflating logical monotonicity with an increasing numerical function, a consistent search heuristic, or monotonic preference. Those uses involve different objects and different conditions.

Business use

For business systems, the distinction helps explain how new records affect earlier conclusions. Stable, exceptionless relationships can suit monotonic reasoning. Policies involving “normally,” “unless,” or “until corrected” need additional care because their intended behavior often includes withdrawal or revision.
Ask what happens when an exception arrives, a measurement is corrected, or two systems disagree. The answer should be explicit in the data and reasoning design. Keep source assertions separate from derived conclusions, so a revised assertion can trigger appropriate recomputation. A claim that inference is monotonic does not remove the operational need for correction workflows and consistency checks.

Check your understanding

A knowledge base entails Eligible(Request2). A new fact about Request3 is added without deleting anything. Can that addition alone make the original statement cease to be entailed in a monotonic logic?

Answer: No. The original entailment remains. Whether a program displays or recomputes it correctly is a separate implementation question.

Related terms

Learn next

Write “members normally receive a discount” as a default and add an exception for a suspended membership. Compare that intended behavior with an exceptionless implication. Then study belief revision, where adding reliable new information may require removing or changing old assumptions rather than merely extending the premise set.

Belief revision

Sources

Sources: Russell and Norvig, Artificial Intelligence: A Modern Approach, Logical Agents chapter, monotonicity discussion and formal entailment condition: https://aima.cs.berkeley.edu/4th-ed/pdfs/newchap07.pdf . The document examples, correction sequence, and business case are original illustrations of the stated semantics.

Previous: Monotonic relationship Next: Monte Carlo