That creates a difficult memory problem. Old facts must not contaminate current answers, but later corrections must not erase the historical record.

Lians is an open-source bitemporal memory and record layer built around that distinction. The repository currently reports zero stale facts in top-5 recall on its included benchmark and 100 percent supersession accuracy across 22 fact pairs.

Those claims should be tested independently.

The Temporal Memory Challenge

We opened a public challenge asking developers to create corrections, conflicting sources, ambiguous entities, and paraphrased updates that can break Lians.

Run the tests locally:

git clone https://github.com/Lians-ai/Lians.git
cd Lians/agentmem
pip install -e ".[dev]"
pytest tests/test_supersession_benchmark.py tests/test_recall_quality.py -v

No API key is required.

Then add your own fact pair and test three questions:

1. Does present-time recall exclude the stale version?
2. Can the system reconstruct what was known before the correction?
3. Does it keep separate facts separate rather than incorrectly merging them?

Report results in GitHub issue #60. Include your environment, test data, expected result, and actual result.

Reproducible failures will become regression tests, and contributors will be credited. Critical results are more valuable than compliments because they create evidence that the product is improving under independent scrutiny.

If your organization deploys agents that depend on changing facts, Lians is also offering a free audit of one sanitized workflow at lians.ai. The goal is to identify stale-memory and missing-evidence risks before they become production incidents.

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?