LithosAnanake/docs/fabric/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.

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?

As a null hypothesis (phrased at his request, 2026-10-16; a starting form, to be sharpened before any experiment):

H0: Delivering information to a computing element as state -- a fact that persists where the element will take it, when it has the means to -- confers no advantage over delivering it as a moment -- an event the element must act on at the instant it arrives, with whatever resources it has then -- as a conventional OS does with signals and interrupts.

H1: Delivery as state gives a measurable advantage on at least one of the measures below, at a cost in the others that does not outweigh it.

Measures that would decide it, each the same for both forms on the same workload:

1. Loss: events delivered that never took effect (believed but not acted on, coalesced, dropped).
2. Corruption under pressure: faults, and state lost to them, when the receiver is short of the resources the event needs (here: stack depth; in general memory, time).
3. Variance: the coefficient of variation of outcomes over repeated runs, and agreement of state hashes across machines.
4. Cost: latency from delivery to effect, and the memory held by facts waiting.

H0 is rejected if state is better on 1, 2 or 3 beyond the measurement floor, with 4 within a bound fixed before the run. It stands if not. Either result is a result.

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.