Vēlo
A safety platform's first AI feature: how a model's judgment gets shown, checked, and confirmed.
An AI that assesses risk, but never gets the final call.
Vēlo brought machine-learning risk analysis into safety software used across international operations. It reads incident reports, suggests hazards, root causes, and corrective actions, and flags potential serious injuries, with a person confirming every step.
About what you're seeing. Every component on this page is a recreation built for this case study, in my own visual language. The interaction logic mirrors what shipped. The pixels are mine, not VelocityEHS's.
How close was this to a serious injury?
Every incident carries a severity potential the report never states outright. The industry calls it pSIF, potential serious injury or fatality, and classifying it correctly decides whether an event is investigated or simply filed. Vēlo puts a model on that question, and on the four questions that lead up to it.
Five suggestions from the model. Five points where a person confirms, edits, or overrules. The design problem is everything around the model.
You're the floor manager. A worker just told you what happened, and now you have to log it.
Press Begin Report to walk through it yourself.
The model doesn't know when it's wrong. The interface has to behave as if it might be.
Every pattern in Vēlo comes from that sentence. Instead of a single "AI" button, the feature became a chain of states a reviewer moves through, each built so that trust is earned by the system rather than assumed by the user. And none of it is mandatory: Vēlo is a guide. A reviewer can complete and file the report without ever pressing it, and the record is just as valid.
Model quality tracked description quality, and most descriptions were one vague sentence. A strength meter scores the description as it is submitted, and Vēlo always runs when asked. Below three of five it answers that it doesn't have enough to go on rather than guessing, and the reporter can still file. Coaching the input did more for trust than any explanatory copy could.
A spinner elsewhere reads as "the page is stuck." The button itself becoming the analyzing state reads as "the system is working on your request," and keeps attention on the thing that is about to change.
Hazards and root causes arrive pre-selected in the same lists a person would use, each with a small chip that says where it came from. Designers call this provenance: the record of who or what made a choice. Suggestions outside the customer's own lists appear in a separate "other suggestions" group. Without the mark, users either over-trust everything in a list or trust nothing in it.
- ✓Exposure to harmful substancesVĒLO
- ✓Task performed without required PPEVĒLO
- Inadequate ventilation
- Slip, trip, or fall
Edit the report after analysis and the output still describes a report that no longer exists. In safety software a stale assessment is worse than none, so any edit flags every result out of date and says exactly how to fix it. The remedy is specific on purpose: "run Vēlo again for current results," not "results may be outdated."
"The model suggested this" matters during review and stops mattering after sign-off. Keeping the chips past save would have implied the machine's choices were still provisional after a person accepted them. This came out of a team review; the first version kept the marks forever.
- ✓Exposure to harmful substancesVĒLO
- ✓Inadequate ventilationVĒLO
The pSIF evaluation is rendered with its rationale and explicitly accepted or rejected. Corrective actions are recommended, then confirmed. No silent auto-classification of the most consequential field in the product, and a record either way that a person decided.
✦ Evaluated as non-pSIF
Rationale: chemical contact with face and eyes; no loss of consciousness; no work at height.
The least-designed state in AI products is the empty one. Click a button, get silence, assume it's broken. Vēlo says "no additional AI insights" in plain words, because in a safety review finding nothing new is itself information.
The acceptance criteria came from machine learning and product. I evaluated each one and turned it into design options a person could use: when Ask Vēlo should enable, how the model's output should appear, what happens on edit, what persists after save, how the empty result is shown. Every requirement became a state, and every state reaches someone who touches an incident: the reporter writing it, the investigator classifying it, the reviewer making the pSIF call, and the admin who has to trust the overview.
Before and after, for everyone the report passes through.
Vēlo replaced guesswork with a supported judgment on the question that matters most. It pushed more detail into every report before the model ran. And it gave serious incidents a visible path through the system, with a person on record at every step.
—
—
—
—
—
Every suggestion came from the model. Every decision came from a person.
Vēlo could only be built on a coherent system. That system is the next case.