Company Brain

/company-brain — Team-shared AI-ready knowledge base

Company Brain (n.): Your team's shared, AI-ready knowledge base — people, companies, meetings, SOPs, and decisions structured so Claude can answer questions on your team's behalf.

Team-scope sibling to second-brain (personal-scope). Same core compile → wiki → outputs pattern; different raw schema optimized for multi-author, sales-heavy, ops-heavy team use.

Also the operational backbone for the Company Brain Setup productized service (was previously called "Second Brain as a Service"; renamed to match the skill).

Mental model

Three layers, same as second-brain — but the raw/ layer is structured, not flat:

raw/          →  wiki/         →  outputs/
(structured      (compiled        (generated
 by category)     interlinked)     artifacts)

Structured raw/ dirs (each is its own top-level folder in the vault):

wiki/, outputs/, and INDEX.md work the same as second-brain.

Reserved dirs (never modified by company-brain): Projects/, Team/, Templates/, Drafts/.

Multi-author discipline

Every capture stamps:

source: <URL / call / email / manual entry>
author: <who added this — email or handle>
captured: YYYY-MM-DD
trust: unreviewed

Wiki pages track cumulative contributions in the ## Sources section (per source file, per author). No overwriting — always append + attribute.

Sensitivity tagging (optional but recommended):

sensitivity: internal        # any team member can read
sensitivity: leadership      # exec team only
sensitivity: confidential    # named list only (list access in the file)

Default: internal. Query mode respects sensitivity — refuses to include confidential content unless the invoker is on the access list.

Trust levels

The other half of multi-author discipline: not everything captured deserves equal weight as context. Every structured-raw file carries a trust: field.

(The field is named trust, not status, because companies/ and decisions/ already use status: for lifecycle — prospect/customer, decided/reversed — and the two must not collide.)

Deliberately an enum, not a numeric weight — teams keep a four-value field current; nobody maintains a 0–1 float.

Deprecation replaces deletion. The "never delete raw files" rule stays intact: when info turns out wrong or stale, mark it deprecated (or superseded with a pointer) instead of removing it. History is preserved; context is protected.

Trust is orthogonal to sensitivity — a file can be verified + confidential, or unreviewed + internal.

Existing vaults: files predating trust levels simply lack the trust: field — treat them as unreviewed. If the vault's schema doc (CLAUDE.md / AGENTS.md) predates trust levels, offer to add the trust spec to it on the first /cb review run (the vault's CLAUDE.md stays authoritative — extend it, don't override it).

Step 1 — Load vault config + schema

