This is a prototype built for a client. A trained model analyzes a veterinary sample and returns results with confidence percentages rather than a bare yes or no, and a professional reviews the output before anything is acted on. Results attach to an individual animal so change can be tracked over time. The system is patent pending and the intellectual property is the client’s, so nothing about how it works is published here.
The operating constraint behind the prototype
The problem was not that the analysis could not be done. It was where it had to be done, how the answer arrived, and what happened to it afterward.
The sample travels to the analysis rather than the other way around
Analysis happens where the equipment is. The animal is somewhere else. That gap sets the pace of everything downstream: when a result comes back, whether it arrives while the animal is still in front of somebody, and how often it is worth doing at all.
A yes-or-no answer hides how sure it is
Output presented as a single verdict tells the reader nothing about whether it was a close call. Two results can look identical while one was unambiguous and the other nearly a coin toss. A professional deciding what to do next needs that difference.
One reading in isolation is hard to act on
A number on its own raises a question rather than answering one. What a professional usually wants to know is whether this is different from last time and in which direction. A system producing excellent isolated readings and no history has solved the smaller half of the problem.
An automated result nobody reviewed is a liability
The moment a system produces output acted on without a qualified person looking at it, it has taken on a responsibility it cannot carry. That constraint shaped the product more than any technical consideration, and it is why review is a designed feature rather than a policy note.
The data generated during use is usually discarded
Every reviewed case is information about how the system performs on real samples. In most deployments that evaporates because nothing was built to retain it in usable form. Designing for retention from the start costs little; retrofitting it later usually means starting over.
The review and escalation policy, band by band
This is the policy governing what the system shows and what it asks for, by confidence band. Bands are named rather than numbered on purpose. The numeric boundaries between them are set with the client’s professional oversight and are not published.
| Confidence band | What the system shows | What it asks the user to do | Who decides |
|---|---|---|---|
| High | The leading result with its confidence figure, and the same figure for the alternatives it was weighed against | Review the output before it is recorded against the animal | The reviewing professional |
| Moderate | The leading result and its confidence, presented alongside the next most likely results rather than above them | Examine the sample directly before recording anything | The reviewing professional |
| Low | The candidate results and their confidence figures, with none of them presented as the answer | Treat the output as a pointer to look at, not as a finding | The reviewing professional |
| Split or conflicting | That the system did not resolve to one result, and what it was choosing between | Recapture the sample or escalate to a second opinion | The reviewing professional |
| Insufficient | That the sample could not be assessed, and why in general terms | Recapture; no result is offered and none is recorded | Nobody yet, because there is nothing to decide on until a usable sample exists |
What the prototype does, described from the user's side
The analysis happens where the animal is
A sample is analyzed at the point of care rather than being sent somewhere and waited on. That is the reason the project exists. How it is achieved is patent pending and belongs to the client, so this page describes the property and stops there.
Results come back as confidences, not a verdict
The output is a set of candidate results, each with a confidence figure, rather than a single answer. The reader can see whether the system was clear or was choosing between close options, and weight what they do next accordingly.
A professional reviews before anything is acted on
Nothing is recorded against an animal, and nothing is communicated onward, until a qualified person has reviewed the output. The review step is enforced by the product rather than left to protocol, because a review that depends on discipline stops happening on a busy day.
Results attach to the individual animal
Each reviewed result is held against a specific animal rather than as a standalone reading. That has to be decided at the beginning, since retrofitting identity onto a pile of historical results is rarely worth attempting.
Change over time is the view that matters
Because results are held against the animal, a professional can look at a sequence rather than a single point and see direction and rate of change. This was specified alongside the analysis itself rather than added later.
Designed to improve, not self-updating
The system is designed so that reviewed cases can be gathered and used to improve the model in later versions. That is a design intent about how the product is meant to develop, not a live capability: nothing about the model changes on its own while the system is in use.
What is deliberately not claimed
This is a prototype. It makes no diagnostic or clinical claim, it is not a substitute for professional judgement, and no accuracy or performance figure for it appears anywhere on this site.
Where this kind of work sits in the practice
- custom software and AI development — Model-backed products where the review boundary and the escalation policy are part of the build rather than documentation around it.
- custom application development — The application around a model, which is usually where most of the work turns out to be.
- workflow automation services — Fitting an automated step into a professional's routine, so review is the path of least resistance.
Is this a fit for your business?
A good fit when
- You have a model or an analytical method that works and no product around it
- A qualified person has to review the output before anyone acts on it, and you want that enforced
- The value depends on results being comparable over time for the same subject
- You hold or are pursuing intellectual property and need a partner who will not publish it
Probably not a fit when
- You want results going straight to an end user with no review step
- You need regulatory clearance work rather than product engineering
- You expect a performance figure before there is data to support one
What to have ready
- Whatever data you already have, in whatever state, including the cases that went badly
- A qualified reviewer who can define what each confidence band should trigger
- Agreement on what is yours, in writing, before a line of anything is written
Questions we get asked
How accurate is it?
We do not publish accuracy figures for this system, and you should be sceptical of anyone who publishes them for a prototype. What the product presents is a confidence figure with each result, which describes how the output is formatted rather than how often it is right. Performance characterisation belongs to the client.
Does the system get better as it is used?
It is designed to. Reviewed cases can be gathered and used to improve the model in a later version, and that shaped how the product was built. It is not a system that updates itself in the field. Design intent and live capability are different things and we keep them separate.
Why can you not describe how it works?
It is patent pending and the intellectual property is the client’s, not ours. That covers the capture side, the analysis approach, and the device. What we can describe is the product: what a user sees, what governs the review, and how results are held over time.
Is this a diagnostic device?
No, and nothing here should be read as a diagnostic or clinical claim. It is a prototype producing analytical output for a qualified professional to review and interpret. Whether a future version pursues any particular classification is the client’s decision.
Related
- a simulation engine productized as a diagnostic service
- mobile construction estimating and field operations platform
- custom software and AI development
- selected product, application and workflow projects
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.