02 — Practice

Custom AI software for five fields that punish a confident guess.

Legal, healthcare, higher education, accounting and manufacturing look unrelated until you watch a general-purpose assistant fail in each of them. It fails differently every time. We build for one organisation at a time, from their requirements — and we reach for whichever AI technique the problem actually calls for.

Where we work

Five fields, five different failure modes.

Anyone can demonstrate a model summarising a contract or a chart note. The gap between that demonstration and something a professional will put their name to is specific to each field, and it is where the work is.

Legal

The work

Contract review and comparison, discovery at volume, research across precedent, drafting from playbook, obligation and deadline extraction.

Why generic AI fails here

General assistants are built to always produce an answer. In legal work a fabricated citation is not a rough edge — it is a filing struck from the record and a professional consequence attached to a name. What is needed is a system that can return “no support found” and mean it, with every proposition traceable to the passage it came from.

What a build usually takes

Layout-aware OCR · clause segmentation · entity extraction · hybrid retrieval · language models for drafting only

Healthcare

The work

Clinical documentation, intake and triage support, coding assistance, prior-authorisation paperwork, retrieval across a record or a body of literature.

Why generic AI fails here

Two hard constraints arrive at once. Patient data frequently cannot reach a third-party API at all, which forces the deployment question before the product question. And anything edging toward diagnosis crosses into regulated territory. The buildable, valuable work is usually the documentation burden — the hours a clinician spends typing instead of with a patient.

What a build usually takes

Speech recognition · clinical entity extraction · structured extraction from scanned forms · retrieval · self-hosted inference

Higher education

The work

Feedback and grading support, course material development, literature review, student services, surfacing an institution’s own accumulated teaching and research material.

Why generic AI fails here

The obstacle is rarely capability. Faculty will reject — correctly — a system that cannot show its reasoning, student records carry their own legal regime, and academic integrity questions arrive attached to every tool. Anything that cannot explain why it reached a judgement is unusable here regardless of accuracy.

What a build usually takes

Retrieval over institutional corpora · semantic similarity · rubric-aligned classification · language models with visible sources

Accounting and finance

The work

Invoice and receipt extraction, reconciliation, month-end preparation, regulatory reporting, sifting exceptions out of high-volume transaction sets.

Why generic AI fails here

Language models are unreliable at arithmetic and fail in the worst possible way: a total that is wrong but entirely plausible. The correct architecture never lets the model calculate. It extracts and classifies; deterministic code does every sum; and each figure carries a link back to the source document, because the reviewer’s real question is always “where did this number come from”.

What a build usually takes

Document AI and table extraction · rules engines · statistical anomaly detection · language models for classification only

Manufacturing

The work

Specification and part matching, quality and defect reporting, maintenance knowledge capture, supplier document intake, technical documentation and work instructions.

Why generic AI fails here

The expertise that runs a plant sits in the heads of people approaching retirement and in filing cabinets nobody has indexed. Meanwhile the shop floor is hostile to software — patchy network, gloves, noise, screens nobody is looking at. And a mis-matched specification is not a bad answer, it is a scrapped batch.

What a build usually takes

Computer vision for defect detection · time-series models for maintenance · OCR on specification sheets · retrieval over service logs

The toolkit

A language model is one instrument, not the orchestra.

Since 2023 almost every proposal in this space has been a language model with a prompt attached. Plenty of these problems are solved better, cheaper and far more reliably by techniques that predate the current wave — and knowing when to reach for which is the engineering.

Computer vision: Defect detection, measurement, reading a gauge or a label. Orders of magnitude cheaper and steadier than asking a multimodal model to look at the same frame.
Speech: Ambient transcription where the alternative is a professional typing up notes after the fact.
Document AI: Layout analysis, table extraction, OCR across forms nobody designed to be machine-readable.
Classical machine learning: Anomaly detection, forecasting, risk scoring. Decades old, well understood, and frequently the correct answer.
Retrieval: The part that decides whether a language model sees the right passage — and where most failures blamed on the model actually originate.
Language models: Drafting, summarising, classifying, and calling the tools above. One instrument in the set, not the set.

How we engage

Built for one organisation. Handed over to it.

Requirements come from your work

We sit with the people doing the job, including the ones who never appear in the requirements document. What gets built follows from that, rather than from a roadmap written for someone else.

Not a platform you configure

There is no product here we are steering you toward. Two clients in the same industry get different systems, because their constraints, their existing software and their exceptions are different.

Deployed where the data can live

Hosted inference where that is permitted; open-weight models on your own hardware where it is not. We tell you what the second option costs in accuracy instead of pretending it is free.

It becomes yours

Source, infrastructure-as-code, documentation and runbooks transfer to your team. Continuing support is something you may want, never something you are trapped in.

Build decisions

What separates a demo from a deployment.

The same five choices recur in every engagement, whichever field it is. Getting them wrong is why so much industry AI stalls after the pilot.

Citation before generation: Retrieval is built and measured on its own before any answer is drafted on top of it.
Calculation belongs in code: Anything arithmetic runs as deterministic code the model calls. It decides what to compute; it never computes.
Refusal is a feature: Returning nothing when the corpus does not support an answer is worth more in these fields than being right slightly more often.
Inside the tools already in use: Output lands in the case management system, the EHR, the LMS, the ledger. A tool needing its own login gets abandoned by the second month.
Measured in professional hours: Not benchmark scores. How long the task took before, how long now, and how often a reviewer has to correct it.

In these five fields, a system that knows when to say nothing is worth more than one that is right slightly more often.

What we optimise for

Working in one of these five?

Tell us the task that eats the most qualified time, and what happens when it goes wrong. If an existing product already covers it, we will name the product — that answer is cheaper for both of us than a build that should not have happened.

Start a conversation How we work