Hour audit: 2026-10-10T03
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.
1 finding
- the checksum ledger does not name this file. No line in the corpus checksum ledger names this file, so the documented verification step passes over it in silence rather than checking it. The manifest below still carries the digest.
1 check could not be evaluated for this hour, listed with the reason in the block below. A check we could not run is recorded as exactly that, and never counted as a pass.
The report
POLYMARKET ORDERBOOK ARCHIVE — HOUR AUDIT
hour 2026-10-10T03 · corpus v3 · verdict AUDIT PENDING
COVERAGE not measured (this hour is not in the corpus attestation, so we have not looked at it)
VOLUME 131,348,604 rows · 1,516,306,712 bytes (1.41 GiB) · 7 products, all holding rows
WITNESSES himno — 5 machines contributed rows
captured i: 131,188,051 · m: 130,695,808 · o: 130,675,125 · h: 130,654,577 · n: 130,631,061 (each machine's own feed; these overlap and do not sum to the file)
supplied i: 755,362 (0.58%) · m: 64,925,647 (49.43%) · o: 65,145,783 (49.60%) · h: 464,742 (0.35%) · n: 57,070 (0.04%) (rows of the merged file that came from it; these partition it)
2 product-machine pairs publish no supplied count; the figures above still sum to the file's 131,348,604 rows exactly, so those pairs supplied none
5 expected, all 5 contributed
INTEGRITY sha256 df5237c68690243102eb37fbfbccd3240d0ff79b9c8ee97a89074e2bf50987a6
no line in the corpus checksum ledger names this file
joined 131,351,060 to merged 131,348,604, minus 2,456 (minus 0.0019%)
boundary drops 2,456 · 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-10-10T11:22:52Z as himno
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 6/8 pass, 1 finding, 1 not evaluated
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
FINDING the checksum ledger does not name this file
SKIPPED the hour's minutes have not been measured
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,330,046 153,783,687 0-47 cab2f0284d05c97365ea596a3baae5dc8c90f168ec685f7fb57ac39e637de127 book 778,575 74,647,982 48-50 a25553fbc4e1d55eb9308e10d5fd908252d2bb43b2826451fde322b01a1f59a1 last_trade_price 42,007 2,488,283 51-51 0dfc2d8e29f661702bdc57473aac3fbcf3753218b2bf898c498624f035130341 market_resolved 1,006 163,480 52-52 ed60f574b4b85611a36cca5a926f414021901a465cc4b6706d3244f337748025 new_market 390 43,399 53-53 c4774c7c6007dfc945bfc3488b78a3fe601511f22a70c98109a25fdecf8b3051 price_change 118,192,260 1,283,527,263 54-504 dd58ac4a9497319e6787703489f56a26fe0dd34d5e5e5e48d9bf6e169b4664c7 tick_size_change 4,320 157,719 505-505 430d509ad80ea7f8ef184d4d9d3d780771dade0aeb697da9621d13c50280df55 EVENT MIX count share price_change 118,192,260 89.98% best_bid_ask 12,330,046 9.39% book 778,575 0.59% last_trade_price 42,007 0.03% tick_size_change 4,320 <0.01% market_resolved 1,006 <0.01% new_market 390 <0.01% PER PRODUCT joined merged boundary exception mkts class best_bid_ask 12,330,184 12,330,046 138 45 FULL book 779,893 778,575 1,318 259,950 FULL last_trade_price 42,007 42,007 0 1 FULL market_resolved 1,006 1,006 0 0 FULL new_market 390 390 0 0 FULL price_change 118,193,260 118,192,260 1,000 216 FULL tick_size_change 4,320 4,320 0 0 FULL ARRIVAL SKEW m rows won p50 p90 p99 max unmeasurable interpretation best_bid_ask h 12,329,324 33,647 17ms 23ms 80ms 25.4s 0 transport_latency_assumed best_bid_ask i 12,326,108 16,208 21ms 38ms 65ms 3.8s 0 transport_latency_assumed best_bid_ask m 12,329,383 6,034,744 4ms 9ms 46ms 3.9s 0 transport_latency_assumed best_bid_ask n 12,328,626 1,354 44ms 51ms 119ms 5.7s 0 transport_latency_assumed best_bid_ask o 12,329,601 6,244,093 4ms 9ms 48ms 5.0s 0 transport_latency_assumed book h 104,146 17,986 22ms 15.6min 20.5d 114.7d 0 book_staleness book i 696,427 554,398 7.8min 2.0d 48.6d 133.2d 0 book_staleness book m 145,642 91,299 10ms 11.2h 34.5d 133.2d 0 book_staleness book n 136,077 39,927 53ms 9.8h 34.5d 133.2d 0 book_staleness book o 130,319 74,965 8ms 7.3h 32.7d 133.2d 0 book_staleness last_trade_price h 41,946 335 19ms 29ms 203ms 3.0s 0 transport_latency_assumed last_trade_price i 41,861 158 22ms 40ms 161ms 2.1s 0 transport_latency_assumed last_trade_price m 41,916 21,097 5ms 12ms 92ms 1.9s 0 transport_latency_assumed last_trade_price n 41,917 10 45ms 79ms 277ms 4.8s 0 transport_latency_assumed last_trade_price o 41,966 20,407 5ms 12ms 116ms 1.9s 0 transport_latency_assumed market_resolved h 980 1 20ms 26.4s 53.4s 54.1s 0 transport_latency_assumed market_resolved i 980 134 25ms 17.9s 49.0s 57.1s 0 transport_latency_assumed market_resolved m 980 390 5ms 18.6s 45.5s 49.7s 0 transport_latency_assumed market_resolved n 980 not meas. 47ms 26.7s 50.1s 57.5s 0 transport_latency_assumed market_resolved o 980 481 5ms 29.1s 51.0s 56.1s 0 transport_latency_assumed new_market h 271 38 54ms 7.0s 18.5s 1.8min 0 transport_latency_assumed new_market i 271 77 43ms 362ms 15.8s 1.6min 0 transport_latency_assumed new_market m 271 144 33ms 12.6s 1.5min 1.8min 0 transport_latency_assumed new_market n 271 39 73ms 11.8s 13.8s 1.7min 0 transport_latency_assumed new_market o 271 92 34ms 269ms 15.6s 1.7min 0 transport_latency_assumed price_change h 118,173,590 412,722 17ms 24ms 115ms 25.4s 0 transport_latency_assumed price_change i 118,118,084 184,384 21ms 39ms 90ms 3.8s 0 transport_latency_assumed price_change m 118,173,296 58,775,956 4ms 10ms 54ms 5.2s 0 transport_latency_assumed price_change n 118,118,870 15,740 44ms 54ms 189ms 6.1s 0 transport_latency_assumed price_change o 118,167,668 58,803,458 4ms 10ms 58ms 5.1s 0 transport_latency_assumed tick_size_change h 4,320 13 17ms 23ms 47ms 71ms 0 transport_latency_assumed tick_size_change i 4,320 3 21ms 38ms 61ms 426ms 0 transport_latency_assumed tick_size_change m 4,320 2,017 4ms 10ms 33ms 83ms 0 transport_latency_assumed tick_size_change n 4,320 not meas. 44ms 50ms 91ms 185ms 0 transport_latency_assumed tick_size_change o 4,320 2,287 4ms 8ms 28ms 93ms 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-10-10/03/2026-10-10T03.parquet sha256sum 2026-10-10T03.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.