LIFE Company Knowledge Base

The Knowledge Base is a controlled door in front of LIFE's company knowledge: every read and write goes through one service that checks who you are, what your AI tool is allowed to see, and whether the content needs human review before publication.

What's broken today

• Knowledge is fragmented. Decisions, processes, and context live in different tools. New hires can't find things; AI assistants can't either.
• AI access is all-or-nothing. If we point Claude Code at our Notion, it sees everything an admin sees. There's no per-document gate, no audit, no way to keep HR or finance material out of certain workflows.
• We don't know who read what. Notion's audit is limited. We can't prove that confidential material wasn't accessed by an AI tool we didn't intend.
• No review on AI-generated content. If an agent writes a doc and saves it, there's no checkpoint. For decision records or sensitive material, that's a problem.

Why not just use Notion / Confluence / Slack search?

We considered it. None of them give us per-document AI-client gating, the audit trail we want, or the ability to require human review before AI-drafted content becomes canonical. Building a small, focused service of our own is cheaper and faster than retrofitting any of those — and it sits naturally alongside the LIFE app's existing infrastructure.

Every protected read and write passes through one place. That makes access control testable, audit trustworthy, and the system small enough for AI coding agents to build correctly.

The five non-negotiables

• Authentication is Google Workspace. No KB-specific passwords. MFA is enforced through Google. If your Google account is disabled, your KB access ends within 5 minutes.
• Group membership is the access boundary. Confidential content is gated by Google groups — leadership, finance, people, legal, security. Group resolution failure denies access; we never default-allow.
• AI clients are pre-registered with a maximum sensitivity. Claude Code can be approved for confidential; Codex for internal only. The KB service decides what to send each client based on its registration, not what the client claims about itself.
• Approval binds to an exact version hash. If a reviewer approves "version A" and someone tries to publish "version B", the approval doesn't carry. This stops a class of "switch the document after review" attacks.
• Every protected access leaves an audit trail. Reads, denials, searches, publishes, approvals, AI-tool runs — all recorded in append-only logs. The logs never contain document body text.

What "fail closed" means here

If the KB service can't reach Google to verify your group membership, it denies access. If the access policy file fails to load on startup, the service refuses all reads and writes and pages an operator. If a database row has missing or invalid metadata, it's treated as inaccessible. We never default to "allow" when something is unclear. This is a cheap rule that prevents most accidental data leaks.

What we still need to be careful about

The biggest residual risk is operational: backups, key management, and the "break-glass" procedure when a security admin needs to investigate something. These are documented as runbooks (with two-admin approval for sensitive reads) rather than automated UI, because automating rare emergency procedures is itself a risk.

Each deferred item has its own security model to design (Slack permissions, Jira workflows, web-fetch sandboxing). Trying to ship them all in v1 was the original spec's biggest risk. By cutting them, we get a working KB in roughly half the time, and we get to design each integration on top of a proven base.

What the agents can and can't do

• Build to spec. Schemas, authorization functions, search queries, validation rules are all explicitly defined.
• Run tests. Every authorization rule has a corresponding test in the spec's "Definition of Done." Agents can't merge code that fails an authorization-matrix or search-leakage test.
• Cannot invent access rules. The spec explicitly forbids agents from adding new sensitivity levels, new policy modes, or new local-cache behavior without human approval.
• Cannot bypass the single authorization function. Search must call the same gate as reads. The spec calls this out as a tested invariant.
• Cannot see production secrets or restricted content during development. They build against a synthetic dataset.

Why this is workable

The system is small enough — five components, one access control function, one search query — that a coding agent can hold the whole shape in context. The two independent expert reviews specifically tested whether the spec could be safely built by AI agents; both said yes after the v0.4 fixes.

Supabase Pro provides managed Postgres with the PITR + encrypted backup story v1 needs at a fraction of the cost of Cloud SQL. Cloudflare R2 is S3-compatible with the same security primitives as GCS, but charges nothing for egress — meaningful since every artifact read goes through the KB service. Running the worker queue inside Postgres (pg_boss) eliminates an entire service. Cloud Run's free tier comfortably covers a small-team internal KB.

Nothing in this stack ties us to a vendor. Postgres is portable; R2 is S3-compatible; Cloud Run is just a container — the same image runs on Fly.io, Railway, or any container host. Migration cost is low if any of these prices change.

Anthropic Enterprise zero-retention is already paid for the LIFE app; KB usage adds a small overhead (classification proposals, draft generation) — likely under $30/month additional. Other providers are optional. Restricted content uses local-only models (no per-request cost).

LIFE is at the size where company knowledge is starting to fragment, and where AI tools (Claude Code, Codex) are becoming a real part of how work gets done. Without a controlled door in front of company knowledge, we either give AI tools too much access or we keep them isolated from the context they need.

The v1 we're proposing is small, focused, and reversible. It uses tools we already pay for (Google Workspace, Postgres). It ships in 4–8 weeks. It establishes the access patterns that Slack, Jira, and richer integrations will plug into later — and it does so with a security posture that survived two independent expert reviews.

The alternative — keep using Notion for everything, give AI tools blanket access, hope nothing leaks — is cheaper in the short term and worse in every other way.