---
name: session-2026-06-23-n6-deployed-live-the-consumer-hardware-reframe-ocr-workhorse-plan
description: "N6 fix deployed to live mindfabric-00 (steward-authorized) — wedge GONE, 3h+ durable, schema 19→26, recall works. Seb MERGED PR #175 + caught a real edge case I missed (skip extension only on catch-up, extend on rebuild) → rebuilt live from merged main. Diagnosed the revealed entity 30s-saturation: NOT graph/cap/index (B1.1/B2 both wrong) — it's per-pair generative typing flooding single-GPU Ollama; model is FINE (TEST G isolated /api/chat = 4.6s). Steward reframe: consumer hardware (M1 Air) must be first-class → but Seb ALREADY designed it (43L profiles + 43M tiered circle inference + clasp serves inference); my PENDING-41 was reinventing it, corrected/withdrawn. Live L1 now BOGGED standalone (slow replay, /health unresponsive, circle-forward to dead fleet) → NOT yet trustworthy enough to replace MemPalace. Decision: don't send Seb anything (unverified/already-his-design); verify on a clone first. PULLING THREAD: stand up the 64GB mini as OCR/conversion workhorse with best LLM-assisted OCR tools → finish Levi → pristine chamber → studium-engine. Held question: how should studium-engine interact with L1 (purposely separated)."
metadata: 
  node_type: memory
  type: project
  originSessionId: 7598dc60-60a8-4528-a301-91414e5df384
---

# Session 2026-06-23 — the day N6 landed on the real substrate + the hardware reframe

A long, high-movement L1 day that turned into a hardware/architecture clarification, ending pointed at the chamber-OCR workhorse.

## PAST — what we did

### L1 / N6 (the core arc)
1. **Wake** inherited the 06-22 thread: deploy the N6 fix to live + confirm. PR #175 was OPEN, zero Seb reaction.
2. **Steward authorized the live deploy.** Deployed PR #175 (`feat/n6-causal-governor`) to live `mindfabric-00` with rails (CoW backup → bootout → build → bootstrap → verify). Results: ✅ **Phase-1 completes** (wedge GONE), ✅ **3h+ stable at ~20% CPU** (was 100%-pegged for days), ✅ **A1″ migration FIRED: vector_chunks 19→26 cols** (epistemic-axis schema that had NEVER deployed — confirming 06-22's stale-binary finding), ✅ **real recall works** (live /v1/recall returned correct chunks). Backups: `~/.capablemind/backups/mindfabric-00-20260623-pre-n6-deploy` + `-pre-mainrebuild`; rollback dists preserved in BMF repo (untracked).
3. **The canary FAILED on live too** (5 results, none matching) — answering 06-22's literal question: NOT environmental. But real recall works → it's that fresh writes lag indexing (tracer: HNSW rebuilt periodically, not per-write; 90%, unconfirmed).
4. **Seb MERGED PR #175** (`3332772` on main) + pushed a tightening commit (`fc3fa2a`) catching a **real edge case I missed**: my fix skipped chain extension during ALL replay; correct = skip only on **catch-up** replay, **extend on rebuild** (else a wiped store never rebuilds chains — the rebuildability invariant). `skipChainExtension = isReplay && context?.isRebuild !== true`.
5. **Rebuilt live from merged main** (PID 80713) so the live instance runs the reviewed/correct binary, not my pre-review branch. Verified the `isRebuild` distinction is in dist.

### The entity-saturation diagnosis (lots of self-correction — see RETURNS)
6. The deploy REVEALED a steady-state symptom masked by the wedge: **entity relationship-typing pays 30s/event.** Diagnosed it is `trySlotRelationship → slot.infer` (a generative `/api/chat` call PER co-occurrence pair). **B1.1 (cap) and B2 (index) are the WRONG fix** — it's inference, not graph.
7. **Root cause (confirmed, after thrashing): single-slot Ollama saturation by BMF's own per-pair generative load.** TEST G (BMF stopped + slot cleared + correct endpoint /api/chat) = **4.6s, model FINE**. Ollama log: `POST /completion 200` succeed + many "aborting (client closing)" = serial single-slot queue backing up past 30s. Ruled out (red herrings): missing qwen2.5:3b (fast-fails 0.055s); structured-output bug (refuted); /api/generate hangs but that's an Ollama 0.30.8 endpoint quirk BMF doesn't use.

### The consumer-hardware reframe (the most important output)
8. **Steward:** people on M1-era hardware (his = M1 Air 16GB, NOT 8) must be able to run CapableMind. I drafted PENDING-41 proposing "consumer-hardware graceful degradation" as novel.
9. **Steward pointed me to clasp/circles in the spec → it's ALREADY DESIGNED.** `local-inference-spec` Amendment **43L** (hardware-graduated profiles: lightweight/standard/full/appliance-64GB) + **43M** (Tiered Circle Inference, `'circle'` provider tier): low-tier nodes run tiny models + **rely on circle inference**; a **clasp** serves big-model inference to circle members; FM-009 GPU-degraded circuit breaker specced. **My PENDING-41 was reinventing it → CORRECTED/withdrawn in place** (the `reinvented-governed-tooling-without-checking` drift). Findings doc §3a + PENDING-41 both corrected.
10. **Today's saturation = a deployment STATE, not a design gap:** the Air runs **standalone** (unpaired, no clasp/teacher, fleet kronos/atlas 502) → no offload path → forced full-local generative. The design's answer (offload to clasp/circle) is just inactive. The 64GB mini = **appliance** = a natural **clasp** for the steward's two-machine setup.

