# 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. ## 3. Information state over information moment (2026-10-16) Raised in conversation with Captain Bob during MESH step 7 (`docs/v4.0.0/MESH.md` §9a) -- theory stage, no code, no scope, deliberately not punch-listed yet. **The idea, in his words:** "I actually have a theory about what information actually is; the temporal existence and not a moment." And: "What we have is a 'information state' over information moment. The question I will answer is that is there any advantage to this over a conventional OS." Said after "simple is the object." **Where it came from.** Step 7 first handed a believed GONE on from inside the node that believed it, at that instant, on the stacks of whatever text it was in -- information as a moment. The final review found it could be lost at depth, and a node between texts could lose its values to a fault. The fix that was ruled (2026-10-16) makes the GONE a state: the kernel puts it on each node's wire, where it waits until the node takes it. The moment version needed depth sweeps and stack constants; the state version needs neither. The same shape runs through the design already: messages that wait on wires, not in nodes (7d); patrons that arrive and depart over time (the Stadium, `FABRIC-0.md`); K conserved, not sampled. **The question he will answer:** is there any advantage to this over a conventional OS? **Contrasts noted in the conversation, as starting points, not conclusions:** - A conventional OS delivers much information as moments: Unix signals run a handler at whatever instant they land, on the interrupted code's stack, may call only async-signal-safe functions, and plain signals arriving together coalesce -- the failure step 7's hand-on had. Interrupts, preemption points and callbacks share the shape. - What state may buy: no reentrancy class of bug (nothing runs on borrowed stack); nothing silently lost to timing (a fact persists until taken, or is refused at once and its sender told, 7d.1); reproducibility (state can be hashed and compared across machines, as `dict_hash` and K are); verifiability (state is what Isabelle reasons about; interleavings of moments are what make conventional kernels hard to prove). - What it costs: latency (a fact waits until it is taken), memory for the queues, and a policy for a full wire (today: refusal, or for the kernel's GONE, not told). - How it could be answered with evidence: the DoE apparatus -- the same workload with facts delivered as state and as interrupt-style moments, measuring lost events, variance (CV), and behaviour under pressure. **Explicitly not decided:** what "information" means formally in this theory; whether it bears on the patent work; any experiment design. Captain Bob's question to answer, not yet scoped.