How does an AI product know what is true?

It is easy to make an impressive AI demo. Put a model behind a polished chat window, give it a few documents, and it will produce answers that sound good. The harder questions begin when an answer creates an invoice, changes a record, sends a message, or influences an important decision.

Fluent text is no longer enough. The product must answer less comfortable questions: Where did this information come from? How recent is it? Which part was calculated, which part was inferred, and who approved the action?

What I mean by a truth model

I use “truth model” for the rules by which a product handles information. It is not a feature of the AI model or merely a database schema. It is the agreement between the product and its users about what is known and how much confidence a result deserves.

For important information, I want to retain:

• the source and the time it was read;
• the original value and any transformations;
• the difference between fact, calculation, estimate, and generated text;
• conflicts or missing data;
• the person or rule that approved the result;
• enough information to audit a later action.

A measurement, a calculation, and an estimate may appear in the same sentence, but they are not the same. If the distinction is lost in storage, the interface cannot recover it later.

Finding a document does not make it authoritative

Document retrieval helps a model find relevant text quickly. It does not tell us whether the document is current, whether it has authority for the question, or whether a newer version contradicts it.

This matters particularly with public and official data. A press release is not a regulation. A forecast is not a measurement. The first search result is not necessarily the source that should be cited.

The interface can remain simple, but the product should retain the source, version, retrieval time, and the connection between the quoted passage and the displayed claim. When the evidence is weak, “we do not have enough information” may be the correct answer.

The model proposes; a person or rule approves

AI can extract information, compare documents, suggest a classification, or draft an explanation. That does not mean it should have authority over every decision.

For each consequential step, I define who may:

1. confirm extracted data;
2. approve an action;
3. correct the stored record;
4. review a failure and change the rule.

In the interface, “suggested” and “approved” must be different states. So must “a source was found” and “the source supports the conclusion.” If that difference exists only in an internal policy, daily use will eventually erase it.

Uncertainty is a normal state

A conventional system often has two outcomes: success or error. An AI product needs more. Evidence may be insufficient, sources may conflict, data may be old, or the model provider may not respond.

Each case needs a concrete behaviour. The system can ask for missing context, send the case to a person, fall back to a deterministic rule, or stop before an external action. What it should not do is hide uncertainty beneath confident language.

Test the path, not only the final prose

A well-written answer can come from a broken process. Tests should therefore follow the whole path:

• Was the right source selected?
• Were exceptions and qualifications preserved?
• Does the result match the required structure?
• Is missing information visible?
• Was the action approved by the right person?
• Can we reconstruct the reason later?

In my AI platform work, I begin with a narrow case, known inputs, and clear rules. I test it with ordinary and problematic inputs before expanding it.

The AI model is one component. The product becomes useful when it can use the model without handing it responsibility as well.