An AI answer is not a sourced fact

An AI answer is not a sourced fact. A model can produce fluent text without showing which record supports a claim, and a retrieved passage can still be stale, mismatched, or ambiguous. Product teams should keep generated interpretation visibly separate from source evidence. Preserve where a value came from, when it was retrieved, and whether it matched the item under discussion. Then test whether a user can trace a consequential statement before acting on it.^[1]

That distinction matters anywhere software answers questions about a product, document, order, machine, policy, or customer record. The interface does not need to expose every retrieval detail at once. It does need to make the evidence available at the point where a person decides whether to trust, correct, or escalate the answer.

What should a source-aware answer show?

It should show which text is generated, which values come from records, and enough provenance to inspect those records. A useful evidence panel can identify the source, link to it, show when it was retrieved, explain the field's role, and state whether the record matched the requested item. Keep those details attached to the value as it moves through the product. If provenance exists only in a prompt or log, the operator cannot use it to check the answer.^[2]

At Tiding, one of our own consumer products, SourceProvenance records sourceID, sourceURL, retrievedAt, origin, sourceRole, fieldRole, confidence, and matchState. SourcedValue carries a value together with that provenance. In the Ask About Peptide experience, generated explanation stays distinct from source facts. The transferable choice is to keep origin and status attached to the value so a person can distinguish evidence from explanation.^[2]

Why is a citation alone not enough?

A citation can point to a real document and still fail to support the sentence beside it. The passage may describe another version, refer to a different product, or omit a condition that changes the meaning. A timestamp also has limits: a recent retrieval does not prove that the source itself is current. Users need to see enough context to notice those gaps, and the system should avoid presenting a weak match as a confirmed fact.^[1]

This is why source matching and answer generation should be treated as separate steps. Retrieval finds candidate evidence. Matching checks that the evidence refers to the right entity and field. Generation may explain or summarize the result. Each step can fail differently, so a single confidence score or green citation icon can hide the part that needs review.

Which facts need traceability first?

Start with claims that can change an operational decision: identity, quantity, status, date, permission, compatibility, or an exception reason. In a hypothetical factory workflow, an assistant might summarize a maintenance manual beside a work order. The manual, machine revision, retrieved section, and generated summary should remain distinguishable. A summary must not turn a nearby passage into proof that it applies to the machine on the floor.^[1]

Choose a narrow decision and map its evidence before choosing a model. Ask who owns each record, how often it changes, which identifier joins it to the workflow, and what the user should see when the join fails. If a source has no owner or cannot be checked, that is a discovery finding. It should shape the scope instead of being hidden by a more confident answer style.

How can a team test provenance before release?

Give a reviewer realistic cases and ask them to trace each important answer back to its source without help from the developer. Include a correct match, a stale record, a near-match for another item, a missing source, and conflicting records. Record whether the interface exposes the distinction and whether the workflow offers a safe next step. A demo with only clean examples tests fluency, not traceability.

• Can the reviewer open the source and identify the exact record or passage used?
• Can they tell when a value was retrieved and what entity or field it describes?
• Does a stale, missing, or mismatched source produce a visible limitation?
• Can they correct, defer, or escalate the decision without accepting generated text?
• Do logs preserve enough provenance to investigate a disputed answer later?

For offline-first products, include a disconnected case too. A cached source may be useful, but its age should travel with it. The workflow should show whether it is reading a local copy, whether that copy is stale, and whether a new answer depends on data that cannot currently be refreshed.

Where should source handling sit in the product?

Keep source identity with the data model, not only in prompt text. A typed sourced value can carry an identifier, source URL, retrieval time, origin, field role, and match state. The display can then decide which details to show, while tests can assert that transformations do not discard them. This also makes it easier to distinguish a value copied from a source from a sentence composed by a model.^[2]

Do not assume that more metadata automatically means better evidence. A source URL can be broken. A retrieval timestamp can outlive the content it describes. A match state can be wrong if the underlying identifiers are poor. Define who updates the source, how revisions are recognized, and what a person should do when evidence is incomplete. The data contract and operating procedure belong in the same design conversation.

What is a practical first step for an existing product?

Pick one answer that influences a real user action. Draw its path from source record to retrieval, matching, generated explanation, screen, and human decision. Mark each handoff where identity, freshness, or uncertainty can disappear. Then prototype only the missing evidence controls and test them with the people who own the workflow. This keeps the first engineering decision anchored to a specific process rather than an abstract request to add retrieval or citations.

A source-aware feature is not finished when it can produce a plausible paragraph. It is ready for a bounded pilot when the team can show what supports a claim, what remains interpretation, how exceptions are handled, and who is responsible for the final decision. For a manufacturing workflow, that means testing against the actual document versions, identifiers, permissions, and operator handoffs involved.