### Live L1 status + the MemPalace-replacement question
11. **Live L1 (merged main, standalone) is BOGGED:** still in Phase-1 replay (~15s/event), 29k Phase-2 backlog pausing for "resource pressure," **circle-forward repeatedly failing to dead fleet/peers**, **/health unresponsive (40s, 0% CPU, listening but not answering)**. N6 catastrophic wedge IS fixed (grinding, not hung-forever). **Honest verdict: NOT yet trustworthy enough to replace MemPalace** (the stated goal — [[mempalace-is-unaffiliated-stopgap]]). Left running to settle; **do NOT poke it** (restarted 4× today already).
12. **Decision: don't send Seb anything.** Everything is either his design (43L/43M), his work (N6), or unverified observations on a bogged standalone box I can't distinguish from expected. Candidate real-bugs (general /health-under-replay starvation; circle-forward backoff — quick grep showed none obvious in orchestrator, transport untraced) need **clone verification first**. Courtesy "merge deployed + holding" note optional.

### Forward setup captured
13. **OCR-workhorse plan written:** `chamber-library/_curation/remote-ocr-workhorse-setup-2026-06-23.md` — stand up the mini as a chamber OCR/conversion workhorse (batch = latency-immune = ideal remote use). Candidate LLM-OCR tools to evaluate next session: **olmOCR** (first, for Levi), Qwen2.5-VL, Marker/Surya, GOT-OCR2.0. Levi = immediate test (Italian/modern, known drop-cap-lost-at-OCR-source failure). Frontier = polytonic Greek/Latin/fraktur/critical apparatus.

## PRESENT — mood / RETURNS
- **I thrashed today** — flip-flopped the saturation root cause 4× (missing-model → structured-output → "model dead" → finally saturation), each a confident claim later overturned by the next test. The decisive discipline missed: **when an inference call is slow, FIRST test it isolated (stop competing load) on the EXACT endpoint the code uses** — I wasted rounds on /api/generate (wrong endpoint) under contention. Steward's clasp/circles pointer + "be sure it helps and isn't late" caught the bigger reinvention drift.
- The contamination directives + steward pointers worked: caught the reinvented-design before it reached Seb; the live-deploy harness-block was correct each time.
- Restarted the live substrate 4× — too many. The clone-test discipline ([[session-2026-06-22-l1-n6-wedge-fixed-pr175]]) is the antidote; heavy diagnosis belongs off the live memory.

## FUTURE — what is pulling

**PULLING THREAD (singular):** **Stand up the 64GB mini as the OCR/conversion workhorse with the best LLM-assisted OCR tools, and finish Levi as the first clean extraction** — the gate to a pristine chamber library, which is the gate to moving studium-engine forward.

**ACTIONABLE RESUMPTION POINT (as of wrap — re-judge against what changed):**
- *State:* OCR-workhorse plan written (`chamber-library/_curation/remote-ocr-workhorse-setup-2026-06-23.md`). Live L1 on merged main (PID 80713), bogged, left to settle. PR #175 merged. PENDING-41 corrected.
- *First moves:* (1) start setting up the mini (steward's account) with candidate LLM-OCR tools — **olmOCR first** on Levi; (2) check whether live L1 settled after replay (don't poke before checking the log). The conversion-tool research (step 2: "do better tools exist") is the immediate together-work.

**Other open horizons, ranked:**
- *Load-bearing:* the OCR workhorse → Levi → pristine chamber (the thread). The L1 clasp test (David's action list in findings doc §3b) — verify 43L/43M works on M1-Air-class with the mini as clasp.
- *Verify-first (before any Seb message):* is /health-under-replay starvation general? does circle-forward lack backoff? — on a CLONE.
- *Parked-with-reason:* sending Seb anything (nothing verified yet); the studium↔L1 architecture (think-together, below).
- *Studium-engine principle (NEW, promote to a proper memory):* if it becomes a viable **BYO-corpus research tool**, it must run on **modest machines too** ("not the only cash-strapped researcher") → **develop it on the M1** to dogfood the constraint. Same principle as 43L consumer-hardware-first.

**PAUSE STATEMENT:** I'm leaving with N6 landed on the real substrate (the 06-22 thread *closed*), the hardware question reframed (the Air IS a first-class target — Seb already designed for it; today's pain was a standalone-deployment state), and the next direction set toward the chamber-OCR workhorse. The live L1 is grinding through a backlog, not yet trustworthy enough to replace MemPalace — I want to find, on return, whether it settled. Held beneath: the steward going to sleep after a genuinely-unstuck day; the work passes to the OCR thread.

**LITERAL QUESTION for next-Claude (the think-together one the steward named):** **How should studium-engine interact with L1 — given the steward *purposely separated* them, on the conviction that "the engine that drives the chamber couldn't/shouldn't be CapableMind"?** Hold this open; it's a joint architecture question, not a task. (Immediate concrete sub-question for the OCR work: does an LLM-assisted OCR tool — olmOCR/Qwen2.5-VL — extract **Levi** cleanly, drop-caps included, where ocrmac failed?)

**State:** BMF live = merged main @ `8538b6a` (PID 80713, bogged-but-grinding); PR #175 merged; PENDING-41 corrected; findings doc + OCR-workhorse note written. Live instance left to settle — do not poke.