Knowledge base

Shipped

The knowledge base is your instance’s living memory of how the business actually runs — processes, approval rules, thresholds, conventions, and how your team uses each connected source. It is a tree of markdown pages at /knowledge-base, organised process-first rather than system-first, and it feeds Pilot, your AI assistant: when someone asks “what’s our month-end process”, Pilot answers from these pages.

Editors and readers

What you see at /knowledge-base depends on whether you hold the write:document capability (administrators hold it implicitly — see Users and permissions):

• Editors see the full live tree, drafts included, and can create, edit, move, publish, and delete pages.
• Everyone else sees the current published release — a snapshot, never the live drafts. Nobody gets a 403; readers of an instance with nothing published yet simply see an empty state.

Any member can comment on the pages they can see; threads anchor to a text selection and can be resolved. A new comment emails the page’s editors and the other people on the thread, so a question doesn’t sit unseen.

While a page has unpublished work, it belongs to the editor who started it — others see “in progress by” and are blocked from overwriting. The owner (or an admin) can discard the draft, resetting the page to what readers currently see.

Editors can also import a folder of markdown at once: each file lands as a draft page under a parent you choose, so you can seed the tree from existing docs in one step. Imports are per-file — a bad file is reported and skipped rather than failing the whole batch.

Publishing and releases

Publishing is what moves content from the editors’ tree to readers. Publishing a page makes it reader-visible and cuts a new immutable release snapshotting the whole published tree — so it also captures any other pages with pending edits, which the per-page “Unpublished” state makes visible beforehand. Unpublishing works the same way in reverse.

Administrators additionally get the release history panel: every version with its changelog (pages added, edited, removed), rollback to an earlier release, and export of a release — or the full live tree — to a single self-contained HTML file.

Sharing pages outside your team

The knowledge base is for people with an account on your instance. There is no external-guest access: sharing a page means giving someone a seat, or exporting what you want them to have.

Administrators can export a release — or the full live tree — to a single self-contained HTML file (see Publishing and releases above) and send that. It is a snapshot, so it does not update when the page does, and it carries no session, no code and no link back into the instance.

House standards

Requirements documents, SOPs and house rules you upload for the whole instance land here as pages under a House standards node. You add them from the Standards icon in the Proposals header — see Development → Standards for the fuller picture of how they fit the proposal pipeline.

They are drafts when they land, like every other page here, and they ground proposal drafting once published — so a document nobody has reviewed is not quietly steering every proposal, and publishing one is what puts it into effect. Being KB pages, they are also retrieved rather than injected: a standard grounds a proposal when the proposal is about it. If you need a rule that holds every time regardless of the subject, that is a skill, not a standard — see Knowledge base or skills? below.

Knowledge base or skills?

The knowledge base is retrieved: when someone asks a question, the most related pages are pulled in. That is right for how your business works — processes, thresholds, conventions — and wrong for a rule that has to hold every time, because a page only applies when the question lands near it.

For those, use agent skills, which are injected into every relevant answer whether or not the question mentions them. The test: would the AI get this wrong if nobody reminded it? Then it belongs in a skill.

Related

• Agent skills — standing rules injected into every answer
• Development → Standards — the Standards library in the Proposals header, and where House standards pages come from
• Pilot — answers “how do we do X” from published pages
• Users and permissions — capabilities, including write:document
• Connect Claude Code — how app developers feed what they learned back here, as unpublished draft pages an editor reviews (turbobase kb push)