# sgtoe_kernel_v5.0.9.py — CURRENT-STATUS NOTE (2026-09-05, Rev32.7 basis). Read this before reading the kernel's own printed status block.

The kernel file is IMMUTABLE (sha256 in MANIFEST.sha256). It is a REGRESSION FIXTURE: it recomputes the Rev12 + Session-64 numerics exactly and its expected-output file
is the byte-for-byte record of that run. Its printed "EPISTEMIC STATUS" header was written at Rev32.4 and is now HISTORICAL. Three things it prints are superseded:

1. "3/8 mixing observables Derived-conditional or above" → Rev32.6/32.7: TWO of eight (θ12, δCP). The atmospheric octant and |V_cb| are typed on two axes: the internal
   identity sin²θ_mismatch = 7/16 is theorem-grade; the physical attachment (octant registration; |V_cb| = 1/(9√7)) is Loaded-correspondence (assessment A1566).
2. "|V_us| 0.225268" in the header is a hand-typed digit. The kernel's OWN computed row prints 0.22525606, which is the correct closed-form value
   sin(arctan(√3/φ²))/√6 = 0.225256056 (kernel s1162 in the release bundle; +1.11σ vs PDG 2026 0.22431±0.00085). Trust the computed row, not the header string.
3. "Rev32.4 suite" as the claim surface → the suite of record is Rev32.7 (sealed 2026-09-05, 385 pp). The suite wins wherever a header string and the suite differ.

What this program actually tests (verification coverage): the Rev12/S64 mass-ratio and mixing formula chain with its three dimensionful anchors v_EW, m_τ, Λ_G2 declared
in the file; the |V_us| Route-B row; the m_t = v_EW/√2 row with its +4.9σ pole-mass tension printed as GENUINE. It does NOT test the Rev29 re-tier, the A1566 octant
adjudication, the R2 edge target, or any Rev32.x appendix result — those live in the per-result kernels of the release bundle (s#### files, each with an expected output).

Authority order for any reader, human or AI: current claim registry (Rev32.7 suite, Papers 0–9 + App A–Y; SOURCE_LEDGER_REV32.csv) → versioned release + MANIFEST →
historical fixtures and the March 2026 library archive. The registry governs the DECLARED status of a claim; the proofs, source data and per-claim kernels
determine whether that status is SUPPORTED — where a registry entry and its supporting artifact disagree, the discrepancy is exposed, not settled by whichever label is newer.
A successful rerun of this kernel validates the fixture, not every current claim.