// AI systems architecture & autonomous operations
I build AI systems that run on hardware, not just in the cloud.
Thirty years of embedded engineering — from the first instruction after reset, through the drivers and the operating system, up to the application architecture on top — pointed at machine learning that has to work on a board with a power budget, in a room with people in it, without an engineer standing over it.
Accepting select engagements// annunciator panel · lamp test
every lamp lit deliberately, to prove none has failed
// the premise
A dark factory runs unattended. This one runs in a bright room.
A classic dark factory needs no accommodation for humans, because there are none: lights off, noise irrelevant. The systems I build are fully automated while surrounded by people, during something that matters to them. That inverts the defaults. Silence becomes a requirement. Motion becomes a distraction. And failure has to degrade, never halt — because the thing in front of the audience does not stop.
// capabilities
Models that run on the metal, inside a real power and thermal envelope — where latency is measured, not assumed, and the network is optional.
Production pipelines with no human in the loop, built to refuse rather than guess. A stage that cannot verify its own output stops and says so.
Hardware and software designed together, from schematic to boot to application — and reviewed adversarially before anyone believes it works.
// measured, not claimed
A Hailo-8 accelerator benchmarked at 58.7 frames per second. Nothing had failed. The board was healthy, the model was correct, and the run completed cleanly.
The compiled binary had been built for the Hailo-8L — the 13 TOPS part — and was running on the 26 TOPS Hailo-8. The vendor's own tool spotted it, printed a one-line warning, and ran it anyway. The right build measured 309.4 FPS on the same board with the same model: 5.3×, from a filename suffix.
That is the failure worth designing against. Not a crash — a plausible number. It looks like it works, it produces a figure you would happily put in a report, and nothing downstream can tell that it is wrong by a factor of five.
// record
An eclectic engineering background, and the list is the point. Precision bench instruments. Medical devices under FDA. Carrier networking. Consumer audio at very high volume. Defence research. Now AI on hardware. Different products, different regulators, different decades — and underneath all of them one problem: knowing whether the thing actually works.
// how I work
Spend the parts. Internal loopback, bounded ring buffers, an identity record on every board. A box that cannot tell you why it failed costs more in field service than the components you saved by leaving them off.
A factory can stop the line and wait for a technician. A system performing in front of people cannot. Whatever fails, something sensible keeps going out.
Not evidence. Corrupt a known-good artefact in exactly the way the check exists to catch, and watch it bite. Until then you have a test that only knows how to pass.
A model does not improve because someone thought hard about it. It improves because the cases it got wrong were collected, looked at, and fed back. Without that loop quality stops moving at whatever level it happens to be sitting — and the worse part is that you cannot tell it has stopped.
Especially before saying something does not exist, is not wired up, or cannot be done. Read the code. Take the measurement. Inference is how confident wrong answers get made.
// contact
Or
Remote consulting in AI systems, edge AI and embedded machine learning: architecture, review, and finding out what is actually happening. Short engagements welcome — a week of measurement is often worth more than a month of opinion.
Happy in front of your customers as well as your engineers — a lot of this work has been explaining a technical position to the people who have to buy it.
Useful things to send with a first message: what the system has to do, what it is doing instead, and how you know.