UNI Universal Natural Intelligence

Wiki · Evidence & Verdicts

RED pre-registration — gaia-golden-pins

Evidence & Verdicts · docs/receipts/red_preregistration_golden_pins.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

How to read this page

Eighty-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.

That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.

A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.

What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.

A Plain and a Clear version of this page have not been written yet. What follows is the document itself.

Precise — the source document

This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.

verdict: PENDING evidence_class: pending

RED pre-registration — gaia-golden-pins

  • Gate name (ledger name): gaia-golden-pins
  • Registry id: golden-pins — viewer/gate_registry.json:30-34
  • Phase: Phase 9, step 1.4 (viewer/gaia/verify_golden_pins.cjs:1)
  • Pre-registered: 2026-08-01
  • Runner: viewer/gaia/verify_golden_pins.cjs
  • CI: ci: true
  • Related: viewer/gaia/gaia_lint.cjs check (e), viewer/gaia/goldens.json

What this document is, and what it is not

This is a transcription, not a judgement. The gate is registered in viewer/gate_registry.json and has no row in evidence/gates.ndjson; the blocker is the empty receipt_path the schema requires (viewer/lab/desk.cjs:317-322, production/schemas/gate_row.schema.json:8).

Both conditions below are quoted verbatim from the runner's own header comment, with path:line locators. Appending the ledger row is S4 — the operator's alone.

Motivation (verbatim from the runner)

viewer/gaia/verify_golden_pins.cjs:3-16

// WHAT THIS PROVES, AND WHY IT IS SHAPED THIS WAY:
//   gaia_lint's check (e) pins the on-disk bytes of Gaia's core sources (gaia.cjs, sig.cjs, gaia_server.cjs)
//   against a committed manifest, viewer/gaia/goldens.json — the byte-identity idiom. Before Phase 9 step 1.4
//   that manifest DID NOT EXIST, so all three read "unpinned" and the check could not fire at all.
//
//   The pre-registered falsifier for 1.4 is: "AN EDIT WITHOUT A RE-PIN PASSES." That has THREE distinct
//   routes, not one, and pinning alone only closes the first:
//     (1) edit a pinned file            -> "mismatch"  -> already a hard violation
//     (2) edit it AND delete goldens.json -> "unpinned" -> PASSED, by default, before this step
//     (3) edit it AND drop just its entry -> "unpinned" -> PASSED, by default, before this step
//   Routes 2 and 3 make the pin self-erasing: the guard could be removed by deleting the guard. The lint's
//   `requireGolden` flag existed for the honest PRE-pin era ("golden not yet established"), but once the
//   manifest is committed, a MISSING pin is not an honest pre-pin state — it is a removed guard, and this
//   gate treats it as such.

PASS condition (verbatim)

viewer/gaia/verify_golden_pins.cjs:22

// PASS — the real tree is fully pinned AND all three evasion routes are refused.

Mechanical form, viewer/gaia/verify_golden_pins.cjs:23:

// Usage: node viewer/gaia/verify_golden_pins.cjs      exit 0 = PASS, 1 = FAIL.

For the ledger row's pass_condition field:

PASS — the real tree is fully pinned AND all three evasion routes are refused.

FALSIFIES condition (verbatim)

viewer/gaia/verify_golden_pins.cjs:8

//   The pre-registered falsifier for 1.4 is: "AN EDIT WITHOUT A RE-PIN PASSES."

For the ledger row's falsifies_condition field:

AN EDIT WITHOUT A RE-PIN PASSES.

evidence/remediation/phase9_plan.json step 1.4 declares the same in lower case: "an edit without a re-pin passes". The runner and the plan agree.

The runner enumerates the three routes the falsifier covers, and the row should not lose them — viewer/gaia/verify_golden_pins.cjs:10-12:

//     (1) edit a pinned file            -> "mismatch"  -> already a hard violation
//     (2) edit it AND delete goldens.json -> "unpinned" -> PASSED, by default, before this step
//     (3) edit it AND drop just its entry -> "unpinned" -> PASSED, by default, before this step

Protocol

  1. Run node viewer/gaia/verify_golden_pins.cjs from the repository root.
  2. Sandbox only — viewer/gaia/verify_golden_pins.cjs:18-19: "gaia_lint.cjs resolves its paths from __dirname, so a copy in a temp dir lints THAT dir — the real viewer/gaia/ is never edited, never re-pinned, never touched."
  3. Record the exit code and the final GOLDEN-PIN GATE: line (viewer/gaia/verify_golden_pins.cjs:161). If any of the three routes fires, the runner prints THE PRE-REGISTERED FALSIFIER FIRED and names which (:116, :130, :147) — quote the line verbatim rather than summarising which route it was.

Ship-gate discipline

  • A red here has two very different meanings: the tree is not pinned, or an evasion route is open. The runner distinguishes them by check name; the receipt must too.
  • Evidence class C on a first local run.

Non-goals

This gate does not verify that the pinned bytes are correct — only that they are pinned, that the pin cannot be erased, and that an edit without a re-pin is refused.

sha256 563d3bc072ef7f70 — of the original file, so what was ingested stays checkable.