LithosAnanake/FABRIC-4.md

FABRIC-4.md — forward-looking design notes

Status: Not a successor to FABRIC-2.md and not a punch-list document. FABRIC-2.md is still the living document — 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 used (that chain triggers on closing a document; FABRIC-2.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-2.md §I (or wherever FABRIC-2.md 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).