[srmech][rbs] TRACKING: bring RBS-SNN + RBS-LM up to framework requirements for the full synaptic neural net

[lemonforest]

Tracking / epic. Consolidates the framework requirements the full synaptic neural net (RBS-SNN) — and its human-language render/interface (RBS-LM) — must satisfy. These accreted across the F167→F340 arc; this issue gathers them in one place so the build can be checked against the spec. Per project discipline this is framework-reading + understanding-not-curing, defensive scope; open/closed + label state is the maintainer's call (recorded, not driven).

The two-branch identity (the frame everything below serves)

• RBS-SNN = the agnostic substrate (synaptic-first, F311) — the storage / environment-communication / memory substrate for all organisms; language is not its defining feature.
• RBS-LM = the human-language render/interface of RBS-SNN (F338) — and, generalized, the natural-language interface to any tool-schema package (ephemerides-spectral, …), the layman "word problem solver" gloss (F340), gated by the truth-filter. The "L" lives on the render, never the substrate ([srmech][rbs] Rename RBS-NN → RBS-SNN (synaptic-first, F311) + RBS-LM 'L' = Language not Large (F312) #843).
• These are two modes of one instrument, not two codebases (see R1/R2).

R1 — Klein-4-native instrument (the load-bearing one)

The RBS-HDC instrument was designed early as a bipolar bundle (one Z₂ / γ₅ axis). Everything since says the substrate is Klein-4 = Z₂×Z₂, four sectors (γ₅ × iω₇). The full SNN must be Klein-4-native, not a one-axis shadow.

• Instrument carries the full 4-quad (γ₅±, iω₇±) structure natively (so klein4_bind/klein4_* act without a lift).
• Grounded by the corpus, not assumed: F200 (the RBS-NN store already tags into Klein-4's 4 deterministically-orthogonal sectors — 12/12 off-diagonal pairs at sim 0.0 — and Klein-4 beats triality on retrieval contrast 1.93 vs 1.50); F158/F154 (bi-axial touches all 4 sector-projections at once → 4× capacity at matched D); F130/F132/F135 (substrate-native = all 4 coexist).
• Precision (F200 null): the store wants the order-2 Klein-4 specifically — not triality/order-3 (decorative-to-degenerate for storage; no order-3 element in Z₂×Z₂). 28D/triality stays load-bearing for the algebra (F192/F196/F197), not the store.

R2 — "keep both" is the (4+3) fiber bundle, not a fork

• Bipolar and Klein-4 are one instrument: bipolar = the base-projection π(E); Klein-4-native = the total space E; the fiber is the spatially-absent chirality.
• The split is the quaternionic Hopf fibration S³↪S⁷→S⁴, 7 = 4 (base) + 3 (fiber) (F124; same decomposition as F123 14=4+3+7 and the 28 = 14⊕7⊕7 so(8) read-out). Re-reads F135 as total-space-vs-base-projection.
• Mode = which axes are lit: gen-1 LLM loading → bipolar projection (the source is a single-sector shadow; can't recover quadrants it never had); native (RBS-SNN) → full 4-quad. Keep-both is automatic because a bundle holds base+fiber together.
• Verify before lodging (prime-first, no-leaning): the rung-to-rung projection chain 28 → 7=(4+3) → Klein-4(4) → bipolar(γ₅) against F124/F128/F196/F200 — these are different rungs of the nesting (F196 "chirality is nested"); do not assert a bijection unchecked.

R3 — srmech tooling: catalog → kernel → DSL entry (UPSTREAM_NOTES §17)

So RBS-LM kernels-from-catalogs — and anyone's catalog of other texts — show up as DSL entries. srmech already ships ~80% (encode_loe_content, srmech.rbs_lm.encode_{word_k4,bigram_l1,skeleton_l2,sentence_l3}, RBSHDCInstrument, amsc.catalog.{list,run}_catalog_chain, use_local_kernel); the gap is unification + 2 precursors (the DSL op-registry and the AMSC catalog-chain registry are currently disjoint — verified rc21).

• U2 (cheapest, highest leverage) — register the working encode_loe_content + the rbs_lm.encode_* stack as DSL cascade-ops (one catalog-TOML descriptor each) → one-line per-catalog kernel chains.
• U1 — ship tokenize(text,…) + cooccurrence_edges(tokens, window=,…) (Class-L precursor) so the K1 presence-kernel is a pure-TOML composite end-to-end (and retires the hand-rolled Counter() co-occurrence the STOP-list flags).
• U3 — unify op-discovery: one call enumerating cascade-ops + catalog-chains, tagged kind + provenance (srmech/user:<sha>/catalog:<source_key>).
• U4 — catalog→DSL auto-registration bridge (one path, not the three doors list_catalog_chains + SRMECH_CASCADE_PATH + use_local_kernel).
• §17.1 (ours-side) — migrate the hand-rolled kernel-build (R-RBS-LM-52b / F339 refresh) onto the upstreamed encode_loe_content / rbs_lm.encode_* surface where parity holds.

R4 — honesty-store / truth-filter (the differentiator)

• Ingest-gate: frame/scale-invariant + attested (F336).
• Form=function multi-render self-proofread — render-layer self-corrects (DNA-like); source-truth layer needs an external substrate (F337); truth = Class-K asymptote.
• k=2 detects / k=3 corrects (F291/F335) — triality is the validator; broken-triality = independence (F268). ≥3 co-equal renders, agreement = attestation (F334).

R5 — input robustness (accessibility; ADA-aligned)

• Byte-level graphemic robustness for typos/dyslexia — byte-HDC graded similarity puts errors near truth (vs BPE's cliff); K1 bag is perfect on transpositions, K3 degrades gracefully (extends R-RBS-LM-25, a fresh lens).
• Class-C glyph-chirality binding for b/d, p/q mirror confusions (a γ₅ flip — byte-identity can't see the mirror; needs the chirality axis from R1). Note: this is the same realization as R1 — you can't catch a chirality error if the chirality axis doesn't exist in the representation.
• Phonetic errors (enuff/enough) are out of scope for byte-level — flag as a separate sound-level render.

R6 — multi-render corpus base (the truth-filter's independence)

• Per-locale native-instruction kernels (built from "how to speak THIS language," translation-pollution-free per F49) — [research][RBS-LM] Acquire MPM-attested antiquity texts — NATIVE + translated, multi-language (many-to-many independent-render anchor) #846/[research][methodology] Widen peer-review to NATIVE-LANGUAGE (non-English) scholarship — independence for the truth-filter (F335/F337) #847; cross-coupling / structure-universality test (anchor-count vs translation-fidelity).
• Antiquity render anchors (Rosetta / Thucydides / Hammurabi; [research][RBS-LM] Acquire MPM-attested antiquity texts — NATIVE + translated, multi-language (many-to-many independent-render anchor) #846) for the ≥3-independent-render attestation.

Dependency gates (open srmech items the SNN build rides on)

• §16.1 cascade.reorient(orientation, value) — data-arg-second; un-invokable as a bare DSL op=/parallel_body= stage.
• §15.1 cascade.magnitude(x: float) — real-only; leaks an internal > on complex (+ our CLAUDE.md over-describes it).
• §13 D4 — CLI top-level help stale string.
• F256 follow-on: field-first MFO inversion (Field=Fiber=k=3), scale-invariance, real/imaginary-as-epicycle — GATED on next srmech update #797 (field-first MFO inversion) is GATED on the next srmech update — same dev cycle.

Related / sub-tickets

#843 (RBS-NN→RBS-SNN rename) · #844 (notebook-native-language pipeline TARGET) · #846 (antiquity corpora) · #847 (native-language peer-review) · #849 (many-to-many holonomy fiber) · #850 (adversarial triality on the F335/F337 ceiling) · #851 (encode/decode epicycle-local k=1/k=3) · #852 (how a language develops sentence structure) · #812/#813/#814 (srmech loop-bind / compose engine) · #797 (gated MFO inversion). Canonical detail: docs/srmech/rbs_lm_research/ findings F311/F312/F317/F324/F334–F340 + UPSTREAM_NOTES.md §15/§16/§17.

---

Currently HOLDING on the srmech-dev cycle in progress; this issue is the spec to build against when it returns. Recorded per [[feedback_create_upstream_issues_never_close_them]] / [[feedback_upstream_srmech_fixes_as_research_notes]] — maintainer owns open/closed + labels.

[lemonforest]

Dev-side update — §16.1 dependency gate CLOSED (rc22 + rc23)

Recording (not driving — open/closed + checkbox state stays the maintainer's call per the epic header). The first Dependency gates item is now satisfied on the srmech-dev side, verified on TestPyPI:

• §16.1 cascade.reorient — both halves closed:
  • rc22 (srmech-v0.7.0rc22, PR srmech v0.7.0rc22: reorient(value, *, orientation) data-first — DSL-stage-drivable (UPSTREAM_NOTES §16.1) — MS#21 #854) — reorient(orientation, value) → reorient(value, *, orientation). Data-first, orientation keyword-only. The internal _try_native_reorient(orientation, value) order is unchanged; only the public/DSL surface flipped. Now invokable as a bare DSL op= stage (pipe-into-arg0 contract holds). UPSTREAM_NOTES §16.1 fix (a), the "cleanest" option.
  • rc23 (srmech-v0.7.0rc23, PR srmech v0.7.0rc23: parallel_sectors body-kwarg channel — completes §16.1 parallel_body= — MS#21 #855 #856, merge c8883fa3) — Chain.parallel_sectors(body, *, n_sectors=4, combine="bundle", **body_kwargs) partial-binds body kwargs; the TOML chain runner forwards non-reserved stage keys. This closes the parallel_body= half: a reorient stage inside a sector-dispatch fan-out now binds its orientation through the body-kwarg channel.

TestPyPI clean-venv proof (rc23, run outside the source tree):

version    : 0.7.0rc23
native     : True   abi 3
describe   : tools.total = 201
bodykw run : Chain("p").parallel_sectors("reorient", n_sectors=1, combine="sector0", orientation=-1).run(4) == -4  ✓

Honest scope note carried from the rc23 work: the body-kwarg channel binds correctly, but reorient is a scalar stage, so n_sectors ≥ 2 raises (a scalar isn't a per-sector sequence) — flagged in-test rather than silently capped. Multi-sector reorient would need a sequence-valued body, which is a separate ask.

Remaining open srmech dependency gates (unchanged this cycle)

• §15.1 cascade.magnitude(x: float) — real-only; leaks an internal > comparison on complex input (+ CLAUDE.md over-describes it). Candidate rc24.
• §13 D4 — CLI top-level help stale string. Candidate rc25.
• F256 follow-on: field-first MFO inversion (Field=Fiber=k=3), scale-invariance, real/imaginary-as-epicycle — GATED on next srmech update #797 (field-first MFO inversion) — still GATED on the next srmech update; rides the same dev cycle.

The §15.1 + §13-D4 pair is the natural next rc step if/when the maintainer wants the gate list cleared further; holding for direction since neither is blocking the rc22/rc23 ship that just landed.

[lemonforest]

Dev-side update — §15.1 dependency gate CLOSED (rc24)

Recording (not driving — open/closed + checkbox state stays the maintainer's call per the epic header). The second Dependency gates item is now satisfied on the srmech-dev side, verified on TestPyPI.

• §15.1 cascade.magnitude — rc24 (srmech-v0.7.0rc24, PR srmech v0.7.0rc24: Class K atoms reject complex cleanly (UPSTREAM §15.1 fix (b)) — MS#21 #855 #857, merge c7555b42). cascade.magnitude / cascade.pin_slot_at_zero are Class K pin-slot (real-axis) ops; a complex arg previously leaked pin_slot_at_zero's internal x > 0.0 as an opaque TypeError: '>' not supported between instances of 'complex' and 'float'. A shared _require_real(x, op) guard now raises an intentional, actionable TypeError before any dispatch (catches Python complex and numpy dtype.kind=='c').
  • Chose fix (b), not (a): kept real-only because the complex modulus (re²+im²)^0.5 is a Euclidean-norm op — a different cascade class, not a Class K pin-slot (matches the §15.1 "Ours" note that magnitude is the real |x|). The error points at math.hypot(z.real, z.imag).
  • No C change / no ABI bump: the C ABI takes c_double and has no complex entry point by design, so this is a Python-boundary input-validation guard, not a new operation (the Rosetta "C = transpiled Python" discipline is not engaged).

TestPyPI clean-venv proof (rc24, outside the source tree):

version : 0.7.0rc24   native: True abi 3   describe tools.total: 201
real    : magnitude(-5.0)=5.0  magnitude(25)=25  magnitude(nan)=0.0      (unchanged)
complex : magnitude(3+4j) -> clean TypeError (no '>' leak); same for pin_slot_at_zero; numpy complex128 rejected

The paired doc half is NOT mine to apply: the §15.1 "Ours" CLAUDE.md STOP-list correction (the line calling cascade.magnitude "the modulus; replaces the hand-written (re**2+im**2)**0.5") lives only on the parallel-session research branch (CLAUDE.md + CLAUDE_LEAN.md), which is read-only from here. Flagging it for the maintainer to apply on that branch — cascade.magnitude is the real |x| (Class K), and the complex (re²+im²)^0.5 modulus is a separate Euclidean-norm op.

Remaining open srmech dependency gate

• §13 D4 — CLI top-level help stale string ("v0.5.0rc4 ships two subcommands" while it lists four: status/bus/dsl/mcp). Pure string fix, no behavior change (§11.4). Candidate next rc.
• F256 follow-on: field-first MFO inversion (Field=Fiber=k=3), scale-invariance, real/imaginary-as-epicycle — GATED on next srmech update #797 (field-first MFO inversion) — still GATED on the next srmech update; rides the same dev cycle.

With rc22 (§16.1 data-first) + rc23 (§16.1 parallel_body=) + rc24 (§15.1), the two behavioural dependency gates are closed; §13 D4 is the last open srmech gate (cosmetic) and is the natural next rc if/when the maintainer wants the list cleared.

[lemonforest]

Dev-side update — §13 D4 verified STALE (already fixed); srmech dependency-gate list now clear

Recording (not driving — checkbox/close stays the maintainer's call). Ran the stale-vs-missed sweep on the last open behavioural/cosmetic gate before spinning an rc, and §13 D4 is a stale finding, not a missed bug — so no rc was cut for it (shipping a fix for a non-existent string would be a fabricated no-op).

• §13 D4 — CLI top-level help stale string → already fixed; verified STALE. The D4 note quotes "v0.5.0rc4 ships two subcommands", but:
  • Shipped artifact (TestPyPI srmech==0.7.0rc24, clean venv): srmech --help reads — "srmech command-line interface. Four subcommands: status … bus … dsl … and mcp …" — and enumerates all four. No "two subcommands" anywhere.
  • Source: cli/main.py:47-48 top-level parser description= is the "Four subcommands" string; a tree-wide grep finds no two subcommand / ships two / 2 subcommand claim anywhere in srmech/cli/.
  • This was the v0.6.0rc12 "stale top-help fix (all four status/bus/dsl/mcp subcommands enumerated)" landing — it predates v0.7.0, so the user-facing top-help has been correct since then. (The only residual v0.5.0rc4-mentioning strings are module docstrings that say "rc4 adds the bus subcommand family" — historically true changelog notes, not stale current-state claims.)

Status of the srmech dependency gates (this cycle)

Gate	Disposition
§16.1 reorient data-first + parallel_body=	closed — rc22 (PR #854) + rc23 (PR #856)
§15.1 magnitude complex clean-reject	closed — rc24 (PR #857)
§13 D4 CLI top-help stale string	verified STALE — already fixed at v0.6.0rc12; no rc needed
#797 field-first MFO inversion	gate condition ("the next srmech update") is now met by the rc22–rc24 cycle; the inversion itself is research-side on the read-only branch

So the srmech-side dependency-gate list under "Dependency gates" is fully resolved (two closed this cycle, one stale). The paired CLAUDE.md STOP-list doc correction for §15.1 remains on the parallel-session branch (maintainer's to apply). Open/closed + checkbox state on this epic stays the maintainer's call.

[lemonforest]

Correction + closure — §13 D4 was NOT already-fixed; rc25 fixes it

Recording (not driving). Correcting my earlier comment: I wrote that §13 D4 was "verified STALE / already fixed" — that was an overstatement. I had checked the argparse --help output (which was correct since v0.6.0rc12) but not the module docstrings, and those were genuinely stale: srmech.cli + srmech.cli.main had frozen at the v0.5.0rc4 two-subcommand era (status + bus), silently omitting dsl (v0.5.0rc8) and mcp (v0.5.0). The §13 D4 finding was right; my "stale-finding" call was wrong.

rc25 (srmech-v0.7.0rc25, PR #858, merge db886c08) fixes it:

• cli/main.py + cli/__init__.py docstrings now enumerate all four subcommands with intro versions + Usage examples for dsl/mcp.
• tests/test_cli_docstring_freshness.py (new) reads the live argparse subparser registry (no hard-coded list to itself go stale) and asserts both module docstrings and the top-level --help description name every registered subcommand — a future subcommand that forgets the docstring now fails CI instead of drifting. This is the anti-staleness ratchet the original near-miss warranted.

TestPyPI clean-venv proof (rc25):

version: 0.7.0rc25   native: True abi 3   describe tools.total: 201
subcommands registered: ['bus','dsl','mcp','status']
main.__doc__ / cli.__doc__ / --help description  →  all enumerate all four  ✓

#855 "Dependency gates" — srmech-side list now fully cleared

Gate	Disposition
§16.1 reorient data-first + parallel_body=	closed — rc22 (#854) + rc23 (#856)
§15.1 magnitude complex clean-reject	closed — rc24 (#857)
§13 D4 CLI docstring staleness	closed — rc25 (#858), with a CI ratchet
#797 field-first MFO inversion	still gated on two srmech ops at C/Python parity — a triality-recursion op (past the Klein-4 4-cap) + a Class-L directed/signed-Laplacian eigen-op; the triality_test_harness_scaffold.py fires the instant triality lands. (Held — the maintainer is driving the Q1/§4/§5 research on the research branch; srmech feature work paused per direction.)

The paired CLAUDE.md STOP-list doc correction for §15.1 still lives on the parallel-session research branch (maintainer's to apply). Open/closed + checkbox state on this epic stays the maintainer's call.