Services
A demo takes an afternoon. Something that answers correctly from your own content, refuses when it should, only ever quotes what the person asking is cleared to see, and still costs the same next quarter — that part is engineering.
The demo convinced the room. Production asks four harder questions.
With no grounding and no citations, the model fills gaps with something plausible, and nobody reading the answer can tell which half to trust.
An index built across everything will happily quote the salary review to whoever asks. Grounding without access control is a breach waiting to happen.
Stuffing context into every request is cheap in a pilot and ruinous at real traffic, and the invoice explaining it arrives a month later.
Without an evaluation set, every model change is a guess and every regression is found by whichever user happens to be unlucky.
Evaluation first, then grounded retrieval, then the interface.
Answers drawn from your documents with a link to the paragraph behind them, and a system built to say plainly that it does not know.
Your access rules travel with the index, so a user can only be answered from documents they were already entitled to open.
Built from your real questions before any model is chosen, so quality is measured rather than argued about in a meeting.
Context budgets, model tiering, and caching, with cost per request treated as a first-class metric rather than a surprise.
Two representative slices of a typical build.
Staff ask in plain language and get an answer drawn from your own policies and documentation, linked to the paragraph it came from and filtered to what they are cleared to read.
A scored set built from your real questions, run against candidate models so the decision rests on evidence about quality, cost, and latency rather than on whichever model is in the news.
Production features, not notebooks or proofs of concept.
Your content chunked, indexed, and tuned until citations hold.
Access rules carried into the index, not bolted on after.
A scored eval set that makes the choice defensible.
Context assembled deliberately, within a budget.
For stable behaviour and format, or to cut inference cost.
Input and output checks, and a defined way to decline.
Model tiering and caching, with cost per request tracked.
The measure before the model, and permissions before the index.
We collect real questions and the answers you would accept. Everything after this is measured against that set rather than against an impression.
Content indexed with its access rules intact, and retrieval tuned until the citations survive being checked by someone sceptical.
Guardrails, refusal behaviour, context budgets, and load testing at traffic you actually expect rather than traffic that flatters the design.
Staged release with quality and cost per request monitored, then retuning on the questions real users actually ask.
Directional outcomes from comparable builds — not contractual targets.
Answers you can check
Every response links to the source paragraph, so trust is verifiable.
Nothing leaked by retrieval
Users are answered only from documents they could already open.
Cost per request you set
Budgeted and tracked, rather than discovered on an invoice.
Whichever one wins your evaluation set. We build the set first, then score candidates against it on quality, cost, and latency. The right answer depends on the task and changes every few months as models ship, which is exactly why the measure matters more than the pick.
Usually both, for different jobs. Retrieval handles knowledge that changes — policies, documentation, prices — because you update a document rather than retrain. Fine-tuning is for stable behaviour: tone, format, following your conventions. Fine-tuning to teach facts is the expensive way to get a model that is confidently out of date.
Retrieval grounds each response in your own documents, answers carry a citation back to the paragraph, and the system is designed to decline rather than improvise. Then we measure that behaviour on the evaluation set, because assuming it is the same mistake as hoping.
Not if retrieval is built correctly, and this is the failure we design against hardest. Your access rules are attached to the index, so a query can only ever be answered from documents that user could already open. A grounded assistant without permission filtering is a search engine over your most sensitive files.
Not under the enterprise API terms we deploy on, and we set retention explicitly rather than trusting a default. Where your policy requires that nothing leaves at all, we run open-weight models inside your own environment.
Context is budgeted per request, cheaper models handle the easy majority with escalation only where it earns its cost, and caching absorbs repeat questions. Cost per request is a tracked metric from the first week, not a line item someone queries later.
It depends on how much content is in scope, how clean it is, and how strict the permission model has to be. Building the evaluation set comes first and is deliberately small, so the decision to continue rests on measured quality rather than on a pitch.
Bring the use case. We will bring the evaluation set and an honest read on feasibility and cost.