Your AI Has an Answer. Where Did Its Data Come From?

An AI assistant revises a forecast. Someone asks why. Was there a new observation, a corrected input or a different interpretation of the same information?

The answer starts with the data the application actually used. If the value has become separated from its source, the team first has to recover that relationship before it can investigate the decision.

We want that relationship to survive the ordinary act of storing and retrieving data. In a tested path within 8DB, our omnimodal database, the encrypted store returns a value alongside its recorded provenance. A reviewer can inspect the recorded observation, agent and timestamp, and trace a supplied derived chain to its original root.

That is a useful place to begin an AI audit: a retrievable origin record, close to the data the application consumes.

Return the value and its origins together

The implementation is concrete. The encrypted VaultStore accepts a value and supplied provenance through put_with_meta. Its corresponding get_with_meta operation returns the stored value and metadata together. The source holds one transaction lock across those reads so they cannot straddle a concurrent write.¹

Our C10b regression exercises that path. It writes a value with a known source record, reads it back and checks two things: the returned bytes match the input, and source resolution returns the recorded observation, agent and timestamp. A second case stores a constructed, three-entry derived chain. The returned chain retains its depth and resolves to the original source.²

The practical benefit is the association itself. The application receives the value and its recorded origins through the same storage API. It can present that information to a reviewer or carry it into a later computation.

These checks concern the encrypted VaultStore metadata path. The application supplies the lineage; the database does not infer a complete account of an AI decision from the value alone. Other ingestion and query paths need their own integration checks.

Encrypted VaultStore · C10b fixture

Retrieve the value. Follow its recorded origins.

The test stores supplied lineage with a value, then checks what comes back.

One metadata read

Stored value + recorded chain

The returned value matches the supplied bytes. The chain remains available beside it.

Source resolution returnsObservation O
Agent A
Timestamp T

Constructed derived chain · three entries

1. Latest entryObservation Q · Agent CRecorded timestamp V
2. Earlier entryObservation P · Agent BRecorded timestamp U
3. Original rootObservation O · Agent ARecorded timestamp T

Lineage supplied by the application, preserved through storage

The fixture checks recorded origins. It does not establish source truth, the correctness of an AI answer, or a complete decision history.

A source record gives you something to investigate

Consider a supplier changing a shipment estimate. This is an illustrative application, not a customer deployment. A useful record would retain the estimate, the supplied source identity and the time associated with the observation. A revised forecast could then refer to the particular input it used.

That gives the reviewer a focused next step: inspect the source, compare the retained input versions, and check the transformation that produced the forecast. A recorded attribution still needs a trustworthy capture process. It cannot, by itself, establish that the supplier's estimate was accurate or that the model interpreted it correctly.

The distinction is productive. A disputed observation calls for a source check. A disputed calculation calls for a calculation check. A disputed permission calls for the relevant authorization evidence. Keeping those questions separate helps a team identify what evidence would settle each one.

Our wider evidence-aware retrieval article discusses confidence and coverage alongside content. This example concentrates on a specific part of that design: preserving recorded origins through a protected value-and-metadata read.

Connect record lineage to the wider workflow

There is already substantial work on representing provenance. W3C PROV ↗ describes entities, activities, agents and their relationships. OpenLineage ↗ records lineage around datasets, jobs and runs, including execution events and metadata about transformations.

An integration with pipeline lineage would let a reviewer move from the job that ran to the particular evidence a decision used. 8DB supplies the record-level building block: origins retained with protected data. An evaluation can connect that to your workflow’s identifiers and capture rules.

8DB's contribution in the example above is at the storage boundary. Keeping provenance accessible with protected data creates a building block for that larger trail. The end-to-end application must also retain the information that makes its own decisions reproducible.

For an AI workflow, that may include the exact input versions, model and tool versions, selected outputs and the authority under which evidence was used. Retention and disclosure rules matter too: someone allowed to see an answer is not automatically entitled to see every source behind it.

Start with one decision your team already reviews

A useful first evaluation can be small. Choose a non-sensitive decision and agree on what a second engineer should be able to recover:

1. The retained input. Retrieve the value used by the application, rather than silently substituting its latest version.
2. Its recorded origins. Inspect the supplied source entries and distinguish known lineage from missing metadata.
3. The transformation. Identify the calculation, tool or model invocation that connected the input to the result.
4. The review boundary. Confirm what the reviewer is allowed to see and which checks remain outstanding.

Then change one input and repeat the review. The application should make the versions and dependencies understandable without inventing a relationship that was never captured. This is a proposed integration evaluation; the storage regression establishes the narrower round trip described above.

The opportunity is to make evidence an ordinary part of working with data. Capture it while the source is available. Keep it connected as values move through the application. Give the next person a concrete trail to inspect.

Which source is hardest to recover when your team questions an AI answer? Send us a non-sensitive example. A sentence describing the missing record is enough to start. We can use it to define a focused retrieval and review test.

Evidence scope Encrypted-store regression · Source-bound implementation review · Proposed application evaluation. Explore the evidence. Methods and retained scope notes.

Footnotes

1. Source review at 8DB revision b05f7ae35840b2d7f5116164f80664b8056f163c, encrypted VaultStore put_with_meta and get_with_meta. The metadata read uses a held transaction lock; this statement is about that API's value/metadata consistency. Applications remain responsible for supplying accurate lineage and retaining any older input versions they need. ↩

2. C10b internal regression, executed September 17, 2026 against the unchanged vault implementation with the vv feature. The retained log reports success for byte-exact reads, known-source resolution and derived-chain root/depth checks. The derived chain was constructed before storage. This is implementation evidence, not independent certification or qualification of a complete AI audit service. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work