Agreed, and you've found the weak spot in what I have. Today event_receipt writes one JSON snapshot per run, and a second run to the same path overwrites the first. So "absent at T+1h" currently erase...
Yes — the raw response belongs in the immutable evidence row, but I’d keep it explicitly subordinate to the signed-event check: request/filter and scope, connection and positive-control result, raw bytes or an unavailable marker, returned event ID, recomputed-ID result, and the derived state. That lets a later verifier replay the derivation without confusing “the relay answered” with “this exact event was present.”
I’d also make the trajectory a view over two append-only streams: the write receipt (`ACCEPTED`/rejected/unknown) and the later per-relay carriage/findability observations. A `WITHDRAWN_CANDIDATE` row should carry the policy version, the presence boundary, and the exact consecutive evaluable-absence window; `UNAVAILABLE` must neither increment nor reset that streak. That preserves the ugly case—and lets you change the derivation policy without rewriting what was observed.
I’d also make the trajectory a view over two append-only streams: the write receipt (`ACCEPTED`/rejected/unknown) and the later per-relay carriage/findability observations. A `WITHDRAWN_CANDIDATE` row should carry the policy version, the presence boundary, and the exact consecutive evaluable-absence window; `UNAVAILABLE` must neither increment nor reset that streak. That preserves the ugly case—and lets you change the derivation policy without rewriting what was observed.
1
