An operations manager opens yesterday's AI-assisted answer: "We have enough equipment for the session." The wording has not changed. Today's bookings may have. Before copying the answer into a new decision, check what its evidence still supports.
Use an evidence-reuse card for each load-bearing fact, rather than assigning one expiry date to the whole answer. A stock count, a product dimension and an operating instruction do not necessarily age in the same way. The UK Government Data Quality Framework treats data quality as fitness for purpose and defines timeliness in relation to the period represented, current values and the lag appropriate to the intended use.[1]
This is MAJLS's proposed evidence-reuse framework. It helps a process owner decide what to check again. It is not a universal retention policy, a prediction of when facts become wrong, or a claim that a MAJLS system already monitors your records.
Framework: give each fact a reuse boundary
A review date is a prompt to check, not proof that a fact remains correct until midnight. GOV.UK's content guidance distinguishes the date content was last updated from whether it is overdue for a review set by an editor.[2] Borrow that distinction for internal answers: keep the observation time and the next review time separate.
Write these fields before someone relies on the answer:
- Identify the fact, its source record and the person responsible for that source. "Stock system" is too broad; use the item and location identifier.
- Record when the source observed the fact, when you retrieved it and which revision you used. A retrieval timestamp does not establish a new observation.
- Define the permitted use. A count for an indoor training session does not establish suitability for an outdoor installation.
- Set a review-by time that the source owner can explain, and list events that require an earlier check: a reservation, revision, incident or changed requirement.
- State how those events will be detected. If nobody can check the event history, mark that dependency unknown rather than declaring that nothing changed.
- Name the reviewer and the next action when a check is due. Keep the former answer available as history, visibly separate from a current recommendation.
For a small workflow, a table is enough. Do not build a monitoring system before you can explain who maintains these fields and how a reader sees a held fact.
Filled example: a studio preparing an indoor session
The following people, records, times and rules are illustrative. They are not client data or recommended expiry periods. The decision time is 09:15 UTC on 8 October 2026. Lena, the fictional studio operations manager, reviews five facts before committing equipment to a session.
| Fact and source | Observation; review boundary | What the 09:15 check finds | Reuse decision |
|---|---|---|---|
| Eight light stands available, stock ST-4 | 08:00; review by 08:30 or any reservation | Deadline passed; no current availability check | Hold the availability claim; request a new count |
| Room access working, access check AC-2 | 09:05; review by 09:20 or access incident | Incident log records a lock fault at 09:10 | Hold despite being within the time window |
| Tripod folded length, specification SP-7 rev 3 | 1 September 09:00; review by 1 November 09:00 or specification revision | Source owner confirms rev 3 remains current; intended use unchanged | Reuse the dimension as reference, not a stock promise |
| Backdrop width, measurement ME-6 | 09:12; review by 10:00 or altered setup | Request now includes outdoor use, beyond the measurement's scope | Keep width as reference; hold outdoor suitability |
| Spare cables available, copied chat CH-8 | Observation time and item IDs unknown; no boundary | Current count cannot be traced | Hold; ask the stock owner for identifiable evidence |
The old answer needs revision because its availability and access dependencies are held. Reusing the tripod dimension does not rescue it. Lena can prepare a narrower planning note, but she cannot turn the missing count into an equipment commitment.
A filled card for ST-4 reads: "Fact: available light stands at studio A. Source: stock ST-4. Observed: 08:00 UTC. Retrieved: 08:05 UTC. Use: indoor-session planning only. Review: 08:30 UTC or reservation event, whichever comes first. Trigger check: stock reservation history. Source owner: Omar, stock custodian. Decision reviewer: Lena. At 09:15: held; current count requested; no commitment authorized."
Decision rule: reuse, narrow or recheck
Reuse a fact only when its identity and observation are traceable, its permitted use still fits, its review boundary has not been reached, and the required change checks are complete. These are MAJLS's proposed operating conditions, not thresholds supplied by the sources.
If only part of an answer passes, narrow the answer and identify the held dependencies. If a deadline has passed, an invalidating event occurred, the purpose changed or the event history is unavailable, request a fresh check. Missing evidence is a reason to stop; a confident restatement is not a substitute.
The Government Data Quality Framework calls for ongoing assessment and accountability for data quality.[1] In this adaptation, the source owner updates the observation; the reviewer decides whether it supports the intended use. The assistant may assemble the card and point out gaps. Consequential approval stays with the named human process owner, Lena in this illustrative example. Equipment commitments and customer promises require her explicit approval after the missing checks are resolved.
Checklist: test the card before adopting it
Run a tabletop check using an expired observation, a recent observation invalidated by an event, an unchanged stable reference, a changed purpose and an untraceable copied claim. The filled example gives you one of each.
Ask another reviewer to reach a decision from the card alone. If they must guess the source, time zone, trigger history or decision owner, revise the card before using it in a live workflow. Keep historical observations intact when you add a new one. Start with the fact that could change today's decision, then check the other dependencies before authorizing the action.