MSBAi · K-ai · Internal Review

How the knowledge base defends itself — and where it doesn't

A governance review of K-ai's entry gates, triggered by one real miss: on July 28 the agent surfaced "onboard three faculty to K-ai" as an open gap when all three had been onboarded for weeks.

Date 2026-07-29 Method live probes against the production files, not code reading Registry program/kb-governance.md (G1–G55) Status fix pre-authorized by G38; spec planned

Verdict in one sentence: the write path is guarded but only lexically, the read path is guarded by age but not by premise, and semantic review exists only for the decisions file — so a reworded duplicate, or an item the world has already satisfied, passes every control the system has.

None of this was hidden. The governance registry itself anticipated the failure and pre-authorized the fix: rule G38 was logged as convention-tier deliberately, with the instruction to "promote to a kb-entry-gate v2 skill if the monthly review shows leaks." This review is that leak evidence.

The mechanism, in four layers

K-ai maintains an organizational knowledge base (decisions, action items, open questions, curriculum state) fed by email and chat from a 28-person allowlisted team. Around every write and every outbound message sit four layers of control. Each layer lists its strongest rules and its measured blind spot.

1 · Write gates fires when the agent appends to the KB

G1/G47 — every decision entry passes a skeptical-reviewer subagent (semantic review) plus a cross-check against the operational files that would have to change if the fact were true. G37 — action items and open questions pass a duplicate/contradiction script. G55 — every open question is date-stamped by the gate so it can age.

Blind spot: the G37 script is token matching, not judgment. It opens only the file being written to — zero references to the decisions file or KB state. A paraphrased duplicate passes clean.

2 · Read-path monitors fires on a schedule, against the whole repo

Weekly lint (Wed): fact contradictions across files, overdue items, aging questions, broken links, orphaned decisions. Weekly exceptions digest (Mon, G30/G55): the single escalation surface — questions crossing 14 days, sensor flag counts, integrity failures. Owner nudges (Mon).

Blind spot: every monitor tests how old an item is or whether files contradict each other. None tests whether an open item's premise still holds against current KB state — and none runs at the moment the agent surfaces an item in a live reply. The July 28 item would have been flagged ">4 weeks old," never "already done."

3 · Outbound verification fires on every message the agent sends

G23 — host-side audit log the agent cannot skip. G24–G26 — a behaviour sensor fact-checks every reply against ground truth and writes pass/flag/fail inline; fails become triage files. G51 — claims about system state ("gate ran clean," commit hashes) must have a machine-logged counterpart; unverifiable self-reports are flagged. G46 — delivery-integrity gate: no scaffolding leaks, no silently partial sends.

Blind spot: the sensor checks facts the reply asserts; it does not currently check whether a gap the reply raises is still a gap.

4 · Change control on the mechanism itself fires when someone changes the rules

G39/G52/G53 — role and access changes are admin-only host commits; agents get compose/propose authority at most; agent-filed tickets are untrusted proposals (G54). G43 — CI fails the deploy on unregistered structural drift. G48 — any automation credited with closing a control loop must enter the registry with a named owner, or be replaced by a designed invariant. Every rule row names its enforcement tier: code, skill, or convention.

This layer worked as designed — including this week, when the registry's own escalation clause (G38) turned an incident into a pre-authorized upgrade rather than an ad-hoc patch.

Two journeys through the gates

The registry is a table of ~45 rules; nobody thinks in tables. The rules become legible when arranged by the two events that trigger them — a message arriving, and the agent writing to the KB. (A full all-rules graph was considered and rejected: at this count it's a hairball. Event-triggered pipelines are the honest decomposition, and they mirror the registry's own section structure.)

Life of an inbound email

Sender checked against the allowlist
G17 · fail-closed
Unknown UIUC sender → one courtesy reply; external → silent drop
Loop guard & rate cap
G20 · G19
Auto-replies dropped before any agent spawns; 10 turns/24h per sender
Agent reads, composes — never sends
G36 · G53
No send capability exists inside the container; host sends after gates
Outbound authorization & integrity
G42 · G22 · G46
Tiered authorization; recipients re-checked; scaffolding leaks blocked; partial fan-out fails loud
Logged, then fact-checked after the fact
G23 · G24–G26 · G51
Audit log the agent can't skip; sensor writes pass/flag/fail; self-claims need machine counterparts

