Does an open standard guarantee interoperability?

No. Implementations must support the relevant parts and versions, and the surrounding workflow still needs compatible meanings and behavior.

Can systems interoperate through an adapter?

Yes. An adapter can translate formats or meanings, but its assumptions and limitations need documentation and testing.

Does moving a model preserve its accuracy automatically?

No. Conversion, preprocessing, runtime behavior, and deployment data can affect results. Evaluate the transferred model in its intended environment.

AI Glossary / Governance, ethics and safety / Beginner

Interoperability

Definition

Interoperability is the ability of different systems or components to communicate and work together for an intended purpose. In AI, this includes exchanging usable data, connecting services, and moving supported model representations between tools. Successful exchange requires compatible formats and shared meaning, not merely a network connection or a file that opens.

What it means

An AI application often combines databases, models, business software, and monitoring tools built by different organizations. Interoperability determines whether these parts can cooperate without losing information or creating misunderstandings.

For example, two services may both accept a number called score. One may mean probability of success, while the other expects probability of failure. Their software can exchange the number perfectly and still make the wrong decision.

The required level depends on the task. Importing a dataset, calling a model service, and reproducing a model's computation are different goals. A supplier's broad interoperability claim therefore needs a concrete scope: which systems, versions, operations, and information can actually work together?

How it works

Teams agree how components connect, how messages are structured, and what their fields mean. They also specify practical behavior such as missing values, errors, authentication, version changes, and limits on requests.

Shared standards can reduce the amount of custom translation. For example, ONNX defines a common representation for machine-learning computations. Its operator definitions and versions help tools understand a represented model. Support for the required operations still matters; a common format does not make every possible model automatically portable to every runtime.

Testing should follow the whole workflow. Confirm that the receiver interprets units, labels, timestamps, and output ordering as intended. Compare relevant results after conversion or integration, including unusual inputs. An adapter may bridge differences, but its mappings and assumptions become part of the system that needs maintenance and evaluation.

Three practical examples

1. A forecasting model sends demand estimates to an inventory system, with both sides agreeing on product identifiers, forecast dates, units, and whether values represent individual items or cartons.

2. An organization exports a supported model representation to a deployment runtime, then checks that preprocessing, model operations, and output labels remain compatible.

3. A support assistant connects to a ticketing service using a documented interface, with agreed meanings for status fields and clear responses when access is denied or a request fails.

Think of it this way

Think of two people completing a shared form. They need a way to pass it between them, compatible spaces for the answers, and agreement about what each question means.

The analogy is limited. Software also relies on exact types, versions, timing, and permitted operations. People may notice an implausible answer and ask for clarification; an automated component may accept a well-formed but misunderstood value without noticing that the business meaning has changed.

Worked example

A fictional supplier sends a temperature reading of 68 with no unit. An AI monitoring service expects degrees Celsius and raises an alert above 30°C. It therefore treats the reading as 68°C and raises an alert.

The supplier intended 68°F. Converting correctly gives (68 − 32) × 5 / 9 = 20°C, which is below the threshold. The number arrived unchanged, so successful transmission did not establish meaningful interoperability.

The teams revise the exchange to include an explicit unit and require validation before the reading reaches the model. They also test a genuine high-temperature case, a missing-unit case, and an unsupported-unit case.

The example illustrates a semantic mismatch rather than a defective prediction algorithm. A conversion rule resolves this particular mismatch only when the stated source unit is itself reliable and the receiving workflow uses the converted value consistently.

Illustrative case study

Fictional case: Cedar Distribution links a demand model to its ordering system. During a trial, staff notice unexpectedly large orders for products sold in packs. The model outputs individual units, but the receiving system interprets the quantity as packs.

The integration team adds explicit quantity units, checks pack-size mappings, and tests products with different packaging arrangements. It records which component is responsible for conversion and how packaging changes will be communicated.

This invented case has no claimed savings or performance result. It shows why validating exchanged meaning matters alongside checking that a request succeeds. The organization still needs separate tests of forecast quality and purchasing policy; interoperability does not establish that the forecast or resulting order is appropriate.

Common misconceptions and mistakes

A shared file extension does not guarantee equivalent interpretation. Likewise, an available API does not mean that every requested operation is supported or that access permissions will transfer between systems.

Interoperability is related to portability, but they are not identical. Portability concerns moving something between environments; interoperability concerns cooperation between components. Neither guarantees numerical identity, adequate speed, security, or model quality. Those requirements should be stated and evaluated separately rather than assumed from a successful connection test.

Business use

Businesses can use interoperability requirements to reduce avoidable integration work and make supplier comparisons more concrete. Specify the workflows that must work, the data meanings that must be preserved, and the evidence needed to accept an integration.

Include representative examples, boundary cases, version support, and failure behavior in acceptance testing. Ask who maintains mappings when either component changes. The useful outcome is dependable cooperation for the required process, supported by tests and documentation, rather than a vague promise that a product connects to everything.

Check your understanding

Two systems successfully exchange a quantity of 12, but one means items and the other means boxes. Has the workflow achieved the needed interoperability?

Answer: No. Transmission works, but the receiving system misinterprets the quantity. The exchange needs an agreed unit and any necessary, validated conversion.

Related terms

Application programming interface
Semantic interoperability
Metadata
Data Quality
data schema
model portability
ONNX
integration testing

Learn next

Next, study data schemas and semantic interoperability. Follow one AI output into a downstream business system and document its unit, meaning, allowed values, missing-value behavior, and responsible owner at each boundary.

Semantic interoperability

Sources

NIST Computer Security Resource Center, Interoperability: https://csrc.nist.gov/glossary/term/interoperability ONNX documentation, ONNX Concepts: https://onnx.ai/onnx/intro/concepts.html W3C, RDF Data Cube Vocabulary, shared terminology discussion: https://www.w3.org/TR/vocab-data-cube/ Relevant primary passages were read. The workflow examples and temperature calculation are original illustrations.

Previous: Internal validity Next: Interpolated precision