One AI knowledge platform across your documents, wikis and business systems

A knowledge platform is shared infrastructure, while a RAG chatbot is usually one interface over one collection of files. The platform connects many sources, maps permissions from each of them, gives every source an owner and exposes a retrieval API that several channels and teams reuse. A chatbot can be one of those channels. Building the platform first avoids each department paying for its own index and maintaining its own copy of the same content.

Yes, one query can cover all three, provided each system allows API or export access we can use with read-only credentials. Every source has its own connector, sync schedule and permission mapping, and results show which system each passage came from. We usually connect the source with the most questions first, confirm that permissions behave correctly, then add the others one at a time so problems are easy to isolate.

Their access follows your identity provider, so removing them from a group or disabling their account removes the matching content from their results. Depending on what the identity provider supports, group membership is checked on each request or refreshed on a short schedule you agree, and permission changes inside each source are picked up at its next sync. Before launch we test leavers, movers, shared links and nested groups, and every request is logged against the user.

Yes, by querying those systems through their APIs at the moment a question is asked rather than copying all their data into the index. A question such as what our standard terms are and which of them apply to this customer's current orders can combine a policy document with live records. Each system call is limited to the fields and records the user is entitled to see, and the answer cites both kinds of source.

Your content owners do, and the platform is designed to make that job lighter. Each source has a named owner who receives reports on unanswered questions, low-rated answers and frequently cited documents that are past their review date. Admins can withdraw a document from the index at any time, without waiting for the next sync. We set up these routines with you during the pilot so accuracy is maintained by process, not by occasional clean-up projects.

Yes, through a Microsoft Teams or Slack app that calls the same retrieval API as the web portal, so permissions, citations and logging behave identically. People ask in a direct message or by mentioning the app, and answers include links that open the source in its original system. In shared channels, answers are limited to content every member may see, or sent privately to the person who asked, so a reply does not expose restricted material to the room.

The platform reports which topics are asked about most, which questions went unanswered, which answers were rated poorly and which documents are cited most often, grouped by team and over time. Personal identifiers can be removed from these reports if your policy requires it. The reporting shows content owners and managers where documentation, training or processes are failing the people who rely on them, and which gaps to fix first.

If almost all your knowledge lives inside one productivity suite and its built-in assistant answers well enough, using it is usually the sensible choice. A custom platform earns its place when knowledge spans several suites and business systems, when you need control over models, hosting region and evaluation, or when other applications must reuse the same retrieval layer. We make that assessment with you during discovery, using your own sources and questions.

Yes, and that reuse is a large part of the platform's value. The retrieval service is published as an internal API with authentication, rate limits and per-caller logging, so a customer chatbot, an internal agent or a line-of-business application can request cited passages without building its own index. Each caller can be restricted to particular sources, and every request still applies the permissions of the person it acts for.

Yes, every source and folder is included only by explicit decision, and any of them can be excluded or restricted. HR casework, legal matters or board papers can be left out entirely, indexed for a named group only, or held in a separate index that general users never query. Rules can also stop particular sources from being sent to external models. Content, embeddings and logs stay in the cloud account and region you choose, deployed with infrastructure as code.

Enterprise search returns a ranked list of documents that match your words, while a knowledge platform also finds passages by meaning, reads them and writes a direct answer with citations. It can combine documents with live records from business systems, which keyword search alone does not do. A results list is still useful when people want the documents themselves, so the platform can offer both views over the same permission-aware index.

It is rolled out in stages, and timelines depend mainly on how many sources you have, how complex their permissions are and how much content needs cleaning before indexing. We start with one or two high-demand sources and a pilot group, which tests access control and answer quality on real questions. Further sources and departments are then added one at a time, each checked against its own evaluation questions, with working software to review every one to two weeks.

The cost depends mainly on how many sources the platform connects and how complex their permissions are, and we give a fixed quote for the first phase after discovery. Other drivers are parsing difficulty, the channels required and your hosting choices. Running costs cover hosting, storage, embedding new content and model calls per question. We estimate these from your document volumes and expected users, so you can see the monthly figure before each new source or department is added.