A Status Model for Case Decisions: Active, Superseded, Withdrawn

If you store case decisions for reuse, give each one a status, or old conclusions will quietly act as current ones. Here is a small model.

Three statuses

• Active. Reviewed, in scope and safe to cite as evidence.
• Superseded. Replaced by a later decision. Keep it, link to its successor and say why.
• Withdrawn. Found to be wrong or unsupported. Keep it for audit, never surface it as a reference.

Fields to hold with each decision

Decision ID, the question, the evidence, the outcome and why, scope, date, valid-from, review-by, status, superseded-by, related decisions.

Rules

1. No transition without a reason.
2. Statuses are append-only: add a record, never overwrite.
3. If two active decisions conflict, show both with their dates.
4. Retrieval should rank by relevance and status, not recency alone.

Why this matters for AI retrieval

A retrieval layer that ignores status will return a withdrawn decision as happily as an active one. See why retrieval has to be grounded and traceable. The wider picture is in organisational memory in AML.

Related: how a commit-message approach feeds this model https://dev.to/technoxander/reviewing-a-closed-case-like-a-pull-request-2dk3 and a diagram of the reuse test https://www.tumblr.com/vop25/832421899455905792/when-can-yesterdays-judgement-help-todays-alert?source=share.

Conclusion. Status is cheap to store and expensive to lack. We build for it at TechnoXander. If you’ve modelled decision history, did you version the reasoning or only the outcome?