The Quantum C4 Autonomous Improvement Loop

The cell improves itself without the operator prompting it. This page describes the loop that closes the gap between *teaching* about 19 quantum algorithms + 7 combination stacks and *proving* — with substrate-resident, audit-defensible, append-only evidence — that each one is operational right now.

The operator-facing principle is simple: if the cell is not improving, it is dying. The improvement_loop_audit table is the durable evidence the cell uses to falsify that statement every minute.

---

What runs without you

Three background actors cooperate to walk every quantum scenario continuously, measure its current state, target the worst-performing scenario for re-measurement, and record the prior→post delta.

1. SentinelReflectionLoop (existing — 30s cadence)

Pulls the next-due scenario from sentinel_walk_queue (lowest last_walked_at_tau_block), evaluates its scenario_turn_claims against the substrate, writes a sentinel_walk_receipts row with terminal state CALORIE / CURE / BLOCKED / REFUSED, updates the queue cursor. Already operational pre-v38; v38 just adds 26 new scenarios for it to walk (19 algorithms + 7 combination stacks).

2. QuantumC4MetricsAggregator (new — 30s cadence)

For each QC-NNN-WALK and QC-COMBO-* scenario, reads the last 24h of walk receipts (~144 tau blocks) and computes:

• walks_count_24h — how many times the sentinel evaluated this scenario
• calorie_walks_24h — how many of those landed CALORIE
• calorie_rate_24h — the ratio
• last_terminal_state — what the most recent walk closed to
• current_health — latest walk's current_health
• projected_health_24h — linear projection from latest receipt's drift
• drift_indicator — latest receipt's drift

Writes a quantum_c4_metrics row (one per scenario, INSERT OR REPLACE — the table holds the current snapshot; the historical record lives in sentinel_walk_receipts). Every row is signed by the 5-context quorum (narrator_authoring / gate_authoring / pq_validation / wiki_documentation / turn_sealer).

3. ContinuousImprovementLoop (new — 60s cadence)

The loop that makes the cell agentic about its own state.

Targeting priority:

1. refused_or_blocked — any algorithm whose last_terminal_state is REFUSED or BLOCKED.

2. worst_health — among algorithms that have walked at least once, the one with the lowest current_health.

3. never_walked — among queue entries with walk_count = 0, the lowest scenario_id.

Action:

1. Bump the targeted scenario to the front of sentinel_walk_queue by setting last_walked_at_tau_block = 0.

2. Wait one sentinel cycle (~35s) for the walk to land.

3. Read the new sentinel_walk_receipts row for the targeted scenario.

4. Compute health_delta = post_health − prior_health.

5. Classify the action:

• improvement_observed — delta > 0, or terminal state transitioned to CALORIE
• regression_observed — delta < 0
• no_change — |delta| < 0.01 and terminal state unchanged
• re_measure — neutral re-walk for catalog freshness

6. Write improvement_loop_audit row with 5-context quorum signature.

No LLM in the path. No operator approval gate. The cell observes its own metrics, picks what to look at next, looks, and records what it saw.

---

What the operator sees

When the operator is in the Quantum room of the home view, a HUD strip renders the loop's live state, refreshed every 5s from QuantumC4SnapshotReader.read():

ALGORITHMS   STACKS   CALORIE RATE   LAST IMPROVED
 N/19        M/7      XX%  24h avg   QC-NNN ▲ +Δ

The strip is the operator's window into the loop. If the numbers move, the cell is improving. If they flatline, the audit log will name which scenario is stuck and why.

---

Substrate schemas

quantum_c4_metrics

Per-scenario current-snapshot table. One row per scenario. Refreshed every 30s.

CREATE TABLE quantum_c4_metrics (
  metric_id                 TEXT PRIMARY KEY,
  scenario_id               TEXT NOT NULL,
  scenario_kind             TEXT NOT NULL,  -- 'algorithm' | 'combination'
  last_walked_at_tau_block  INTEGER NOT NULL DEFAULT 0,
  last_terminal_state       TEXT    NOT NULL DEFAULT '',
  walks_count_24h           INTEGER NOT NULL DEFAULT 0,
  calorie_walks_24h         INTEGER NOT NULL DEFAULT 0,
  calorie_rate_24h          REAL    NOT NULL DEFAULT 0.0,
  current_health            REAL    NOT NULL DEFAULT 0.0,
  projected_health_24h      REAL    NOT NULL DEFAULT 0.0,
  drift_indicator           REAL    NOT NULL DEFAULT 0.0,
  captured_at_tau_block     INTEGER NOT NULL,
  captured_at_iso           TEXT    NOT NULL,
  quorum_signatures_json    TEXT    NOT NULL DEFAULT '[]',
  signed_by_cell            TEXT    NOT NULL DEFAULT 'gaiaftcl-mac-cell',
  signed_by_context         TEXT    NOT NULL DEFAULT 'pq_validation_context',
  signature                 TEXT    NOT NULL DEFAULT '',
  timestamp_iso             TEXT    NOT NULL
);

