How to actually build a single source of truth

Every growing company eventually decides it needs a single source of truth. The reasoning is sound: when the same information exists in different versions across different tools, mistakes happen. Someone works from the wrong brief, the wrong spec, the wrong deadline. The cost of conflicting information, measured in rework, misaligned teams, and delayed decisions, grows with every tool and every team that's added.

The standard approach to building an SSOT is consolidation: pick one platform (Confluence, Notion, SharePoint, Google Drive) and mandate that everyone uses it. Move all documents there. Create a folder structure. Train people on the conventions. Declare victory.

This approach fails so reliably that most companies have attempted it more than once with different tools, each time concluding that the tool was the problem. The tool wasn't the problem. The method was.

Why consolidation fails

Specialised tools exist for a reason. Engineers use GitHub because it's built for code. Designers use Figma because it's built for design. Sales uses a CRM because it's built for pipelines. Asking these teams to move their primary work into a general-purpose wiki degrades their productivity and produces resistance. The teams that comply do so resentfully, and the quality of what they produce in the wrong tool reflects that resentment.

Migration is expensive and lossy. Moving years of accumulated content from multiple tools into one platform takes months. Formatting degrades, links break, context is lost, and the migration project consumes engineering and operations time that could have been spent on the actual work.

The consolidated tool creates its own fragmentation. Within Notion or Confluence, teams create their own spaces with their own naming conventions and their own organisational structures. The tool is shared but the organisation within it is just as fragmented as the multi-tool landscape it replaced. You've traded external silos for internal ones.

It can't stay current. A consolidated wiki requires humans to maintain it. Every change to a system, every new decision, every process update needs to be reflected in the wiki manually. This maintenance is never prioritised, and the wiki goes stale within weeks, which destroys trust, which destroys adoption, which makes the entire consolidation effort pointless.

What a working SSOT actually requires

The goal of SSOT is that anyone in the organisation can find the current, authoritative version of any piece of information. This requires three things, and consolidation provides none of them reliably.

Comprehensiveness. The SSOT must contain or reach all the organisation's knowledge, not just the portion that someone remembered to move into the designated tool. If the engineering team's knowledge is in GitHub and the SSOT is Confluence, the SSOT is incomplete by design.

Currency. The information must be current. A document that was accurate when it was migrated three months ago and hasn't been updated since is worse than no document, because it misleads with the authority of being in the "official" system.

Findability. People must be able to find what they need quickly and reliably. Keyword search that requires guessing the author's exact phrasing, or a folder structure that requires knowing the organisational conventions, fails too often to be trusted.

The connective approach

The approach that achieves all three is a connective layer that spans existing tools and adds the intelligence needed to make the combined knowledge useful.

Comprehensiveness through connections. Rather than moving content into one tool, connect all the tools where knowledge already lives: Google Drive, Slack, GitHub, Gmail, Notion, Figma, HubSpot, Linear, and dozens more. Every tool's content becomes searchable from one place. The SSOT isn't a single tool. It's a single search that spans all tools.

Currency through self-writing documentation. Documentation that generates and maintains itself from live activity (GitHub PRs, Slack conversations, meeting recordings) stays current because it's derived from the same sources that change the underlying systems. The wiki doesn't go stale because it updates as the team works, not when someone remembers to edit it.

Findability through semantic search. Search by meaning rather than keyword. "The Q3 client proposal" finds the document whether it's titled "Proposal," "Q3 Pitch Deck," or "Acme Deal Docs." People find what they need on the first search rather than giving up after three failed keyword attempts and asking someone on Slack.

What this looks like in practice

A product manager needs the current architecture for the payments service. They search once and find the self-writing engineering wiki entry, which was updated yesterday when a PR modified the retry logic. The entry cites the PR and the Slack discussion where the change was discussed.

A new hire needs to understand why the data pipeline uses batch processing instead of streaming. They search and find the decision record, generated from the meeting where the decision was made eight months ago, with the reasoning, the alternatives considered, and the constraints that drove the choice.

A sales rep needs the latest case study to share with a prospect. They search and find it in the marketing team's Google Drive, surfaced alongside the Slack thread where the marketing team discussed the key metrics to highlight. The rep didn't need to know which team created it, which folder it was in, or which tool it lived in.

In each case, the information was found through one search, it was current, and it was authoritative. That's a single source of truth, achieved through connection and intelligence rather than consolidation and migration.

The AI dimension

Through MCP (Model Context Protocol), the connective SSOT layer also becomes the context for any AI agent the organisation uses. An AI tool that can search across all your connected sources operates from the same comprehensive, current knowledge base that human users access through the single search.

This is where the SSOT investment compounds: every AI tool in your stack becomes more useful because it can access the full picture rather than the fragment visible from any single tool. The AI readiness gap that most companies face (80% of enterprise data invisible to AI) closes as more sources are connected and more knowledge is captured by the self-writing documentation.

Getting started

The practical path to a working SSOT:

Week one: Connect your primary knowledge sources (Google Drive, Slack, Gmail) to the search layer. The search begins returning results immediately.

Month one: Add self-writing documentation from GitHub, Slack, and meetings. The wiki begins building itself from live activity.

Month three: Connect additional sources (Notion, HubSpot, Linear, Figma). The search layer now covers the majority of the organisation's knowledge.

Ongoing: The system gets better every day. More knowledge captured, more connections resolved, richer context for both human users and AI agents. The SSOT that consolidation projects promise in a big-bang migration is achieved incrementally, sustainably, and without anyone having to give up the tools they work best in.

Frequently asked questions

How does this handle conflicting information across tools? When different tools contain conflicting information, the search surfaces both with their timestamps and sources. The self-writing documentation resolves conflicts where possible by using source recency and authority (a merged PR takes precedence over a Slack message from three months ago). Where the system can't resolve automatically, it flags the conflict for human review.

What about access controls? The search layer respects the permissions of the underlying tools. Content that's restricted in the source tool remains restricted in search results. The SSOT is comprehensive for each user within the boundaries of what they're authorised to access.

Does this replace our existing wiki? The self-writing wiki handles current, operational documentation. Your existing wiki can remain as a repository for manually authored content (policies, style guides, strategic documents) that requires human writing. Over time, the self-writing wiki typically becomes the primary reference because people trust it more, since it stays current.

How is this different from enterprise search tools? Enterprise search tools index and search. Fabric also generates and maintains the documentation itself through self-writing docs, which means the knowledge base grows automatically rather than depending on human contribution. The search is the retrieval layer. The self-writing docs are the knowledge layer. Together they provide both the content and the findability that a working SSOT requires.

Related reading: The cost of scattered knowledge, Information silos are the default, Nobody reads the wiki, How to break down information silos. Related pages: One search, Self-writing docs, Search, Connections, Marketplace connections.