Your business data, indexed for AI. On hardware you own.
A secured layer that pulls from your systems, keeps one current copy and indexes it by meaning, so AI answers come back in about a second, cite the record they came from and never have to leave your network.
Pointing AI at a live API is the obvious way to do this. It is also the worst.
It works beautifully in a demo with three documents. Then real people ask real questions of a real system and the same six problems turn up every time.
Every question hits the live API. Ask enough of them and Microsoft Graph starts throttling, your PSA starts refusing and the tool gets slower the more people find it useful.
One question can mean dozens of API calls in sequence, each waiting on the last. Half a minute of spinner is all it takes for people to stop bothering.
Ordinary search wants the exact words. “Mailbox is full” never finds the ticket logged as “quota exceeded”, so the answer comes back as nothing found.
When the model can't retrieve the right record it fills the gap with whatever sounds plausible. That is what hallucination actually is in practice. Confidently wrong is considerably worse than an honest blank.
Every query is metered. The same forty documents get re-read, re-sent and re-charged each time somebody asks a slightly different version of the same thing.
To answer from your data, most setups send your data. Client records, contracts and mailboxes end up in a context window you don't own and can't audit.
Pull it once. Index it properly. Answer from the index.
Five stages. The whole trick is that the expensive ones happen on a schedule rather than while somebody waits.
- 1PULL
Connect and collect
Connectors read from your systems on a schedule using credentials that stay with you. Read-only unless you specifically ask otherwise, scoped to the records you nominate rather than everything an account can reach.
- 2CACHE
One current copy, held locally
Questions hit the copy instead of the live API. Your source systems see a handful of scheduled syncs a day rather than thousands of ad-hoc calls, which is what makes throttling and rate-limit failures stop happening.
- 3INDEX
Indexed by meaning, not just wording
Each record and document passage is converted into a numeric fingerprint of what it means, then stored in an index built to compare those fingerprints at speed. This is the vectorised part. It is why a search across millions of records lands in milliseconds.
- 4RETRIEVE
Find the handful that matter
The question gets the same treatment. The index then returns the few records that genuinely relate to it, by meaning and by keyword together, so vague questions and invoice numbers both work.
- 5ANSWER
Composed from those records, with citations
Only the retrieved records are used to write the answer, each one linked back to its source in your system. Nothing else is in play, so there is nothing to invent and every claim can be checked.
Why this fixes accuracy as well as speed: a model that has been handed the four right records has very little room to invent anything. Most wrong AI answers aren't a reasoning failure at all. They're a retrieval failure that nobody noticed, because the model answered anyway.
Fewer hallucinations. A fraction of the inference.
Everything above is mechanism. These are the two effects people actually notice once it is running: one in the quality of the answers, the other in the wait and the bill.
A grounded answer has far less room to invent.
A model asked something it cannot ground has no mechanism for admitting it. It produces the most plausible continuation available, which is a different thing from the true one.
Handing over the actual records first turns the task from recall into summarising four documents that are sitting right there. A much narrower job with far less room to invent.
The index knows whether anything relevant came back. When nothing did, the honest answer becomes available: nothing in your data covers this. That single behaviour removes most of the damage.
Every claim points at a record someone can open. A wrong answer that cites its source gets caught in seconds rather than quietly forwarded to a client.
Less model work for every question asked.
Retrieval does the narrowing before the model is involved at all. Less text to process per question means less GPU time, lower latency and a smaller box to buy.
The numeric fingerprints are computed when a record is indexed rather than on every question. The expensive pass over your data happens on a schedule then gets reused for as long as the record is unchanged.
A client's current contract end date is a lookup. The index returns the record and the field is the answer. No generation, no wait and nothing to hallucinate.
Repeated and near-identical questions land on work already done. Across a busy team that turns out to be most of the traffic.
Worth being straight about: retrieval reduces hallucination rather than abolishing it. A model handed the right four records can still summarise them carelessly. What changes is that every answer is grounded in something you can open and check, so a wrong one becomes an error somebody finds rather than a claim nobody can trace. That distinction is what a compliance conversation actually turns on.
The vocabulary, without the vendor fog.
Every AI vendor now says vector, semantic and RAG. Here is what each one actually means, so you can tell who is describing a real system and who is reading a brochure.
- Embedding (or vector)
- A list of numbers that captures what a piece of text means. Two records about the same subject end up with similar numbers even when they share no words, which is what lets a computer compare meaning at all.
- Vectorised indexing
- Storing all those numbers in a structure designed for finding nearest matches fast. The difference between searching your data and scanning it. One is instant at millions of records, the other is not.
- Semantic search
- Searching by meaning rather than exact wording. “Who looks after the Brisbane site?” finds the record filed as “QLD branch, primary contact” without anyone having guessed the right keyword.
- Hybrid search
- Meaning-based search and old-fashioned keyword search run together, then merged. Meaning handles the vague questions; keywords handle serial numbers, invoice references and surnames, which meaning is genuinely bad at.
- RAG (retrieval-augmented generation)
- Retrieve the right records first, then write the answer from them. The retrieval half is the part that stops the answer being fiction. It is also the half most quick AI deployments skip.
- Chunking
- Splitting long documents into passages small enough to retrieve precisely. You get the clause that answers the question rather than the whole forty-page contract for the model to wade through.
- Re-ranking
- A second, closer pass over the shortlist to put the best match first. Cheap to run and usually the difference between an answer that is technically correct and one that is actually useful.
- Grounding
- Tying every statement in an answer to a specific retrieved record. An answer that can name its source is grounded. One that cannot is the model's best guess wearing a confident tone.
- Inference
- The work a model does to produce an answer: the part that costs money, time and GPU. Despite how it sounds, it has nothing to do with the model inferring or guessing anything: making things up is hallucination. Inference is just the running of the model, so less of it buys you a cheaper and faster answer rather than a less reliable one.
- Freshness
- How current the cached copy is, set per source: minutes for tickets, hourly for mail, nightly for contracts. Answers can state how old their data is, so nobody has to wonder.
Local hardware, a dedicated server, or your own tenancy. Your choice.
The layer is yours and it runs where you want it. For businesses under privacy, confidentiality or client-contract obligations, this is usually the part that decides whether the project is allowed to happen at all.
The index, the cache and the models all sit inside your network. Nothing crosses the boundary, which makes the data-sovereignty conversation short. We can supply and install the server, or use one you already have.
Hosted in an Australian data centre with no shared tenancy and no shared storage. Suits businesses that would rather not run hardware but still want a single named machine.
Under your existing policies, logging, backup and network controls. Your cloud bill, your subscription, your access reviews.
And nothing has to be sent to a public AI model.
The indexing step doesn't need a hosted model. The models that turn text into those numeric fingerprints are small, they run happily on a modest GPU and they run on your machine. Your documents are never sent anywhere to be indexed.
Fully local. Pair the index with an open-weight model running on the same hardware. No part of the question, the retrieved records or the answer leaves your network. Nothing is logged by a vendor and nothing is available for training.
Or local retrieval, hosted writing. Keep a commercial model for the drafting step and send it only the few passages that were retrieved, filtered and redacted first. Sharper prose, a fraction of the exposure. It's a setting rather than a rebuild. It can also differ per use case.
We can supply the server, too.
Retrieval is one of the few AI workloads with a genuine hardware shape to it: an index that has to be read constantly, models that want a GPU and a query path where latency is basically the whole product. So we spec and supply the machine rather than leaving you to assemble a parts list from forum threads.
Embedding and re-ranking are GPU work. The card is sized against how much you're indexing and how quickly you want the first full load finished. Running a language model on the same box moves that requirement up, which is a decision we make with you rather than after delivery.
NVMe, because the index is read constantly and random-access latency is most of what makes an answer feel instant rather than laggy. Sized for the cached copy, the index and headroom to build a new index without dropping the old one.
Scales with how much of the index you want held hot. Given enough of it, the questions your team asks most often never touch the disk at all.
It lives on your network, behind your firewall, in whichever VLAN your policy puts it. Nothing has to be published to the internet for any of it to work.
What comes with it
- ✓Specced against your actual sources and volumes rather than a generic tier, because the difference between indexing a document library and indexing ten years of tickets is most of the spec.
- ✓Built, configured and loaded before it arrives, so it does something useful the week it lands instead of becoming a project of its own.
- ✓Delivered, racked and connected, with the sync schedules and retrieval tuning done against real questions from your team.
- ✓Monitored, patched and supported like any other server we look after, including the model and index components that ordinary server monitoring ignores.
- ✓Yours outright. Not a subscription appliance that stops answering questions if a licence lapses.
- ✓Able to run as a pair, or with a warm spare, where the business would notice it being down.
And if you already have a box that will do it, use it. Plenty of businesses have spare capacity on a host that will carry this comfortably and we would rather tell you that than sell you hardware you didn't need. The layer runs the same either way. The hardware is an option rather than a prerequisite.
Faster, cheaper and checkable, in that order.
None of this is exotic engineering. It is the difference between asking a question of an index and asking it of an API.
- ✓Answers in about a second rather than half a minute, because the work happens against a local index instead of a queue of API calls.
- ✓Throttling and rate-limit failures stop, because the source systems are no longer being asked thousands of questions a day.
- ✓Cost per question drops close to nothing once the index exists. The expensive part was re-reading the same documents, which now only happens once.
- ✓Accuracy improves in a way you can verify, because every answer names the records it came from and you can open them.
- ✓The same index serves everything: your own applications, your agents, your reporting and your MCP gateway. Built once, used by all of them.
All of it exists so a person can make a decision. Somebody in your business has a call to make and the information it rests on is spread across five systems. This is how it gets brought together so it's in front of them in a second with the source attached. The AI isn't replacing their judgement. It's doing the fetching and the reading so there is something to exercise judgement on, then teasing out the patterns nobody had time to go looking for.
If it has an API or a database, it can go in the index.
Most engagements start with two or three sources rather than all of them, because the value shows up early and the scope stays sane. Usually documents plus whichever system holds the client or job records.
Permissions come across with the data. Someone who can't open a file in SharePoint can't retrieve it through the index either, which is the failure mode that makes most quick AI search projects unshippable.
We build it, load it, tune the retrieval against real questions from your team and hand over something documented that your people can run and extend. Adding a source later is a day of work, not a new project.
// NEXT
The index decides what AI can find. A gateway decides what it's allowed to reach and logs every request.
Explore →Tried this and found it slow, expensive or unreliable? That's the normal result.
Tell us which systems hold the data and what your team keeps needing to look up. We'll tell you what an index over it would change and whether it's worth building.