Practices
Applied AI Spatial computing & XR Physical AI & roboticsProduct studio
Product research Product design Product engineeringRegulated health
Digital health Clinical trials & evidenceMore
AI Research Sectors Approach Insights About Start a projectEach of these can be engaged on its own. They are more useful together, because the seams between research, design, engineering and evidence are where most programmes quietly lose their schedule.
Practice 01 · Layer one
There is a large gap between a model that performs well on a benchmark and a system that behaves acceptably in a clinic, a factory or a patient's home.
We work in that gap: choosing what should be a model at all, proving it on the data you can actually get, and building the evaluation and monitoring that lets you defend it later.
What we do
A six-week feasibility study: can this be done at the accuracy you need, on the data you have, within the compute and latency the product allows, with a written recommendation either way.
Tooling & standards
Practice 02 · Layer one
Immersive technology stopped being a novelty when it started producing measurable outcomes: faster competence, fewer errors, better adherence.
We build for that standard: sessions people will repeat, comfort over a full training block, and instrumentation that shows whether anything transferred.
What we do
A four-week concept build: one representative scenario, running on the target headset, tested with real users, enough to decide whether the full curriculum is worth funding.
Tooling & platforms
Practice 03 · Layer one · our largest practice
If you want to be ahead of the AI race, this is the next front. The last decade of AI happened on screens. The next one happens in warehouses, operating theatres, farms, factory floors and airspace.
Physical AI is what you get when a model has to perceive a real environment in real time, decide, and then act, where being wrong has a cost that cannot be undone with a retry. It is a materially harder problem than text, and it is where the durable advantage now sits.
Why this, why now
Three curves crossed at once. Robot foundation models made general manipulation tractable instead of bespoke. Sensors (especially event-based vision) got fast and cheap enough to perceive motion properly. And simulation got good enough that a policy trained in a datacentre can survive contact with a real machine.
Almost nobody is set up to exploit all three together. It needs an ML team that understands actuator dynamics, and a mechanical team that understands what a learned policy will and will not tolerate. That combination is exactly what this practice is.
Inside the practice
The sensor stack decides the ceiling on everything downstream. Most autonomy problems we are handed are really perception problems wearing a control costume.
Event cameras report per-pixel brightness changes asynchronously, at microsecond latency and enormous dynamic range, for a fraction of the power and bandwidth of a frame camera. For fast motion and awful lighting there is nothing comparable.
Where the field actually moved. Policies that generalise across tasks instead of one hand-tuned routine per part number, and an honest account of where they still fail.
Inspection, survey, logistics and response, where the constraint is rarely flight and almost always perception, endurance, and what the aircraft does when the link drops.
Building the machine itself, from a blank sheet. Mechanism, actuation, structure and controls, designed around what the policy needs rather than around what was convenient to model.
The half that decides whether any of it earns money. A fleet of one is a research project; a fleet of two hundred is a business, and they are not the same engineering problem.
Also within scope
An eight-week rig. We build the one motion, grasp or perception task your product depends on and run it against real parts and real lighting until the failure rate is a measured number rather than an assumption.
"Should we train a policy or program the motion?" Often the answer is programming, and we will say so. Learned policies earn their cost when variation is high and the task is contact-rich, not when a fixture would have solved it.
Stack & standards
Practice 04 · Layer two
The cheapest change you will ever make is the one you make before anyone has committed to an architecture.
Research here is not a slide deck. It produces the requirements, the use environment, the user profiles and the risk inputs that the rest of the programme is formally built against.
What we do
A three-week discovery sprint: interviews, a use-environment map, a framed problem statement and a short list of the assumptions that would sink the programme if they turned out to be wrong.
Frameworks
Practice 05 · Layer two
Design that cannot be manufactured, serviced or cleaned is a rendering.
Our industrial designers sit with the mechanical engineers and our interaction designers sit with firmware, so the decisions that look purely aesthetic are made with their real cost visible.
What we do
A design language sprint: three directions explored to a credible level, pressure-tested against manufacturing and use constraints, ending with one direction and the rationale for it.
Tooling
Practice 06 · Layer two
Electronics, firmware, mechanical and software in one group, because the expensive problems live between them.
We take products through design freeze, verification and transfer to manufacturing, and we stay through the first builds when the interesting failures show up.
What we do
An architecture and de-risking phase: system requirements, the interface definition between hardware and software, and breadboards for whichever subsystem is least understood.
Standards
Practice 07 · Layer three
In digital health the hard part is rarely the app. It is the claim, the evidence behind it, the data path and everyone who has to trust it.
We build connected products with the regulatory pathway, the security posture and the reimbursement story treated as design inputs rather than downstream paperwork.
What we do
A pathway and architecture review: intended use and claim, likely classification, the evidence you will need, and the system design that keeps all three achievable at once.
Standards
Practice 08 · Layer three
Studies are usually delayed by logistics, data quality and site burden, not by the science and not by the platform.
We build the technology that removes those delays, and we build it under the validation regime that lets the resulting data be used.
What we do
A digital endpoint feasibility review: what you want to measure, what the sensor can actually support, what validation the endpoint needs, and what that means for site and participant workload.
Standards
In practice
Almost nothing we do uses one practice alone. These are the combinations we are asked for most often.
Applied AI + Product engineering + Digital health. The model is the easy part. The programme is really about intended use, the boundary between what the model decides and what the clinician decides, the evaluation dataset you can defend, and a change control plan that lets you retrain without re-opening the whole submission.
Usually 9–15 months to submission-ready.
Spatial computing + Product research + Clinical evidence. Content design and clinical design are the same activity here. We define the outcome measure first, build the experience to move it, and instrument sessions so the study you run afterwards has usable data rather than session counts.
Usually a 6–10 week concept phase before any study commitment.
Robotics + Product design + Product engineering. Research instruments are built to work when an expert is present. Turning one into a product means designing for the operator who is not an expert, the consumable that varies, and the service engineer who has to fix it in the field.
Usually 12–18 months to pilot production.
Product research + Digital health + Clinical evidence. Retention is a design problem wearing a logistics costume. We look at the whole participant path (recruitment, provisioning, first week, the moment most people drop) and rebuild the parts that cost you the most people per unit of effort.
Usually a 4-week diagnostic, then targeted rebuild.
Product engineering + Product design + Applied AI. A common position for companies with strong hardware and a decade of accumulated firmware. The work is usually a platform architecture, a connectivity and data strategy, and one visible product built on top to prove the platform is real.
Usually a 3-month architecture phase, then parallel tracks.
Next step
Most clients aren't at first. Describe the outcome you're after and we'll tell you which practices it actually takes, including when the answer is fewer than you thought.