DEV Community

Ethan Beirne
Ethan Beirne

Posted on

Why AI audit logs break when the facts change

Most AI agent audit logs can tell you what prompt ran, what model answered, and which tools were called.

That is useful until someone asks a harder question six months later:

Why did the agent make that decision with the information available at the time?

Imagine an agent reviewing a company, customer, or transaction. It retrieves a policy, a filing, an entity record, and a risk rule. Later, the policy is updated, the filing is amended, and the entity record is corrected.

If you replay the workflow using today's sources, you are not reproducing the original decision. You are running a new decision against a different world.

You have an activity log, not decision reconstruction.

The hidden problem is time

Agent systems need to distinguish at least three clocks:

  1. Event time: when the agent performed an action.
  2. Valid time: when an underlying fact was true in the real world.
  3. System time: when your platform learned or stored that fact.

A record can be valid in March, corrected in June, and audited in September. The September review may need both the March version that influenced the original decision and the June correction that changed the current truth.

Without those distinctions, old facts can resurface as if they are current, or current facts can silently rewrite the past.

What evidence must be preserved

For a meaningful reconstruction, I would preserve:

  • The exact retrieved source content or an immutable source version
  • The prompt, policy, and instruction versions
  • Model and tool configurations
  • The permissions and identity active during the run
  • Intermediate facts, citations, and transformations
  • The order and timestamp of each state transition

Logging only an ID is not enough if the document, policy, or record behind that ID can change later.

Content hashes help prove integrity, but the original content or a recoverable immutable version still needs to exist.

Corrections, changes, and disagreements are different

A new fact should not always overwrite an old fact.

Correction: The previous record was wrong. Preserve it for audit, but make the correction authoritative for current decisions.

Real-world change: Both facts were true at different times. Give each fact a validity interval.

Disagreement: Two sources conflict and neither one clearly supersedes the other. Preserve both with provenance and surface the conflict.

This structure lets current retrieval avoid stale information while point-in-time retrieval can still reproduce what the system knew earlier.

Why this matters beyond compliance

Decision reconstruction is not only an audit requirement. It improves:

  • Debugging when an agent behaves unexpectedly
  • Evaluations across prompt, model, and policy versions
  • Incident response after a source or rule changes
  • Human review of high-impact decisions
  • Trust between operators, customers, and regulators

If an agent cannot explain what evidence it used at decision time, it becomes harder to improve safely.

What we are building

At Lians, we are building a system of record for AI in regulated workflows. The goal is to reconstruct what an AI system knew, did, and why at the moment a decision was made, even after the underlying facts change.

We are three weeks old, pre-1.0, and working with a functioning product. We are looking for 5 to 7 design partners in financial research, risk, compliance, and other evidence-heavy agent workflows.

If you operate an agent where policies, records, filings, or external sources change over time, I would genuinely value hearing how you handle reconstruction today.

What breaks first in your current audit trail when the facts change?

Top comments (0)