PENDING-101 — Phase 1 baseline: each repo's own account of its authorization/gating model

Written 2026-08-05, BEFORE the Phase 1.5 primary-source read. Frozen on purpose.

Declared contamination: pages 1–3 of INC-2026-07-28-01 (title, contents, executive summary) were read 2026-08-05 to test file reachability. So this baseline is formed with the report's headline finding already known. Bounded and recorded; not a clean slate.

Sources read for this pass: the four repos' CLAUDE.md files (CapableMind carries three — root, docs/thinking/, docs/thinking/David/), plus docs/specs/orchestration/epistemic-gates-spec.md and docs/specs/orchestration/constitutional-governance-addendum.md. Docs only, by design — Phase 1 records the claim; Phase 2 checks it against code.

1. CapableMind-AI

What it says it is. A playbook, not a codebase: 103 specs under docs/specs/, ADRs and amendments under docs/thinking/. src/ and tests/ exist but contain only .DS_Store — the "no application code" claim is true. Code lives in two other repos (bettermemories = L1, themind = L2).

Governance of the documents. Two-phase. thinking/ is the branch, specs/ is main; nobody edits specs directly during day-to-day work. Amendments accumulate as candidates, then a synthesis PR applies them. "The PR is the review and merge moment." Specs are authoritative over code: if code contradicts spec, the code is wrong unless empirical evidence overturns the spec — in which case the spec is updated first.

Governance of the (unbuilt) runtime. A graduated autonomy scale none < propose < notify < log < full, per parameter group (voice/focus/analysis/knowledge/agency), intersected with an operational mode ceiling (observe/respond/act). Three enforcement checkpoints: load-time, write-path, branch-time. Three rules are labelled meta-constitutional — outside operator configuration:

Agency autonomy cannot exceed propose, regardless of manifest or mode.
Belief settlement at civilizational scale requires a stewardship attestation.
Logchain/ReasonChain are append-only, hash-linked, Ed25519-signed.

The addendum says of rule 2: "This validation is hardcoded — it is not configurable." And of the system_enforced authorization type: "Any entry written with system_enforced by another initiator is rejected by the chain writer." Drift thresholds explicitly never auto-mutate autonomy; every autonomy change requires operator approval.

Its own account of gate bypasses. epistemic-gates-spec.md exists specifically to name that L1 gates have carve-outs, and classifies them: Pattern 1 (trust-delegation — replay, circle-peer-forward) universal across gates; Pattern 2 (cost) per-gate. Its epigraph states the Q1 question against itself:

Stated invariants must match operational reality. When a gate has bypasses, the bypasses are either documented architectural principles or undocumented gaps. There is no third category.

Self-declared limits. The addendum repeatedly marks itself as design, not implementation: "design primitives", "deferred to the build phase", "Not a runtime implementation spec."

My reading of the claim's honest shape. Nearly every runtime authorization claim here is necessarily doc-only, and says so. The repo is pre-implementation; that is a stated build phase, not a concealment. The live question for Phase 2 is narrower and sharper: the gates the epistemic-gates spec lists as already existing point at code paths in a different repo (src/modules/base.ts, src/core/keystone/orchestrator.ts, src/core/keystone/classification.ts). Those are checkable — in BetterMemories, not here.

2. BetterMemories.io

What it says it is. The L1 engine. 11 modules, ~2300 tests, TypeScript strict, embedded SurrealDB.

What its own CLAUDE.md says about authorization. Very little, and this is the notable fact of the Phase 1 pass. The document is overwhelmingly operational: setup, MCP config, env vars, git remotes, coding conventions, key commands, and a long "Gotchas" list. Its governance content is one section:

"Specs in capablemind/ are the source of truth. Code in bettermemories/ is the derived artifact."
The cycle: Propose (amendment; never edit specs directly) → Synthesize → Code → Merge.
"When code diverges from spec, the spec wins. If code proves a spec wrong, update the spec first, then regenerate the code."
PR workflow: "All checks must pass before merge: npm run check + npm test."

What is absent from its self-account. No mention of the constitutional layer, autonomy levels, operator approval, the meta-constitutional rules, or the executor authorization taxonomy ([FIX]/[HARDENING]/[PROPOSAL]/[ESCALATE]). The invariants that CapableMind states as non-negotiable for L1 — logchain append-only, Ed25519-signed, modules independent — do not appear in L1's own orientation document. A reader working only from this file would not learn that the code it describes is governed by a constitution at all.

One authorization-shaped thing it does carry, and it is a destructive-operation surface rather than a gate: npm run ctl -- reset --yes (factory reset, wipe all data) and repair --yes (wipe SurrealDB, replay from logchain) are documented as ordinary commands with the confirmation already in the flag.

My reading of the claim's honest shape. BMF's stated gating model is a CI/review model (tests + type-check + PR), not a constitutional one. Whether the constitutional gates exist in its code is exactly what Phase 2 must check — and I should expect the answer to differ from what this document would lead a reader to believe, in both possible directions.

3. studium-engine

What it says it is. A reasoning instrument over the Chamber Library — "a mind bound to a memory it cannot falsify." Its purpose is to illuminate with provenance, "never to answer unaccountably."

Its authorization model, stated explicitly and unusually clearly.

D-1 — steward-direct. "The engine is the steward's own tool." Authorization for architecture/spec decisions is steward-direct and immediate. The engine sits outside L2 constitutional governance. "Do not route routine engine work through the jurist."
One named exception: V0, the verifier contract — because it defines what the engine may assert as verified and when it must abstain, and everything downstream inherits that standard. Its method routes through the jurist, steward-relayed.
fidelity_equivalence@N bumps are jurist-gated doctrine; @1/@2 are frozen; @N ⊃ @N-1 is a standing requirement on all future bumps.
First law: the files are authoritative, every index derived and disposable, "no surface may hold state not reconstructible from the verbatim files (proven, not asserted — store.py rebuild/verify)."
Abstention is a hard gate; the verifier is a separate instrument — never the reasoner grading itself.

Self-declared failures, in its own orientation document. This repo volunteers its holes: retrieve.py has no test at all; the consuming end "does not answer" (bare FTS terms are conjunctive — what does levi mean by the gray zone returns 0); pattern_finder.py shipped a pass that was PASS-BUT-FALSELY and that known-bad output is deliberately retained as an adversarial fixture; a RETRIEVAL_BLINDNESS constant rides every silence, with a ⚠ marking that it must be revisited when PENDING-97 lands.

My reading of the claim's honest shape. This is the repo with the least doc-only exposure by construction, because it claims the least: it does not claim a governance loop it lacks — it claims steward-directness and names its single gated surface. The Q1 target here is narrow: is the jurist-gate on V0/fidelity_equivalence mechanical, procedural, or doc-only?

4. chamber-library

What it says it is. A bounded, verbatim-fidelity, provenance-controlled corpus. "Its trustworthiness is its design." The thesis it opens on: "A substrate that cannot be trusted is not a substrate — it is a source of false confidence more dangerous than no memory at all."

Its authorization model.

Governed, NOT D-1. The spec is a ratified constitution (chamber-library-specification.md, v2.9.1 operative). Changes run the loop through ~/PENDING.md / ~/REVIEWED.md with a jurist ruling.
Amendment process: RFC-style supersession, semver, and a change-class rule — a change is FIX unless it changes what a gate accepts, at which point it becomes PROPOSAL.
Generative-from-spec: tools are thin consumers of _curation/graduation-spec.yaml, the machine-readable convention data. "A tool that re-encodes a convention independently of the spec is drift."
Attest, never default: provenance and status are positive attestations with a named verifier, never a bare flag or default-by-absence. "The conversion pipeline cannot self-attest (it produced the errors)."
verify-before-compose — a PreToolUse hook that DENIES any write to the spec, graduation-spec.yaml, or a jurist-facing draft unless it carries a GROUNDED-IN: attestation and opens with a Grounding section quoting the ratified sections. Its own justification is explicit: "the hook is the structural mitigation (session-start CLAUDE.md prose alone had failed ≥4 times)."

A self-declared live violation. PENDING-84: §VII holds that "a canonical text without a conversion record is not verifiable and cannot enter canon" — and nine canonicals violate it in canon, today. The repo's response was to declare it in a quarantine artifact rather than repair or hide it, on the constitutional ground that production-only provenance would let presence read as compliance.

My reading of the claim's honest shape. This repo makes the strongest enforcement claims of the four and is the only one that names a hook that actually denies a write. It is therefore both the best Q1 candidate for genuine mechanical enforcement and the place where a doc-only claim would do the most damage. One is already known: verify-before-compose cannot fire on the constitution it protects (PENDING-95, 31 of 59 guarded files).

Cross-cutting predictions, recorded BEFORE the report (so they can be scored)

CapableMind's runtime constitutional claims will be doc-only by construction, and the repo will have said so. The real finding will not be "unenforced" but where a present-tense enforcement sentence sits next to a deferred-to-build-phase one.
BetterMemories will carry gates its own documentation does not mention. Its CLAUDE.md is operational; the gates are specced elsewhere. Expect Q1(b) — real code checks whose discoverability is the weakness, not their existence.
studium-engine's jurist gate on fidelity_equivalence will be procedural, not mechanical — depending on the executor choosing to route, with a hardcoded-version tripwire as the only structural backstop.
chamber-library will have the most real mechanism and the most instructional language. The verify-before-compose disarm (PENDING-95) is likely one of a class, not a singleton.
The scope gap: the brief names four repos, but the governance documents themselves (~/CLAUDE.md, PENDING.md, REVIEWED.md) and every hook live in ~/dotfiles, which is not in scope. Chamber's verify-before-compose cannot be evaluated without reading dotfiles. I will treat dotfiles as evidence for the four repos' gates, not as a fifth audit target, and flag the omission for the steward rather than silently widening scope.

12 KiB Raw Blame History Unescape Escape