# A Status Model for Case Decisions: Active, Superseded, Withdrawn ![](https://cdn.hashnode.com/uploads/covers/6ae04d7c9adf5de0a6c3164d/1cc0490c-07da-4175-b360-a8083935dd39.png align="center") 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](https://technoxander.com/rag-ai-aml-investigation-explainable/). The wider picture is in [organisational memory in AML](https://technoxander.com/organisational-memory-aml-ai-investigations/). Related: how a commit-message approach feeds this model and a diagram of the reuse test . **Conclusion.** Status is cheap to store and expensive to lack. We build for it at [TechnoXander](https://technoxander.com/aml-investigation-platform/). If you’ve modelled decision history, did you version the reasoning or only the outcome?