Build it with AI
Create a knowledge system that connects documents, decisions, workflows, and operating context.
Build interfaces for finding, organizing, and applying company knowledge instead of treating search as the end state.
Introduction
What a company knowledge system has to hold.
Most teams end up with a company knowledge system the same way: documentation across a wiki, a drive, and several people's heads. Shared drives work while the people who wrote the documents are still there to point at them. The failure arrives with turnover, when the knowledge exists and the index to it — which was a person — has left.
The wiki is comprehensive and out of date, so people ask a colleague instead and the wiki decays further. There is no signal about whether a document is current, no record of the decision a document justified, and no permission model that survives content being surfaced out of its original folder.
What follows covers building a company knowledge system: the records it holds (documents, owners, currency, the questions people actually ask, and the answers given), the systems it reads (Google Drive and Slack), and what it does not fix.
The problem
The answer exists, in a document, that nobody can find.
Search returns documents ranked by relevance and has no opinion about whether any of them are still true. Wikis are current on the day they are written and decay silently, which is worse than being obviously out of date.
The records are documents, owners, currency, the questions people actually ask, and the answers given, and the authoritative copy of most of them already lives in Google Drive or Slack. Two documents answer the same question differently, both are findable, and neither is marked superseded.
The cost is not the inconvenience: onboarding time is spent discovering which documents are still true.
You're likely here because
- The same question is answered from scratch every few months
- The wiki is comprehensive and out of date, so people ask a colleague instead and the wiki decays further.
- When it is wrong, onboarding time is spent discovering which documents are still true
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Knowledge workspace
- • Search and retrieval views
- • Decision context
Operated through Grow
- • Follow-up
- • Workflow actions
- • Notifications
Systems it reads
- • Google Drive
- • Slack
- • Gmail
The record model
What an authoritative answer carries.
- Owner per answer
- A named person accountable for whether it is still true. Retrieval without ownership surfaces old decisions with a modern interface and full confidence.
- Review date
- Because retrieval cannot tell whether a document is still true, and freshness is the only available signal that it might not be.
- Supersession link
- Explicit. Two findable and contradictory documents are the standard failure of every knowledge base and the most damaging thing one does when it goes wrong.
- Source permissions, inherited
- Rather than reindexed into a flat store. A knowledge system that widens access as a side effect is a security incident with excellent recall.
- Decision record
- What was decided, why, and what was rejected. The highest-value artefact in the system, and the thing missing when the question returns in eighteen months.
- Recurring question
- The ten that get asked repeatedly. Starting from the questions rather than the corpus is what makes curation tractable.
- Answer provenance
- Which document an answer came from, so a reader can judge it rather than accept a fluent summary.
How it runs
From storage to retrieval that can be trusted.
Step 01
Describe what a company knowledge system has to do
Decide what makes an answer authoritative — an owner, a review date, a supersession link — before building retrieval. Retrieval over unmarked content confidently surfaces the wrong answer.
Step 02
Connect the systems of record
The document store, chat, and email hold the material. Reading them with their permissions intact is the constraint that shapes the whole design.
Step 03
Build the operating surface
A knowledge workspace with retrieval, freshness and ownership on every answer, decision records, and permissions inherited from the source.
Step 04
Start narrow
The ten questions that get asked repeatedly, answered authoritatively with an owner and a review date. Ten trustworthy answers beat retrieval across everything.
Step 05
Route the exceptions
A question with no authoritative answer routes to whoever owns the area, and their answer becomes the record rather than another message.
Step 06
Measure questions answered without interrupting a colleague
Measure repeat questions and the share of answers that carry an owner and a review date. The second predicts whether the first keeps falling.
Implementation path
Building knowledge retrieval that does not go stale.
- 01
Start from the questions rather than the corpus. Indexing everything produces confident retrieval over material whose currency nobody has assessed.
- 02
Baseline the repeat-question rate in your chat channels. It is easy to sample and it is the clearest statement of the cost.
- 03
Attach an owner and a review date to every authoritative answer. Retrieval without freshness signals is a system for surfacing old decisions with a modern interface.
- 04
Inherit permissions from the source rather than reindexing into a flat store. A knowledge system that widens access as a side effect is a security incident with good search.
- 05
Build the narrowest useful version first: the ten questions asked most often, answered once, with an owner and a review date.
- 06
Sampling repeat questions from your chat channels is an afternoon and gives both the baseline and the initial scope. Curating ten authoritative answers with owners and review dates is two weeks. Permission inheritance across systems with different models is the genuinely hard part and should be scoped before anything is indexed.
- 07
Once ten answers carry owners and review dates, add decision records for the choices people keep relitigating. Broader retrieval comes after the curation habit exists, not before.
Controls
Controls that matter.
Control 01
Permissions inherited from the source system, so retrieval cannot surface content a person could not otherwise open
Control 02
Freshness and ownership shown with every answer, since an out-of-date answer delivered confidently is worse than no answer
Control 03
Supersession recorded explicitly, because two findable and contradictory documents are the standard failure of every knowledge base
Examples
Three questions that stop being asked twice.
The question asked for the fourth time
An authoritative answer with an owner and a review date ends the cycle, whereas a search result that returns four documents restarts it with more effort.
The policy that changed last year
Supersession recorded explicitly stops the superseded version being retrieved and acted on, which is the most damaging thing a knowledge system does when it goes wrong.
Why did we decide that?
Decision records capturing the reasoning and the alternatives make it possible to revisit a decision knowing what it was based on, rather than relitigating it from scratch.
How it goes wrong
Three ways knowledge systems mislead.
Everything is indexed, and retrieval confidently surfaces material whose currency nobody assessed.
Start from the recurring questions and curate. Indexing everything produces a system that is actively misleading in proportion to how fluent its answers are.
Content is reindexed into a flat store and people can retrieve documents they could not open.
Inherit permissions from the source. This is the standard shortcut and it turns a productivity tool into an unaudited route around access control.
Generated answers read authoritatively over a corpus nobody maintains.
Corpus discipline matters more than the model. Fluency reads as authority, which makes generated answers over stale material more dangerous than a list of search results.
Limitations and considerations
What retrieval cannot make true.
- Retrieval cannot tell whether a document is still true. Freshness signals and ownership are how that is handled, and both require somebody to maintain them.
- Generated answers over an unmaintained corpus are more dangerous than search results, because fluency reads as authority. The corpus discipline matters more than the model.
- Permission inheritance across systems with different models is genuinely hard, and getting it wrong turns a productivity tool into an access-control failure with excellent recall.
- If the team is small enough that everyone knows who to ask, this is premature. If nobody will own the answers, do not build it — an unmaintained knowledge system is worse than search, because it looks authoritative.
- Connector coverage varies: Google Drive, Slack, Gmail are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a company knowledge system with AI: common questions.
Should we index everything?
No. Start from the questions that recur and curate authoritative answers for those. Indexing everything produces confident retrieval over material whose currency nobody has assessed, which is how a knowledge system becomes actively misleading.
How do we stop it surfacing outdated information?
Ownership and review dates on authoritative answers, and explicit supersession links. Without them, the system reliably surfaces old decisions with the same confidence as current ones.
What about permissions?
Inherit them from the source. Reindexing content into a flat store is the standard shortcut and it turns a knowledge system into a route around access control that nobody audited.
Is a decision record worth the effort?
It is the highest-value artefact in the whole system. Documents record what was decided; decision records capture why and what was rejected, which is exactly what is missing when the question comes back in eighteen months.
What should the first version contain?
The ten questions asked most often, answered once, with an owner and a review date. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure questions answered without interrupting a colleague against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a company knowledge system around the process you actually run.
Start from the ten recurring questions, attach an owner and a review date to every answer, and inherit permissions from the source.