Four AI applications that a business can be accountable for
Every model here ships with three things: a confidence threshold, a human review queue for anything below it, and an evaluation report an auditor can read. That is the difference between an AI feature and an AI demo.
- 4 models live
- Python
- PyTorch
- FastAPI
- PostgreSQL
- Docker
Never silently guess
Below the confidence threshold, the case goes to a person. A wrong answer costs more than a slow one.
Measure before promising
We evaluate on a held-out set drawn from your real documents, not a public benchmark, before quoting an accuracy figure.
Always have a rollback
Every model version is registered and can be reverted in one command without a deployment.
A named human owner
Each model has a person in the client's team accountable for its output. Not "the AI".
Invoice & document extraction
A distribution business received roughly 4,000 supplier invoices a month as scans, PDFs and phone photographs. Two people keyed them into the ERP.
How it works
- Normalise. De-skew, de-noise and page-split whatever arrives — including photographs taken at an angle in poor light.
- Detect. A layout model locates field regions and the line-item table, rather than relying on fixed coordinates that break with every new vendor template.
- Read and validate. Text recognition, then business validation: does the GSTIN checksum pass, do line items sum to the taxable value, does the total match the tax computation?
- Route by confidence. Above 95% and arithmetically consistent, the invoice posts as a draft. Below it, the specific field is queued for a human with the region highlighted.
- Learn from corrections. Every human correction is stored as labelled data and folds into the next training run.
The validation layer does more work than the model. Arithmetic consistency catches most extraction errors without any machine learning, and it is the reason straight-through processing is safe at all.
Field-level accuracy
Held-out set of 1,200 real invoices
Where invoices end up
Confidence routing, last 30 days
What it changed
Demand forecasting
Nine warehouses, 2,400 SKUs, and a purchasing team working from last year's number plus instinct.
We forecast weekly demand per SKU per warehouse, with seasonality, festival calendars and promotion flags as features. The output is not a single number: it is a range, and the re-order suggestion uses the upper bound for fast-moving items and the median for slow ones.
- Gradient-boosted models per product family, retrained weekly on the last three years.
- Festival and school-calendar effects supplied as explicit features, because they move this business more than trend does.
- New SKUs fall back to a category-level model until they have twelve weeks of history — stated plainly in the UI rather than pretending to know.
- Buyers can override any suggestion; overrides are tracked and reviewed monthly, and they are how we found two data errors.
Forecast error against the previous method
Mean absolute percentage error — lower is better
Support ticket triage
Inbound support mail was read by one senior engineer each morning and forwarded by hand. He was the bottleneck and he knew it.
A classifier assigns each incoming ticket a product area, a severity and a suggested queue. Severity is the sensitive one, so the rule is asymmetric: the model may raise severity automatically but never lower it — only a human can downgrade.
- Multi-label classification over product area, module and severity.
- Duplicate detection against open tickets, which alone removed 9% of the queue.
- Confidence below threshold routes to a general queue rather than a wrong specialist.
- Weekly report of the model's mistakes, reviewed with the support lead.
Classifier quality by label
Precision and recall on a held-out month
Operational effect
Measured over the first full quarter after rollout.
Policy assistant with citations
A 400-page policy and process library that staff were expected to know, and reasonably did not.
A retrieval-based assistant answers questions over the client's own documents. The design constraint that shaped everything: no answer without a citation. If retrieval finds nothing relevant, the assistant says so and offers the closest documents instead of composing something plausible.
- Documents chunked with their heading path retained, so a citation points to a section a person can find.
- Every answer shows its sources, and a click opens the exact paragraph.
- Access-controlled retrieval — the assistant cannot surface a document the asker could not open themselves.
- Answers are logged with their sources, so a disputed answer can be reconstructed later.
- An unanswered-question report goes to the policy team weekly; it has become their best guide to what needs rewriting.
On the limits: this assistant summarises documents. It does not interpret policy, approve exceptions or give legal advice, and the interface says so on every screen. Where a question needs judgement, it routes to the named policy owner.
The pipeline behind all four
The same delivery machinery serves every model. Nothing here is bespoke per project, which is why a fifth model is cheaper than the first.
Where an AI project's hours actually go
Share of total effort across our four builds
Inference latency, per optimisation step
Median response time, document extraction
How we decide a model is good enough
| Gate | What we require | Why |
|---|---|---|
| Held-out accuracy | Measured on your data, never on a public benchmark | A benchmark score tells you nothing about your vendors' invoice layouts. |
| Worst-slice accuracy | No important segment more than 5 points below the average | An average hides a model that fails on one branch, one vendor or one language. |
| Calibration | Confidence must actually predict correctness | Confidence routing is only safe if the number means something. |
| Human agreement | Reviewers accept the output at least 90% of the time | Users abandon a tool they have to second-guess. |
| Failure cost | A written answer to "what breaks if this is wrong?" | It decides the threshold. A wrong severity is not a wrong invoice total. |
| Rollback | Previous version revertible in one command | Drift is not hypothetical; it is scheduled. |
What we tell clients before they sign
If you do not have labelled data, the first phase is labelling
There is no way around it. We usually build a small labelling tool, train two of your staff, and budget four to six weeks. Anyone who tells you their model needs no data from you is selling you someone else's problem.
Accuracy will drift, and we plan for it
Vendors change invoice templates, product mixes shift, a new branch opens. We monitor input distribution and output confidence, alert on drift, and include a scheduled retrain in the support contract rather than waiting for someone to complain.
Some processes should not be automated at all
We have talked two clients out of AI: one wanted automated shortlisting of job applicants, where the failure cost falls on people who never learn why; the other wanted automatic credit decisions on data too thin to support them. In both cases we proposed a decision-support screen instead, and built that.
A model is not a product
The model is perhaps a quarter of the work. The queue, the review screen, the audit trail, the escalation path and the training are what turn it into something a team actually uses on a Monday morning.
Start with a feasibility note, not a pilot
Two weeks, a sample of your data, and a written answer on whether this is worth building — including "no" if that is the answer.