Eleven engagements, ordered to show the span rather than the chronology. Four of them have no model in them anywhere. Two run on hardware that could not be taken out of service. One is enforced beneath a flight controller.
Four engagements at the model and serving layer, framed as what they are.
These sit at the top of the stack, and they are production reliability problems rather than model-building ones. Most of what makes them hard is old distributed-systems discipline arriving in new clothing: drift detection, regression, idempotency, and knowing when the system does not know.
Four of these have no model in them, and that is the point.
Any firm can publish a list of projects. What is worth reading here is the shape of the set. The fleet platform, the hydraulic control, the scaling work, and most of the predictive-maintenance architecture are systems, protocol, and signal engineering. A vendor whose only product is a model would have found a use for a model in every one of them.
The other thing worth noticing is the vertical span. The same principal enforced a fail-closed gate beneath a flight controller, scheduled polling against baseboard-controller session limits, and designed a biosignal chain against a physical recoverability ceiling. Those layers are usually owned by different people. The value of one owner is that the decisions which have to be made together get made together.
The technical specifics are the point. The clients are not.
Every account here is anonymized. The protocols, the silicon, the standards, and the architecture decisions are named because they are what a technical evaluator needs to judge whether the engineering is real, and none of them identify a client.
A portion of what we do sits under agreements that do not allow even this much. If you need to evaluate work closer to yours before committing a program, we can speak to it directly under the right terms.