The interface is the contract: ICDs at every level, from sensor to site

By: Ben Miller, Partner/Principal Consultant, mule.bot

Ask why an autonomous-machine program is late and you will usually be told a story about the hard parts: the perception stack plagued with false positives, the planner that can't put the machine into tight spaces, the localization dropouts near high walls. Those problems are real. But walk a stalled program back to where the schedule actually broke, and you rarely land on an algorithm. You land on an interface — the place where one team's component was supposed to meet another's, and the two did not agree on what was crossing between them. The units were different. A timing assumption went unstated. The failure behavior on one side was not the failure behavior the other side expected. Integration failed because the interface between them was never written down with enough rigor to hold.

The artifact that writes an interface down with that rigor has a boring name and an outsized importance: the Interface Control Document. This piece argues that ICDs are a load-bearing artifact of autonomous-system development, and that the standards conversation the industry is having right now, ISO 23725 included, is best understood as the industry finally writing one of those interfaces down in a form everyone can build to.

It is written for the OEM product and engineering leaders, the integrators stitching multi-vendor systems together, and the operators who have been told that "governance" of a mixed-vendor fleet is mostly a matter of drawing up a responsibility matrix. It is for the people who suspect, correctly, that the matrix is downstream of something more concrete.

What an ICD actually is

An Interface Control Document is a contract — not a metaphorical one, a literal specification of everything that crosses a boundary between two parts of a system, written so that the team on each side can build to it independently and trust that the two halves will meet. A complete ICD pins down the data that crosses (every field, its type, its units, its range), the timing (rates, latencies, what "stale" means), the protocol and physical layer where relevant, the coordinate frames and reference points, and — the part most often left thin — the behavior at the edges: what each side does when a message arrives late, malformed, or not at all.

The discipline is not new. ICDs are a staple of aerospace and defense systems engineering, where a spacecraft and its launch vehicle, built by different organizations over different years, must mate on a schedule with no opportunity to "integrate and see." The autonomous-machine industry is younger, and it has often treated the interface as something to be discovered during integration rather than specified before it. That is the habit that breaks schedules.

A good ICD has a simple test: two teams who never speak can each build their side, and the result works. That is a high bar, and most "interfaces" in autonomy programs do not clear it — they are a shared header file, a wiki page, and a tribal understanding that lives in the heads of two engineers. That is not an interface. It is a liability that has not been triggered yet.

ICDs at every level

The reason ICDs deserve more attention than they get is that an autonomous machine system is interfaces almost all the way down. Walk the stack:

• Sensor to perception — the raw-data contract: the formats and rates the sensors emit, the time base their measurements are stamped on, and the calibration and coordinate frames that let a lidar return and a camera pixel describe the same point in the world. Leave this thin and every layer above inherits the ambiguity.

• Perception to planning — the world-model contract: which objects perception asserts, with what confidence, in what frame, at what update rate, and how "I don't know" is represented. A planner that misreads this interface drives confidently on bad information.

• Planning to control, and control to the machine — here the interface leaves software and meets steel: the command the autonomy stack hands to the machine's drive-by-wire layer — steering, speed, braking, direction — and the feedback it gets back. It is also one of the least standardized boundaries in the stack — today still largely proprietary, often carried over a vehicle bus — which is exactly why a rigorous ICD earns its keep here. Define it well and the mechanism works in your favor: an autonomy stack written to a stable command interface can address more than one make, because the proprietary control law stays proprietary while the interface is the part that travels. Leave it undefined and that same control law is stranded on a single chassis.

• Autonomous system to fleet management — the mission-and-state contract: how the fleet-management or supervisory layer dispatches missions and routes, and how the autonomous machine reports position, status, and production back. This is the boundary ISO 23725 standardizes — the interface between a fleet-management system and an autonomous haulage system — so an operator can pair one vendor's fleet management with another vendor's autonomous machines.

• Machine to machine, and machine to site — the coexistence contract: how an autonomous machine senses and avoids other autonomous machines and monitored manned machines (MMMs), and stays aware of the people and equipment sharing its operating area. Collision warning and avoidance at this level is the subject of ISO 21815.

• System to service — the level most programs forget. Autonomy does not run on parts alone; it runs on services — an RTK or GNSS correction stream, a remote-operations desk, a maintenance-analytics pipeline, a hazard or weather feed. Each is a third party reached across an interface, and each deserves an ICD as much as any onboard component. The ICD for a correction service, for instance, pins down not just the message format but the guarantees behind it: availability, latency, the integrity flags that say a correction can be trusted, and what the machine must do when the stream degrades or drops. Leave those unstated and you have built a single point of failure no one specified — and, when the service belongs to a third party, a governance gap no RACI will catch, because no one wrote the interface it would have sat on.

