Blog
A health snapshot changed its numbers, not its contract
A fresh repository commit updates the CI health snapshot from 156 to 143 failures in a 200-run window and records the denominator and exclusions that give those numbers meaning.
- THE WINDOWA window of two hundred runs.
- THE COUNTFrom 156 failures to 143.
- THE LIMITThe denominator is the claim.
A health snapshot is not the same thing as a repair. It is a record of what a measurement pipeline currently says, with its window and exclusions visible.
The fresh commit 6227bed updates apps/website/src/data/signalHealth.json for gHashTag/trinity’s ci.yml entry. The window remains 200 completed runs. The stored count moves from 156 failures to 143, and the stored red probability moves from 0.78 to 0.715.
What changed in the file
| Field | Before | After |
|---|---|---|
| failures | 156 | 143 |
| pRed | 0.78 | 0.715 |
| bitsPerRed | 0.358 | 0.484 |
| window | 200 | 200 |
The same snapshot raises bitsPerRed from 0.358 to 0.484. The file defines that value as the self-information of the next red, computed as −log2 P(red); it is a description of the stored estimate, not a promise about the next run.
The measurement contract is part of the result
The data file says that the source is a per-workflow list of up to 200 completed runs. Cancelled and skipped runs are dropped rather than counted as passes. That sentence matters: changing the inclusion rule would change the meaning of every number beside it.
A lower count in one snapshot is evidence about that snapshot, not proof that the system became healthier.
What this does not establish
- The commit does not independently re-run or audit the complete run history; it records the refreshed data file.
- The lower failure count is not attributed here to a particular code or workflow change.
- The snapshot does not establish that the CI jobs are correct, only how this health metric currently classifies their recorded outcomes.
- No FPGA, silicon, speed, energy, or downstream-model result is claimed by this post.
The useful change is therefore modest: the dashboard now carries a refreshed, inspectable snapshot and states the denominator and exclusions next to the metric. The receipt is the commit and the file it changed.
What this does not settle
- The commit records a refreshed data file; this post does not independently re-run or audit the complete run history.
- The lower failure count is not attributed here to a particular code or workflow change.
- The snapshot describes the metric's classification of recorded outcomes; it does not establish that the CI jobs themselves are correct.
- No FPGA, silicon, speed, energy, or downstream-model result is claimed by this post.
Receipts
Work with me
Want this kind of check on your own design?
I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.