RAG for operations data: grounding assistants in your own records

Ask a general-purpose language model who won the World Cup, how a diesel engine works, or to draft a polite decline to a meeting, and it answers instantly and well. Ask it which of your orders shipped late last week, what your SOP says about a temperature excursion, or which customer has an open escalation, and one of two things happens. If it's honest, it tells you it has no idea. If it's not, it invents an answer that sounds exactly as confident as the true ones — a plausible order number, a paraphrased policy that isn't yours, a customer who doesn't exist.

The model isn't broken. It has simply never seen your operation. Everything it knows came from public text that stops well short of your database. The fix is not a bigger model or a better prompt. It's giving the model your records at the moment you ask, so it answers from them instead of guessing around them. That pattern is Retrieval-Augmented Generation — RAG — and for operations data it's the difference between a demo and a tool you can actually rely on.

The problem

A logistics coordinator wants to know why a shipment stalled. A support lead wants every ticket that mentions a recalled part. A compliance officer wants the exact clause in a signed contract that governs a late delivery. None of these answers live on the open internet. They live in orders, work tickets, customer records, and the PDFs and documents attached to them — the operational data your team generates every day, updated hourly, specific to your business, and shared with no one. It is precisely the data a general model has never seen and never will, and precisely the data your hardest questions depend on.

A bare chatbot bolted onto that workflow is worse than no chatbot, because it fails in the most expensive way: silently and confidently. It doesn't know your schema, so it can't distinguish a real order ID from a well-formed guess. It has no access to the contract PDF, so when asked what the contract says, it reconstructs a generic version from training data and presents it as yours. In an operations context, an answer that's wrong but sounds right is a liability, not a convenience. Someone acts on it before anyone checks.

RAG closes the gap by inverting the order of operations. Instead of asking the model a question and hoping the answer is in its head, you first retrieve the records most relevant to the question from your own data, then hand those records to the model as the ground to answer from. The model stops being the source of facts and becomes what it's genuinely good at: reading the material you gave it and writing a clear reply.

Why it matters now

Two things changed that make this practical rather than aspirational.

The first is that retrieval no longer requires shipping your data anywhere. For years the assumed architecture was: send every record to a hosted embedding API, store the vectors in a managed service, and query them from the cloud. That works, but it means your orders and contracts leave your network to be indexed — a fact you then have to explain to a security reviewer. Local embedding models have gotten good enough and small enough that you can compute those vectors on the same machine that holds the data, and search them there too. The privacy story flips from "trust the pipeline" to "the data never moved."

The second is that expectations rose. A general assistant that's fluent about the world sets a bar; the first time it confabulates a customer, trust collapses and doesn't come back. Grounding and citation aren't nice-to-haves anymore. If an operator can't see which record produced an answer, they can't verify it, and if they can't verify it, they won't use it for anything that matters. The teams getting value from AI in operations are the ones who made the assistant show its sources.

How FastYoke approaches it

FastYoke's assistant is called Yoker, and it's built retrieval-first for exactly this reason. Here's what it does today.

When you enable Yoker for a tenant, it takes your entity records — the orders, tickets, customers, or whatever your app models — and their text attachments, which today means PDF, Word, and plain-text files such as the SOPs and contract PDFs your team attaches to records. Each record's payload is rendered to text, split into chunks, embedded, and indexed. All of that indexing is scoped per tenant: one tenant's corpus is never searchable from another's, the same isolation boundary that governs every other query in the platform.

The part that matters for privacy is where this happens. The embeddings are computed on your VM using ONNX, and the vector search runs in Rust against tenant-scoped storage on that same machine. Your records are not sent to an external embedding API — not OpenAI's, not Anthropic's — to be indexed or searched. Retrieval stays local, start to finish. If your data is regulated or simply sensitive, that's a categorical claim you can make to an auditor: the search half of RAG doesn't touch a third party.

When you ask a question, Yoker retrieves the most relevant chunks from your corpus and answers from them — and every answer carries citation chips showing which records grounded the reply. This is the feature that separates a grounded assistant from a confident one. You don't take the answer on faith; you click through to the exact order or contract the model read, and you confirm it yourself. For a regulated workflow, where an operator is expected to verify the source before acting, that traceability is the whole point — it turns "the assistant said so" into "here is the record it said it from," which is the only version of that sentence an auditor accepts.

A few deliberate design choices round it out. Sessions are ephemeral: the server does not persist your chat history, so the conversation lives in the client for the duration of the session and isn't retained server-side afterward. And the final synthesis step — turning retrieved chunks into a written answer — can optionally use an external language model when you want its fluency; that path is PII-scrubbed by default before anything leaves the box. The retrieval half is always local regardless. You choose how far, if at all, the answer generation reaches out; the search never does.

What to watch out for

Be honest with yourself about what's in the corpus, because RAG can only ground an answer in what it has actually indexed. Today, Yoker's corpus is your entity records and their text attachments — nothing more. That's a deep well for operational questions, but it has edges. If you ask about a platform how-to, or about the way a particular workflow is configured, that content isn't part of the retrievable corpus yet. Those additional sources are on the roadmap, not shipping today, and it's better to know the boundary than to be surprised when an answer comes back thin.

The corollary is that retrieval quality tracks data quality. A tenant with rich, well-populated records gets sharp, well-grounded answers; a tenant with sparse or inconsistent records gets exactly what you'd expect from sparse, inconsistent input. RAG doesn't manufacture information that isn't there — and that's a feature. When the records don't support an answer, you want the assistant to come up empty rather than fill the void, which is precisely the failure mode a bare chatbot doesn't have and shouldn't be trusted for.

Finally, treat the citation chips as the product, not the decoration. The temptation, once an assistant is fluent, is to skim the prose and skip the sources. In an operations context the sources are the reason the tool is safe to use. The habit worth building on your team is: read the answer, then read the records it cites, and let the second one settle the matter.

Where this goes next

Grounding an assistant in your own records changes what you can safely ask it. The question stops being "what does the model think?" and becomes "what do my records say?" — with a click-through to prove it. That's the version of AI that belongs inside an operation, where a wrong answer costs something and a cited answer can be checked in seconds.

If you want the hands-on version, our RAG recipe walks the full loop end to end — enabling Yoker, seeding its corpus, and reading the citations that back each answer. And if the local-first architecture is what draws you, on-VM AI with no cloud round-trip explains why keeping inference next to your data pays off in both latency and privacy.