October 12, 2026

Tracing an Agent Answer Back to a Source Version

Why citation URLs fail audit trails, how citation revision identifiers trace answers to exact commits, and why document rollback versus answer reproduction are distinct architectural problems.

To investigate an agent answer later, retain the answer and the exact source material it used. A current document URL is useful for navigation, but it may point to revised text. This guide describes a proposed technical trace record and the controls needed to keep it useful; it does not establish regulatory compliance.

Mutable links alone may be insufficient for historical tracing

When an agent references an internal standard operating procedure (SOP) or policy, it typically cites a live URL or document path. In dynamic environments, documents are updated continuously. When a policy is edited, a dynamic URL resolves to the updated text.

If an agent answered a question based on Revision 2 of a policy, and the policy is later updated to Revision 3, checking the dynamic URL later shows Revision 3 text. While URLs can be version-pinned to an immutable revision (such as a commit SHA, rather than a mutable tag that can be re-pointed) and systems can retain independent evidence, relying solely on mutable links can break historical context. Retaining the retrieved text alongside revision identifiers preserves clarity without requiring blanket claims about audit survival.

Proposed trace manifest design and field separation

To establish clear provenance, a system architecture can record an explicit trace manifest alongside generated outputs. This trace manifest is a proposed design pattern rather than an automatic feature of any specific tool.

A complete trace record should separate source system identifiers from imported repository references, retrieved passages, and model inputs:

