Work

The programs, and what they changed.

We do not publish client names or logos. The organizations we work with operate in defense, in regulated medicine, in industry, and in critical infrastructure, and discretion is part of the job. What we can show is the shape of each program: what was at stake, which layer the hard decision was actually made at, and what changed as a result.

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.

The upper layers

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.

Read as a set

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.

What we hold back

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.

How we engage

Your program is not on this page.
Tell us what it is.

The work closest to yours is often the work we cannot publish. Describe the system and the stakes and we will tell you what is relevant, and what we would own.

Start a conversation
mostafa@opulion.dev · Response within 24 hours · By inquiry