Part 3 of Foundations. Part 1 and part 2 covered structure and questions. This one is about making honesty precise.
"Proof or honest abstention" is a product principle, but it did not start as one. It has decades of database theory behind it, and the theory is the interesting part.
Database researchers asked a deceptively simple question: what may a system conclude from incomplete data? A landmark treatment came from Tomasz Imieliński and Witold Lipski in 1984, building on relational and logical accounts of databases. Under an open-world interpretation (one that assumes your stored facts can be true without being complete), a certain answer is one that holds in every admissible completion of the available data: every way the world could fill in the blanks without contradicting what you stored.
Other candidates may turn out to be true, but this evidence does not establish them. That distinction is the basis for abstention.
What incomplete data can still tell you#
"I don't know" can become an evidence-based outcome. One candidate may be possible but not certain; there may be no supported candidate; or two supported candidates may remain unresolved. Those are different conditions and should be reported differently. In the last case, the right response is the tie itself: "the 1997 film or the 2005 remake: which one did you mean?"
Saying "no" requires a license. This is the subtle one. Take "has the invoice been paid?" Answering no means knowing your records are complete for payments. Not finding a payment isn't the same as there being none. Systems that skip this distinction can manufacture a negative answer from a missing row. Open-world semantics treats absence as unknown, not false, unless a declared completeness boundary licenses that conclusion.
The license has a name and a precise definition, which is worth knowing because most software assumes it without ever saying so. Raymond Reiter formalized the closed-world assumption in 1978: if a fact is not derivable from the database, treat it as false. That is an enormously convenient rule and it is why your airline booking system can tell you seat 14C is free rather than saying it has no information about seat 14C.
The assumption is correct exactly when the database is the authority on its subject. The airline owns the seat map, so absence of a booking really does mean the seat is open. A pile of documents somebody sent you is not the authority on anything. It is a sample of the world, assembled by a process you did not control, and running a closed-world rule over it converts "I was not sent that document" into "that did not happen" without anyone ever deciding it should.
Here is the whole distinction in one line. A filing cabinet that cannot find a receipt is telling you about the filing cabinet. A system that reports the same thing as "no payment was made" has quietly promoted itself from filing cabinet to oracle, and nobody authorized the promotion.
Neither assumption is right in general. What is not acceptable is holding one implicitly. If a system will ever answer "no," somebody should be able to point at the scope over which it claims to be complete, and that scope should be narrow, written down, and inspectable.
Counts inherit the same rule. "How many meetings did I have with Dana?" is exact only if the underlying set is complete for the relevant people and time range. Otherwise the system should label the result as partial, give a bound if one is justified, or abstain.
Computability depends on the query language and the representation of missing information. Not every question admits an efficient certain-answer check, but important classes do. Tractable fragments, including important classes of conjunctive queries (questions built by joining conditions with "and"), have well-understood evaluation procedures. More expressive questions need separate analysis; natural language is not one uniform tractable fragment.
Why a wrong answer is worse than none#
An abstention costs you a lookup somewhere else. A wrong answer, delivered confidently by the component whose whole job is being trusted, costs you the decision you built on top of it. Eventually it costs you your trust in every answer the system ever gave. A memory layer is infrastructure for trust, and certain-answer semantics is just what that looks like when you write it down.
That is the bar: return an answer with its supporting derivation when the stored evidence warrants it, and otherwise distinguish missing support, ambiguity, and an unsupported premise. The controlled fixtures test each of those branches. Published numbers will follow the runs, not the other way around.
All of this assumes the records themselves hold a sentence together, which turns out to be its own problem. Part 4 looks at events, roles, and why a sentence is not a bag of triples.