KB Governance Registry

The canonical inventory of every rule that governs how the MSBAi knowledge base is written to, protected, verified, and audited. Rules are defined here once, with an ID, an enforcement tier, and pointers to where they are implemented, evaluated, and surfaced. The operational documents (CLAUDE.md, the K-ai playbook, the stakeholder docs) are views of this registry: they carry the rule text their audience needs, tagged with the IDs below.

Audiences: auditors scan the Tier column (a convention tier on a high-stakes rule is a finding); the evaluation team treats every row as an evaluable claim (an empty Evaluated-by cell is eval backlog); researchers use the changelog as the longitudinal record of how governance evolved.

Published on the password-gated live site since 2026-06-12: the interactive governance page parses this file at page load, so that view can never drift from this registry. The site auto-deploys on every push to main (.github/workflows/deploy.yml) — a registry commit is live within minutes, no manual deploy.

Human-readable companions: the July 2026 governance review walks the whole mechanism in one page — the four control layers, live probe results, and the G37/G38 v2 promotion; the interactive gate simulator lets you send a message through the pipeline and toggle the v1 vs. v2 entry gate. Reviews like this are produced on events (incidents, structural changes, tier promotions), not on a calendar — the changelog below is the continuous record between them.

Tiers: code (hard — enforced by nanoclaw runtime, cannot be skipped by the agent) · skill (semi-hard — programmatic gate the agent must invoke) · convention (soft — instruction text only). ⚠ marks a known-weak tier for the rule’s stakes.

Implementation pointers prefixed nanoclaw: live in the nanoclaw-msbai repo; unprefixed paths are in this repo.

Surfaced-in shorthands (used in the tables below):

1. Decision integrity (write gates)

G9 is load-bearing beyond classification: the triage approver-CC router (G27) reads the Category: line to detect the governance domain.

2. Protected files & write scope

3. Input attenuation (who and what gets in)

4. Verification & audit

G31 is load-bearing for G28: bot-vs-human commit detection keys off the author identity. Changing the bot identity without updating the push-webhook bot set breaks terminal-commit auditing.

5. Freshness & propagation

6. Structure & transparency (human legibility)

7. Delivery integrity, ingestion evidence & agent principals (v9)

Change protocol

