AI knowledge systems

Ask the business. See the evidence.

The useful problem is not “chat with your documents”. Policies, procedures, project notes and operational records already exist, and people still cannot find the relevant part when they need it. PrimeLabs builds the application around that material: retrieve what the person is allowed to see, show where an answer came from, and keep the model from being treated as the source.

An application around known sources

A knowledge system helps an authorised person retrieve and work with information from sources the organisation already holds. The screen might be search, a question, a summary, a comparison, extraction, a guided look through a policy, or assistance beside a job. Whatever the screen, the answer is tied to identifiable material. This is one pattern inside AI application development. That page is the broader capability. This one is the retrieval application.

The model does not know the organisation on its own. It sees the context the application hands it, after the permission check. A prompt with no source behind it is not this system.

Search, meaning, and a written answer are different

Traditional search finds matching terms or indexed records. Semantic search finds a passage with related meaning when the person’s words are not the words in the document. A generated answer uses the retrieved context to write a response. A useful application can offer all three. The written answer does not replace the results. The person should still be able to open the match, the record, and the passage.

Retrieval-augmented generation, usually called RAG, is the path for the written answer. The person asks. The application selects relevant source material they are allowed to see. The model receives that context. The response is generated. The evidence stays on the screen. RAG is a method inside the application. It is not a claim that the model has read the business.

The response is not the source of truth

The document, the database row, the approved policy, the procedure, or the business system remains the source. The generated sentence is a view of what was retrieved. The application should make that split visible: the passage, the version, the time the records were read, and a way to open the original. If the sources do not support an answer, the application should be able to say so.

A citation is the document or record, the passage or reference, the date or version when that matters, and a plain statement when the match is uncertain. Trusting the prose without a way to inspect it is the failure this screen is meant to avoid.

Permission is applied before retrieval

A document is not retrieved because it is semantically close. Identity, organisation, role, ownership, team visibility, confidential material and account boundaries are applied first. Retrieval then runs only over what that person may access. In the example, Priya can read Operations policies and equipment requests. Finance-only contracts never enter the result, even if the wording would have matched.

The same rule holds whether the screen sits in an internal application, a customer portal, or a SaaS product. A portal shows one account’s material. A product keeps tenants apart. A knowledge feature does not get a wider view than the application around it.

The index follows the source

Indexing is not a one-time project. A policy is revised, a file is deleted, a permission changes, or new material arrives. The retrieval index has to follow. A superseded version can remain available for comparison, labelled as superseded, as v3.1 is in the example. A deleted source should stop being offered as current. A permission change should take effect on the next question, not on the next reindex someone remembers to run months later.

Documents and records answer different parts

Unstructured material is the PDF, the policy, the procedure, the manual, the report, the note. Structured material is the customer row, the project status, the invoice, the workflow state, the catalogue item. The equipment question needs both: the policy says who must approve, and the workflow says which requests are waiting. A document workflow turns one incoming file into checked fields and a decision. A knowledge system makes a body of material retrievable and explainable. Some applications need both.

Structured rows often already live in another product. Reading them is an API integration, and only where that system’s interface, permissions and data model allow it. When the fact is deterministic — an amount, a due date, a status, a count — ordinary application logic should produce the value. The model can explain it, summarise the surrounding policy, or help the person find the row. It should not invent the figure. A dashboard remains the place a defined calculation lives. A knowledge screen may help someone navigate that number. It does not replace the calculation.

Someone has to be able to challenge an answer

Helpful or not, a report that an answer is wrong, a look at the source, a link to the original record, a handoff to a person, and a flag that the content is outdated: those are how the system stays operable. The example can open the policy, the requests, the previous version, and the highest amount. It does not approve the purchases. Understanding the work is not the same as performing it.

The model can be wrong. The application has to expect that.

Generated text can be wrong even when the retrieval looked plausible. Mitigations are ordinary: retrieve from known sources, show the evidence, take deterministic facts from application data, constrain what the model is asked to do, validate what comes back, refuse when the evidence is not there, and send an important decision to a person. None of that eliminates the failure. It makes the failure visible, and it stops the screen from inventing a policy or an amount.

Sensitive documents, tenant boundaries, what a provider is allowed to receive, what is logged, and how long that log is kept are design questions before the first index is built. A source that cannot legally or safely be sent to the required provider is a reason to change the design, or not to build this pattern. Removal and update have to propagate. A deleted policy that still answers questions is a defect.

Evaluation is a set of realistic questions, not a demo. Did retrieval find the right source? Was unauthorised content excluded? Did the answer stay inside the evidence? Were the citations the passages that were used? Did the system decline a question the sources do not support? Those checks are how a later change is judged.

Start from the question people already ask

A useful note names that question, the sources that should answer it, who may see them, and what must stay a record rather than a sentence. There is no corpus on this website.

Discuss a knowledge application

Straight answers