LithosAnanake/FABRIC-4.md

FABRIC-4.md — forward-looking design notes

Status: Not a successor to FABRIC-3.md and not a punch-list document. FABRIC-3.md is the current living document (bare metal boot, opened 2026-09-04, successor to the now-closed FABRIC-2.md) — nothing here supersedes it, and this file doesn't follow the close-and-carry-forward discipline FABRIC-0.md → FABRIC-1.md → FABRIC-2.md → FABRIC-3.md used (that chain triggers on closing a document; FABRIC-3.md isn't closed). This is a separate, lower-discipline scratchpad for design ideas caught early — theory-stage, pre-punch-list, often missing a stated "why" on purpose (captured as raised, not fully justified yet). An idea graduates out of here into FABRIC-3.md (or wherever the living document is by then) once it has a real scope, not before.

---

1. Stadium-level "wheel" — a second clock alongside the heartbeat (2026-09-03)

Raised in conversation with Captain Bob, theory stage — no code, no scope, deliberately not punch-listed yet.

The mechanism. A second clock, independent of but derived from the true heartbeat (HeartbeatState, Loop #7), advanced by a fixed-point (Q48.16, this project's standard) phase accumulator: each master heartbeat tick adds a rate scalar to the wheel's own phase; whenever phase crosses 1.0 the wheel fires (advances its own state) and the crossing remainder carries forward. This is a continuous scalar, not an integer tick-divisor — rate can sit anywhere, including above 1.0. A wheel with rate > 1 fires more than once per master tick (multiple threshold-crossings per tick, remainder still carried); one with rate < 1 accumulates across several master ticks before firing once. Nothing about the mechanism privileges either side of 1.0 — "runs ahead of baseline" and "runs stretched behind baseline" are the same math with a different scalar.

What feeds it. Not a new signal source — this wheel listens to two already-real, already- built mechanisms: rolling_window_of_truth.c (Loop #2's circular-buffer execution history — rolling_window_measure_diversity(), rolling_window_find_hottest_word(), rolling_window_count_transition(), rolling_window_pattern_capture_rate(), rolling_window_is_warm()) and inference_engine.c (Loops #5/#6 — InferenceOutputs: decay-slope, variance-inflection point, fit quality). Both exist today at the per-VM level (each patron/word-owning VM has its own rolling window and runs its own inference pass) — the wheel itself is meant to live at the Stadium level, one layer up. This is a genuinely new axis: nothing today aggregates RWOT/inference-engine output across the whole Stadium floor into one fleet-wide signal. Open, not decided: what the aggregation actually is (sum across patrons? mean? the hottest patron's own values only? something else) — flagged in conversation, not resolved.

What it's for. Not a sieve itself. The wheel is a scheduler/gate: it decides when to slip an appropriate sieve into a stack of sieves that doesn't exist yet (see §2 below) — running its own clock, potentially ahead of the true heartbeat, is what buys it lead time to notice a transition worth reacting to before the baseline heartbeat would get there on its own. It is not itself the thing doing the sieving.

Build sequencing, decided in conversation. rate starts as a fixed build parameter (same shape as ACL-BASE-TTL/Q.SLOT — a plain constant or Kconfig symbol, not adaptive from day one). Reasoning, Captain Bob's own: a fixed rate is the only version that can go through this project's existing DoE apparatus and produce a clean, attributable measurement (rate held constant, everything else varies) — if the rate self-tunes from day one there's no fixed baseline to compare "does the wheel actually help" against. Only after a real, measured baseline exists does rate itself graduate to adaptive/self-tuning — reusing the same inference-engine machinery the wheel already listens to, not new plumbing. This mirrors the L8 Jacquard selector's own real history: hardcoded compudynamics constant first, later replaced by the VM Fleet Attractor's dynamically-inferred rate (docs/working/architecture/VM-FLEET-ATTRACTOR-DESIGN-20260705.md). Same graduation, one level up the stack.

Explicitly not decided yet, per Captain Bob ("we'll talk about why later"):

• The actual purpose — why this wheel, what real problem it solves. Deferred on purpose.
• The sieve stack itself — what a "sieve" is concretely, what gets sieved, how many. A larger, separate vision (128–256 wheels, each fed by an "appropriate" — possibly learned/neural, vocabulary not yet resolved against anything this codebase currently has — source, forming a coincidence-pattern sieve) was raised earlier in the same conversation as a distinct, further-out idea; this single-wheel scheduler is deliberately scoped smaller and doesn't presuppose that larger picture is right.
• Whether "trivial to add a wheel" (an earlier framing) still matters once there's only one — a generic {rate, phase, state} table is a premature abstraction for a single instance; build the one wheel concretely first, generalize only if/when a second one is actually needed (this project's own standing convention — three similar lines beat a premature abstraction).

2. A pinned GPIO VM per real-hardware board (2026-09-04)

Raised in conversation with Captain Bob during FABRIC-3.md §IV/§V's bare-metal-boot planning — theory stage, no code, no scope, deliberately not punch-listed yet.

The idea, as stated: the Raspberry Pi 5 will need a special pinned VM dedicated to GPIO — presumably following the same Tripod precedent Hermes/Artemis already established (a permanently-pinned, born-at-boot VM with a fixed role, per FABRIC-2.md §H.1's "pinned sessions never leave" model). Whether the Milk-V Mars needs the same treatment is explicitly not yet decided — Captain Bob's own framing: "same for Milk-V (? not sure here)." Worth noting the Mars does have its own 40-pin GPIO header (§VI), so the question isn't "does it have GPIO" but whether it needs its own dedicated pinned VM for it the same way the Pi 5 does, or whether GPIO access there fits some other shape.

Why a dedicated VM, not just a C driver, presumably (not yet confirmed as the actual reasoning — inferred from the Tripod precedent, not stated outright): GPIO is shared, stateful hardware that multiple capsules/patrons might want to touch — the same category of problem Hermes (messaging) and Artemis (block storage) already solve by being a dedicated, addressable VM other patrons talk to, rather than a bare C primitive anyone can call directly.

Explicitly not decided yet:

• Whether Milk-V Mars needs the same pinned-VM treatment, or something else.
• What this VM's own vocabulary/interface would look like (a GPIO-READ/GPIO-WRITE-shaped word set? something richer, given the Pi 5's GPIO header also muxes UART/SPI per §IV.1?).
• Whether this is one pinned VM per board doing double duty (GPIO + whatever else that board's bring-up needs) or GPIO specifically warrants its own separate VM distinct from, say, a future UART-handling VM.
• How this interacts with §IV.1's own still-open native-boot-flow work — a GPIO VM needs GPIO register addresses from the DTB the same way the rest of that bring-up does, so this idea isn't independent of that work, just downstream of it.