knowledge bank as a pluggable shared context service.

# SUB-018 — Knowledge Bank as a pluggable shared context service

> Paste SUB-018 to context-shift here. From the 2026-06-02 Sett OS session. The SUB-016 §2 "public/shared library other Claudes plug into" ambition, made its own subject.

Name decision

The data bank / knowledge bank / brain is now called the Knowledge Bank (Ishai, 2026-06-02). Resolves the open naming question across the Sett OS docs.

The concept

The Knowledge Bank should be something you plug into, not something you download. A live, pluggable shared context source:

• Any employee connects to it from their own Claude Code (or their own AI tool), from anywhere.
• They use it as context , instant project understanding, the company's shared brain.
• Not a file you clone + that goes stale; a live endpoint that reflects the current verified state.

This is the "plug into my Claude's brain" idea from SUB-016 §2: Ishai does a lot of research + discovery, and that context is valuable to the whole company. Rather than re-explaining, others' AIs consume the bank directly.

Why it matters

• Turns Ishai's personal vault into a company resource (SUB-010 Phase 2 graduation, made concrete).
• Eliminates the re-explanation tax: a teammate's Claude already knows the product, the decisions, the values.
• Live, not a snapshot , no sync drift, no stale downloads.

The hard dependency: verification gates it

A public/shared bank is only safe if gated by the trust layer (see _tech-databank-schema.md, CLAUDE.md verified-facts rule). SUB-016: "any idiot can add unrelated content." So:

• Only verified content is exposed to the shared/pluggable layer (per the existing rule: only certified items are pushable to the Shared overlay).
• Floating content stays private to Ishai's vault until reviewed.
• You can see who wrote/verified what , trust is attributable.
• Likely two layers (SUB-016): a shared/general bank (leadership-approved, verified) + each person's private vault that can override the shared view for exploration.

So SUB-018 (pluggable) literally cannot ship before the trust layer is real. Verification is the prerequisite, not a nice-to-have.

How it could work (early , to develop)

• Mechanism: expose the verified slice of the vault as an MCP server / endpoint that any Claude Code instance can add as a context source. (Markdown vault stays the source of truth; the endpoint serves a read view of the verified layer.)
• Auth: company-gated; read access for employees. Write/contribution = proposal → review → verify (SUB-010 contribution model).
• Scope of exposure: Shared overlay only (verified + non-private). Private overlay never exposed.
• Ties to: the deploy/host question (the bank must live somewhere reachable, like the Studio cloud-action gap but for read-context).

Open threads

• Mechanism: MCP server vs hosted API vs git-based shared repo , what does "plug in from your own Claude Code" actually require?
• Auth + access model (who reads, who proposes, who verifies).
• Shared vs private split , how the two layers (general + personal) coexist + override.
• Hosting: where the verified read-view lives so it's reachable from anywhere.
• Contribution flow for other people's input (proposal → review → verify), reuse SUB-010.
• Privacy guarantee: private overlay provably never leaks to the shared endpoint.

Raw refs

• concept: SUB-016 §2 (single source of truth, shared/public library, "plug into my Claude's brain") + §2 Certified.
• trust layer: vault/08-Design-specs/studio/_tech-databank-schema.md, CLAUDE.md "VERIFIED FACTS" rule.
• graduation strategy: SUB-010 Phase 2 (company knowledge base).

Last activity

2026-06-02 23:24 — Subject created. Seed. Name "Knowledge Bank" locked. Verification is the hard prerequisite.