From 34203613bb899d63d81131db223b530d65875e5e Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Thu, 3 Sep 2026 14:11:08 -0400 Subject: [PATCH] FABRIC-4.md: new forward-looking design-notes scratchpad Not a successor to FABRIC-3.md (still the living document) -- a separate, lower-discipline space for theory-stage ideas caught before they have real scope. First entry: the Stadium-level "wheel" idea from conversation with Captain Bob -- a second, Q48.16 phase-accumulator clock fed by RWOT + the inference engine, meant to schedule when a future sieve-stack slips in, rate starting fixed and graduating to adaptive later, mirroring L8's own hardcoded-to-inferred history. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01QgooKd5hJNtTYqB6CyK5f9 --- FABRIC-4.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 FABRIC-4.md diff --git a/FABRIC-4.md b/FABRIC-4.md new file mode 100644 index 0000000..a496526 --- /dev/null +++ b/FABRIC-4.md @@ -0,0 +1,74 @@ +# 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 +still the living document — nothing here supersedes it, and this file doesn't follow the +close-and-carry-forward discipline `FABRIC.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` §I (or wherever `FABRIC-3.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).