Correction and calibration
The protocol we apply to our own integrity outputs.
A firm that scores others must be scoreable. This is the protocol under which our own integrity outputs are registered, scored, corrected, and refused — written before the first record, so the rules cannot be tuned to the result.
Pre-registration
Registered before the outcome is known
A record that is not registered before the outcome is known is not scored, and cannot be added afterwards. These four fields are written at registration and never edited.
| Field | Rule |
|---|---|
record_class | One of live, backtest, or shadow. A backtest or shadow record is never promoted to live, and never reported as if it were. |
registered_at | The registration timestamp in UTC, recorded before the outcome exists. A record with a later timestamp than its outcome is void. |
protocol_version | The protocol version in force at registration. A record is always scored under the version it was registered under, never under a later one. |
inputs | The inputs relied on, named and hashed, so the record cannot be re-argued later on a different basis. |
Scoring
Coverage, with n and an interval
Every score is reported as coverage with its n and a Clopper-Pearson interval. A proportion without its denominator is not a score, and a score without an interval is not published.
The denominator never shrinks. A record that was registered and then became inconvenient stays in the denominator; it resolves as a failure or a refusal, and it is never removed.
Publication
Failures at the resolution of successes
- Failures are published at the same resolution, in the same place, and with the same detail as successes.
- Corrections are new records that supersede, never edits to an existing one. The superseded record stays readable.
- Refusals are logged with their reason code, and count in the ledger as their own resolution class.
The ledger
Every registered record, and how it resolved
Live state Veridian integrity ledger · live state
0 registered0 resolved0 refusals
No integrity record has resolved yet.
This is a designed state, not a missing feature. An empty ledger is what an honest ledger looks like before the first record resolves, and we publish it rather than wait for numbers worth showing.
Synthetic fixture · not an engagement
Ledger, sample rows Sample · CI fixture · not live
| Record | Class | Registered at | Protocol | Coverage (n) | Interval (95 %) | Resolution |
|---|---|---|---|---|---|---|
| REC-0001 | live | 21 Jun 2026 06:00 UTC | v4.2 | 1,412 / 1,480 | 94.2 – 96.5 % | Published |
| REC-0002 | shadow | 21 Jun 2026 06:00 UTC | v4.2 | 3,106 / 3,240 | 95.1 – 96.5 % | Published, not reported as live |
| REC-0003 | live | 22 Jun 2026 09:30 UTC | v4.2 | 0 / 118 | coverage below threshold | refusal · coverage_below_threshold |
| REC-0004 | live | 23 Jun 2026 14:05 UTC | v4.2 | 870 / 902 | 94.6 – 97.1 % | Superseded by REC-0007, original readable |
Sample rows from a CI fixture, shown to make the ledger's shape reviewable. They correspond to no contest and no engagement, and they are not a record of resolved work.
Request an engagement
Tell us the contest, the date, and the artifact you need. We reply with scope, refusal conditions, and a price against the published floor.