Glossary
Closed-world assumption
Under the closed-world assumption, a statement absent from a defined complete dataset is treated as false within that dataset's scope.
Knowledge fusion
The closed-world assumption interprets missing statements as false, but only relative to a declared universe of facts. It is useful when a dataset is complete for a particular question, such as all transactions posted in a closed accounting period. It should never silently extend beyond that scope. A registry complete for one class of entities may be incomplete for another.
Practitioners must specify what is closed: the entities, properties, dates and data refresh state. A negative result from a query then has a precise meaning. Without those boundaries, an empty field could mean uncollected, withheld, not applicable or genuinely absent. Changes in coverage or reporting lag can invalidate a previously reasonable completeness assumption.
An organization defending a negative conclusion needs evidence for the dataset's completeness as well as evidence that the search was correctly run. Open-world reasoning is safer where completeness is unproven. Null semantics records the distinct reasons for an empty result; a closed-world policy may justify one of those reasons but cannot erase the others by default.
Example
A Halden Therapeutics AG (fictional) ledger declared complete for June has no June payment to a vendor; that scoped absence says nothing about July.
Origins and where it holds by default
The closed-world assumption was formalised by Reiter in his 1978 paper on closed-world databases: if a fact cannot be derived from the database, it is taken to be false. It is the default reading of a relational database. If an employee table has no row for a person, a query for that person returns nothing and the application treats the person as not an employee. It is also the reading behind a missing key in a configuration file or a missing line in an allow list. The Wikipedia article gives a concise statement and contrasts it with the open-world assumption used in much web reasoning.
The assumption is justified when the dataset is a complete account of a defined scope, such as every transaction in a ledger for a period or every user in a directory. It is unjustified when the dataset is a sample, a partial extract or a record that depends on someone having chosen to enter the fact. The error arises when a scope that was true at design time stops being true: a table that once held every customer is joined with a feed that holds only some.
Making closure explicit
The defence is to make closure a stated property of a collection, not an unexamined default. A record of the collection should say what it is meant to cover, the date or version at which it was complete, the method that ensured completeness, and who attests to it. A query that depends on closure then reads: according to collection X, complete as of date D, no such fact. If the collection has no completeness statement, the same query returns not found in X, which is weaker, and the application is obliged to treat it accordingly.
In validation, closure is deliberate. A SHACL shape that requires every study to have a sponsor treats the data graph as closed for that check: a study with no recorded sponsor fails. This is useful because it finds gaps that an open-world reasoner would never report. The article on OWL versus SHACL discusses using the two views for different questions.
A worked example
An access list for a document room about Halden Therapeutics AG (fictional) names twelve users. The system denies access to anyone not on the list, which is a correct use of closure: the list is the authority on who may enter. A separate report asks which counterparties have not been screened against a watch list. The screening log was only switched on in April, so a counterparty missing from the log may have been screened before April or not at all. Applying closure here would incorrectly report every earlier counterparty as unscreened; the right answer is that the log is complete only from April and the earlier period is unknown. The two systems look similar and need opposite readings of absence.
Related terms and boundaries
Closure interacts with null semantics, since a null in a closed collection can be read as false or as unknown depending on the declared scope. It affects as-of queries, because a collection is complete only as of a date. It is the working assumption of the system of record for the facts it owns, and the contrast with an ontology-based open-world reasoner is the main design question when the two are combined.
Checks a reviewer can run
For each negative answer the system gives, ask which collection was searched and whether it is stated to be complete. Check that scope and date are recorded with the collection. Test a case where a new feed joins an old table and the older closure no longer holds. Ask who attests to completeness.
Common misreadings
- Applying a local completeness rule globally.
- Ignoring reporting lag.
- Conflating unavailable data with a negative answer.
Appears in
- Blank cell vs declared unknown
A blank leaves its reason unstated; a declared unknown records what was checked and why no value is available.
- Declaring unknowns
Distinguish not found, blocked by licence and not applicable, with a dated search boundary.
References
- Reiter (1978), On Closed World Data Bases, Logic and Data Bases, Plenum Press.
- Wikipedia, Closed-world assumption.
- W3C (2017), Shapes Constraint Language (SHACL).
- W3C (2012), OWL 2 Web Ontology Language Primer (Second Edition).
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Where does "Closed-world assumption" bear on a decision of yours?
This entry sits under knowledge fusion. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.
Or write to [email protected] in your own words.