1. Read references/vault-config.md for the vault path (default: ${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/)
2. Read the vault's schema doc — <vault>/CLAUDE.md or <vault>/AGENTS.md, whichever exists (if both, read both) — for the authoritative team schema. If present, trust it over references/schema.md — the team's vault is the source of truth.
3. If neither exists, fall back to references/schema.md — the team schema starter kit.

Step 2 — Parse mode

Step 3 — Run the mode

capture

Same intake mechanics as second-brain, but the routing is different — pick the structured dir based on content type.

1. Detect content type + route to the right dir:

   • Call/meeting transcript → meetings/YYYY-MM-DD-<company-or-topic>-<slug>.md
   • Person's LinkedIn / bio / contact context → people/<name-slug>.md
   • Company profile / prospect / client → companies/<company-slug>.md
   • Documented process / how-we-do-X → sops/<team>-<process>.md
   • Decision made by leadership / team → decisions/YYYY-MM-DD-<decision-slug>.md
   • Verbatim customer quote → customer-language/<theme-slug>.md (append to existing themed file if one exists)
   • Question asked in a call → recurring-questions/<question-slug>.md (append counter if repeat)
   • Sales objection heard → sales-objections/<objection-slug>.md (append variant if repeat)
   • If ambiguous, ask.
   • If the target dir doesn't exist yet, create it with this capture. New vaults start with only one pilot workflow's dirs (see references/vault-config.md → "Start narrow").

2. Add multi-author metadata (top of file):

   source: <URL / call with X on YYYY-MM-DD / email from Y / etc.>
   author: <who captured this>
   captured: YYYY-MM-DD
   trust: unreviewed      # every capture starts unreviewed — review mode promotes it
   sensitivity: internal  # or leadership / confidential

3. Save + report file path + one-line summary.

Don't compile into the wiki here — capture is fast intake.

compile

Same core pattern as second-brain's compile mode — process unprocessed structured-raw files into wiki pages, update INDEX.md, add Sources sections.

Differences from second-brain:

• Multi-author attribution: Sources section includes author, not just filename

  ## Sources
  - `people/jane-doe.md` (added by @alex, 2026-06-30) — CTO of Acme, evaluated us Q2

• Cross-category compilation: a wiki page on "Acme Corp deal" might pull from companies/acme.md, meetings/2026-06-15-acme-discovery.md, sales-objections/acme-pricing.md, and people/jane-doe.md — all into one wiki page.
• Sensitivity inheritance: wiki pages inherit the highest sensitivity of any source. If any source is confidential, the wiki page is confidential.
• Trust filtering: deprecated and superseded sources are excluded from wiki pages. If a source that already fed a wiki page later gets deprecated, recompile flags the affected pages for re-review and drops the source, noting it in Sources using the file's reviewed + reviewed_by stamps: - meetings/2026-06-15-x.md (deprecated 2026-07-01 by @alex). Pages built mostly from unreviewed sources get a > ⚠ Mostly unreviewed sources callout at the top.
• INDEX.md categories for teams: Sales, Customers, Ops, Product, Team & People, Decisions, Playbooks. Extend as needed.

Everything else (one-page-per-concept, [[wikilinks]], Connections mandatory, quality > quantity) is identical.

query

Same as second-brain query, plus:

• Sensitivity check first: identify the invoker; refuse to include content above their sensitivity level.
• Trust rules: prefer verified over unreviewed, and recent over old. Never use deprecated or superseded content as context — at most cite it as a pointer: "(deprecated — see [[replacement]])". When two sources conflict, prefer the newer + higher-status one AND surface the disagreement in the answer.
• Confidence flag: if the answer leans mostly on unreviewed sources, say so up front: "Low confidence — 3 of 4 sources are unreviewed. Run /cb review to firm these up."
• Author-aware answers: when citing, include who contributed the info: "Per [[Acme Deal]] (source: meetings/2026-06-15-acme-discovery.md by @alex)..."
• Route external gaps to deep-research, same as second-brain.

Save to outputs/<YYYY-MM-DD>-<question-slug>.md with the answer + wiki pages consulted + sensitivity level of the output.

review

The human culling pass. This is how a team keeps garbage-in from becoming garbage-context: everything gets captured freely (nothing is lost), but only reviewed info earns full weight.

0. Sensitivity check first — same rule as query mode: identify the invoker and exclude files above their sensitivity level from the queue. Report the exclusion count: "3 items above your sensitivity level were skipped — someone on the leadership list needs to review those."

1. Build the triage queue:

   • All trust: unreviewed files across the structured-raw dirs (including files with no trust: field at all), newest first
   • Everything lint flags (checks 1–12; check 13 is about review itself)
   • Files whose review dates have lapsed, where those fields exist: decisions/ files past review_by, sops/ files past last_reviewed + review_cadence

2. Walk the queue one item at a time. For each file show: one-line summary, source, author, captured date, and which wiki pages cite it. Offer four dispositions — every disposition except skip stamps reviewed: YYYY-MM-DD + reviewed_by: <handle>:

   • verify → trust: verified
   • deprecate → trust: deprecated (wrong or obsolete; kept for history)
   • supersede → trust: superseded + superseded_by: [[target]] (ask for the replacement)
   • skip → leave as-is, resurfaces next review

3. Batch-apply the frontmatter updates — don't rewrite file bodies, only the metadata block.

4. Flag downstream effects: if a deprecated/superseded file feeds existing wiki pages, list those pages and offer to recompile them now.

5. Close with a summary: "12 reviewed: 8 verified, 3 deprecated, 1 superseded. 2 wiki pages recompiled. Next review suggested: <date>." Save the summary to outputs/<YYYY-MM-DD>-review.md so the cull itself has an audit trail.

Cadence: weekly for active vaults; pair with loopify to schedule it so the cull actually happens instead of depending on someone remembering. A vault where reviews lapse >1 month shows up in lint (check 13).