Hour audit: 2026-09-30T14
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-30T14 · corpus v3 · verdict AUDIT PASS
COVERAGE minutes present 60/60 · first event 2026-09-30T14:00:00.000005103+00:00 · last event 2026-09-30T14:59:59.999842576+00:00
VOLUME 134,679,324 rows · 1,523,284,689 bytes (1.42 GiB) · 7 products, all holding rows
WITNESSES ghikm — 5 machines contributed rows
captured h: 133,164,964 · m: 133,125,707 · i: 132,814,847 · k: 121,258,442 · g: 121,222,068 (each machine's own feed; these overlap and do not sum to the file)
supplied h: 6,118,914 (4.54%) · m: 112,762,216 (83.73%) · i: 2,034,400 (1.51%) · k: 12,850,617 (9.54%) · g: 913,177 (0.68%) (rows of the merged file that came from it; these partition it)
1 product-machine pair publish no supplied count; the figures above still sum to the file's 134,679,324 rows exactly, so those pairs supplied none
5 expected, all 5 contributed
INTEGRITY sha256 dfe4780f4c616d04ab1e27a4ce5f94ea900aff245a1ebfaa75dcd5a7754d9820
the corpus checksum ledger names this file with the same digest
joined 134,682,065 to merged 134,679,324, minus 2,741 (minus 0.0020%)
boundary drops 2,741 · 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-30T21:01:39Z as ghikm
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 status feed unobserved for this hour. Our incident register was last checked against the venue's feed at 2026-09-23T20:35Z, before this hour ended, so nothing has looked yet. This is a could-not-look and never an all-clear.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 12,498,697 149,348,719 0-47 84c8e94c39e7afc749185a89100a0bcc392adca9d7dfe0eb1904dfabaa611d15 book 1,980,010 108,260,275 48-55 7400c71ebf08c0672e61c75cc16b8da61694b7fad0c0f0829bfa4bb71a54a34e last_trade_price 68,801 3,934,713 56-56 1881f1b1fbbb02b4b516dbfea7a576fe37567de68f30d26e06b0f314bc06aaa3 market_resolved 1,211 147,185 57-57 30ed6602f8a9931151eb342a835bfa96e592973d5af722c33c2b345b09fedf64 new_market 1,815 189,139 58-58 003fa1007d878c0c60e4539efa94b85200dd7193f479e51db9b9cd5b94c6dd9c price_change 120,125,214 1,259,738,906 59-517 5a0006ba8097682bb5180621f2687c0b0e72b122202e31ff4526490a28f5b98c tick_size_change 3,576 132,876 518-518 c46c4cea0eef36a3c8423abe3bd8dd1fa19295a8bce82cdbc2f4414e8c6556ab EVENT MIX count share price_change 120,125,214 89.19% best_bid_ask 12,498,697 9.28% book 1,980,010 1.47% last_trade_price 68,801 0.05% tick_size_change 3,576 <0.01% new_market 1,815 <0.01% market_resolved 1,211 <0.01% PER PRODUCT joined merged boundary exception mkts class best_bid_ask 12,498,975 12,498,697 278 2,051 FULL book 1,980,082 1,980,010 72 225,588 FULL last_trade_price 68,802 68,801 1 472 FULL market_resolved 1,211 1,211 0 115 FULL new_market 1,867 1,815 52 78 FULL price_change 120,127,552 120,125,214 2,338 2,331 FULL tick_size_change 3,576 3,576 0 174 FULL ARRIVAL SKEW m rows won p50 p90 p99 max unmeasurable interpretation best_bid_ask g 11,295,062 6,109 80ms 108ms 497ms 25.0s 0 transport_latency_assumed best_bid_ask h 12,494,084 405,589 18ms 34ms 323ms 2.6min 0 transport_latency_assumed best_bid_ask i 12,498,182 157,148 21ms 56ms 188ms 16.3s 0 transport_latency_assumed best_bid_ask k 11,277,388 943,000 15ms 38ms 140ms 53.4s 0 transport_latency_assumed best_bid_ask m 12,495,402 10,986,851 5ms 19ms 107ms 5.0s 0 transport_latency_assumed book g 1,324,589 841,555 57.6min 3.1d 39.0d 123.7d 0 book_staleness book h 537,379 139,178 8.1min 2.2d 39.0d 123.7d 0 book_staleness book i 145,867 6,535 27ms 116ms 14.8h 105.2d 0 book_staleness book k 1,252,751 770,258 57.3min 3.2d 39.0d 123.7d 0 book_staleness book m 508,140 222,484 6.1min 2.0d 39.0d 123.7d 0 book_staleness last_trade_price g 62,492 136 89ms 246ms 7.0s 25.0s 0 transport_latency_assumed last_trade_price h 68,728 6,859 19ms 48ms 603ms 45.4s 0 transport_latency_assumed last_trade_price i 68,779 1,551 26ms 68ms 440ms 16.2s 0 transport_latency_assumed last_trade_price k 60,774 8,823 17ms 51ms 185ms 1.5s 0 transport_latency_assumed last_trade_price m 68,686 51,432 8ms 40ms 213ms 4.9s 0 transport_latency_assumed market_resolved g 952 186 92ms 7.9min 12.2min 12.7min 0 transport_latency_assumed market_resolved h 846 28 20ms 224ms 32.4s 44.7s 0 transport_latency_assumed market_resolved i 846 3 26ms 147ms 34.8s 43.5s 0 transport_latency_assumed market_resolved k 949 235 21ms 8.5min 10.5min 11.6min 0 transport_latency_assumed market_resolved m 846 759 6ms 57ms 27.3s 37.5s 0 transport_latency_assumed new_market g 1,233 385 15.4s 1.3min 22.3d 32.8d 0 transport_latency_assumed new_market h 1,173 124 432ms 23.9s 1.2min 1.5min 0 transport_latency_assumed new_market i 1,173 459 13.1s 35.7s 1.4min 32.8d 0 transport_latency_assumed new_market k 1,333 448 306ms 3.1min 6.2min 6.3min 0 transport_latency_assumed new_market m 1,173 399 13.2s 26.9s 1.3min 32.8d 0 transport_latency_assumed price_change g 108,534,444 64,806 81ms 129ms 1.8s 25.1s 0 transport_latency_assumed price_change h 120,059,182 5,566,952 18ms 37ms 349ms 2.6min 0 transport_latency_assumed price_change i 120,096,424 1,868,626 21ms 59ms 227ms 21.0s 0 transport_latency_assumed price_change k 108,662,083 11,127,413 15ms 40ms 150ms 53.9s 0 transport_latency_assumed price_change m 120,047,884 101,497,417 6ms 25ms 135ms 5.0s 0 transport_latency_assumed tick_size_change g 3,296 not meas. 80ms 111ms 242ms 503ms 0 transport_latency_assumed tick_size_change h 3,572 184 19ms 37ms 100ms 558ms 0 transport_latency_assumed tick_size_change i 3,576 78 21ms 59ms 186ms 284ms 0 transport_latency_assumed tick_size_change k 3,164 440 14ms 36ms 131ms 203ms 0 transport_latency_assumed tick_size_change m 3,576 2,874 5ms 27ms 70ms 129ms 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-30/14/2026-09-30T14.parquet sha256sum 2026-09-30T14.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.