Can a default rule have no substantive prerequisite?

Yes. A prerequisite-free default can license an assumption whenever its justification is consistent under the selected semantics.

Does an exception disprove the general default?

Not necessarily. A rule intended to admit exceptions can remain useful while failing to apply in a particular case.

Can two defaults disagree?

Yes. A reasoning system needs a defined interpretation or priority policy; silently choosing whichever happens to run first can conceal ambiguity.

AI Glossary / Graphs and symbolic AI / Intermediate

Default rules

Definition

Default rules are rules that permit a provisional conclusion when stated conditions hold and no relevant defeating information prevents the inference. They represent what may reasonably be assumed in an incomplete model while allowing exceptions to change the result.

What it means

A default rule fills a specified gap in knowledge. For example, a workflow model might assume that an ordinary request uses the standard queue unless evidence supports a different route. The conclusion is an assumption with a reason, not an established fact about every request.

In Reiter's default logic, defaults have a formal consistency-based meaning. Other rule systems use different exception or priority mechanisms, so the phrase alone does not identify a universal execution procedure.

A default rule is also different from a software setting selected when a user leaves a field blank. That setting can be a simple deterministic convention, whereas a reasoning default concerns which conclusions are supported.

How it works

A common formal pattern has three parts: a prerequisite, a justification and a consequent. The prerequisite must be established; the justification must be consistent with the accepted beliefs; the consequent is then licensed by the rule. When the justification equals the consequent, the default is called normal.

A rule can be written informally as: given A, if assuming B remains consistent, conclude C. It is not the classical implication A implies C, because the consistency condition can stop it from applying.

The surrounding semantics matter. Conflicting defaults may support alternative extensions rather than a single answer. Priorities and exception policies can be added in particular frameworks, but they should be stated explicitly. Recording which default supports a conclusion helps a system identify what must be reconsidered when information changes.

Three practical examples

Product knowledge: A catalog assistant assumes a usual accessory relationship unless a model-specific incompatibility is known.
Administrative routing: An assistant proposes the ordinary queue for a request while preserving explicit exceptions.
Symbolic interpretation: A knowledge-based language system uses an explicitly represented typical situation as a provisional interpretation, subject to additional context.

Think of it this way

Think of a meeting organizer using the usual room until told that the room is unavailable. The organizer can plan without waiting for every fact, but the room choice remains conditional. The analogy does not imply that default logic books rooms or determines the best fallback; it illustrates why a useful assumption should remain distinguishable from confirmed information.

Worked example

Consider three requests: R1, R2 and R3. The known facts say that R1 and R2 are ordinary. A further fact says that R2 must not use the standard queue. There is no information about whether R3 is ordinary.

Use one normal default: if a request is ordinary and StandardQueue(request) is consistent with the accepted beliefs, conclude StandardQueue(request).

For R1, the prerequisite is established and there is no contrary information in this small theory. The default supports StandardQueue(R1).

For R2, the prerequisite is established, but the explicit ¬StandardQueue(R2) fact blocks the justification. The default does not support StandardQueue(R2).

For R3, the prerequisite has not been established. The system cannot use this rule merely because it lacks a known exception. Thus, only one of the three requests receives a standard-queue conclusion from this rule.

Now add ¬StandardQueue(R1). Its former default conclusion loses support. By contrast, simply deleting a fact about an unrelated request would not explain why R1's conclusion should change.

This example separates three states that an interface should avoid collapsing: supported by default, explicitly contradicted, and not established because the prerequisite is unknown. None of them is a numerical confidence score.

Illustrative case study

Fictional case: Willow Parts builds an assistant that suggests commonly paired components. Its first design stores the suggestion as if it were a confirmed compatibility statement.

When an engineer adds an incompatibility for one component revision, the old suggestion remains in downstream summaries. The team changes the data model to record whether a statement is an explicit fact or a default-derived suggestion, along with its supporting rule and component revision.

A change now triggers reconsideration of affected suggestions. The interface explains that a usual pairing was withdrawn because a specific incompatibility became known. The team separately tests conflicting rules and unknown prerequisites. The example shows why provenance and revision handling matter even when an individual default sounds simple.

Common misconceptions and mistakes

No known exception means every default applies. Its prerequisite and other conditions still need to be satisfied.
A default conclusion is indistinguishable from a fact. Treating them identically can hide what new evidence should overturn.
The last rule in a list always wins. That is an implementation policy, not a universal property of default reasoning.
A default is a probability estimate. It can express a defeasible assumption without specifying how frequently it is true.

Business use

Default rules can make a knowledge system practical when incomplete records would otherwise halt every recommendation. They also make implicit assumptions visible enough to inspect and challenge.

For each rule, document its scope, prerequisite, defeating information and intended conflict handling. Keep default conclusions separate from final action permissions. Test cases with missing prerequisites, explicit exceptions and competing defaults. When changing a rule, identify conclusions that depended on it rather than assuming that adding new facts will automatically repair every cached output.

Check your understanding

A default says that ordinary requests normally use queue S. A request has no known restriction, but its status as ordinary is unknown. Does this rule establish queue S?

Answer: No. The missing restriction does not supply the prerequisite. A separate rule or fact would be needed to establish that the request is ordinary.

Related terms

Default logic
Justification
defeasible rule
exception handling
prerequisite
nonmonotonic reasoning
rule priority
truth maintenance

Learn next

Extend the worked example with an independently justified alternative queue. Write down whether each request has a fact, a default conclusion or no established route. Then add a conflicting default and specify how the application should report the resulting ambiguity.

Sources

Reiter's original paper establishes the formal default-reasoning approach: https://www.sciencedirect.com/science/article/pii/0004370280900144

Reiter and Criscuolo examine how default knowledge is represented: https://www.cs.ubc.ca/tr/1980/tr-80-07

Rychlik states default-rule components and compares extension semantics: https://cdn.aaai.org/AAAI/1991/AAAI91-058.pdf

The request-routing example and Willow Parts case are original illustrations. Broader rule-engine terminology may use different default semantics.

Previous: Default logic Next: Defective matrix