Decision Systems for the Real World

The pressure

I know what a tidy dashboard can hide. A task can look completed while its evidence is missing. Someone can hand off a job without passing on the reason for an exception. And an automated step can move too quickly through a decision that should have stayed with a person.

Those aren't abstract interface questions. In time-sensitive operations, they become real questions: who owns the next move, what is known, and what still needs proof?

The design question

I want an operating system that can tell the difference between a recorded event, a verified fact and a decision waiting for a person.

That means mapping everyday paths alongside the difficult ones. An unavailable driver. A missing record. Two conflicting statuses. A deadline that changes while a job is in motion.

The visible screen matters, but the rules behind it matter more. If a user can't understand why something changed, a green badge hasn't earned their trust.

My contribution

My work has focused on translating field experience into product priorities, process maps, decision boundaries, exception rules, and realistic test scenarios. Implementation is a team effort and is sometimes AI-assisted; I do not present every component as code I wrote myself.

What is proven — and what isn't

Real operating experience stands behind the questions, and active development stands behind the system. This is an evolving product, not a claim that every planned feature has been released, deployed, or proven at scale.

The standard I return to is simple:

A useful system shouldn't just say what's next. It should make clear why that is the next responsible move.

For roles and companies, see Career. For specific past experiments, see the Journal.