Hour audit: 2026-09-14T19
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-14T19 · corpus v3 · verdict AUDIT PASS
COVERAGE minutes present 60/60 · first event 2026-09-14T19:00:00.000051885+00:00 · last event 2026-09-14T19:59:59.999948063+00:00
VOLUME 119,575,028 rows · 1,302,011,080 bytes (1.21 GiB) · 7 products, all holding rows
WITNESSES cefgh — 5 machines contributed rows
captured h: 117,806,470 · e: 117,693,783 · f: 113,413,857 · g: 113,287,466 · c: 100,543,860 (each machine's own feed; these overlap and do not sum to the file)
supplied h: 21,761,258 (18.20%) · e: 1,539,207 (1.29%) · f: 1,007,583 (0.84%) · g: 148,252 (0.12%) · c: 95,118,728 (79.55%) (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 119,575,028 rows exactly, so those pairs supplied none
5 expected, all 5 contributed
INTEGRITY sha256 063f79352231e34df2b916884f1f3a321af46d55bc6c40b9ab0524dca5397d93
the corpus checksum ledger names this file with the same digest
joined 119,582,476 to merged 119,575,028, minus 7,448 (minus 0.0062%)
boundary drops 7,448 · 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-14T21:00:08Z 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 11,018,170 126,561,426 0-42 61d4bd2efdf38325f169cc4aac7a0bb370a9598ccb6d94bf24a22159b4e9a119 book 1,800,879 90,627,625 43-49 5c49b5d5506ee13255399de7ebc52558164adf616aa55353d4a1261257c3ec9f last_trade_price 58,051 3,394,334 50-50 8de6d959b6288e95d021b6690fc7c7ff00f359dad865f4c262dcb1ed3087f19b market_resolved 1,187 168,446 51-51 3dd333378c3feeca078a547239f1660625ec6accb78cd21744c1e2655964f455 new_market 4,425 413,543 52-52 4144e57272ccad5cd174f5381422809de7d0318b934d377eb8effa34e2221667 price_change 106,686,812 1,079,286,560 53-459 1871fa559b25f3036c18deb50903eeedb7d8ced88a6a10597c1e7c70c6849b3e tick_size_change 5,504 199,222 460-460 63c035ad8898fe6419864cda4ba066a9bd3490acfa8a39093bdf90f7157515da EVENT MIX count share price_change 106,686,812 89.22% best_bid_ask 11,018,170 9.21% book 1,800,879 1.51% last_trade_price 58,051 0.05% tick_size_change 5,504 <0.01% new_market 4,425 <0.01% market_resolved 1,187 <0.01% PER PRODUCT joined merged boundary exception mkts class best_bid_ask 11,018,348 11,018,170 178 2,468 FULL book 1,805,421 1,800,879 4,542 167,331 FULL last_trade_price 58,053 58,051 2 504 FULL market_resolved 1,187 1,187 0 244 FULL new_market 4,425 4,425 0 20 FULL price_change 106,689,538 106,686,812 2,726 1,732 FULL tick_size_change 5,504 5,504 0 218 FULL ARRIVAL SKEW m rows won p50 p90 p99 max unmeasurable interpretation best_bid_ask c 9,269,876 8,785,718 6ms 15ms 162ms 7.4s 0 transport_latency_assumed best_bid_ask e 11,012,626 142,901 47ms 73ms 388ms 26.1s 0 transport_latency_assumed best_bid_ask f 10,563,047 78,140 49ms 73ms 384ms 29.8s 0 transport_latency_assumed best_bid_ask g 10,555,317 6,071 83ms 165ms 819ms 40.1s 0 transport_latency_assumed best_bid_ask h 11,016,100 2,005,340 18ms 38ms 379ms 55.3s 0 transport_latency_assumed book c 1,622,081 1,575,886 19.3min 3.1d 37.2d 107.9d 0 book_staleness book e 128,642 6,319 56ms 1.4s 9.5h 89.4d 0 book_staleness book f 464,272 121,967 2.6min 1.4d 33.2d 107.9d 0 book_staleness book g 485,871 69,293 2.9min 1.4d 33.2d 107.9d 0 book_staleness book h 125,628 27,414 23ms 150ms 2.5min 47.3d 0 book_staleness last_trade_price c 46,746 44,036 12ms 53ms 240ms 5.0s 0 transport_latency_assumed last_trade_price e 57,421 812 65ms 349ms 4.6s 26.0s 0 transport_latency_assumed last_trade_price f 55,185 506 66ms 347ms 6.9s 29.9s 0 transport_latency_assumed last_trade_price g 54,332 109 107ms 946ms 19.7s 37.3s 0 transport_latency_assumed last_trade_price h 57,846 12,588 26ms 104ms 585ms 53.3s 0 transport_latency_assumed market_resolved c 1,076 1,031 7ms 4.9min 8.3min 10.3min 0 transport_latency_assumed market_resolved e 854 8 50ms 171ms 612ms 1.2s 0 transport_latency_assumed market_resolved f 834 23 49ms 190ms 4.1min 4.1min 0 transport_latency_assumed market_resolved g 811 3 86ms 384ms 3.6min 4.5min 0 transport_latency_assumed market_resolved h 854 122 19ms 62ms 303ms 3.6s 0 transport_latency_assumed new_market c 3,323 2,126 96ms 4.3min 5.4min 8.0min 0 transport_latency_assumed new_market e 2,580 480 226ms 16.9s 1.2min 1.9min 0 transport_latency_assumed new_market f 2,579 564 255ms 32.5s 2.7min 3.5min 0 transport_latency_assumed new_market g 2,561 352 375ms 23.0s 3.8min 3.9min 0 transport_latency_assumed new_market h 2,580 903 156ms 18.8s 1.2min 1.7min 0 transport_latency_assumed price_change c 89,595,866 84,705,403 6ms 17ms 191ms 7.5s 0 transport_latency_assumed price_change e 106,486,156 1,388,627 47ms 95ms 774ms 26.1s 0 transport_latency_assumed price_change f 102,322,656 806,347 49ms 92ms 743ms 29.9s 0 transport_latency_assumed price_change g 102,183,254 72,424 85ms 221ms 2.5s 40.2s 0 transport_latency_assumed price_change h 106,597,958 19,714,011 18ms 43ms 457ms 55.4s 0 transport_latency_assumed tick_size_change c 4,892 4,528 6ms 17ms 286ms 529ms 0 transport_latency_assumed tick_size_change e 5,504 60 46ms 86ms 339ms 729ms 0 transport_latency_assumed tick_size_change f 5,284 36 48ms 89ms 367ms 641ms 0 transport_latency_assumed tick_size_change g 5,320 not meas. 84ms 237ms 753ms 2.2s 0 transport_latency_assumed tick_size_change h 5,504 880 18ms 35ms 413ms 5.3s 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-14/19/2026-09-14T19.parquet sha256sum 2026-09-14T19.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.