Alain Morris Engineer, founder, researcher.
I build AI and the systems underneath it, for work that can’t fail quietly.
Transit, railway safety, field robotics, health records. From research to production. San Ignacio, Belize. Building anywhere.
I build the systems you only notice when they fail: how a town moves, how a railway stays safe, how a robot keeps working, how a record gets where it is going. A screenshot can’t show that. So they run here, and you can break them.
Korea National University of Transportation, 2024 to 2026
I can tell you how a transit system will behave before anyone buys a bus.
On-demand shuttles are expensive to get wrong. I built the simulator that gets them wrong first, cheaply: fleets, demand, rush hours, and dispatch policies that learn from which rides people accept. This is a small one. Call a ride, then take shuttles away and watch the wait climb.
Click a corner to call a ride. Drag to turn the town.
- Mean wait
- —
- Waiting
- —
- Riding
- —
- Delivered
- —
- 900
- full simulation runs
- 45
- scenarios tested
- 3
- dispatch policies compared
- Open
- source, on GitHub
A small model written for this page, not the research code.
How the real one worksKORAIL platform screen doors, 2024
I turned 10,078 door failures into a decision a railway can make.
Platform doors keep people off the tracks, and they fail. I cleaned and analysed the failure records of 279 stations, then simulated four ways of maintaining them against cost, safety and time out of service. Here are those four on one small line, with the same luck. Break a door and see which one recovers.
Click a station to break a door. Drag to turn the line.
- 10,078
- failure records analysed
- 279
- stations
- 18
- rail lines
- 4
- strategies compared
A small model written for this page. Its failure rates and costs are invented; the study's are real.
How the study was doneAdaviv, an MIT spinoff, 2022 to 2024
My code ran robots in greenhouses, where the network gives up.
A robot drove the rows photographing crops in colour and in heat. Farms are bad places for a connection, so the software was built around losing it: keep working, keep everything, catch up later, and get back up without a person. Cut the network. Knock the robot over.
Click a plant to make it run hot. Drag to turn the house.
- Waiting on the robot
- —
- Photographed
- —
- Delivered
- —
- Hot plants found
- —
- ~30%
- faster backend responses
- 2
- cameras: colour and thermal
- 2 yrs
- in production
- MIT
- spinoff
A small model written for this page. The production system is private, and what a hot plant means here is invented.
What I owned thereHealthbridge, 2026, open source
I build the plumbing where losing one message is not allowed.
Health records arrive late, twice, or broken. Healthbridge is my open reference for handling that properly: nothing gets in without proof of who sent it, nothing is stored twice, and what cannot be processed is set aside, never dropped. Send it a forgery, a repeat, a broken record. Stop the worker.
Use the buttons to attack it. Drag to turn the model.
Left to right: three ways in, the gate that checks who sent it, the queue, the worker that checks the record, the store. In front of the worker: the tray for what cannot be processed.
- Lost
- —
- Stored
- —
- Waiting
- —
- Repeats ignored
- —
- Set aside
- —
- Turned away
- —
- 3
- ways in: API, email, AI agents
- FHIR R4
- the health-data standard it speaks
- 0
- real patient records: synthetic only
- Open
- source, on GitHub
A small model written for this page. Healthbridge is a reference system run on synthetic data, not a clinical product.
How it is builtOutside builds
I take on a small number of outside builds: getting an AI feature from demo to production, and the backend underneath it.
- Applied AI product implementation
- Backend architecture and delivery
- Technical discovery for operational software
It starts with a 20-minute call about where the work is stuck. If I'm not the right person for it, I'll say so. Write to me