Retrieval that fits your corpus
Chunking, embedding and ranking tuned against your documents and your query patterns. A benchmark score tells you how a strategy performs on someone else’s data.
AI Development
BuildThe model is the easy part. Everything else is the work.
Applied AI systems built with retrieval, evaluation and observability from the first commit — because those decide whether it still works in month six.
Typical stack
- Claude
- OpenAI
- Gemini
- LangGraph
- pgvector
- Python
- Next.js
- PostgreSQL
Written for: A technical or operational buyer who has seen an AI demo work and does not trust it to survive real users.
Who it is for
Is this built for a business like mine?Built for businesses where a wrong answer costs something.
The engineering below matters in proportion to what an error costs you. If a bad output is an inconvenience, most of it is overkill. These are the businesses where it is not.
What we see
Applications, statements and KYC packs arrive as unstructured files, and a qualified person reads every one before anything can move.
What we build
Document extraction with a confidence score on every field, a review threshold that routes anything uncertain to a human, and a lineage record for each figure.
The detail that matters
The threshold is a business decision, so it is a setting you own — not a constant in our code.
What we see
Purchase orders arrive as emailed PDFs and someone types part numbers into an ERP all day.
What we build
Order extraction validated against your live catalogue, with anything below confidence held for a human rather than guessed.
The detail that matters
Part numbers are validated against what you actually stock, so a plausible-but-wrong SKU fails instead of shipping.
What we see
Rate confirmations and BOLs are re-keyed from PDF into a TMS that was written a decade ago.
What we build
Extraction into your TMS on its own terms — file drop, EDI or a legacy endpoint — with exceptions surfaced rather than silently corrected.
The detail that matters
We integrate with the system of record you have, not the one a modern architecture diagram assumes.
What we see
Clinical documentation holds the answer to a question staff ask twenty times a day, and finding it takes minutes each time.
What we build
Retrieval over your documentation where every answer carries its source, and the system declines rather than infers when the source is not there.
The detail that matters
Where data cannot leave your infrastructure, the system runs inside it. That is decided on day one.
What we see
Onboarding documents arrive in a dozen formats and half a dozen languages, and a trained reviewer opens every one before an account can be funded.
What we build
Document extraction with a confidence score on every field, validated against the issuing format, holding anything uncertain for a reviewer rather than guessing it.
The detail that matters
Every extracted field carries its evidence and the policy version it was checked against, so a decision is reconstructable for a regulator years later.
And who it is not for
If you want a chatbot on a marketing site answering general questions, this is more engineering than the job needs, and we will say so on the first call.
The problem
Do they understand what is actually going wrong?The demo works. That is the problem.
A prototype is a model, a prompt and a handful of examples that someone chose. Production is every input a real user can type, every document nobody cleaned, and a stakeholder asking why the answer changed. The distance between those two states is not model quality — it is the engineering nobody budgeted for.
It answers well on the examples used to build it, and poorly on the ones nobody thought of.
A prompt was changed last week. Nobody can say whether that made things better or worse.
It is right most of the time, and there is no way to know which times.
It cannot reach the systems where the real data lives, so it works on a copy that is already stale.
What we build
What exactly would I be buying?We build the four things that are not the model.
Choosing a model is an afternoon. Retrieval quality, measurement, failure behaviour and observability are the months, and they are ordinary software engineering rather than research — which is precisely why they get skipped and precisely why we do them first.
An evaluation set that grows
A labelled set built from your real cases, extended every time something fails. Prompt and model changes are then measured rather than argued about in a meeting.
Failure that is visible
Structured outputs, schema validation and explicit refusal paths, so the system says it does not know instead of inventing something fluent.
Traces you can read
Every call recorded with its retrieved context, its cost and its latency. When an answer is wrong, the question is what happened, not what might have happened.
How it works
How does this actually function?What happens between the question and the answer.
Most of an AI system is the part that decides what the model gets to see, and what happens when it responds badly. Both are inspectable.
Query
Retrieve
Rank
Generate
Validate
Refuse & logAnswer
Retrieval is scored before generation, so a bad answer can be traced to a bad document rather than blamed on the model.
Validation runs against a schema. A response that does not fit the contract never reaches the user.
Refusals are logged as first-class events. They are the cheapest source of new evaluation cases you will ever get.
What changes
What is different afterwards?What is different afterwards.
Quality moves in one direction
Every change is scored against the evaluation set before it ships, so improvements accumulate instead of trading one regression for another.
Regressions caught before deployment rather than by a customer.
Spend stops surprising you
Token cost is traced per feature, with caching where inputs repeat and routing to a smaller model where a smaller model is sufficient.
Cost per transaction, visible per feature, not one monthly invoice.
Wrong answers become explainable
A full trace means a complaint turns into a fifteen-minute investigation with a specific fix, instead of a discussion about whether AI is reliable.
Root cause identified from the trace, not reproduced by guesswork.
How we deliver
How does this start, and what do I get at each step?Six stages, and every one has an exit.
You can stop after any stage with something useful in hand. That is the point of naming the artefacts rather than the activities.
- 01
Decision mapping
What decision is this system making, how often, and what does a wrong one cost? If the answer is "not much", we say so.
- The decision written down with its failure cost
- Data and systems inventory
- A go or no-go recommendation, including no
- 02
Evaluation first
Before any prompt work, we agree how quality gets measured. This is the step most projects skip and the reason most projects stall.
- Labelled evaluation set from your real cases
- Scoring rubric and pass threshold
- A baseline score before any tuning
- 03
Retrieval build
Ingestion, chunking and ranking, tested against the evaluation set rather than against intuition.
- Ingestion pipeline
- Retrieval scored against baseline
- Documented chunking strategy and why
- 04
System build
Generation, validation, refusal paths and the integrations into your existing systems.
- Working system in your environment
- Schema contracts
- Integration tests
- 05
Shadow run
The system runs against real traffic without acting on it, so its failure modes appear before anyone depends on them.
- Shadow report with failure taxonomy
- Evaluation set extended with real failures
- Go-live checklist
- 06
Handover
You own the code, the evaluation set and the runbook. If we stop working together, nothing stops working.
- Repository and infrastructure in your accounts
- Runbook and escalation paths
- Training session, recorded
Questions
But what about the thing that worries me?The questions people actually ask.
How long before something is running?
A scoped first system is typically six to ten weeks, with the evaluation set agreed in the first two. If a proposal promises production AI in two weeks, it is describing a prototype.
Do we need to move our data somewhere?
No. Where data cannot leave your infrastructure, the system is designed to run inside it — that constrains the model choice and the architecture, so it is decided during discovery rather than discovered later.
Which model do you use?
Whichever passes your evaluation set at acceptable cost and latency, and it is usually more than one — a capable model where judgement is needed, a cheaper one where it is not. Because evaluation exists, swapping models later is a measurement rather than a rebuild.
What if the AI gets something wrong?
It will. The design question is what happens next: whether it fails visibly, whether the failure is logged with enough context to explain it, and whether the case joins the evaluation set so it does not recur. All three are built in.
Who owns the code?
You do, from the first commit, in your repository and your cloud accounts. There is no runtime licence and no dependency on us continuing.
The other half
And then someone has to handle the ones it refused.
A system built to decline rather than guess will decline. That is the correct behaviour and it produces a queue — of edge cases, unusual documents and questions the corpus never covered. We staff that queue too, which is why our refusal thresholds are set where they should be rather than where they flatter a demo.
Data Entry & ProcessingStart
What is the next step?Tell us the problem, not the specification.
A short call is usually enough to say which half of the business your problem belongs to, roughly what it costs, and whether it is worth doing at all.
Related services
- AI EngineeringAI AgentsAutonomous agents that plan, call real tools against real systems, and leave a trace of every action — with human approval gates on anything consequential.
- AI EngineeringAI Voice AgentsVoice agents that answer, qualify and book against live availability — and hand a warm call to a person the moment the conversation needs one.
- DevelopmentWebsite DevelopmentFast, accessible, search-legible websites built on a performance budget — and handed over as a codebase you own, not a platform you rent.