You ask an AI assistant for the approved launch price, hiring plan, or customer commitment. It returns a precise answer with convincing context. The answer was once correct, but the decision changed.

The model did not forget. It remembered without understanding which memory still governed the work. Fixing that problem requires more than a larger context window or a better vector database. You need a memory system that distinguishes current truth from proposals, history, and unresolved evidence.

Freshness is a business property, not a timestamp

Teams often define freshness as recency: retrieve the newest message, note, or document. That rule fails as soon as someone discusses a change before approving it.

A proposal written this morning may be newer than an approved decision from last week. It is not therefore more authoritative. A correction entered today may apply retroactively. A regional exception may be current for one customer and wrong for another. A historical record may be accurate for an as-of question even though it must not answer a current-state question.

For operational memory, define current as the record that is approved, applicable to the requested scope and time, and not superseded by another approved record. That definition forces you to retain several signals that a single updated-at timestamp cannot carry:

• Recorded time: when the system captured the statement.
• Effective time: when the decision starts governing the business.
• Approval state: whether the statement is authoritative, proposed, historical, or unresolved.
• Scope: the product, customer, market, workflow, or other boundary to which the decision applies.
• Supersession: which approved record replaced an earlier one.
• Evidence: where a reviewer can verify the decision and its exact meaning.

This also changes how you interpret contradictions. Two different values do not always mean corrupted memory. They may represent a valid change over time, a proposal that has not been approved, or decisions that apply to different scopes. Your system should classify the relationship before asking a language model to explain it.

The dangerous policy is last write wins. It turns conversation order into authority. The safer policy is latest applicable approval wins, while every displaced or unapproved value remains visible under a different status.

Use explicit states to build a decision ledger

Treat mutable business facts as decision records rather than loose snippets of text. A compact ledger can begin with four states:

Status	Meaning	Behavior during retrieval
Approved	The authoritative value for its stated scope and effective period.	Eligible to answer a current-state question.
History	A value that used to govern but has been superseded.	Use for an as-of question or to explain how a decision changed.
Pending	A proposed replacement that has not completed approval.	Do not use as current truth; disclose it when relevant.
Unknown	The available evidence cannot support a reliable answer.	Abstain, identify what is missing, and route the issue for review.

Unknown deserves first-class status. Without it, the assistant is pressured to choose among incomplete or conflicting records. A useful abstention is not merely “I don’t know.” It identifies the decision key, the conflicting candidates, the missing evidence, and the person or process that can resolve them.

Each record should be inspectable without opening a chat transcript. At minimum, capture:

• A stable record ID and canonical decision key.
• The value and its unit, so semantically different representations are not mistaken for different decisions.
• Status, effective date, and applicable scope.
• An evidence reference and the exact supporting sentence or decision entry.
• The record it supersedes, if any.
• The approver or approval mechanism.
• The reason for the change.

You do not need an elaborate database to validate this model. An initial implementation can keep approved values, decision history, and pending changes in separate inspectable files. A structured ledger becomes valuable when you need validation, transactional updates, permission controls, or generated views for several AI products. The status model should stay the same as the storage layer evolves.

Do not overwrite the previous value when approval changes. Move it into history and connect both records through supersession. That preserves the answer to “What is current?” without destroying the answer to “What did we believe before this change?”

Resolve contradictions before the model drafts an answer

Retrieval should not hand a pile of similar passages to the model and hope the prompt sorts them correctly. Contradiction handling belongs in the retrieval and policy layer, where you can make the rules deterministic and testable.

1. Parse the requested subject, scope, and time. “Current price” and “price before the change” are different queries.
2. Retrieve candidate records using the canonical decision key as well as semantic similarity. Similar wording alone is not a reliable identity rule.
3. Group records that refer to the same decision and compare their scopes and effective periods.
4. Partition candidates by status before ranking them. Pending and historical records must not outrank an applicable approved record merely because they are newer or more semantically similar.
5. Select the applicable approved record. If multiple approved records govern the same scope and time, stop and mark the result unresolved instead of choosing silently.
6. Attach relevant pending changes and historical context as annotations, not as competing answers.
7. Return the value with its record ID, effective date, scope, and evidence reference.

Consider the acceptance case in which USD 5,000 is approved with an effective date of October 5, 2026, while USD 3,000 is pending. The correct current answer is USD 5,000, accompanied by a notice that USD 3,000 is proposed. Once the reduction is approved with an October 8 effective date, USD 3,000 becomes current and USD 5,000 becomes historical. The values did not stop contradicting each other at the text level; their statuses and effective dates made the relationship resolvable.

