How the MSBAi Knowledge Base Works

A plain-language overview of how the program tracks decisions, action items, and open questions — and how the K-ai assistant helps maintain it. Written for stakeholders who don’t need the technical details but should understand what the system does, what it doesn’t do, and how to participate.

What this is, in one paragraph

The MSBAi program runs on a shared knowledge base — a structured collection of Markdown files in a private repository. It records every decision the team makes, every open question, every action item, and the source material those came from. K-ai (the program’s AI assistant) reads from and writes to this knowledge base on the team’s behalf, so that when someone asks “what did we decide about X?” the answer is one search away rather than buried in an email thread.

The knowledge base is the source of truth. K-ai is the interface to it.

What’s in the knowledge base

The repository (msba-online) is organized into a few top-level folders:

Within discussions/ are three files that do most of the day-to-day work:

• DECISIONS.md — every confirmed decision, dated, with the people involved, the rationale, and a link back to where it came from.
• ACTION_ITEMS.md — open work, organized by owner. Checked off when complete.
• OPEN_QUESTIONS.md — questions waiting for answers. Resolved questions move to DECISIONS.md.

These three files are deliberately separate but kept in sync. When something changes in one, related entries in the others should be updated in the same change.

How entries are organized

Two simple axes:

Which file an entry lives in tells you what kind of thing it is. A decision goes in DECISIONS.md, an action item in ACTION_ITEMS.md, an open question in OPEN_QUESTIONS.md. No tag needed for that — the file is the type.

Each new decision also gets a topic tag. Seven topics cover the program’s surface area:

Entries also carry optional Risks: and Dependencies: fields when relevant — for surfacing items that block launch, onboarding, or stakeholder commitments.

If an item could fit two tags, K-ai picks the one a stakeholder would most likely filter by. New tags aren’t invented on the fly — gaps surface to Vishal as a taxonomy question.

How information arrives

Stakeholders can reach K-ai through any of five channels — same knowledge base behind each:

Whichever channel you use, K-ai sees the same repository and writes to the same files. It will mention the channel name in the audit log so you can later see how something arrived.

What K-ai does with each message

Every incoming message gets sorted into one of three modes:

Mode 1 — You’re sharing information. A meeting decision, a status update, a confirmation. K-ai extracts the decisions, adds them to DECISIONS.md, files action items under the right owner, updates any open questions that are now resolved, and replies with a summary of what was captured. Each logical change is its own commit, so the history shows exactly what was added and when.

Mode 2 — You’re asking a question. K-ai searches the knowledge base, composes a cited answer (with file references so you can verify), and replies. No changes are made.

Mode 3 — Scheduled review. Once a week, K-ai scans the action item list, identifies items that look stalled, and sends gentle nudges to the responsible owner.

How the knowledge base stays trustworthy

A knowledge base is only useful if you can trust what’s in it. A few conventions keep it honest:

1. Every decision links back to its source. Each entry in DECISIONS.md carries a Source: line pointing to the email, meeting, or message it came from. If you ever wonder “why did we decide this?”, the trail is one click away.

2. New entries carry a provenance line. As of late April 2026, every new decision includes a metadata line stating who said it, when, the channel it came through, and a confidence rating (high / medium / low). High = stated explicitly by an authoritative voice. Low = inferred from indirect signals; treat with care.

3. Decisions can be superseded, not overwritten. When a new decision contradicts an older one, the old entry is marked Superseded — see [new entry] and stays in the file. The history is preserved. Nothing silently disappears.

4. Knowing-overrides are explicit. When someone deliberately reverses a prior decision (for example, “we’re moving the deadline from June 4 to July 4 — this supersedes the prior choice”), they signal it with the phrase lore: intentional in the change description. This is the difference between a typo and a real reversal.

5. Cross-file consistency. When K-ai updates DECISIONS.md, it checks ACTION_ITEMS.md and OPEN_QUESTIONS.md for related entries and updates them in the same change. Resolved questions don’t linger; closed actions don’t show up as open.

6. A separate audit log captures every conversation. Each message in and reply out is logged in discussions/audit-log/ with timestamps, channel, and message content. Useful for retracing how a particular decision was reached, and for spot-checking K-ai’s behavior.

7. Outbound replies pass a delivery-integrity gate. Since 2026-07-17, every email K-ai sends passes a hard reply gate before it leaves: a reply that is missing, empty, or contains internal working notes instead of a real answer is refused and retried, and if it still can’t produce a clean reply, nothing is sent — the failure is dead-lettered and the admin is alerted. A malformed reply never reaches your inbox.

8. Facts from external documents are cross-checked before they’re recorded. Since 2026-07-17, when K-ai ingests facts from an external document (a spreadsheet, meeting notes), it checks them against what the course and program files already say — not just the decision registry. A mismatch routes to human triage and the submitter is asked to confirm; a fact that exists only in a single spreadsheet cell, with nothing else corroborating it, is recorded at low confidence.

