About

Devices speak. Systems must listen.

I architect the interpretation layer—the space where raw signals become operational truth.

The Correlation Problem

A weighbridge reports a number. It doesn't know which vehicle produced it. A camera captures a license plate. It doesn't know which trip it belongs to. An RFID reader detects a tag. It doesn't know if access should be granted.

The fundamental challenge of industrial IoT isn't connectivity—it's correlation. Devices generate fragments. Architecture creates meaning. My work lives in that gap: taking isolated signals and weaving them into authoritative records that survive audit, support decisions, and enforce rules the devices themselves know nothing about.

Events, Not Intentions

I don't build systems that tell the physical world what happened. I build systems that listen to what the physical world reports, then derive state from that reality.

When a barrier opens, the system doesn't record "we opened the barrier." It records "the barrier reported it opened." When a scale stabilizes, the system doesn't record "we weighed the truck." It records "the scale reported a stable reading." The distinction is subtle but absolute: the event trail must reflect what was observed, not what was commanded. Only then can you reconstruct truth when things go wrong.

Authorization Before Action

A contract isn't a business agreement. It's a capability container—a set of constraints that determine what a vehicle can do before it arrives. The system doesn't ask "should this truck enter?" It asks "does this truck have remaining capacity under an active contract for this material type at this facility?"

Authorization completes before the barrier command is ever sent. Not during. Not after. Before. The physical world moves slowly enough that we can afford to think first. Systems that open barriers and then check permissions have inverted the trust model. They've made the default "allow" and the exception "deny." I design for the opposite: silence is denial, and action requires proof.

Constraints as Architecture

Every device limitation becomes an architectural decision. Scale indicators can't identify vehicles? Then detection must happen at every weighpoint—not just the gate. Barriers can't validate authorization? Then validation must complete before the command. Hardware can't guarantee delivery? Then the system must tolerate silence.

Vendors who fail my specifications try to work around these constraints. They assume gate detection can correlate with scale readings. They assume the barrier will wait. They assume the network will deliver. Assumptions are where systems die. I document constraints because the constraints are the architecture.

The Specification Filter

I spend more time writing specifications than code. This seems inefficient until you watch a vendor misinterpret a requirement, build the wrong abstraction, and spend months recovering from an assumption a single sentence would have prevented.

The irony of detailed documentation is that it exposes capability gaps. The more precisely you specify a system, the fewer people can build it. When I hand a vendor a state machine challenge instead of a knowledge questionnaire, I learn quickly whether they understand orchestration or just claim to.

A specification no one can implement isn't a failure of the vendors—it's information about the gap between what's needed and what's possible. Sometimes the right response is to simplify. Sometimes to wait. Sometimes to build the operational layer yourself while the specification matures.

Layers of Truth

Configuration defines what's possible. Authorization defines what's permitted. Operations record what happened. Analytics reveal what it means. Each layer has its own source of truth, its own rate of change, its own failure modes.

The foundation layer changes rarely—sites, zones, device locations. The supporting layer changes occasionally—contracts, vehicle registrations. The operations layer changes constantly—trips initiated, weights captured, states progressed. The intelligence layer synthesizes everything into decisions. When layers couple incorrectly, the fast layers drag the slow layers into instability. When they couple correctly, each layer can fail independently without corrupting the others.

Ground Zero

I operate on a simple protocol: no assumptions. Every claim traces to a source. Every decision references a constraint. When I don't know something, I stop and ask rather than guess and apologize later.

This discipline isn't about being thorough—it's about being honest. Systems built on assumptions inherit the assumptions' fragility. Systems built on verified constraints inherit the constraints' strength. The difference compounds over time until one system is maintainable and the other is a museum of workarounds.