Hour audit: 2026-09-13T20
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-13T20 · corpus v3 · verdict AUDIT PASS
COVERAGE minutes present 60/60 · first event 2026-09-13T20:00:00.000204633+00:00 · last event 2026-09-13T20:59:59.999949192+00:00
VOLUME 133,896,782 rows · 1,484,265,650 bytes (1.38 GiB) · 7 products, all holding rows
WITNESSES cefgh — 5 machines contributed rows
captured h: 131,043,131 · e: 131,037,055 · f: 118,425,169 · g: 106,972,733 · c: 100,799,683 (each machine's own feed; these overlap and do not sum to the file)
supplied h: 31,931,413 (23.85%) · e: 3,373,617 (2.52%) · f: 1,740,187 (1.30%) · g: 663,178 (0.50%) · c: 96,188,387 (71.84%) (rows of the merged file that came from it; these partition it)
5 expected, all 5 contributed
INTEGRITY sha256 3f55f6328fda3ff58e81b2601ddd4b3d65d9c6fc4c3f8e2750eb3625bcfa5657
the corpus checksum ledger names this file with the same digest
joined 133,943,412 to merged 133,896,782, minus 46,630 (minus 0.0348%)
boundary drops 46,630 · 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-13T22:39:09Z 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 13,855,775 155,297,572 0-52 8df9e5a17e87aa6d15bc50944322bb751a747ba17aacc7fa7fd3f8bea57f9f25 book 2,953,414 114,444,972 53-64 2a401136eaaa5057e8a9d0fdc45975e6b6d6e10d664c9e6c7df8ac819c2161c2 last_trade_price 59,698 3,480,682 65-65 d017d9c09d44640fbbc5cfaea78fca37979842f7b0ca724a73b8956adc3c173e market_resolved 7,470 717,214 66-66 e9e999e8fa5c67be722a28f52647b30a83c367273c9fabb52fa74e4779c47762 new_market 9,927 773,674 67-67 f2b816bf62a40cae4d1ed69468f734184f9ef2846e2faa8f042f85bcea010b8a price_change 117,001,970 1,207,714,815 68-514 23e1788f153c264233ba169cb2d07369ed5577e7f42e7c25923449b76d7cd3a8 tick_size_change 8,528 314,783 515-515 988f253d3e14ff168aff37a424f45eaece2b0e733fa729cdad842b2e9879ab97 EVENT MIX count share price_change 117,001,970 87.38% best_bid_ask 13,855,775 10.35% book 2,953,414 2.21% last_trade_price 59,698 0.04% new_market 9,927 <0.01% tick_size_change 8,528 <0.01% market_resolved 7,470 <0.01% PER PRODUCT joined merged boundary exception mkts class best_bid_ask 13,858,718 13,855,775 2,943 7,420 FULL book 2,980,607 2,953,414 27,193 172,979 FULL last_trade_price 59,702 59,698 4 831 FULL market_resolved 7,471 7,470 1 803 FULL new_market 10,156 9,927 229 1,007 FULL price_change 117,018,230 117,001,970 16,260 6,377 FULL tick_size_change 8,528 8,528 0 689 FULL ARRIVAL SKEW m rows won p50 p90 p99 max unmeasurable interpretation best_bid_ask c 10,492,968 10,072,867 5ms 11ms 184ms 6.6s 0 transport_latency_assumed best_bid_ask e 13,853,521 347,490 40ms 66ms 430ms 16.9s 0 transport_latency_assumed best_bid_ask f 12,508,588 115,175 46ms 74ms 440ms 16.9s 0 transport_latency_assumed best_bid_ask g 11,147,720 7,594 84ms 153ms 1.2s 1.6min 0 transport_latency_assumed best_bid_ask h 13,855,290 3,312,649 18ms 40ms 717ms 1.9min 0 transport_latency_assumed book c 2,266,043 1,721,461 24.5min 2.1d 36.3d 106.9d 0 book_staleness book e 131,222 5,963 44ms 716ms 14.6s 88.4d 0 book_staleness book f 1,168,720 612,797 17.0min 2.1d 35.9d 106.9d 0 book_staleness book g 1,998,500 579,560 23.7min 2.1d 36.3d 106.9d 0 book_staleness book h 131,516 33,633 23ms 248ms 7.2s 88.4d 0 book_staleness last_trade_price c 44,058 42,022 11ms 49ms 276ms 4.9s 0 transport_latency_assumed last_trade_price e 59,595 1,352 52ms 282ms 10.9s 16.9s 0 transport_latency_assumed last_trade_price f 52,965 594 59ms 289ms 3.2s 14.1s 0 transport_latency_assumed last_trade_price g 47,079 98 97ms 401ms 15.4s 1.5min 0 transport_latency_assumed last_trade_price h 59,596 15,632 25ms 109ms 1.6s 55.2s 0 transport_latency_assumed market_resolved c 4,877 4,483 7ms 9.4min 13.4min 14.2min 0 transport_latency_assumed market_resolved e 4,019 81 109ms 207ms 591ms 2.3s 0 transport_latency_assumed market_resolved f 3,874 327 115ms 383ms 4.6min 4.8min 0 transport_latency_assumed market_resolved g 5,652 1,693 357ms 11.8min 20.3min 22.9min 0 transport_latency_assumed market_resolved h 4,020 886 38ms 96ms 1.0s 1.3min 0 transport_latency_assumed new_market c 5,563 3,969 288ms 6.7min 8.7min 1.5h 0 transport_latency_assumed new_market e 3,704 889 250ms 45.3s 3.6min 19.2min 0 transport_latency_assumed new_market f 3,991 1,002 311ms 3.6min 4.1min 34.2min 0 transport_latency_assumed new_market g 8,048 2,655 4.8min 14.2min 19.9min 1.6h 0 transport_latency_assumed new_market h 3,713 1,412 195ms 41.4s 3.7min 1.2h 0 transport_latency_assumed price_change c 87,979,274 84,336,882 5ms 12ms 193ms 6.8s 0 transport_latency_assumed price_change e 116,976,466 3,017,696 40ms 80ms 555ms 16.9s 0 transport_latency_assumed price_change f 104,679,587 1,010,218 47ms 85ms 541ms 20.8s 0 transport_latency_assumed price_change g 93,758,562 71,574 85ms 178ms 2.0s 1.6min 0 transport_latency_assumed price_change h 116,980,468 28,565,600 18ms 44ms 728ms 2.0min 0 transport_latency_assumed tick_size_change c 6,900 6,703 5ms 10ms 81ms 416ms 0 transport_latency_assumed tick_size_change e 8,528 146 40ms 53ms 373ms 581ms 0 transport_latency_assumed tick_size_change f 7,444 74 46ms 60ms 383ms 818ms 0 transport_latency_assumed tick_size_change g 7,172 4 84ms 136ms 733ms 3.8s 0 transport_latency_assumed tick_size_change h 8,528 1,601 18ms 38ms 382ms 7.5s 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-13/20/2026-09-13T20.parquet sha256sum 2026-09-13T20.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.