Git-owned company knowledge

Git-owned company knowledge means durable truths live as versioned files (often Markdown or structured data) in repositories your team controls — reviewed like code, diffable, branchable, and exportable. It is a build-and-govern pattern for the company brain, not a religion that everything must be a repo.

Why git for knowledge

Wikis hide change. Chat evaporates. Git gives operators:

Diffs — Exact what changed between “policy A” and “policy B”
Review — PRs, CODEOWNERS, required checks before canonical merge
History — Blame and revert without archaeology
Portability — Clone, backup, migrate; reduce vendor lock-in
Automation — CI to lint frontmatter, check broken links, validate owners

For agent-readable memory, text in git is also easy to index, cite by commit, and pin to a SHA when you need reproducibility.

What belongs in git

Good candidates:

Decision records and ADRs
Playbooks and runbooks that change with the product
Canonical product/pricing explanations (when not solely in a CMS)
Agent-facing skill docs and tool contracts
Schemas for memory records

Poor candidates (link out instead):

Large binaries and raw dumps
Highly personal or ephemeral notes
Live transactional data (use systems of record)

Repo layout patterns

Keep it boring:

/records or /brain for canonical governed docs
Frontmatter: owner, last_verified, tags, sensitivity
CODEOWNERS mapped to teams
A DRAFT/ or branch workflow for promotion from tribal knowledge

Pair with a runtime company-brain product (Mensara or similar) when you need agent policy, access control, and search UX on top of the files — git is the source of truth; the product is the serving and governance plane.

Workflow

Propose — Branch + PR for material changes to canonical memory
Review — Owner approves; bots check metadata
Merge — Becomes the governed record; deploy/index hooks run
Verify — Calendar or CI reminds owners to re-verify stale docs
Retire — Tombstone or move outdated records; do not leave silent forks

Indexing and serving

Git is the source of truth; agents still need a serving layer. Typical pattern:

On merge to main, CI validates frontmatter and publishes to the company-brain index
Runtime retrieves by record ID and path, citing commit SHA when reproducibility matters
Draft branches stay out of production retrieval unless an explicit preview policy says otherwise

Without publish hooks, a beautiful repo is still invisible to agents. Without git (or equivalent versioning), a beautiful index drifts without review.

Collaboration norms

Treat knowledge PRs like small code PRs: tight diffs, clear why, linked sources. Prefer updating a canonical record over creating a near-duplicate page. When debate is unresolved, keep the decision record in proposed state rather than merging conflicting “truths.”

Pitfalls

Everything-in-monorepo sprawl — Split by domain when permissions differ.
No owners in metadata — Then git history is archaeology again.
Bypassing PRs via admin UI sync — Dual write without rules recreates wiki drift.
Secret leakage — Scan repos; keep sensitive memory in properly controlled stores with references from git when needed.

When not to force git

Non-technical teams may need a friendlier editor that exports to git, or a brain product that versions under the hood. The principle is versioned, reviewable ownership — git is the sharpest common tool, not the only UI.