David F GliddenandClaude Opus 4.8
902e53116a
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015jYS1tpR4P4NBxui4FSgfv
2.6 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| project-studium-cm-sandbox-and-transfer | Studium engine + chamber-library are the steward's personal projects AND the unfettered experimentation sandbox for CapableMind — separable from CM's runtime, but breakthroughs transfer CM-ward; Seb now sees them as fundamental to the shared vision. |
|
The Studium engine + chamber-library are David's personal projects — but Seb now recognizes them as fundamental to the shared CapableMind vision. The strategic value of keeping them separate: David can experiment unfettered on the library/engine without risk of breaking CM's production L1/BMF runtime — while breakthroughs still transfer CM-ward. The engine is a microcosm of CM: the same governance thesis (executor/jurist/steward loop, L2-over-L1, honest-degradation / earned-confidence) instantiated over a bounded, provenanced library instead of the L1 runtime. Code-separable (zero L1/BMF/mcp__capablemind imports; verified 2026-07-08); coupled only at the governance-thesis level.
Concrete transfer surface — the V2 verifier work is the live example: per-language honest-degradation semantics ↔ CM's honest-degradation contract (REVIEWED-22); abstain-when-ungrounded ↔ earned-confidence ("the system does not grant epistemic authority to its own outputs without external grounding", REVIEWED-19); per-language trust/revise/abstain thresholds against a real failure taxonomy ↔ the confidence-floor/ceiling invariants (I-CF / I-CC), which L1 has only specified abstractly. Studium is where CM's epistemic-integrity invariants get pressure-tested on a real corpus before L1 hardens them.
Why: this is the rationale for concentrating effort on the library/engine — a safe, unfettered ground for the epistemic risks CM's live runtime cannot take, with a transfer path back. Named by the steward 2026-07-08 (the Fable-window allocation conversation).
How to apply: treat Studium/chamber as the experimentation sandbox (design freely, take research-grade risks there); when designing there, actively surface what transfers to CM — cf. the V2 charter's Deliverable 9, the CM-transfer note (studium-engine/docs/v2-validation-harness-scope-charter-2026-07-08.md). Keep them distinct projects — don't conflate Studium with CM, kin to mempalace-is-unaffiliated-stopgap's build-vs-use discipline — but do harvest the transfer. Companion to project-studium-engine-telos-chamber-of-voices and reference-studium-engine-architectural-charter.