Every time we tested the contract, and every time it broke

One sustained break: 84 consecutive failing runs

From 2026-08-31T19:36:41Z to 2026-09-08T14:23:29Z, runs #270 through #353 all failed. Every run in this span failed. The first and last were read from their job logs and they broke different invariants, so the span is not attributed to a single defect. The 82 runs between them were not individually read. During most of the span the canary was running 5 to 12 times a day rather than the current 48, so the run count understates the duration: it lasted 7 days and 18.8 hours.

First run of the break

#270 (run 33431517783) — coverage: 200 — got 400

Last run of the break

#353 (run 34237946738) — directory: 304 keeps the version header

Every other failure, with the invariant it broke

5 runs outside the break failed. Each is listed with the exact assertion the API did not satisfy, read from that run’s job log.

Two runs are excluded from the denominator

897 runs are listed; 895 are counted. The difference is named here rather than dropped, because a denominator a reader cannot reconstruct is not a published figure.

The record, day by day

Runs per UTC day and how many of them failed. The cadence is not flat: the job ran a few times a day through late August and early September before moving to twice an hour, so a day with five runs is five samples, not a quiet day.

Why there is no availability SLA

An availability commitment needs a request-outcome log. Every request Veridion serves, with its status, its latency and its caller, retained over a window long enough to compute an error budget. The canary samples the API 48 times a day from one region; it is evidence the contract holds, not a measurement of what callers experienced. No availability percentage is published from it and no availability SLA is offered until the log exists.

What is committed instead is this record: the contract is proven against live production rows on a schedule, every run is retained and linkable, and a conformance regression is treated as a release-blocking defect rather than a known issue. When the request-outcome log exists, the figure computed from it will be published here beside this one, and this one will not be quietly replaced.

How this was measured

Every page of the workflow run list was walked and each run's terminal state read. Job logs were read for the first and last run of the sustained break and for all five isolated failures. Interior runs of the break were not individually read. Each run issues ~24 GET requests, two of them deliberately keyless against https://www.veridionmarkets.com. Measured 2026-09-20T06:05:00Z. Each run is retained in Veridion’s CI with the identifier printed beside it above, so a reader under diligence can pull any run named here and recount every figure on this page against it.