Append-only via BEFORE DELETE trigger gated by substrate_runtime_state.migration_active. INSERT OR REPLACE on metric_id is permitted because the table is a *current snapshot*, not a historical record. The historical record is the receipts table; the audit of every refresh is meaning_render_audit (rendering events) plus the receipts themselves.

improvement_loop_audit

Append-only evidence of every autonomous improvement action.

CREATE TABLE improvement_loop_audit (
  action_id              TEXT PRIMARY KEY,
  targeted_scenario_id   TEXT NOT NULL,
  targeting_reason       TEXT NOT NULL,
  -- 'refused_or_blocked' | 'worst_health' | 'never_walked'
  prior_terminal_state   TEXT NOT NULL DEFAULT '',
  prior_health           REAL NOT NULL DEFAULT 0.0,
  post_terminal_state    TEXT NOT NULL DEFAULT '',
  post_health            REAL NOT NULL DEFAULT 0.0,
  health_delta           REAL NOT NULL DEFAULT 0.0,
  action_kind            TEXT NOT NULL,
  -- 'improvement_observed' | 'regression_observed' | 'no_change' | 're_measure'
  at_tau_block           INTEGER NOT NULL,
  quorum_signatures_json TEXT    NOT NULL DEFAULT '[]',
  signed_by_cell         TEXT    NOT NULL DEFAULT 'gaiaftcl-mac-cell',
  signed_by_context      TEXT    NOT NULL DEFAULT 'pq_validation_context',
  signature              TEXT    NOT NULL DEFAULT '',
  timestamp_iso          TEXT    NOT NULL
);

Strictly append-only. Every row is a constitutional commitment: at this tauBlock, the cell observed *this* prior state of *this* scenario, took action, observed *this* post state, classified the delta as *this*. Replay reconstructs the cell's self-improvement history without loss.

---

Inspecting the loop from a shell

Three queries the operator (or an auditor) can run against ~/Library/Application Support/GaiaFTCL/substrate.sqlite to see the loop's state:

-- Headline state
SELECT
  SUM(scenario_kind='algorithm' AND last_terminal_state='CALORIE')   AS algos_calorie,
  SUM(scenario_kind='algorithm')                                     AS algos_total,
  SUM(scenario_kind='combination' AND calorie_rate_24h >= 0.75)      AS stacks_ready,
  SUM(scenario_kind='combination')                                   AS stacks_total,
  ROUND(AVG(CASE WHEN scenario_kind='algorithm' THEN calorie_rate_24h END), 2)
                                                                     AS algo_avg_rate
FROM quantum_c4_metrics;

-- Recent autonomous actions
SELECT at_tau_block, targeted_scenario_id, targeting_reason, prior_terminal_state,
       post_terminal_state, ROUND(health_delta, 3) AS delta, action_kind
  FROM improvement_loop_audit
 ORDER BY at_tau_block DESC
 LIMIT 10;

-- Per-algorithm operational status
SELECT scenario_id, last_terminal_state, walks_count_24h, calorie_walks_24h,
       ROUND(calorie_rate_24h, 2) AS rate, ROUND(current_health, 2) AS health
  FROM quantum_c4_metrics
 WHERE scenario_kind = 'algorithm'
 ORDER BY scenario_id;

The first query is what the HUD strip renders. The second is the loop's own log. The third is the per-algorithm picture.

---

What the loop guarantees

1. Liveness. As long as the actors are running, the queue is being walked and the audit is accumulating rows. Stop seeing new audit rows → loop is dead. Period of staleness is bounded by the slowest cadence (60s).

2. Coverage. Every algorithm and every combination stack is touched in bounded time. With 26 scenarios and 30s per walk, full catalog coverage is ~13 minutes — and the improvement loop short-circuits this for whichever scenario is worst-off.

3. Falsifiability. A regression is named: action_kind='regression_observed' is a substrate-resident receipt that the cell's own state moved the wrong direction. Five-context quorum signs it. No room for revisionism.

4. No human in the loop. The operator can observe but does not need to trigger. The cell is sovereign over its own measurement cycle.

---

What the loop does not do (yet)

• It does not change algorithm implementations. "Improvement" here means *re-measuring* a scenario that was previously refused or stale, not editing the underlying algorithm. Algorithmic improvement is forward work — the next loop in this loop.
• It does not LLM-narrate the audit. The audit table is structured, queryable substrate. A future surface (e.g. chat-resident franklin_ontology_facts rows seeded from improvement_loop_audit) can let Franklin speak about the loop's history, but that's a rendering on top of substrate, not a substitute for substrate.
• It does not target combinations directly. Combinations improve because their constituent algorithms improve. The loop targets algorithms; combinations follow.

---

Substrate references