Hour audit: 2026-09-07T06
back to the files for this hour · how the archive is audited
Every number on this page is a stored measurement read from this hour's own records: its
manifest.json, its witness
statistics sidecar, and the corpus attestation. Nothing here is computed from the served
bytes at the time you load the page, so no line below claims the bytes are correct. The
digest and the one command that checks them are printed instead.
No findings
Every check that could be evaluated for this hour passed. That is not the same as the hour being perfect: it means the records this archive keeps about it agree with each other and with the corpus ledger.
The report
POLYMARKET ORDERBOOK ARCHIVE — HOUR AUDIT
hour 2026-09-07T06 · corpus v3 · verdict AUDIT PASS
COVERAGE minutes present 60/60 · first event 2026-09-07T06:00:00.000013811+00:00 · last event 2026-09-07T06:59:59.999994967+00:00
VOLUME 84,258,249 rows · 810,621,412 bytes (773.07 MiB) · 7 products, all holding rows
WITNESSES cefgh — 5 machines contributed rows
captured f: 84,133,651 · c: 84,128,685 · g: 84,114,156 · e: 84,088,842 · h: 84,013,095 (each machine's own feed; these overlap and do not sum to the file)
supplied f: 101,301 (0.12%) · c: 81,653,395 (96.91%) · g: 26,193 (0.03%) · e: 276,362 (0.33%) · h: 2,200,998 (2.61%) (rows of the merged file that came from it; these partition it)
6 product-machine pairs publish no supplied count; the figures above still sum to the file's 84,258,249 rows exactly, so those pairs supplied none
5 expected, all 5 contributed
INTEGRITY sha256 b092150e27e4e431a3749e1394c122729d0333b9547755b3918db4d0e30510b6
the corpus checksum ledger names this file with the same digest
joined 84,259,944 to merged 84,258,249, minus 1,695 (minus 0.0020%)
boundary drops 1,695 · guard cache
SIDECARS none: this hour's manifest has no v31 key. The v3.1 sidecars are optional, and hours before them have none
MARKETS not measured (the per-hour market census runs on the capture host and its output is not published per hour)
HISTORY merged 2026-09-07T07:52:41Z as cefgh
layout union-event-sorted-v1
re-merges not measured (the merge ledger records the merge that produced this file, not the history of attempts)
supersessions not measured (supersession is recorded per corpus in the storage registry, not in the hour manifest)
CHECKS 8/8 pass
PASS all products present
PASS row counts reconcile
PASS byte ranges tile the file
PASS the merge delta is explained
PASS every expected machine contributed
PASS the checksum ledger names this file
PASS the hour is whole
PASS a boundary guard ran
UPSTREAM our incident register was checked against the venue's own status feed at 2026-09-23T20:35Z and names no event in this hour. That is a statement about what they published, not a check that every message they sent reached us.The words in this report
Each line in the CHECKS block states what was found, not what was
hoped for: a check that passes is named for the thing that is true, and a check that does
not is renamed to the thing that is wrong. So FINDING never sits beside a
sentence asserting the opposite of the one below it.
The report above is fixed-width text, so nothing in it can be clicked. The same terms are linked here instead. Its verdict is a statement about minutes and nothing else. The row it reports comes from this hour's own manifest and its witness-statistics sidecar, and the completeness line comes from the corpus attestation. The gap between the joined and merged counts is deduplication, not loss, and the boundary drops are the duplicates discarded at the seam with the hour before. Where the history line names a supersession, this hour was rebuilt to a better state after it was first published. The precision is the timestamp resolution these files carry.
Detail
The same records, per product. A product holding no rows renders its zero rather than
being dropped: dropped and empty are indistinguishable to a reader, and only one of them is
a defect. A cell reading not meas. is one nothing published, which is a third
thing again and never a zero.
The class column is the merger's own verdict for that product, and it is
keyed to CONTRIBUTION rather than presence. FULL means every machine expected to
be capturing this hour delivered rows for that product; PARTIAL means some did
and some did not; SINGLE-BY-DESIGN means only one machine was ever expected, and
SINGLE-BY-DEFECT means several were and one delivered. So PARTIAL
here is a statement about the fleet, not about the product being damaged or truncated: the
rows that are present are whole.
PRODUCT rows bytes row groups sha256 best_bid_ask 7,663,877 84,012,203 0-29 6bb430df67f802ae19c5334ffc948911e891a7660ac5ddfdbb05d40e2b6f9f03 book 119,685 12,091,605 30-30 d5de551eb53c2116133d11274a6388d6cb7fab36598729fd204b632f03a3a5b9 last_trade_price 48,741 2,762,127 31-31 0c0824f4f2db5d3101400243659ee24fbda24ca3e705499ca8b470ac2a79a0d2 market_resolved 699 114,991 32-32 ec8162e4d5c9f1812a5a793ed34428ae4b340b320c892e6a61e843663e50d51c new_market 1,741 167,659 33-33 46fb5e86c792395d1a28b37349da1600f3a957603c2d97f85b5817e5031c5911 price_change 76,420,246 710,389,490 34-325 7274d1d1a03363eb8002467771860e06c2627bb89f356de3cc4ea182faf079cc tick_size_change 3,260 118,720 326-326 53cb88b2a82ba56f8c0a39643d3e59588856e68aafcc5156b0cef2fe3cc3e40f EVENT MIX count share price_change 76,420,246 90.70% best_bid_ask 7,663,877 9.10% book 119,685 0.14% last_trade_price 48,741 0.06% tick_size_change 3,260 <0.01% new_market 1,741 <0.01% market_resolved 699 <0.01% PER PRODUCT joined merged boundary exception mkts class best_bid_ask 7,664,043 7,663,877 166 385 FULL book 119,687 119,685 2 7,241 FULL last_trade_price 48,742 48,741 1 0 FULL market_resolved 699 699 0 0 FULL new_market 1,741 1,741 0 0 FULL price_change 76,421,772 76,420,246 1,526 805 FULL tick_size_change 3,260 3,260 0 0 FULL ARRIVAL SKEW m rows won p50 p90 p99 max unmeasurable interpretation best_bid_ask c 7,662,446 7,452,204 5ms 8ms 81ms 8.9s 0 transport_latency_assumed best_bid_ask e 7,661,208 17,621 39ms 43ms 156ms 9.4s 0 transport_latency_assumed best_bid_ask f 7,660,820 7,507 50ms 54ms 174ms 5.8s 0 transport_latency_assumed best_bid_ask g 7,659,836 644 80ms 97ms 353ms 19.5s 0 transport_latency_assumed best_bid_ask h 7,661,763 185,901 17ms 21ms 126ms 1.6min 0 transport_latency_assumed book c 103,774 98,370 7ms 24ms 10.5min 81.8d 0 book_staleness book e 104,158 3,613 41ms 158ms 39.5min 81.8d 0 book_staleness book f 103,264 1,954 52ms 166ms 1.2min 81.8d 0 book_staleness book g 111,022 10,074 91ms 1.6s 23.9h 81.8d 0 book_staleness book h 102,460 5,674 20ms 44ms 3.5s 81.8d 0 book_staleness last_trade_price c 48,638 46,662 10ms 36ms 218ms 5.0s 0 transport_latency_assumed last_trade_price e 48,669 170 45ms 107ms 900ms 9.6s 0 transport_latency_assumed last_trade_price f 48,640 48 56ms 121ms 919ms 5.8s 0 transport_latency_assumed last_trade_price g 48,470 8 94ms 186ms 1.6s 19.6s 0 transport_latency_assumed last_trade_price h 48,626 1,853 22ms 50ms 253ms 51.3s 0 transport_latency_assumed market_resolved c 699 688 5ms 9ms 29ms 61ms 0 transport_latency_assumed market_resolved e 699 not meas. 41ms 186ms 440ms 639ms 0 transport_latency_assumed market_resolved f 699 not meas. 51ms 200ms 453ms 650ms 0 transport_latency_assumed market_resolved g 699 not meas. 85ms 354ms 809ms 1.1s 0 transport_latency_assumed market_resolved h 699 11 18ms 81ms 159ms 229ms 0 transport_latency_assumed new_market c 1,080 687 96ms 19.4s 37.5s 7.8h 0 transport_latency_assumed new_market e 1,080 414 152ms 24.9s 39.6s 2.6h 0 transport_latency_assumed new_market f 1,080 177 182ms 28.8s 41.9s 13.5min 0 transport_latency_assumed new_market g 1,080 117 251ms 30.9s 39.6s 1.7h 0 transport_latency_assumed new_market h 1,080 346 155ms 27.1s 39.7s 11.0h 0 transport_latency_assumed price_change c 76,308,788 74,051,584 5ms 9ms 97ms 8.9s 0 transport_latency_assumed price_change e 76,269,768 254,544 39ms 45ms 206ms 9.7s 0 transport_latency_assumed price_change f 76,315,888 91,615 50ms 56ms 222ms 5.8s 0 transport_latency_assumed price_change g 76,289,789 15,350 81ms 99ms 424ms 19.8s 0 transport_latency_assumed price_change h 76,195,207 2,007,153 17ms 22ms 149ms 1.6min 0 transport_latency_assumed tick_size_change c 3,260 3,200 5ms 7ms 26ms 95ms 0 transport_latency_assumed tick_size_change e 3,260 not meas. 39ms 42ms 73ms 122ms 0 transport_latency_assumed tick_size_change f 3,260 not meas. 50ms 53ms 112ms 124ms 0 transport_latency_assumed tick_size_change g 3,260 not meas. 80ms 93ms 202ms 233ms 0 transport_latency_assumed tick_size_change h 3,260 60 17ms 20ms 74ms 2.1s 0 transport_latency_assumed
Captured and supplied are different numbers
Captured is how many rows each machine's own feed carried. Redundant capture means these OVERLAP, heavily and on purpose, so they do not partition the file and their sum is larger than it. Two machines each capturing nearly every event is the archive working, not double counting.
Supplied is how many rows of the merged file actually came from that machine. This one does partition: it sums to the file's row count exactly. But it is decided by the merge's tie-break, so a machine can capture almost everything and supply almost nothing. Read alone, either number tells a false story about the fleet, which is why both are printed and neither is called "the witness share".
What the skew columns mean
Arrival skew is the receipt timestamp minus the venue timestamp, in milliseconds. For six of the seven products the sidecar interprets it as transport latency, and marks that interpretation assumed: it rests on the venue timestamp being emit time, which we cannot verify from outside.
book is not latency and must not be read as latency. Its
venue timestamp is the last time the book changed, so the sidecar interprets it as book
staleness and warns in its own note that large values mean a quiet book rather than slow
transport. Its maximum runs to weeks for that reason. This is why the table above gives a
row per product per machine and never one figure for the hour: percentiles do not average,
and these seven do not measure the same quantity.
Check it yourself
The digest above is a claim. This is how you refuse to take our word for it:
curl -O https://archive.pendulumflow.com/v3/2026-09-07/06/2026-09-07T06.parquet sha256sum 2026-09-07T06.parquet # compare with the sha256 line in the report above
A range digest certifies bytes. That those bytes are the product the manifest names comes from the manifest, which is why both are published and both are checkable.