Every one of those is an ICD waiting to be written, and the maturity of a program is largely the maturity of those documents. The levels are not independent: a sloppy sensor-to-perception interface poisons everything above it, and a missing failure-behavior clause at the control-to-machine boundary is the kind of omission that becomes a safety-case problem, not just an integration headache. The safety-relevant interfaces carry additional weight — the functional-safety communications discipline of IEC 61784-3, the "black channel," which is really just an ICD with its integrity requirements made explicit and verified.

ISO 23725 is the standardized AHS and FMS interface

Seen this way, ISO 23725 is not a mysterious new thing. It is an ICD — the one between a fleet-management system and an autonomous haulage system — that the industry agreed to write once, in common, so that every vendor can build to it instead of to a different proprietary integration agreement on every site. It standardizes the boundary, not the box: the path planner, the perception architecture, the autonomy that lives inside a vendor's machine all remain proprietary, while the interface where fleet management meets the autonomous fleet becomes common property. That single move is what loosens the lock-in dynamics of the autonomous-haulage market — an operator can pair one vendor's fleet management with another's machines — but the mechanism, underneath the commercial story, is simply a well-written, widely adopted ICD.

What ISO 23725 does at the top of the stack is what a disciplined program should be doing at every other level on its own: define the interface explicitly, before integration, in a form the other side can build to without a phone call. The standard is valuable precisely because it is an ICD that escaped the confines of a single program and became an industry asset. The lesson for an OEM or an integrator is not "conform to 23725 and you are done." It is "the rigor 23725 forces at the site boundary is the rigor your own interfaces need at every level beneath it."

Governance rides on the interface

This is where the governance question operators keep asking — what do we actually do about a multi-vendor system? — gets its honest answer. The instinct is to reach for a responsibility matrix: a RACI that names who is Responsible, Accountable, Consulted, and Informed for each part of the system. That instinct is right, and the matrix is useful. But a RACI is a layer on top of something more concrete, and it is only as meaningful as the thing underneath it.

The thing underneath is the interface. "Accountable for the machine-to-supervisor interface" means nothing until there is a machine-to-supervisor ICD that says what that interface is — what crosses it, at what rate, with what failure behavior. Write the ICDs first and the RACI very nearly falls out of them: each interface has two sides, an owner on each side, and a jointly owned contract between them. Conformance becomes checkable, because there is a document to check against. Disputes become resolvable, because there is a written agreement to point to. Skip the ICDs and the RACI is a list of names attached to boundaries no one has defined — governance theater, and the first integration surprise exposes it.

So the practical answer to "how do we govern a multi-vendor system" is not "draw the matrix." It is "write the interfaces down, at every level, as ICDs — and let the governance structure map onto them." ISO 23725 hands you that document, already standardized, for the hardest boundary. The rest you write yourself, to the same standard of rigor.

The honest limit

An ICD is a floor, not a guarantee. A document can be complete and still be wrong — an interface specified precisely around a mistaken assumption integrates precisely into a failure. Conformance-on-paper is not integration-in-practice: two components that both honor an ICD can still produce surprising behavior at the seam if the ICD did not anticipate a case the real world supplies. And ICDs rot; an interface that is not maintained as the system evolves becomes a document describing a machine that no longer exists.

The discipline, then, is not "write the ICD and move on." It is to treat each interface as a living contract — versioned, tested against, and revised deliberately when one side changes — and to back the document with the one thing that actually validates an interface: integration evidence. A vendor whose component has met another's across a real ICD, on a real site, is making a claim you can trust. A vendor whose conformance lives only on paper is making one you should test. The standard, and the ICD generally, makes those demands legible. It does not make them go away.

The interface-first program

The programs that integrate on schedule are not the ones with the cleverest algorithms. They are the ones that decided, early, that the interfaces were first-class deliverables — that the seam between two components deserved as much engineering attention as the components themselves, and that the document defining it was worth writing before the code that crossed it. That posture is unglamorous. It is also the difference between a system that integrates and a pile of good parts that do not.

ISO 23725 is the industry making that decision in public, at the boundary where the stakes are highest. The opportunity — for OEMs, for integrators, for operators assembling multi-vendor fleets, and for the standards work itself — is to carry the same decision down through every level of the system, from the site boundary all the way to the sensor. Integration is an interface problem. The interface is a contract. Write it down.