# PRUVIQ forward paper trading — verifier readings fixed before start (v1, 2026-09-26)

These readings apply the pre-registered rules (forward-rules-v1, batch1-prereg) to cases the rule text does not spell out.
They were fixed before any forward data existed. Readings added before a later start are published as a new
version (v1.x) with a new commitment. Nothing here changes a rule; where a reading would have changed a rule, it
was withdrawn (see R7).

## B1 · B2 · B3 (shared verifier logic)
- R1 parity-A «explained» mismatch: a batch-vs-hourly mismatch counts as explained only if one of the price cells that
  row actually read arrived late (that hour's cell plus the unbroken run of late hours just before it, up to 31 days
  back). Explained mismatches are excluded from D3; if they exceed 5% of the window's compared hours at the horizon end
  → CANNOT_JUDGE (data problem). All parity-A counts are taken over the judged window only. A funding-only mismatch
  at hour h is explained only by an equity restatement recorded within 48 h after h (L = 48 h).
- R1b settling: the end-of-horizon label is final only once the journal reaches horizon end + 48 h; a run before that
  reports «SETTLING» (not a label). If the journal still has not reached horizon end + 48 h once 96 h have passed
  after the horizon end (e.g. the tracker stopped), the label becomes final anyway (for a journal that stopped early this
  is CANNOT_JUDGE). A journal that covers the window but ends before horizon end + 48 h is CANNOT_JUDGE («settling
  incomplete»), so a data lag at the end can never become a D3 REJECT. The same journal therefore always gives the
  same final label, whenever it is run.
- R2 parity-A coverage: every journal hour inside the window must have been compared; otherwise CANNOT_JUDGE.
- R3 parity-B input: must carry candidate, window start/end and the generator's sha256, and the generator's sha must be
  recorded before first use; otherwise CANNOT_JUDGE. Counts must be non-negative integers.
- R4 source_missing: a day counts as «no data at the exchange» only if a recorded, hash-checked exchange response shows
  the bar absent while a later bar is confirmed and the response reaches back past that hour. Anything else is
  unresolved → CANNOT_JUDGE at the horizon end, never silently excluded.
- R5 integrity: the verifier checks the code it actually runs against the pinned hashes, the journal hash chain and
  decision/snapshot hashes. Daily anchors: every anchor must match the journal chain; once the journal is older than
  48 h the newest anchor must be ≤ 48 h old; anchor times are strict UTC, and an unparseable time or one more than
  1 h in the future is invalid. Any failure → CANNOT_JUDGE.

## B3 only
- R6 funding day closure: a day's funding counts as complete only if the source was observed at or after 23:15 UTC that
  day (file version checked); otherwise the coin is blocked for that decision as a data problem.
- R7 withdrawn: an earlier draft exempted a D4 shortfall «covered» by data-blocked signals. It contradicted D4's text
  («entries blocked by data do not count») and was withdrawn. D4 applies as written.
- R8 data-problem thresholds (new CANNOT_JUDGE conditions, applications of the rule «data problems are CANNOT_JUDGE, not
  REJECT»): signal-data blocks > 10% of evaluations; missing fills + late exits + price skips > 10% of fills plus price
  skips; inconsistent counters (e.g. blocks with zero evaluations, negative counts).
- R9 exposure cap: an entry that would exceed the pre-registered cap on open legs (so that gross exposure stays within
  the pre-registered |w| ≤ 1) is skipped and logged as «cap»; this is a rule, not a data problem.
- R10 reporting only (no effect on the label): the 12-week report also shows D1 with the funding stamp at the entry hour
  excluded, because including it slightly favours the candidate. (Already implemented in the B3 verifier.)