1. New rules originate as candidates in discussions/rule-candidates.md (RC-###) — filed by anyone including K-ai autonomously (trigger classes and format documented there). G-IDs are assigned only at approval, by the host commit that promotes the candidate to a registry row. A Proposed candidate changes nothing about live behavior.
2. Any PR that adds or changes a governance behavior updates this registry in the same PR — new rule row, tier change, or pointer change. The PR description names the affected G-IDs.
3. Consumer constraints (do not break):
   • kb-conflict-check (nanoclaw skill) and the K-ai playbook reference CLAUDE.md’s “KB Write Protocol” section by that exact heading. Tag it, never rename or move it.
   • CLAUDE.md is loaded into agent containers: rules must remain inline and operationally complete there. This registry adds IDs and metadata; it never replaces CLAUDE.md text.
   • G9’s Category: line and G31’s bot identity are consumed by code (see callouts above).
4. Derived views carry a “verified against registry” stamp — except /governance (the live-site explorer page), which is auto-derived: it fetches and parses this file client-side at load and needs no stamp or sync step. Stamped views: program/how-the-knowledge-base-works.md and docs/stakeholder-bot-guide.md (stakeholder-facing), plus the rule text in CLAUDE.md and the nanoclaw playbook (operational). When a rule changes, update the views in the same PR and bump their stamp.
5. Tier upgrades are tracked here: when a convention becomes code (e.g. G11 under review R11), update the Tier cell and the changelog — that trajectory is the system’s hardening record.
6. This file is not one of the three gated discussion files; changes follow the normal SoT change protocol (host-applied, human-reviewed PRs). Keep program facts (counts, dates, names) out of this file — it describes rules, not program state, so it cannot go stale against curriculum.md.

Changelog

• v9.6 — 2026-08-04 (G40 scope reverted: sensor skip-not-flag for non-fact claims). The original G40 added ACTION_ITEMS.md to the sensor’s ground truth to stop pilot-day false FAILs; that conflated program facts (stable, verifiable) with tracking state (operational, fluid) and by 2026-08-02 the flags were unusable (~20 of 27 daily were noise). Reverted per Vishal’s 2026-08-02 approval: ACTION_ITEMS leaves the bundle, a deterministic out-of-scope classifier (tracking-state / infrastructure / conversational-ack) runs before the model, and the prompt states absence-from-ground-truth ≠ error. Deterministic pre-checks still run on every reply. Acceptance-replayed over 104 real outbound entries before shipping — all reclassified FAILs were false positives (“Yes, go ahead” had FAILed as unverifiable); citation checking on out-of-scope replies was evaluated and rejected with the same replay (2 hits, both false positives, zero true catches). Three codex rounds tightened the classifier from both directions (short factual claims stay in, month-name false signals stay out).
• v9.5 — 2026-08-04 (RC-016 approved → G56: CC’d mail is context, not a request). Implements the R1+R2 pair approved 2026-08-01 (analysis: _agent-inbox/2026-08-01-kai-cc-behavior-analysis.md), deliberately held past the JPIM prospective-data window (through 2026-08-03). R1: recipient truth restored — real .eml To:/Cc: headers replace the Worker’s lossy envelope values in the agent prompt and metadata. R2: Cc-only mail with no direct request files as normal but acks nowhere; host-side suppression (a prompt-only silent mode would trip G46’s mandatory-reply gate into retry/alert storms), [CC-CONTEXT] audit entries, one daily-digest line each. Ambiguity always acks. G46 row gains the interaction note. R3–R5 from the same analysis stay deferred.

• v9.4 — 2026-07-28 (RC-012 approved → G55: aged OPEN_QUESTIONS monitor). Closes the gap RC-012 named: open questions could sit indefinitely with nothing surfacing them, and G42’s routed questions had no reply-chase. Implemented in the same session as collectAgedOpenQuestions (src/exceptions-report.ts) reporting into the existing weekly digest per G30 — no new notification path.

  Design changed from the filed candidate. RC-012 asked whether to parse an Added: field or adopt a date-stamp naming convention; the answer is neither-as-written. The file had 0 Added: fields across 105 open questions, so both options required a ~105-item hand-backfill plus a new field K-ai must remember on every write — and a convention enforced only by prose gets skipped, which would make the monitor silently under-report. Instead: a one-time git-blame backfill (git blame -w -M -C on each bullet, so the file’s reorganisations don’t date every question to a reformat commit) materialised the true authorship dates — 44 distinct dates spanning 2026-03-01 to 2026-07-22, with no single date dominating, confirming genuine authorship rather than a mass reset. Going forward the kb-entry-gate skill stamps the date deterministically (emits stampedProposal for the agent to append verbatim) and the digest reports any open question missing the stamp, converting a skipped gate from a silent failure into a visible one.

  Flag-once semantics, matching the G47 auto-close scanner. Only questions crossing the 14-day threshold inside the window are enumerated; the standing backlog is a single count that deliberately does not wake the digest. Validated against real data before shipping: 99 of 105 questions are already past 14 days, so a naive threshold would have opened the first digest with 99 one-liners — the kind of report that trains its reader to skip it. Actual first-run output: totalAged=99, newlyAged=0, missingAdded=0.

• v9.3 — 2026-07-28 (G42 in effect; scope bounded to the main group). The playbook mirror that v9.2 filed as a ticket landed (nanoclaw-msbai PR #25): groups/global/CLAUDE.md gained an §Outbound Email Authorization (G42) section carrying Tier 1/Tier 2 and all eight Tier-2 conditions, and the groups/msbai-email/CLAUDE.md negation clause (“Tier-2 relay, when implemented, will restore immediate nudges”) was removed. G42 is now in effect, not merely activated — the ⚠ approved-but-not-in-effect condition that v8 flagged is fully cleared.

  Implementation surfaced a scope limit the rule text never drew, now recorded in the row: Tier 2 splits in half. The G37 logging obligation works in every group; the send obligation does not. send_email is gated to the main group (G36) because in-container capability grants are unwinnable in NanoClaw — the 2026-06-10 R2 review (8 rounds) found every scheme leaks through a group-shared writable surface (IPC dir, group logs, runner source cache), so the host cannot attribute a send request to a container within a group. Non-main calls are dropped silently (src/ipc.ts, warn + break, no error returned), so an email-group agent reading “Tier 2 is pre-authorized” would attempt a relay, receive no failure signal, and could then claim it nudged an owner — the invisible-send failure mode. The playbook therefore states where Tier 2 is actionable (main group = Telegram) and forbids claiming a relay elsewhere.

  Enabling email-group relay is not a config change: it requires a host-side relay-proposal path (agent composes a structured proposal → host validates against the allowlist, enforces the ≤2 cap, writes the parent-authorization audit entry, sends), i.e. the outbound-email.ts / processOutreachResult compose-then-host-send pattern applied to a new shape. Deferred — the Ron Guymon case that motivated activation arrived on Telegram, where Tier 2 works end-to-end. Provenance: session 2026-07-28; group topology verified against the live VPS registered_groups table (msbai-telegram is_main=1).

• v9.2 — 2026-07-22 (G42 activated). G42 promoted from approved-but-not-in-effect to active convention. Rule text updated: Tier 2 trigger clarified (“K-ai cannot answer from the KB and a named decision-maker exists”), CC-sender requirement added, OPEN_QUESTIONS logging via G37 made explicit. Email overlay negation clause removal filed as Hermes agent-inbox ticket (2026-07-22-g42-activate-playbook-mirror.md). Provenance: Telegram session 2026-07-22, Ron Guymon routing case as the concrete example.

• v9.1 — 2026-07-17 (G45/G46/G47/G51 implemented — ⚠ markers cleared). Same-day implementation of the four pending rows (nanoclaw merges 9926c3d8 + d163976a, 641/641 tests, deployed to VPS): G46 shared delivery-gate.ts (chat profile now gated, delivery-completeness, required per-channel profile); G47 v2.1 (n-gram extraction replaces the fixed term list; bare no-incumbent spreadsheet facts route to OPEN_QUESTIONS); G51 phase 1 ([GATE RESULT] audit-log entries via log_gate_result IPC; commit-hash existence FLAG in the sensor); G45 playbook bullet. Registry §7 now asserts only live behavior.

• v9 — 2026-07-17 (RC-005–011 approved: §7 added, G45–G54). Vishal approved all seven pending rule candidates with the governance-review amendments (RC-006 widened with delivery-completeness; RC-007 amended: no-incumbent facts → OPEN_QUESTIONS, n-gram extraction to replace the fixed term list). New rows: G45 FAQ freshness (RC-005) · G46 uniform delivery gate (RC-006) · G47 ingestion evidence sets (RC-007) · G48 accidental-governance adopt-or-replace incl. adopted inventory (RC-008) · G49/G50 working-context layer + precedence (RC-009) · G51 self-claims verification (RC-010) · G52/G53/G54 agent registry / delegation cap / inbox authenticity (RC-011). Rows whose implementation is not yet live carry ⚠ per the G42 lesson (G45, G46 partial, G47 partial, G51); implementation items filed in _agent-inbox/. Derived views restamped v9 (kb-works, stakeholder-bot-guide). Hermes marked agent in EMAIL_ALLOWLIST.md (G52).

• v8 — 2026-07-17 (freshness corrections; no new G-numbers). Registry audit (four-dimension review, see reference/governance-architecture-review-2026-07.md) found the registry frozen at v7 while the 07-17 hardening wave shipped. Corrections: G1 row amended to describe the shipped ingestion cross-check v2 (Step 2b + confidence downgrade; RC-007 remains the formal generalization); G16 de-facted (named individuals → “senders marked read-only in EMAIL_ALLOWLIST.md”, per this file’s own step-5 rule); G22 gained the src/outbound-email.ts pointer (enforcement moved there when host-send was extracted); G34 re-tiered — the site-link half has been code-tier CI (check-site-links.py) since ~06-12; G42 marked ⚠ approved-but-not-in-effect (playbook mirror never landed; email overlay explicitly negates it — resolve by implementing or demoting). Shipped mechanisms still awaiting rows (G-numbers at RC approval only): outbound reply gate (RC-006), ingestion evidence-set rule (RC-007), working-context layer (RC-009), self-claims verification (RC-010), agent-principal/delegation governance (RC-011). Derived views restamped to v8 same day.

• v7 — 2026-06-19 (G43/G44 — structure & transparency). Added §6. G43: type: front-matter taxonomy across knowledge files (50 files gained the field this session; reconciled with the pre-existing research-corpus vocab into one taxonomy), enforced by a new CI gate scripts/check-kb-schema.py that fails the deploy on any unregistered type: value or new front-matter key — making KB structural drift impossible to ship silently. G44: the auto-generated /updates page (per-page git-derived change log, shipped this session). Both are code-tier. Filed because the type: rollout initially shipped with no registry entry and collided with the existing vocab — the deterministic gate exists so that gap (a CLAUDE.md rule deprioritized under context pressure) cannot recur.
• v6 — 2026-06-12 (G40/G41 implemented). Tier flipped to code (nanoclaw a8f9e5a). G40: sensor prompt gains an ACTION_ITEMS block (deterministic per-owner open-count index + relevance-selected sections) when the reply makes action-item claims; review-time-HEAD semantics chosen for the open SHA question and stated in the sensor prompt; OPEN_QUESTIONS deferred. G41: stable triage anchors + daily-digest FAIL one-liners; FLAG counts were already in the weekly exceptions digest. Codex review caught two P2s (ownership-wording gate gap, type-tail parsing), fixed with regression tests.
• v5 — 2026-06-12 (RC-002 approved with conditions). Added G42 (two-tier outbound email authorization — removes relay friction observed in the Ashish Excel-forward incident while bounding the self-assessed “no content judgment” risk with five conditions: parent-task-named audit entries, template-only bodies, digest counting, per-task relay cap, G39 exclusion). Convention tier; revisit at monthly review. Candidate provenance: rule-candidates.md RC-002 (filed by K-ai).
• v4.1 — 2026-06-12 (process). Rule-candidate pipeline documented and made K-ai-actionable: discussions/rule-candidates.md is the single entry path for new rules (change protocol step 0); filing triggers, required format, no-G-number-at-filing rule, and admin-only promotion are specified there. Playbook mirror requested via the monday-alert-golive inbox item.

• v4 — 2026-06-12 (RC-003/RC-004 approved). Added G40 (ACTION_ITEMS as sensor ground truth for action-item claims — closes the false-positive FAIL class from pilot day, where accurate replies citing the 6/10 meeting failed because the content lived only in ACTION_ITEMS) and G41 (sensor FAILs roll up into the digest — reconciles G26’s triage files with G30’s single-escalation-surface principle). Both code-tier, implementation pending in nanoclaw (_agent-inbox/2026-06-12-sensor-g40-g41.md). Candidate provenance: discussions/rule-candidates.md RC-003/RC-004.

• v3 — 2026-06-12 (plan-and-test meeting). Added G38 (ACTION_ITEMS in-place update protocol — closes the gap that G37 gates only appends; convention tier chosen deliberately to match the meeting’s teach-by-example refinement model, with a named promotion path to a kb-entry-gate v2 skill) and G39 (role/access state is admin-only, changed via host commits — closes the meeting-flagged risk that a user could email K-ai to override another’s role; ⚠ convention-only against in-band instruction for now). Stakeholder view text (kb-works, bot-guide) lands with the ingestion of Amber’s canonical 6/12 meeting notes (expected weekend of 2026-06-13); playbook mirror requested via _agent-inbox/2026-06-12-monday-alert-golive.md.
• v2 — 2026-06-10 (R2/R7). Added G36 (send_email invocation gate: main group or run-scoped host-granted capability token for the weekly outreach task — closes the 2026-04-13 “send_email unavailable” failure class without opening email to all scheduled tasks) and G37 (kb-entry-gate on ACTION_ITEMS / OPEN_QUESTIONS appends + owner-header canonicalization — closes the L2 gap “ACTION_ITEMS / OPEN_QUESTIONS ungated”). The change protocol’s “KB Write Protocol exact-heading” consumer constraint is now monitored, not just convention-guarded: nanoclaw src/exceptions-report.ts asserts the heading from the read mirror and surfaces a regression in the weekly digest (G30).
• v1 — 2026-06-10. Initial harvest: 35 rules from CLAUDE.md (KB Write Protocol, conventions), the K-ai playbook (guardrails, commit rules, freshness), nanoclaw channel/sensor/IPC code, and the kb-conflict-check skill. Tier ⚠ on G11 (curriculum.md guardrail — convention-only, violated historically; hardening decision pending, review R11). Evaluated-by is populated only where nanoclaw unit tests exist today; empty cells are the evaluation team’s starter backlog.