RPAS-26 · The desk bound by its own rule

Conformance

freshness — the ledger this dashboard reads

The live ledger audited against the desk's own published standard. Per RPAS 6.04 the desk is bound by its own rule; per 5.03/5.07 gaps are printed, not hidden. The ledger holds more than one forecaster, so accuracy is scored per arm and never pooled — a pooled score belongs to no forecaster. Numbers below compute from ledger.json in your browser at load time — nothing is hand-typed.

The stranger's verdicts — both instruments

Written at build time by the two reference verifiers and published as JSON beside the records they judge; your browser reads the same files a stranger would. Reproduce either verdict with the commands on the verify page against the live URLs.

rpas_verify · ledger.json · entries
knp_verify · kalls_hashlog.json · records
must-failures / should-departures
verdicts written

Raw verdicts: rpas_verdict.json · knp_verdict.json.

The population — every status printed

issued
forecasters
open
hits
misses
void

Issued = open + hits + misses + void. The denominator reconciles on this face by construction; a category the ledger carries is a category this page prints. Counts pool legitimately because they are population, not performance. Scores do not.

Accuracy by arm — segregated, never blended

Each arm is a separate record with a separate information position. RPAS scores a record. The arm label is the per-entry model field carried in the ledger since issuance; this page reads it rather than assuming one forecaster.

ArmIssuedOpenHitMissVoidResolvedBrierNoise floor
Computing from ledger.json…

No arm's score is comparable to another's until both clear the thirty-resolved floor. Below that floor a Brier is printed because the rule is print-and-caveat, not suppress — it is not evidence of skill in either direction.

Against a named baseline

A Brier score alone cannot tell a reader whether a forecaster beat the dumbest available strategy. RPAS's fourth law requires a named baseline, so this page prints one: the climatological forecast, which ignores every question and states the arm's own realized base rate every time. Its Brier is b(1−b). Skill is 1 − (Brier ÷ climatological): above zero beats the baseline, below zero loses to it.

ArmResolvedBrierBase rateClimatologicalSkill
Computing from ledger.json…

The baseline is a lower bound on competence, not a target. It is also self-referential — it is computed from the same resolved set it is compared against — so it flatters no one and is only meaningful once the resolution count is large. At the counts on this page, a skill score of either sign is noise and should be read as one.

The record, explorable — recomputed in your browser

Nothing below is hand-typed. Calibration, trajectory, and the clock all derive from ledger.json at load time, per arm, never pooled. Under thirty resolved, every figure is data, not evidence of skill (KNM 6.05).

Brier trajectory — the score as each resolution landed

Cumulative Brier after every resolution, in resolved-date order. A record compounds on a clock; this is the clock.

Next resolutions — what the record answers for next

idarmdeadlinestatus

Gates and floors

RPAS 5.02 · fifty-entry gaterequires JavaScript
Thirty-resolved noise floor (whole ledger)requires JavaScript
Brier over the pooled populationnot computed — three forecasters, see per-arm table
RPAS 4.02e/4.03 · failure condition presentrecomputes from the ledger with scripts
RPAS 4.02f/1.04 · keyed/keyless determinedrecomputes from the ledger with scripts

Failure-condition and keyed/keyless gaps are per-entry conformance defects, not performance, so they are counted across the whole ledger; the arm each defect sits in is printed for remediation, not for comparison.

The dated findings register

The full finding-by-finding register — severity, RPAS paragraph, per-entry citation — is a dated document regenerated by the desk's conformance pipeline: REPORT_conformance.md. Recomputed daily and committed by an automated identity the desk does not control: citation integrity — do the cited priors support their claims — and identifier groundedness — do the identifiers in machine-drafted prose exist in the record beneath it. The elicitation inputs are committed by digest in the packet register, the external timestamps in the anchor manifest, and the criterion behind every keyed/keyless determination in the determination doctrine. Standard: RPAS-26.

Finding — 2026-07-26T00:00Z · this face

Through this date this page printed one accuracy figure and attributed it to the ledger as a whole: Brier 0.221 over 13 resolved. The ledger carries three forecaster arms. At the moment of correction all thirteen resolved entries belonged to the machine arm and the other two arms had none — so the figure was arithmetically correct and is unchanged. It appears above on the machine's row. Nothing was withdrawn.

The defect was attribution, not arithmetic. The face assigned one arm's record to the whole ledger, and would have become a genuinely pooled score — one belonging to no forecaster, which is not what RPAS grades — the first time a fable or operator entry resolved. It is corrected before that happened rather than after, which is the only reason this finding is small.

No entry required rescoring, resealing, or amendment. The ledger has carried a per-entry model field since issuance, so the data was always segregable; the defect was in the display layer and nowhere else.

Segregation lowers what this page can claim. The machine's thirteen still sit below the thirty-resolved floor, and two of three arms now print a dash where a score would go, because a forecaster with no resolved entries has no record. That is the correct outcome: a figure captioned as the ledger's was a claim the ledger did not support, even while the number itself was right.

A conformance page that flattered the desk would be worthless. The FAIL rows are the point: the standard is real enough to fail its own author, in public, with paragraph numbers.

Standing disclosure · the pre-RPAS ledger copy

The repository carries ledger.json.pre_rpas, a copy of the ledger taken before the RPAS-26 rescoring pass. It is public deliberately. Anyone may diff it against the live ledger.json and see exactly which entries changed when the standard was applied.

It is published because a record that can be rescored and offers no way to inspect the rescoring is asking to be trusted rather than checked, and this desk's whole proposition is the opposite. The before-copy is the evidence; naming it here is what separates a disclosed methodology change from a quiet one.