How to build shared company knowledge for AI
Contents
Design the first useful answer
Source, identity, retrieval and updates
“Build us a company brain” leaves too much unspecified. A more useful starting point is a recurring question, its authoritative source and the people allowed to receive the answer. The design below follows one question all the way through. It is an architecture example, not a tested HeyBrain setup tutorial.
Choose an answer with a visible boundary
In our fictional company, the support team repeatedly asks which troubleshooting steps are approved for an export timeout. The first system will answer from published support guides. It will not search customer tickets, unreleased engineering notes or private messages, and it will not send replies or change accounts.
Guide G12 revision 3 says: check the status page, retry once, then open an internal incident if the timeout persists. A draft revision 4 adds an unapproved workaround. The design must return revision 3, cite it and leave the draft out. That is much easier to evaluate than “understands our company.”
Choose how the source reaches the answer
A direct source lookup can obtain current content when the source is available and the request is authorized. An imported index can improve search over selected material, but introduces synchronization, storage and removal work. Neither label establishes correctness or permission handling.
For this example, choose an index of published support guides because the first workflow needs search over that collection. Keep the source identifier, revision and publication status with each indexed item. The source remains authoritative; the index is a derived representation that can fall behind.
Do not import the draft collection and hope the prompt ignores it. The ingestion boundary should exclude it. If the selected tool cannot isolate the approved collection, this design is not implemented yet.
Put identity on the retrieval path
The application must establish the requester and apply the intended grants before supplying evidence to the model. Signing in is not the whole decision: NIST’s Zero Trust Architecture distinguishes authentication from authorization.
Here, support member Rae may retrieve G12; an account outside support may not retrieve this internal collection. The same distinction must hold when opening the cited source. If another client or agent is added, establish its effective identity and scope explicitly rather than assuming the browser’s rules carry over.
Trace the completed design
This is a fictional design record. The right column states the intended behavior, not observations from running software.
| Step | Input or boundary | Intended result |
|---|---|---|
| Ingest | G12 revision 3, published; revision 4, draft. | Index revision 3 only, with its source reference. |
| Authorize | Rae is a support member. | Search the approved support collection. |
| Retrieve and answer | Question: what should I do after an export timeout? | Return the three approved steps and cite G12 revision 3. |
| Handle missing evidence | Question asks whether to apply the draft workaround. | Say the approved sources do not establish that instruction. |
| Open the source | Rae follows the G12 citation. | Apply the source access rule; do not turn the link into a bypass. |
Design the update path before widening access
When revision 4 is approved, the source owner changes its status and the import process replaces the active evidence. Define how the application detects a failed or delayed update. A fresh-looking answer drawn from yesterday’s index is still stale.
For a withdrawn guide, stop treating its indexed copy as current evidence. Separately identify retained conversations, operational records and backups. Removing a search result does not establish deletion everywhere. Logs can help investigate the listed requests, but cannot prove that no information ever escaped.
Acceptance should include allowed and denied reads, source links, a published revision change and a withdrawal. The five-check permission example adds concrete access fixtures; it does not replace the answer-quality and freshness checks above.
What is ready at the end of this exercise?
The team now has a buildable boundary: one approved source set, one audience, a defined answer, a revision route and explicit failure behavior. The unresolved work is implementing those choices in the selected product and observing them through the real client. No production system has been configured by completing this design.
Start with read-only answers and assess whether they help. Write tools are a separate scope decision with separate failure consequences. The rollout handoff guide assigns the remaining work to source, technical and review owners.
Prepared by HeyBrain Editorial Team with AI assistance. Examples are fictional illustrations, not observed customer incidents or product tests. This correction retains the original publication date and corrects the earlier account. Primary sources were checked on 13 October 2026.
