Make production knowledge searchable with appropriate access controls

Start with the operational bottleneck

A production question rarely arrives as a well-formed search query. Someone needs the correct setup instruction for a particular job, a maintenance exception, or the latest approved process change. The information may be spread across a shared drive, a wiki, and an engineer’s working notes. A plausible answer from an obsolete document can be more disruptive than no answer at all.

Start with one recurring question family and a named process owner. For example, use approved packing instructions for one product line. Record how people currently find answers, how often they interrupt colleagues, and which exceptions require engineering judgement.

Design the target workflow

Create a controlled collection from approved instructions. Store document ID, revision, effective date, process owner, and the groups allowed to read it. Split the text into retrievable sections, retaining those attributes with each section. Apply access filtering before retrieval, not after the model has seen the content.

The answer service retrieves a small number of relevant passages and asks the model to answer only from those passages. Its output includes a short answer, cited document sections, and an explicit unresolved state when the sources are missing or contradictory. The original document remains one click away. Keep write access to production systems out of this first version.

Connect to the existing systems

Connection	Information	Control
Approved document store	Versioned instructions and access groups	Owner approves the source collection
Identity service	User and group claims	Enforce permissions during retrieval
Operator interface	Question, job context, answer and sources	Record feedback without changing instructions

Use stable identifiers and versioned inputs. A retry should resume the same piece of work, with the original permissions and evidence attached. Treat an upstream outage as a visible workflow state.

Fit the model to the task

Begin with a small open-weight model and a bounded context. This task is grounded answering, not a request to reproduce all engineering knowledge from model weights. Retrieval quality and current source material often matter more than adding parameters. Keep the retrieval and generation stages independently measurable so a missing passage is not mistaken for weak reasoning.

Keep a clear human boundary

The process owner decides which sources are authoritative. Operators verify the cited revision before applying an instruction. Conflicting documents route to the owner; the model must not select a convenient answer. Include requests for inaccessible products and deliberately obsolete revisions in the test set.

Measure the complete operating cost

Count ingestion, permissions maintenance, document updates, inference, and review. A locally hosted service has an ongoing owner even when it has no per-request API charge. Cache only within the same permission boundary, and invalidate answers when the underlying revision changes.

Pilot checklist

• Choose one process and identify its authoritative documents.
• Test current, obsolete, conflicting, missing, and restricted sources.
• Measure source correctness separately from answer readability.
• Compare retrieval effort and exception handling with the existing process.
• Document who updates sources and who can disable the service.

Agree on acceptance thresholds before testing, then compare the proposed workflow with the same work handled through the current process. Expand only after the operation can explain both successful and failed cases.

Further implementation detail

• Choose the lowest-cost model that meets the task requirements
• Serve a local model to a team
• Ollama’s local API reference