Give the assistant a response contract

A current-state response should expose enough metadata for a person or downstream system to challenge it. Require the assistant to return:

• The current approved value.
• The record ID, scope, and effective date.
• The evidence reference used to support the answer.
• Any materially different pending value.
• Any unresolved conflict that prevents a reliable answer.

This response shape does two jobs. It makes mistakes easier to detect, and it prevents a polished sentence from hiding a weak retrieval decision. If the system cannot show why a record governs, it should not present that record as settled truth.

Provenance still does not prove that a decision is correct. A citation proves traceability, not truth. A reviewer must be able to inspect the underlying evidence, confirm its authority, and correct the ledger when the evidence was misunderstood or entered incorrectly.

Govern memory changes like product releases

A reliable retrieval rule cannot compensate for an uncontrolled update process. Treat every proposed memory change as a small release with staging, approval, publication, verification, and rollback.

Separate proposal from approval

1. Create a pending record rather than editing the approved value in place.
2. Compare the candidate against the current record and show the old value, proposed replacement, effective date, evidence, and reason.
3. Have an authorized person or system verify the evidence. The language model can extract a candidate, but it should not approve its own extraction.
4. Commit the new approved record and historical version as one controlled operation. A partial update can leave two current truths.
5. Regenerate any human-readable or retrieval-facing artifacts from the structured ledger.
6. Replace deployed copies instead of leaving old and new files side by side as equally authoritative knowledge.
7. Audit the generated views against the ledger, then create a recoverable backup.

A typed confirmation is useful friction in a local workflow, but it is not an enterprise authorization boundary. Anyone who can directly modify the underlying files may bypass it. Production implementations need access control, durable audit events, constrained write paths, and a recovery process appropriate to the consequence of a bad change.

The product decision is not simply whether humans remain in the loop. It is which changes require approval, who has authority for each decision domain, and what the system does while approval is pending. A price, policy, contractual commitment, or compliance rule usually deserves stricter handling than a personal preference whose correction is cheap.

Test state transitions, not just answer quality

A demo in which the assistant repeats one stored fact proves very little. Your evaluation set should exercise the transitions that make memory dangerous:

Test	Setup	Expected behavior
Pending contamination	An approved value and a newer pending replacement exist.	Return the approved value and label the proposal as pending.
Approved supersession	The pending replacement receives approval and an effective date.	Return the replacement as current and retain the old value as history.
Overlapping approvals	Two approved values govern the same key, scope, and time.	Abstain and raise a contradiction instead of selecting one.
As-of retrieval	A question requests the value before an approved change.	Return the historically applicable record, not the current one.
Missing evidence	A candidate value has no verifiable decision reference.	Mark it unknown or pending review rather than treating it as approved.
Stale deployment	Old and regenerated knowledge artifacts are both available.	Detect the conflicting authoritative copies and fail the publication check.

Track failure modes separately. Stale-answer rate tells you how often superseded facts escape. Pending-contamination rate shows whether proposals leak into current answers. Conflict-detection rate measures whether the system notices overlapping approvals. Provenance completeness shows whether users can verify outputs. Correction latency measures how long an approved change takes to reach every retrieval surface.

These measures are more actionable than a single answer-accuracy score. They tell product, engineering, and operations whether the fault sits in intake, approval, storage, deployment, retrieval, or presentation.

Key takeaways

• Fresh memory means retrieving the latest applicable approved decision, not the newest text.
• Store approved, historical, pending, and unknown records as distinct states.
• Preserve effective dates, scope, evidence, and supersession links alongside each value.
• Resolve status and scope conflicts before a language model generates the response.
• Never let a pending proposal overwrite current truth automatically.
• If approved records conflict within the same scope and period, abstain and escalate.
• Evaluate memory through state transitions, stale deployments, provenance, and correction speed.

Start with a single decision family that changes often enough to expose the problem: budgets, launch scope, pricing rules, staffing plans, or customer commitments. Model its states, run the pending and supersession tests, and make an unresolved contradiction visible. Once that contract works, expanding memory becomes safer because the system knows not only what it remembers, but what it is allowed to trust.

References

• Substack AI Topic – Build an AI Memory System With Claude Sonnet 5.5

---