What is behind an answer?

When reading an AI-generated answer, we often look at the sentences first. Do they make sense? Do they address the question? Can we use them?

When an answer must inform a decision, other questions arise. What information was used? Which version was valid? Was the system authorised to access it? Did the source actually reach the model? Did it support the answer?

These questions take us from the visible answer to the conditions under which it was produced.

The Nage AI OS and SEDIM white paper I have published explores how to make those conditions visible and open to review. Its central question is what an institution can establish about an AI-generated response, and on what evidence.

Following a source

Several stages separate a document being in a system from its use in a particular answer.

The document may have been admitted and selected for the request. Yet it may fall outside the length limit when the context is assembled. The system may have found the right source without the relevant information reaching the model.

The examination does not end when information reaches the model. A sentence being present in its input does not establish that the answer was produced on that basis. The answer may repeat other information, misinterpret the source or contradict it.

The paper therefore treats source selection, presence in the final input, claim support and causal influence on the answer separately. Each addresses a different question and requires a different observation or experiment.

This distinction has a practical consequence. Seeing where a problem arose helps us discuss more clearly what needs to change.

Knowledge has a lifecycle

Institutional knowledge changes continuously. A guideline is revised, a document becomes obsolete, permission to use a source is withdrawn.

Access alone is insufficient in such an environment. Knowledge identity, version, access scope and usage status also need to be managed.

SEDIM addresses this through the model, knowledge and evidence architecture within Nage AI OS. Nage AI OS provides a framework for considering model execution alongside these controls, observations and reviewable request records.

Withdrawal is an important question here. If information should no longer be used, its meaning within the system must be explicit. Removing it from active use, deleting stored copies and removing information that may be present in a pretrained model's parameters are different operations. Completing one does not establish that the others are complete.

Short statements such as “updated” or “deleted” contain technical decisions whose scope needs to be stated.

What can a record show?

Reviewing an answer afterwards requires the conditions of that moment. Which model, source version and access policy were used? What observations were obtained? What was delivered to the user?

A signed record can help check the integrity and signature of the disclosed record content. It does not, by itself, establish that the answer is correct or that every event in the system was captured.

That boundary matters. We preserve the value of review tools by explaining clearly what they can verify.

The same clarity is needed when a measurement is unavailable. Replacing a missing value with zero does not remove uncertainty; it conceals it. Sometimes the most meaningful output is a record of why a value could not be produced.

The work itself should be reviewable

The white paper presents measured engineering results alongside design targets and capabilities awaiting acceptance tests. Distinguishing their status follows from the paper's central question.

A result observed under particular conditions cannot be extended to every use. Local verification does not automatically establish the same behaviour in production. Work may remain between describing an architecture and meeting all its acceptance conditions.

I have therefore published the document with a technical evidence annex in which results can be read alongside their methods and limitations. CRATON native-model research is treated as a separate research track with its own evaluation requirements.

Progress depends on preserving those distinctions.

When deciding whether to use an answer, we may need more evidence, a current source or human review. Nage AI OS and SEDIM examine how to see more clearly where that need arises.

Alongside the answer, there should be a trace that lets us question it again.

White paper and technical evidence annex