Answers from your own data, with the source attached.
We build question answering and search over your documents, records and internal systems, inside the tools your team already uses. Every answer shows where it came from, respects who is asking, and says so plainly when your data does not contain the answer.
Who this is for, and who it is not.
A good fit if
- Your support team answers the same questions by digging through old tickets, PDFs and a stale wiki.
- The knowledge exists in your systems, but only a few long-serving people know where to find it.
- You tried a chatbot on your documents and it answered confidently from things that were not in them.
- Different people may see different records, and any search you add has to respect that.
Probably not the right call if
- Your documentation fits in a few pages, and a well-organised help centre would serve you better.
- You want a model that knows your business without anyone keeping the underlying sources correct.
- The answers people need are not written down anywhere, or are wrong where they are written.
What changes for your team.
Answers people can check
Every answer links to the passages it was built from. Staff open the source and confirm it before acting, instead of trusting blindly or searching again.
Knowledge stops living in a few heads
New staff find what senior people know, in the helpdesk, intranet or admin screen they already have open, rather than in a separate chatbot nobody visits.
No quiet leaks across permissions
A user only gets answers built from records they could already open. Rolling it out does not reopen the question of who is allowed to see what.
The parts that make it hold up in production.
Ingestion that keeps the index fresh
Connectors pull documents, records, tickets and catalogue data into an index, chunked along headings and record boundaries. Edits and deletions arrive by webhook or scheduled sync, so the index does not drift from the source.
Hybrid keyword and vector search
Keyword search catches product codes, names and exact phrases; vector search catches questions worded differently from the document. Both are combined and ranked in Elasticsearch or Meilisearch, depending on the data.
Permissions enforced at query time
Each chunk carries the access rules of the record it came from, and every search is filtered by the asking user's rights. The rules come from your existing roles, not a second list someone has to maintain.
Cited answers inside your tools
Answers appear in your Laravel or WordPress application, helpdesk or intranet, with links to the exact sources used. When nothing retrieved supports an answer, the system says it does not know.
An evaluation set you keep
Real questions with known correct sources and answers, run against every change to chunking, search settings, prompts or models. Regressions show up before users meet them, not after.
Cost and latency controls
Every request logs tokens, retrieval time and model time, with spend limits and caching for repeated questions. Answers stream, so people start reading while the rest is generated.
Retrieval sits between your data and the tools people use.
The index runs on your infrastructure, next to the systems it reads. At question time only the retrieved passages are sent to the model provider, never the whole collection.
-
Where people use it L4Helpdesk sidebar Intranet search Laravel app WordPress admin
-
Answer layer L3Cited answers "I don't know" Streaming Usage logging
-
Retrieval L2Hybrid search Permission filter Result ranking Evaluation set
-
Your systems and data L1Documents and PDFs Support tickets Product catalogue Database records Internal wiki
From first call to running in production.
Each step ends in something you can look at. Scope grows after something is live, not before.
-
01
Collect the real questions
We gather questions people actually ask, from tickets, inboxes and chat, and note where each correct answer lives. That list becomes the evaluation set before any code is written.
-
02
Map sources and permissions
We list every source, how it changes and who may see what. Access rules are taken from your existing roles, and the data boundary with the model provider is agreed in writing.
-
03
Index, search, measure
We ingest one source and tune chunking and hybrid search against the evaluation set before adding the answer layer. Retrieval is measured on its own, because a good model cannot rescue bad results.
-
04
Ship into one tool, then run it
It goes live where people already work, logging questions, sources used and unanswered cases. After launch we close those gaps, add sources and rerun the evaluation on every change.
Published prices, fixed before we start.
€1,000
delivered within a week
We read the system you already have and tell you what is actually wrong with it, what it would take to fix, and what it would cost.
€5,000 – €20,000
typical project
Fixed scope, fixed price, agreed before anyone writes code. Most of what we do sits in this band.
from €750
per month
We take the system over and keep it alive. This is the part most people discover they needed about six months after launch.
What moves the price for Retrieval Over Private Data
- How many sources there are and how cleanly they can be read, since a documented API is simpler than scanned PDFs or an old database with no export.
- How fine-grained the permissions are, from one shared library everyone can read to per-record rules drawn from several systems.
- How fresh the index has to be, since updates within moments of an edit take more work than a nightly sync.
- Where answers need to appear, from a single admin screen to integrations with a helpdesk and an intranet at the same time.
What we work with
Questions we get asked.
The source documents and the index stay on your infrastructure. When someone asks a question, only the passages retrieved for that question are sent to the model provider, not the whole collection. Building the vector index also sends each chunk's text to an embedding model, so we either use a provider you have approved or run the embedding model on your own servers. We agree that boundary in writing before we build.
The model is instructed to answer only from the retrieved passages, and each answer links to its sources. If search returns nothing relevant, the system says it does not know rather than guessing, and the evaluation set includes questions where that is the correct response. This reduces invented answers; where a wrong answer is expensive, people should still open the source before acting.
Not if the permissions in your source systems are right. The filter is applied inside the search query using the asking user's roles, so passages they cannot open never reach the model or the answer. If the current permissions are wrong, the system will faithfully repeat the mistake, which is why we map them before building.
Yes. Real Estate Club Dubai, a property platform we run, has an AI advisor that answers questions against its own directory rather than from memory. Client work follows the same principle, with the permissions, ingestion and evaluation work that a private dataset adds.
Sources change, providers update models and people ask questions nobody expected. On a Run plan we watch unanswered questions, keep connectors working as source systems change, rerun the evaluation set whenever a model or prompt changes, and track spend per request. The code and index configuration live in your repository, so your own team can take it over at any point.
