Governed knowledge for teams, customers and AI agents.

Who it’s for

One codebase, deployed as two isolated cells.

Access for AI agents, including MyBotBox agents reading approved, permission-checked knowledge through an API and an MCP server, is planned for Phase 3. It does not exist yet.

Built in Phase 1

These work in the product today and are covered by its tests. They are not yet deployed for anyone to use.

• Membership and roles

  Firebase identity, with membership-based access per tenant. Roles: owner, admin, editor, commenter and viewer.

• Tenant isolation

  Postgres row-level security on every tenant table, so one customer can never read another customer’s data. This is covered by tests.

• Spaces

  Confluence-style spaces with keys such as ENG. A space is visible to all members, or restricted to people with an explicit grant.

• Pages and editor

  Nested page trees and a rich editor: headings, lists, tables, code blocks with syntax highlighting, callouts (info, warning, danger, success) and safe links. Markdown import and export, including GitHub-style callouts.

• Revision history

  Every save creates a revision. Conflict-safe saves never silently overwrite someone else’s change. Restoring an old version creates a new revision, so history is never rewritten.

• Review lifecycle

  Draft, review, approved, published and archived. Approval pins the exact revision that was reviewed.

• Permission-aware search

  Full-text search over titles and content. Restricted pages never appear for people who don’t have access to them.

• Customer portals

  Several portals per organization (for example help, engineering or partners), each with its own audience and allowed content classifications. Pages are published as approved snapshots, so later edits never leak to the public.

• Custom domains

  Domains are verified with a DNS TXT record plus a CNAME. Verification can be re-checked, and a domain is suspended if the check fails. Unknown or unverified hostnames return 404.

• Audit log

  Every change is recorded in an append-only audit log.

• Two isolated cells

  One codebase, deployed as an internal cell and an external cell on Cloud Run or Kubernetes. The Terraform for both cells is written but not yet applied.

How to use KnowledgeOS

The Phase 1 flow as built, from first sign-in to a published portal page. It isn’t open for use yet.

1. 1

   Step 1: Sign in

   Access is membership-based: what you can see and do depends on your role in the tenant (owner, admin, editor, commenter or viewer).

2. 2

   Step 2: Create a space

   Give it a name and a key (for example ENG), then choose who can see it: all members, or restricted to explicit grants.

3. 3

   Step 3: Write pages

   Create pages and subpages, write in the editor and save. Every save becomes a new revision.

4. 4

   Step 4: Use history

   Open a page’s history to view any older version, or restore it. A restore adds a new revision on top.

5. 5

   Step 5: Review and approve

   Submit a page for review. An editor or admin approves it, which pins the revision they reviewed.

6. 6

   Step 6: Publish to a portal (admins)

   Create a portal and bind a custom domain. Add a DNS TXT record _kos-challenge.<host> with the value kos-verify=<token>, and a CNAME to your tenant’s KnowledgeOS host. Verify the domain, then publish approved pages to a path on the portal.

7. 7

   Step 7: Search

   Search from the sidebar. Results only include pages you are allowed to read.