Life of a KB write

Which file is this?
G11–G14 · G39
Curriculum, presentations, role/access state: agent may not touch — flag for human
Decision entries: semantic review
G1 · G47 · G8
Skeptical-reviewer subagent + incumbent cross-check; conflicts hold for humans, never auto-resolve
Tracking entries: lexical gate
G37 · G55
Token-overlap duplicate check + date stamp. This is the layer v2 upgrades to judgment
Cross-references & provenance in the same commit
G7 · G4 · G9 · G31
Every entry carries source, date, confidence, category; fixed commit identity
Watched forever after
Wed lint · Mon digest (G30)
Contradictions and aging — premise validity is the gap the fix adds here

What we probed, and what happened

Four proposals were run through the live entry gate against the production tracking files on July 29. Two passes, two misses — and the misses are the structurally interesting ones.

Near-verbatim duplicate of an open question Blocked

Control case. Token overlap catches copies. The gate works for what it was built for.

Same question, reworded Passed clean

An existing open item, rephrased in different words with almost no shared vocabulary, sailed through. Paraphrase defeats the gate — and paraphrase is the normal case when items arrive through different people's emails. (The specific probe pair is in the session record; it's omitted here because this page circulates.)

Re-proposing the already-closed onboarding item Blocked

The July 28 incident item, if re-appended today, is caught. The bug was never on the write path — the agent surfaced an existing stale item; it didn't write a new one.

"Onboard Kate + Myranda" — both already onboarded Passed clean

The fact that makes this item redundant lives in the allowlist file, which no entry gate ever opens. Redundancy usually lives in the KB, not in the tracking file being appended to.

One probe initially looked like cross-file coverage: a question already settled in the decisions file was blocked. Tracing the match showed it hit a resolved twin at line 435 of the same file — coincidence, not coverage. Worth recording because it is exactly how a governance review overestimates its mechanism: a good outcome from the wrong cause.

The diagnosis

Three asymmetries explain both misses:

The fix was already authorized

"Convention-tier deliberately (per 2026-06-12 plan-and-test meeting: teach-by-example, monthly review); promote to a kb-entry-gate v2 skill if the monthly review shows leaks." — program/kb-governance.md, rule G38, written six weeks before the leak it anticipated

The planned change, in registry terms:

ChangeWhat it doesEnforcement tier
Entry gate v2 (amends G37) Keep the token match as a candidate pre-filter; hand the verdict to an LLM subagent that checks the proposal against the sibling tracking file, the decisions file, and retrieved KB state — three axes: redundant / already-satisfied / conflicting. Blocks must cite file + line; ambiguity defaults to allow. skill
Premise-validity lint check (extends the Wed lint, per G30) The existing weekly lint gains one check: for each open item, does its premise still hold against current KB state? Reuses an existing surface — no new monitor, no new report to maintain. convention → scheduled prompt
Surfacing-time check (new, closes the actual incident) Before the agent presents an existing open item as a gap or next action, re-validate its premise. Backed post-hoc by a deterministic behaviour-sensor case: an onboarding-gap claim naming someone already in the allowlist file flags. convention + code (sensor)

Two constraints shaped the design. Metering: container subagents bill the flat subscription, so semantic judgment is effectively free there — but the behaviour sensor calls the metered API directly, so its new check stays deterministic. Honesty about tiers: per the registry's own enforcement hierarchy, a prose rule alone is the weakest control and known to be skipped under context pressure; that is why every element above lands in a script, a scheduled prompt, or the sensor — not in another paragraph of instructions.

Should this review recur on a schedule?

Recommendation: no standing cadence — derive on demand, and snapshot on events. The registry, the governance changelog, and the auto-generated /updates page already track every change to the mechanism continuously; a scheduled report would be a second copy of derivable state and one more thing to maintain (the program's standing rule: net-new-things-to-track should be zero). What a calendar cannot supply is the trigger that makes a review worth reading — an incident, a structural change, a tier promotion like this one. Those events should each produce a dated artifact like this document, exactly as the July harness review did. The existing quarterly control-inventory review (G48) is the natural place to notice that too long has passed without one.

A note for the research thread

Two observations from this episode may be of interest to the jpim26 study of AI governance-in-practice: