# 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:

1. Agency autonomy cannot exceed `propose`, regardless of manifest or mode.
2. Belief settlement at civilizational scale requires a stewardship attestation.
3. 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)

1. **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.*
2. **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.
3. **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.
4. **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.
5. **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.