Case study 001

A company brain for industrial teams

Search manuals, project files, and service records from one place, with permissions and sources kept intact.

Context
Industrial operations
System
Knowledge retrieval
Read
9 min read
Published
20 July 2026
System mapSources to cited answer
01 / SOURCESManuals + drawingsProjects + reportsERP + service dataMessages + tickets02 / INGESTNormalizerevision · owner · access03 / INDEXHybrid retrievalexact + semantic + rerank04 / CONTROLPermissionsfilter before answer05 / ANSWERCitedor no answer
The model is only the final step. Most of the work happens before the prompt.

The answer usually exists in a maintenance manual, quality report, project folder, service ticket, or the head of an experienced engineer. Finding it before the work stops is the hard part.

01 / Where search fails

Finding the right document is the hard part.

Industrial information is difficult to search for good reasons. Part numbers must match exactly. The same component can have several names. A PDF may contain the answer in a table, while the latest correction sits in a service ticket. Two documents can disagree because one is obsolete.

A chat window full of files still needs good search. Research shows that models can miss facts in long inputs, especially when the useful passage sits in the middle. The system has to find the right evidence and check which version is current.

02 / What it does

It searches company files and shows its sources.

A company brain searches the information a person is allowed to see. It answers from those sources and links each important claim back to the original file.

The source systems stay in place. SharePoint owns the controlled document. The ERP owns the item record. The service platform owns the ticket. People get one place to ask a question and can always open the source.

03 / How it works

It does five things.

  1. 01

    Connect the systems people use

    Pull files and records from the systems teams already use. Each connector knows how to detect a change, a deletion, and a new revision.

  2. 02

    Keep the source details

    Every record carries its source, owner, revision, dates, document type, and access groups. Tables and headings stay attached to the text they explain.

  3. 03

    Search meaning and exact terms

    Semantic search catches paraphrases. Keyword search catches drawing numbers, fault codes, abbreviations, and product names. A reranker decides which passages deserve the model's attention.

  4. 04

    Check access before answering

    The retrieval layer checks identity and access before any passage enters the prompt. The interface cannot reveal a document the user cannot open.

  5. 05

    Cite the source or say it cannot answer

    The final answer cites the document and revision. Missing, weak, or conflicting evidence produces a clear refusal and a route to a human owner.

04 / Search

Industrial search needs keywords and meaning.

Embeddings are useful when two people ask the same question with different words. They are less reliable for exact identifiers. Industrial search needs both. We combine semantic retrieval with lexical search, merge the candidates, and rerank the result against the actual question.

Chunking also matters. A fixed slice can separate a tolerance from the drawing it belongs to. We split on document structure, then add a short description of the parent document to each chunk. This preserves enough context for retrieval without sending the entire archive to the model.

Querypart number + intent
Candidate setkeyword + semantic
Evidencepermission filter + rerank

05 / Access and updates

Old documents need to stay out.

An answer from an obsolete work instruction can cause real harm. The service updates changed records, removes deleted content, and shows the source date. Controlled documents rank above informal discussions when the two conflict.

Access control follows the document. A user sees the same boundary in the company brain that they see in the source system. Queries, retrieved passages, and user feedback are logged so the owner can investigate errors without opening access to everyone.

06 / Tests

Test it with questions people actually ask.

We build the evaluation set before broad rollout. Operators, engineers, service staff, and managers contribute questions they regularly ask. Each question has an expected source, an acceptable answer, and examples of failure.

TestQuestionMeasure
RetrievalDid the correct source appear in the first results?Recall at k
GroundingDoes each claim follow from the retrieved evidence?Claim review
CitationsDoes the link open the right document, page, and revision?Citation accuracy
RestraintDoes the system stop when the evidence is missing or conflicting?Abstention quality
UsefulnessCan the person complete the real task with the answer?Task completion

These tests show whether the system helps with real work. The model can change later. The same test set shows whether the replacement is better.

07 / First release

Start with one team and one set of documents.

The first release should cover one bounded knowledge domain and a small group of daily users. Maintenance procedures, quality documentation, or technical service are better starting points than a company-wide launch.

  • A working interface connected to the chosen source systems
  • Search that respects source permissions and cites the document revision
  • An evaluation set built from real employee questions
  • Feedback, audit logs, and a named internal owner
  • A measured decision on what to add next

People trust the system when its answers hold up. Start with information they already use. Show the source. Make mistakes easy to report. Add more after it works.

Sources

Sources behind the system.

Need this at your company?

Start with one set of documents.

Book a 20‑minute call