How the Terminal suite measures

Methodology, versioned

version v1.0last changed 2026-08-014 metrics · 1 instruments

The Terminal suite is the display layer under the same discipline as everything beneath it: a working quant cockpit of roughly ninety panels in which every displayed number carries its provenance — the git SHA and the sha256 of the source artifact it was computed from — or the panel enters an explicit LOCKED state and refuses to render. It does not measure a new quantity; it enforces that no quantity reaches a screen without proof of where it came from.

The July 2026 incident on my core engine included fake telemetry painted into a live cockpit — random numbers presented as a working system. The terminal is the structural answer, built as the anti-cockpit: it cannot display a number it cannot prove. A LOCKED panel is the design succeeding, not failing — an honest refusal where a dishonest system would have painted something plausible.

Every metric below carries five fields, because four of them are the fields a methodology usually leaves out. Definition states what the quantity is, closely enough that a stranger could implement it. Estimator states how it is computed and which parameters must be fixed before the data is read. Known failure modes states where the estimator breaks — written now, while nothing depends on it, rather than conceded later under questioning.Does not establish states the claim the metric will not support, however natural the reading. The last field is the one that costs something to publish, which is why it is published.

Versioning rule: this page is v1.0. A change to any definition, estimator, failure mode or limit above increments the version and appends an entry to the changelog in §04 naming what changed. Definitions are never edited silently, because a definition that can move after a result is published is not a definition — it is a degree of freedom.

Pre-registrations

A pre-registration is a declaration made and dated before the measurement runs: the thresholds that will decide, the rules that will exclude, and the sample bar below which the honest null publishes instead of a number. Its entire value comes from its ordering. Posted before the answer is known it is a constraint; posted afterwards it is a description of a result, which is a different and much cheaper object wearing the same clothes.

Amendment rule, stated in advance: a posted registration is never edited. An amendment is appended beneath the original carrying its own date and its reason, and the original text stays above it, readable. This page will show both.

Proof corpus

The corpus is the set of artifacts a published measurement ships with — not a description of them, the artifacts themselves, downloadable, each with the digest that proves you received the bytes I measured and the code tag that produced them. A result whose inputs cannot be downloaded is not a receipt; it is an assertion with better typography.

The corpus for this suite is empty. Every row below is a slot, and every slot is NOT YET PUBLISHED. The table is printed anyway, because a reader should be able to see the exact shape of what will arrive — and because a page that described a corpus without showing how empty it currently is would be making the claim it exists to refuse.

Five columns: artifact, contents, content hash, code tag, download. Scroll sideways if they do not all fit.

Corpus state, per instrument

Per instrument, so that the emptiness cannot hide behind a suite-level summary.

• HADES Terminal4 metrics definedNOT YET PUBLISHED

Changelog

Append-only, dated, written by a person. It records changes to this page — it is not a measurement log, and it will not become one. A correction is a new entry that names the entry it corrects; nothing here is ever edited away, because a changelog you can rewrite is a marketing surface with a monospace font.

1. 2026-08-01 · v1.0

   Receipt page established for the The Terminal suite, carrying all five parts of the §8.2 anatomy: the versioned methodology with a formal definition, estimator, failure modes and non-claim for each of the 4 metrics its 1 instruments measure; the pre-registration structure with no registration in it; the proof-corpus table with no artifact in it; this changelog; and the independent-recomputation procedure. Supersedes the earlier per-suite methodology summary at this URL, which carried the battery outline without the receipt anatomy. No measurement, pre-registration, artifact or hash accompanies this version — every receipt slot below is empty as a matter of fact, not of omission.

Independent recomputation

Independent recomputation is what makes the rest of the page checkable rather than merely well-written. It is the exact sequence a stranger follows to re-derive a published number from this suite using only artifacts I published — no account, no request, no conversation with me at any point.

Today the procedure terminates at step 1, because no measurement from the Terminal suite has been published and there is no receipt to open. The steps are written now, in the specific form they will take for this suite, precisely so that they exist before the first result does and cannot afterwards be shaped to fit one.

1. Open the receipt and take its four identifiers.

   Every published measurement links a receipt carrying four: the registration reference, the methodology-document digest, the input-manifest digest, and the generation-code tag. If any one is missing, stop — the result is not recomputable and should not be treated as though it were, including by me.

2. Verify the methodology document against its digest.

   Download it, hash it, compare. A mismatch means the method you are about to apply is not the method that was registered, and everything after this step would be measuring a different thing.

3. Check the ordering before you check anything else.

   The registration timestamp must precede the first-data timestamp on the manifest. If it does not, the registration is a description of a result rather than a constraint on one, and no statistic downstream can repair that.

4. Take any published figure and read its stamp.

   The git SHA of the producing code and the SHA-256 of the source artifact. Fetch the artifact by digest and confirm its bytes hash to the value that was on the glass.

5. Apply the registered rules yourself.

   Which artifact the panel is entitled to read, the freshness bar beyond which it must lock, and what counts as a verification failure. A panel that renders outside those rules is a defect regardless of whether its number happens to be right.

6. Check out the producing code at the stamped SHA and run it against the verified artifact.

   The stamp exists so this step needs nothing from me: the SHA and the digest are the whole of the instruction.

7. Recompute the figure and compare it against what the panel displayed.

   They must agree exactly. The terminal renders computed values, not rounded summaries of them, so there is no tolerance to argue about.

8. Run the can-fail proof.

   Corrupt one byte of a copy of the artifact and confirm the panel enters LOCKED rather than rendering. A panel that renders against a mismatched artifact has failed in the exact way this instrument exists to prevent.

9. If your number differs, the difference is the finding.

   Send it with your inputs and the version you ran. A confirmed discrepancy publishes as a correction appended beside the original — and the original stays exactly where it is, unedited, because the error is the part of the record that proves the discipline is real.

The point of publishing this before there is anything to check: a recomputation procedure written after a result is a procedure written by someone who already knows which steps would be inconvenient.