1. Source system ID and version: The canonical path and source revision identifier (such as an immutable commit SHA or timestamped version string; a source version ID need not be content-addressed).
2. AKB imported document URI and revision: An internal URI (e.g., akb://example-vault/coll/policies/doc/travel-allowance.md), the backend-issued document revision identifier, and the storage backend used for the imported document. A Git commit SHA is relevant only for a Git-backed source or legacy Bare Git deployment.
3. Retrieved passage and hash: The exact raw text slice returned by retrieval and its cryptographic hash (e.g., UTF-8 SHA-256).
4. Actual model-input passage: The text supplied to the language model context window after any parsing, template formatting, or truncation, kept distinct from the raw retrieved passage.
5. Retrieval timestamp: The ISO 8601 timestamp recorded when the context chunk was drawn.
6. Run and answer ID: The unique identifier for the execution run and generated answer.
7. Stored generation output: The original response generated by the model.

Hashing alone neither stores the underlying content nor proves authenticity; systems must retain the actual text alongside checksums.

Passage transformations and illustrative trace record

Source text often undergoes parsing, chunking, or template injection before reaching the model context window. Paragraph hashes computed before ingestion may not match the text passed to the prompt. Systems should record the transformation pipeline version and hash the actual retained passage using a defined character encoding (e.g., UTF-8).

Illustrative trace record (all values are illustrative placeholders):
Run ID: run-2026-0919-001
Source System: /policies/travel-allowance.md (Revision: <recorded source revision>)
AKB URI: akb://example-vault/coll/policies/doc/travel-allowance.md (Revision: <recorded AKB revision>; Backend: <recorded storage backend>)
Retrieved Passage: "Standard travel reimbursement rate is $50/day..."
Retrieved Passage Hash (UTF-8 SHA-256): <SHA-256 computed from retained UTF-8 passage>
Transformation Pipeline: chunker-v1.2 (max_tokens: 512, encoding: utf-8)
Model Input Passage: "Standard travel reimbursement rate is $50/day..."
Retrieved At: 2026-09-19T05:00:00Z
Stored Generation Output: "According to the travel allowance policy..."

For organizations managing agent knowledge infrastructure, Dnotitia developed AKB (Agent Knowledge Base). AKB provides organizational knowledge and memory to AI agents through the Model Context Protocol (MCP). AKB supports PostgreSQL Native revisions for new installations and explicit Bare Git support for legacy deployments. In the Native backend, PostgreSQL holds chunk text, metadata, and table state; files use separate file storage; the vector driver maintains a derived search index. In a Bare Git deployment, document history is stored in Git. Git history alone tracks document revisions rather than providing a complete execution or access audit, and document rollback scope depends on what is stored in that specific revision.

Distinguishing four types of state

For this review, distinguish four types of state rather than treating them as a universal system requirement:

1. Canonical Storage Layer: For new AKB installations using PostgreSQL Native, document revisions are stored in PostgreSQL. Git is an example for a Git-backed source or legacy Bare Git deployment. Restoring a document revision does not imply that tables, files, or derived indexes are rolled back; rollback scope depends on what that revision contains.
2. Search Index Layer: Converts raw text into vector embeddings and lexical indices. Ingestion queues and embedding generation introduce temporal latency between storage writes and index availability.
3. Access Authorization Layer: Evaluates permissions at execution time. Historical authorization evidence (recording the principal, relevant policy version, and decision) should be captured during the run. Opening historical trace records later requires current authorized investigator access; historical permission grants are not re-created for revoked users. Sensitive authorization context should be minimized and managed under separate access and deletion policies.
4. Model Runtime Context Layer: Encapsulates system prompts, tool schemas, context payload ordering, and generation parameters.

Decoupling these layers allows investigators to isolate whether a shift in output stemmed from document edits, index synchronization latency, permission changes, or prompt modifications.

Source trace verification versus generation replay

A common misconception is assuming that reverting a document in storage or restoring an index snapshot will reproduce a past agent answer.

Source-trace verification and generation replay are distinct operational tasks:

• Source trace verification: Verify each retained artifact against its own recorded checksum, then use recorded source revision and transformation metadata to trace the passage to its origin. This requires no model rerun or index snapshot.
• Generation replay: Attempts to re-run model inference using historical inputs. Replaying generation requires reconstructing context windows, prompt templates, and model parameters. Even when identical model versions and seeds are available (and seed support varies across model providers), non-deterministic model behavior means identical generation output cannot be guaranteed.

Systems requiring dependable audit records must preserve the original generated output rather than relying on dynamic answer reproduction.

Proposed validation walkthrough

To verify a provenance architecture, teams can execute a validation walkthrough. These manual or automated test scenarios evaluate system tracking capabilities:

1. Capture baseline run: Query the system on Document Revision A. Retain the trace manifest, exact model-input passage, UTF-8 checksum, and generated output.
2. Apply source update: Update the source document to Revision B and re-index.
3. Trace historical version: Use the recorded trace manifest from Step 1 to locate Revision A in historical storage without relying on live URL pointers.
4. Verify checksum match and transformation trace: Recompute the SHA-256 checksum from the SAME retained passage artifact using UTF-8 encoding and compare it against the recorded checksum. Trace transformed or chunked passages back to the source revision using retained transformation pipeline metadata, rather than requiring a chunk hash to equal the entire source document text.
5. Test access and retention boundaries: Verify that a currently authorized investigator can inspect the retained trace record. Confirm system behavior when Revision A is deleted or retention periods expire, ensuring missing evidence is explicitly reported rather than substituted with current text.

Governing versioned knowledge repositories

For a Git-backed source or legacy Bare Git deployment, repository references and access controls need explicit management: Git history can be rewritten or made unavailable through rebasing, branch deletion, force pushes, or commit squashing. For PostgreSQL Native, retention, backup, and deletion must follow the controls of the deployed backend.

For Git-backed sources and legacy Bare Git deployments, commit identifiers alone do not guarantee retention for the required period. Git’s garbage-collection documentation describes cleanup of unreachable Git objects. Use protected references, explicit retention policies, and tested backups. For PostgreSQL Native, retention, backup, and deletion must follow the deployed backend’s controls.

FAQ

What is the difference between a standard document URL and a citation revision identifier?

Standard document URLs point to live web paths or database records that reflect current document state. When text is updated, a standard URL resolves to the new content. Resolve mutable references to the recorded immutable revision and retain that revision and the retrieved text. For a Git-backed source, the recorded immutable revision may be a commit; AKB Native revision identifiers are backend-specific.

Does rolling back a source document reproduce a past agent answer?

No. Restoring an earlier document version only reverts raw text in storage. Surrounding search indices, authorization policies, prompts, and model behavior may have changed. Reproducing a generative answer requires re-assembling the full context window, prompt template, and model parameters, and non-deterministic model behavior means exact reproduction cannot be promised.

Does a revision identifier alone preserve evidence?

No. A revision identifier does not itself retain the referenced evidence. Use retention, backup, and deletion controls appropriate to the deployed backend for the required period. For Git-backed sources or legacy Bare Git deployments, protect required references and account for Git garbage collection; PostgreSQL Native requires its own backend-specific controls.

What is search index synchronization lag and how does it affect citation integrity?

Search index synchronization lag occurs when a document is updated in storage before search indices finish re-embedding and re-indexing. An agent querying during this window may retrieve passages from the previous revision. Record and validate revision metadata against returned passages; metadata alone is not an integrity guarantee.

Related reading

Which Sources Belong in an Agent Knowledge Base First?

October 12, 2026

Where Human Approval Belongs in Automated Knowledge Cleanup

October 12, 2026

Sharing a Knowledge Backend Across Coding Assistants

October 12, 2026