An AI Answer Is Not a Fact
What has to happen before a probabilistic interpretation becomes accepted, reusable state: the Fact Admission Boundary, step by step, with a certification claim extracted from a website and a PDF.
Thesis. A model's answer is at best a candidate claim; it becomes reusable state only after separate, deterministic checks of meaning, source, evidence and authority produce an explicit admission decision — and even an admitted fact is a governed record, not a guarantee of truth.
Research question. What must happen before a probabilistic interpretation becomes accepted, reusable state?
Four things that are often called "the answer"
| Thing | What it is | Can another agent reuse it as-is? |
|---|---|---|
| LLM answer | generated text conditioned on inputs | No: no attribution, no admission, may not be grounded |
| Candidate claim | a structured interpretation: subject, predicate, value, scope, time, source span | Only as a proposal |
| Accepted (admitted) fact | a candidate that passed admission under named rules, recorded as an attributable event | Yes, within its scope and audience |
| State projection | what the admitted history resolves to for a subject, time, viewer and purpose | Yes, as a dated, qualified reading |
Language models generate fluent text that may not be supported by their inputs (Ji et al., 2023). Retrieval grounding reduces but does not remove that risk (Lewis et al., 2020). Neither changes the category: an answer is an output, not a record anyone has taken responsibility for.
The Fact Admission Boundary
We use Fact Admission Boundary as an editorial name for the line between "something a model or parser proposed" and "something the system will treat as admitted state". It is not a protocol term; in Tinor's architecture it corresponds to the separation between the Semantic Runtime, where models and parsers may only produce candidates, and the owner-held services that alone may write admitted events.
Four checks sit on the boundary. They are distinct because each can pass while another fails.
- Semantic interpretation. Does the candidate say what the source says, in the target's vocabulary? Is the subject bound to an exact entity, not a similar name? Is the proposition no stronger than the source supports (e.g., "application received" is not "certificate issued")?
- Source verification. Does the cited span actually exist in the cited material, at the cited location, in the version on record?
- Evidence and authority. Is the class of evidence sufficient for this kind of claim, and does the submitting party have standing to make it? A self-uploaded scan may support "the supplier states it holds a certificate"; it does not support "the certification body attests".
- Admission decision. Given the above, does the owning rule admit, defer or refuse — and is that decision recorded with its reasons?
In Tinor's reference architecture, the corresponding deterministic assessment is layered (contract, grounding, semantic acceptance, binding, evidence sufficiency, authority/state/time, conflict), each producing pass, fail or unknown with a structured diagnostic. A model may propose values and explain issues; it may not decide identity, authority, admission or approval. Human approval does not substitute for authority either.
Distinct outcomes, not one "no"
Failures should be reported by reason, because each has a different remedy:
| Situation | Honest outcome | Typical remedy |
|---|---|---|
| Evidence missing or too weak for the claim's strength | not admitted: insufficient evidence | ask for the certificate, or a register check |
| Another eligible source says otherwise | admitted alternatives coexist; relation reported as conflicting | human or policy review; no automatic winner |
| Claim is outside what the target can express or the purpose covers | out of scope / unmapped | change target, or record as residual note |
| Submitter lacks authority for this claim | refused: not authorized | submit via a party with standing |
| Subject cannot be bound exactly | blocked: ambiguous subject | ask which entity is meant |
Collapsing these into a single "rejected" — or worse, into a confident answer — destroys exactly the information a reviewer needs.
Admission is not truth
An admitted fact means: this party asserted this, supported by this evidence class, admitted under this rule, on this date, visible to these audiences. The party can be mistaken or dishonest; the evidence can be forged; the rule can be too lenient. Admission makes those failures attributable and correctable, and lets later withdrawal or dissent attach to an exact record. It does not make them impossible.
Serving admitted records to other agents
When another agent asks, it should receive state projections, not raw candidates and not prose:
- each item labelled with its standing (admitted record, self-description, quoted material, gap);
- qualifiers that matter — "the recorded validity period does not by itself mean currently valid";
- resolved under the requester's audience, with withheld items withheld rather than silently dropped;
- pending candidates never served as facts — at most as "being recorded, not yet confirmed".
Case: one certification claim, two sources (hypothetical)
A supplier's website says: "Our Ningbo factory is ISO 9001:2015 certified." Its uploaded PDF is a certificate for "Example Precision Co., Ltd." with certificate number Q-0001, scope "design and manufacture of injection-moulded components", site address in Ningbo, valid 2025-04-01 to 2028-03-31, issued by certification body CB.
Step 1 — Source material. Two materials are recorded immutably with content hashes: the web page snapshot and the PDF.
Step 2 — Candidate claim. A model proposes:
{
"subject": "Example Precision Co., Ltd. — Ningbo site",
"claim": "holds_certification",
"standard": "ISO 9001:2015",
"certificate_number": "Q-0001",
"scope": "design and manufacture of injection-moulded components",
"valid_from": "2025-04-01",
"valid_to": "2028-03-31",
"issuer_named_in_document": "CB",
"grounding": [
{ "material": "pdf", "span": "Certificate No. Q-0001 ..." },
{ "material": "web", "span": "Our Ningbo factory is ISO 9001:2015 certified." }
]
}
Step 3 — Semantic validation. Fields are in the target's vocabulary; dates parse; the standard is a known value. The website span supports only the weaker proposition "the supplier states it is certified"; the PDF supports the certificate details. Subject binding: the PDF's legal name and address match the supplier's registered entity and one of its recorded sites — exact match, so binding passes. Had the PDF named a sister company, binding would block as ambiguous.
Step 4 — Evidence and authority check. The supplier has standing to make claims about itself. The evidence class is "supplier-uploaded certificate file"; no independent register check (for example on IAF CertSearch, if the certificate is listed there) has been recorded. For the proposition "the supplier asserts it holds certificate Q-0001", this is sufficient. For "CB attests that Q-0001 is valid", it is not.
Step 5 — Admission decision. Three illustrative outcomes:
| Proposition | Decision | Why |
|---|---|---|
| Supplier asserts its Ningbo site holds Q-0001 (ISO 9001:2015), scope and validity as stated, supported by uploaded certificate | Accepted | grounded, bound, sufficient for a self-asserted claim, submitted by the supplier |
| Certificate is currently valid and verified by the issuer | Needs Confirmation | requires a register check or issuer confirmation |
| "All our factories are ISO 9001 certified" (also on the website) | Rejected — Unsupported | the only evidence covers one site |
Accepted / Needs Confirmation / Rejected — Unsupported are article-level labels for readability. They are not Tinor protocol enums. Tinor's admission path distinguishes semantic processing results (such as create, update, supersede, no-op, evidence-only, reject) and structured diagnostics (such as insufficient evidence or third-party confirmation required); none of these are new core event types.
Step 6 — Atomic Event and state projection. The accepted proposition is written by the owning service as an attest event by the supplier, with evidence commitments folded into the event hash and its derivation from the two source materials kept, as provenance in the PROV-O sense. A later register check by a buyer would be a verify event referencing it. A projection for a buyer's agent then reads: supplier-asserted, certificate on file, validity as recorded, no independent confirmation yet.
Counterexamples and open challenges
- Overhead for low-stakes use. For internal brainstorming, this pipeline is unnecessary.
- Strength calibration is hard. Deciding which propositions a given evidence class supports requires domain rules someone has to write and maintain.
- Model errors upstream still matter. If the model mis-reads a date and the PDF is a scan, grounding checks must compare against the source text, not the model's paraphrase; OCR quality becomes a dependency.
- Users may prefer confident answers. Distinct outcomes are more honest and sometimes less satisfying.
Where Tinor stands
The candidate-only rule for models, the layered deterministic assessment, and owner-held writes are architectural commitments recorded in Tinor's design decisions; bounded versions exist in the reference implementation for specific targets such as credentials and capacity. Broad coverage across claim types is not claimed. Design Proposal.
Related reading
- Agent Memory Is Not Operational State
- Beyond Ontology: From Understanding Reality to Relying on It
- Reality Needs a Type System
References
- Ji, Z. et al. (2023). Survey of Hallucination in Natural Language Generation. arXiv:2202.03629
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401
- W3C (2013). PROV-O: The PROV Ontology. w3.org/TR/prov-o
- IAF CertSearch — a public register for accredited management-system certificates. iafcertsearch.org