The work
we take on.
Six programme shapes we are built for. Each one describes the problem as clients usually bring it to us, what the work actually turns out to involve, and what finished looks like.
Most of our work sits under NDA in regulated programmes. Named references and detailed case material are available on request once we are talking properly.
Point-of-care screening
with on-device inference
How it arrives
A model performs beautifully in a research notebook on a curated dataset. The company now needs it inside an instrument used by non-specialists, in clinics with unreliable connectivity, and defensible to a regulator.
What the work really is
Rebuilding the evaluation set so it represents the population that will actually be screened. Quantising the model to run on embedded hardware without losing the sensitivity the claim depends on. Designing what happens when the model is uncertain, which is the part clinicians judge you on. Then a change control plan so the next model version does not reopen the submission.
What finished looks like
- An offline-capable instrument with a bounded, documented operating envelope
- An evaluation dataset and protocol that survives external scrutiny
- Subgroup performance analysis, written before anyone asks for it
- Drift monitoring in production with a defined retraining trigger
Procedural VR training
with competence scoring
How it arrives
A training team has a budget, an impressive demo and no way to prove the headsets changed anything. Adoption stalls at the pilot because nobody can justify the next order.
What the work really is
Defining the outcome measure before building anything. Working out where fidelity actually changes learning (usually a narrow set of moments) and deliberately not spending there elsewhere. Building an assessment model a training director will accept. Then testing comfort across a full session rather than the ten-minute demo.
What finished looks like
- Scenarios validated against how the procedure is really performed
- Per-trainee competence records that integrate with an existing LMS
- Comfort and cybersickness measured across full training blocks
- A fleet provisioning and hygiene model that survives real deployment
Sample-handling robotics
for a high-throughput lab
How it arrives
Throughput targets that require automation, and a prototype cell that works when a specific engineer is standing next to it. Nobody can say what the real cycle time is once faults are included.
What the work really is
Characterising consumable variance properly, because that is usually what defeats the gripper. Designing a recovery routine an ordinary operator can run in under a minute. Building a rig that runs thousands of real cycles so the mis-pick rate becomes a number. Modelling throughput with faults in it, not without.
What finished looks like
- Measured cycle time and fault rate against real consumables
- A recovery path designed for the operator who is not an expert
- Safety architecture and risk assessment appropriate to the cell
- Telemetry that predicts service needs before a stoppage
A decentralised study
rebuilt around retention
How it arrives
Enrolment is fine and the platform works. Participants are still disappearing between week two and week six, and the assumption is that the app needs more features.
What the work really is
Mapping the whole participant path, including the parts that are not software: how the device arrives, what the first evening at home is like, what happens when a wearable stops syncing on a Sunday. Retention problems are almost always concentrated in two or three of those moments.
What finished looks like
- A diagnosis of where participants are actually lost, with evidence
- Rebuilt provisioning, onboarding and support for those specific moments
- Reduced site burden per participant visit
- Data pipeline validated under 21 CFR Part 11 end to end
A benchtop instrument
turned into a product
How it arrives
A research instrument that produces excellent data and exists in a quantity of four. It was built by the people who use it, and every one of them knows which panel to press when it misbehaves.
What the work really is
Separating what the instrument does from how it was built. Redesigning for an operator with no institutional memory, a service engineer with a flight to catch, and a contract manufacturer who needs tolerances that hold at volume. Usually this means fewer adjustable parameters, not more.
What finished looks like
- A manufacturable design with a costed BOM and second sources
- Usability validated with operators who did not build it
- Serviceability designed in, with field-replaceable modules
- Full transfer package and support through pilot builds
A wearable crossing into
regulated territory
How it arrives
A successful wellness product whose next feature is, in regulatory terms, a diagnostic claim. Nobody inside the company has yet said this out loud, and the launch date is already public.
What the work really is
Being precise about what is being claimed, then designing the smallest version of that claim which is both useful and substantiable. Validating sensor accuracy in the population that buys the product rather than in a lab cohort. Deciding what runs on-device, because latency and privacy are product decisions here, not infrastructure ones.
What finished looks like
- A clear line between the wellness product and the regulated feature
- Sensor performance validated in a representative population
- A regulatory pathway chosen before architecture lock, not after
- On-device processing with a defensible privacy posture
Next step
Recognise your
programme here?
Tell us which of these is closest to your situation, and where it stops matching. The gap is usually the interesting part.