Conformance Is Not Interoperability

Conformance and interoperability answer different questions. Conformance says an implementation meets the requirements of a claimed specification or profile. Interoperability says a particular client and device actually work together.

Most integrations begin with discovery: identify the vendor and model, read a capability document, then choose a code path. That works until the report is incomplete, stale, or technically correct but unusable in the current configuration.

At that point, discovery is no longer a lookup. It is a distributed systems problem involving remote claims, partial failure, stale state, and answers that can change after a firmware or configuration update.

A real example

Take IP security cameras. ONVIF defines interoperable profiles for capabilities such as media streaming and pan-tilt-zoom control. A client can query a camera and use the response to decide which operations to expose.

Conformance narrows the range of possible behavior, but it does not make every optional feature identical or guarantee that every client-device pairing works. A camera can return a media profile while the stream URI for a particular channel or codec remains unusable. The same camera might expose a working stream through its manufacturer-specific interface.

The capability report is not necessarily false. It is a partial observation made under different assumptions. Treating it as ground truth is where the integration becomes fragile.

Discovery requires verification

Vendor and model tables can provide useful hints, but the decision should come from a bounded live check whenever the operation is cheap and safe to probe.

That means:

• Treat reported capabilities as candidates, not confirmed behavior.
• Verify with a time-bounded probe. For a video stream, open it long enough to confirm that frames arrive in a supported format.
• Distinguish unsupported behavior from authentication failure, timeout, and temporary unavailability. They require different decisions.
• Cache verified results with the firmware, configuration, and time at which they were observed. Recheck when those inputs change.

A live check is also a snapshot, but it is evidence from the path the software will actually use. Recording when and how that evidence was collected makes the result useful without pretending it is permanent.

A fallback is policy

Once one source of capability information can be wrong, the integration needs another path. The order of those paths changes system behavior, so it should be reviewed as policy rather than inherited from control flow.

Three decisions matter:

What do you try first? The standard interface is usually the best first choice because one implementation can support many vendors. A manufacturer interface may be an appropriate fallback when the standard path fails verification.

When do you stop? Every probe and fallback needs a time budget and a terminal result. Exhausting the available paths should return an explicit unsupported or unavailable state, not an endless retry.

Can someone observe it? Record which path succeeded, why the preferred path failed, and how often the fallback is used. If four out of ten cameras depend on a manufacturer-specific path, that should be visible before a firmware update breaks it.

The fallback is valid only when its source, activation condition, time budget, and failure state are intentional. Quietly trying the next method is implementation. Knowing why that method is safe is design.

Model evidence, not identity

A boolean such as SupportsStreaming hides too much. The system benefits from distinguishing at least three states: reported, verified, and unavailable. That preserves the difference between a device claim and an observed result.

This is not an argument against standards. Standards reduce integration cost and constrain behavior. They simply do not remove runtime uncertainty, especially where optional features, vendor extensions, firmware, and network conditions meet.

Most devices stay on the happy path. The tail contains the device whose advertised capability fails only for one channel, after one update, in one deployment. Reliable integrations keep declarations separate from evidence so that one device becomes a visible state transition instead of a production mystery.