Must a fact be an English sentence?

No. It may be a logical expression, a structured record or another representation with a defined meaning.

Can a system's fact be wrong?

Yes. The system may treat an assertion as true even when its source, mapping or timing is wrong.

Is a derived fact different from an input fact?

Their reasoning roles can overlap, but their provenance differs. A derived assertion depends on supporting premises and rules, which should remain traceable.

AI Glossary / Graphs and symbolic AI / Beginner

Fact

Definition

A fact, in a symbolic knowledge system, is an assertion treated as true for the purposes of reasoning. In a simple rule-based representation, it is commonly a statement supplied without a condition, such as Available(RoomA). Calling an assertion a fact in the system does not independently verify that it matches the real world.

What it means

Facts provide starting points for inference. A system can combine them with rules to derive further conclusions: an available room and a rule about bookable rooms might support a booking-related conclusion. This separates the information stored from the procedure used to reason with it.

The word has a narrower technical role here than in everyday discussions of truth. A database entry may be outdated, a sensor observation may be mistaken, and an imported assertion may come from an unreliable source. Reliable applications preserve where assertions came from and the context in which they apply, instead of assuming that formal storage makes them unquestionably correct.

How it works

A designer defines a vocabulary of objects, properties and relationships. Facts use that vocabulary to assert particular information, for example LocatedAt(Box7,Shelf2). A ground assertion contains no variables; a general rule can use variables to apply across many objects.

In definite-clause reasoning, a fact can be represented as a clause with a conclusion and no premises. A forward-chaining engine starts from available facts and applies rules whose premises are satisfied. A backward-chaining engine starts from a query and looks for facts or rules that support it.

The interpretation of missing information depends on the system. Under an open-world reading, failure to establish a statement does not establish its negation. Some database and logic-programming settings use closed-world assumptions or negation-as-failure instead. Those choices must be explicit because the same stored assertions can support different operational answers under different assumptions.

Three practical examples

1. An inventory knowledge base records LocatedAt(Parcel8,Bay3). A query can retrieve the recorded location, but the application must also consider when that location was observed and whether the parcel has since moved.

2. A rule-based assistant records Submitted(Form12) and Signed(Form12). A rule requiring both can infer ReadyForReview(Form12), provided those predicates have the intended meanings.

3. A robot stores DoorOpen(Door2,Time5) from an observation. Including the time prevents that assertion from silently becoming a permanent claim that the door is always open.

Think of it this way

Think of facts as labeled cards on a reasoning desk and rules as instructions for combining cards. The desk can produce a new conclusion when the necessary cards are present. The analogy stops at trust: a neatly printed card can still contain a mistake, and removing or correcting a card may require reconsidering conclusions that depended on it.

Worked example

Suppose a small knowledge base contains three facts: Submitted(FormA), Signed(FormA), and Submitted(FormB). It also contains the rule: for any form x, Submitted(x) and Signed(x) together imply ReadyForReview(x).

For FormA, both premises are available, so the rule derives ReadyForReview(FormA). For FormB, only Submitted(FormB) is available. The knowledge base does not establish ReadyForReview(FormB) using this rule.

Under an open-world interpretation, that lack of support does not prove that FormB is unsigned or not ready. Its signature information may simply be missing. If Signed(FormB) is later added, the same rule can derive ReadyForReview(FormB). Conversely, learning that a stored signature assertion was erroneous requires a defined correction process; simply retaining an earlier derived conclusion could leave the system inconsistent with its updated evidence. The example demonstrates logical support, not an actual document-verification procedure.

Illustrative case study

Fictional case study: Birch Services builds an assistant that answers questions about submitted requests. An import labels every listed request as Approved, even though the source spreadsheet's column actually means Received. The rule engine then produces internally consistent but inappropriate follow-up recommendations.

The team corrects the mapping, distinguishes receipt from approval and records source fields for imported assertions. It also reviews conclusions derived from the mistaken facts. The case shows that correct inference cannot repair an incorrect vocabulary mapping by itself. No measured operational outcome or real organization is implied.

Common misconceptions and mistakes

A fact is not a rule: it supplies information without the rule's conditional structure. Nor is every sentence in a knowledge base a fact in the narrow definite-clause sense; knowledge bases can contain disjunctions, negations and other expressions.

Absence from storage is not universally equivalent to falsity. Likewise, a confidence score is not automatically a logical truth value. If uncertain observations are converted to categorical assertions, document that decision and its limitations. Finally, changing facts are not timeless: identity, location, status and other context can matter to whether an assertion remains appropriate.

Business use

For a business knowledge system, define each predicate so that different teams record the same concept consistently. Preserve source, observation time and relevant scope, especially when records change. Separate directly supplied assertions from derived conclusions so reviewers can understand how an answer was obtained.

Establish a way to correct or retract mistaken information and reconsider dependent results. Decide how missing and contradictory information should be handled before using the system to trigger actions. These practices make a fact-based system easier to audit without implying that every assertion can be made certain or permanently valid.

Check your understanding

Does the absence of Signed(FormB) prove that FormB lacks a signature?

Answer: Not under the worked example's open-world interpretation. It means the signature is not established by the available assertions. A closed-world policy would be an additional modeling choice, not a consequence of missing text alone.

Related terms

Knowledge base
Predicate (logic)
Definite clause
Inference
Forward-chaining
assertion
predicate
ground atom
open-world assumption
provenance

Learn next

Practice separating input facts, rules and derived conclusions in a small example. Then compare open-world reasoning with negation-as-failure and study how a system tracks dependencies when an assertion is corrected.

Sources

Primary source: Russell and Norvig, “Logical Agents,” including knowledge bases, entailment and Horn-clause reasoning: https://aima.cs.berkeley.edu/slides-pdf/chapter07.pdf . The discussion here uses the symbolic-reasoning sense of fact. The forms example and fictional case are original illustrations, not evidence that the represented real-world claims were verified.

Previous: Facial recognition Next: Fact table