9. Every change is visible on a live “what changed” page. The /updates page is generated automatically from the version history on each deploy — never hand-written — and each page links to the changes that affected it. Because it’s derived straight from git, it can’t be selectively edited or faked: if something changed, it shows up there. (Behind the scenes, each knowledge file also carries a one-word type: label — course, policy, reference, etc. — so K-ai can find and weigh the right files quickly; a build-time check keeps that labelling consistent and blocks undocumented structural changes from shipping.)

10. New action items and open questions pass a redundancy gate before they’re recorded. Since 2026-07-29, before K-ai appends a new tracking entry it checks — with a second AI reviewer, not just text matching — whether the item is already tracked somewhere (even reworded), already satisfied by the current state of the program (say, an “onboard this person” item when they already have access), or in conflict with a recorded decision. A block must cite the exact file and line it’s based on; conflicts go to a human, never auto-resolved. A weekly sweep also lists open items whose premise the world has since overtaken.

See the mechanism for yourself: the July 2026 governance review explains all of these controls in one page — how they layer, what was tested, and what was fixed. The companion gate simulator is interactive: type a message, watch it travel the same pipeline your emails do, and toggle the old vs. new redundancy gate to see the difference.

K-ai’s private working memory

Alongside the shared knowledge base, K-ai keeps a small private “working memory” per user (since 2026-07-17): active conversation threads, tentative positions, things discussed but not yet decided. It lives on K-ai’s own server — never in the shared knowledge base — is admin-only for now, and auto-expires after about two weeks. If it ever disagrees with the knowledge base, the knowledge base wins. Per-student working memory is deliberately blocked until the program’s privacy decision is made.

What the system deliberately does not do

• It does not auto-resolve contradictions. If a new piece of information conflicts with the existing record in a way that isn’t obviously a supersede, K-ai flags the conflict for human review rather than picking a side.
• It does not act on instructions from non-allowlisted senders. The allowlist (the senders listed in program/EMAIL_ALLOWLIST.md) gates write access. A non-allowlisted @illinois.edu sender gets a single courteous “access is closed” reply; senders from outside the university are dropped silently, with no reply at all.
• It does not delete history. Decisions are superseded, never erased. Action items are checked off, not removed.
• It does not make program decisions. K-ai records what humans decide. It doesn’t propose new policy or commit the program to anything.
• It does not replace meetings or deliberation. It captures the output, not the process.

How to participate

To submit a decision or update: Send an email to msbai@illinihunt.org from your authorized address. Be specific about what was decided and who agreed. K-ai will record it and reply with a summary you can verify.

To ask a question: Same channel. K-ai will search the knowledge base and cite the relevant files in its reply.

To correct something K-ai got wrong: Reply to the original thread, or send a new message saying “this corrects the entry from [date]”. Use the phrase lore: intentional if you’re knowingly overriding an earlier decision — that signals a deliberate reversal vs. a routine update.

To browse the knowledge base directly: It’s at msba-online.pages.dev (password-protected). The discussions/ folder is excluded from the public site to keep working notes private — ask Vishal for repo access if you need it.

Open questions and what’s next

This system is in its second-stage pilot (April 2026, nine-person group). What we’re still working out:

• Coverage of the automated conflict gate. As of 2026-04-28, every K-ai write to DECISIONS.md passes through the kb-conflict-check skill — a separate skeptical-reviewer subagent runs against the top 5 related entries and either lets the commit through ([conflict-check: clean]) or routes the entry to discussions/kb-triage/ for human review. The convention/weekly-review fallback still backs it up for edge cases.
• Promise verification. Live as of 2026-04-28 — Step 5 of the Monday-morning weekly FDE scan. Aging unchecked action items get classified [LIKELY DONE], [POSSIBLY STALLED], or [BLOCKED] based on git log evidence and cross-references. Humans confirm closure; nothing auto-closes.

  Coverage gaps

Not every change arrives through K-ai — Vishal also commits directly from his own machine. Those direct host/terminal commits appear in the audit log as synthetic entries, written automatically when the change lands, so the log stays complete even for changes K-ai never touched (that is what rule G28 governs). Direct edits made through the GitHub web interface still bypass the conventions; those are rare, and if they become common we’ll add a server-side check.

Feedback from the pilot group shapes what gets built next. If something is awkward or unclear, say so — the goal is a record that helps the team, not one that adds friction.

Last updated: 2026-07-17. This page is a derived view of program/kb-governance.md (the canonical registry of every governance rule, its enforcement tier, and where it’s implemented — internal, not on this site) and is maintained alongside CLAUDE.md (the agent operating manual). Verified against registry v9 (2026-07-17). For the technical architecture, see reference/ and the nanoclaw-msbai repository.