One-sentence answer: Interoperability works when independent systems can exchange information or services through compatible interfaces and standards, preserve enough shared meaning for the receiver to use what arrived correctly, and remain governed across versions, permissions, errors and real-world handoffs.
Two systems can communicate without truly interoperating. A file may arrive but use different units. A medical code may be syntactically valid but interpreted differently. An API call may succeed while the downstream workflow rejects the object. A school record may transfer perfectly while losing the meaning of a grade scale. A transport system may publish data that another system can read but not act upon.
Successful transfer is only the first layer. Interoperability is complete when the receiver can use what crossed the boundary without silently changing its meaning or authority.
Quick Read: the causal chain
SENDER → INTERFACE CONTRACT → TRANSPORT → ENCODING / FORMAT → IDENTIFIERS → SHARED SEMANTICS → PROTOCOL STATE → PERMISSIONS → RECEIVER DECODING → WORKFLOW ACTION → ACKNOWLEDGEMENT → END-TO-END TEST → VERSION / ERROR HANDLING → CORRECTION
1. Interoperability begins at a boundary
Every interoperating system has at least two independent parties separated by a boundary. That boundary may be between software applications, organisations, machines, databases, agencies, devices, services or human teams.
NIST defines an interoperating system as a system that exchanges information with the system of interest and uses the information that has been exchanged. That second clause—uses the information—is what separates interoperability from mere connectivity.
The boundary therefore has two jobs:
- move something across;
- preserve enough agreement that the receiver can act correctly.
2. Connectivity ≠ interoperability
| Layer | Question |
|---|---|
| Connectivity | Can the two systems reach each other? |
| Transport interoperability | Can messages or files cross the channel? |
| Syntactic interoperability | Can the receiver parse the structure? |
| Semantic interoperability | Does the receiver understand the same meaning? |
| Process interoperability | Can the receiver incorporate the information into a compatible workflow? |
| Organisational interoperability | Do responsibilities, timing, governance and escalation align? |
| Legal / authority compatibility | Is the exchange and downstream use permitted? |
A system can pass one layer and fail the next. “The message was delivered” is not proof that the job succeeded.
3. Shared interfaces make expectations explicit
An interface specifies what can cross the boundary and how. For software, this may be an API contract. For hardware, it may define voltages, dimensions or signalling. For organisations, it may define forms, roles, deadlines and acknowledgement rules.
A strong interface contract declares:
- allowed inputs and outputs;
- data types and units;
- required and optional fields;
- identifiers;
- state transitions;
- error responses;
- timing and ordering rules;
- version behaviour;
- security and authorisation expectations.
This is why How APIs Work and How Protocols Work are neighbours rather than duplicates. APIs expose callable capabilities; protocols coordinate exchange and state. Interoperability asks whether independent systems can use those contracts together successfully.
4. Encoding and syntax preserve structure—not necessarily meaning
If two systems agree that a date is encoded as 2026-08-28, the syntax may be interoperable. But the field may still be ambiguous: creation date, admission date, billing date or deadline?
Encoding determines how symbols become transferable representations. Metadata adds description and context. Standards create shared specifications. Interoperability depends on all of them but owns the end-to-end question: can another system correctly use what was exchanged?
5. Semantic interoperability is the meaning layer
Semantic interoperability requires shared interpretation. That may depend on:
- controlled vocabularies;
- shared identifiers;
- code systems;
- ontologies;
- unit definitions;
- reference data;
- schemas with documented semantics;
- mapping rules between different conceptual models.
A field named score is not interoperable merely because both systems store a number. One system may mean raw marks out of 100; another may mean a standardised score; another may mean a confidence value between 0 and 1. Shared syntax without shared semantics manufactures silent error.
6. Identifiers keep entities from collapsing into each other
Interoperability often fails not because the message cannot be parsed, but because systems disagree about identity.
Is “Alex Tan” the same person in both databases? Does product code 1824 identify the same version? Does “Singapore” refer to country, city-state, administrative area or market jurisdiction? Does a scientific identifier represent the article, dataset, author or institution?
Stable identifiers and resolvable mappings reduce ambiguity. But identifiers also require governance: assignment, uniqueness, merge rules, deprecation, provenance and privacy boundaries.
7. Versioning is part of interoperability, not an afterthought
Systems evolve independently. Fields are added. Meanings change. Optional features become required. Protocol behaviour is clarified. Security rules are tightened.
A mature interoperability design answers:
- Which versions can communicate?
- How is version negotiated?
- What happens to unknown fields?
- Can older receivers safely ignore new information?
- How are deprecated codes mapped?
- When is backward compatibility impossible?
- How is migration tested?
Silently guessing is dangerous. An explicit “unsupported version” failure can be safer than a plausible but incorrect translation.
8. Interoperability depends on protocols and state
Many exchanges are not one-shot file transfers. They involve requests, responses, acknowledgements, retries, timeouts and ordering.
Two systems can understand the same message format and still fail because they disagree about:
- whether a retry creates a duplicate;
- which message must come first;
- how long state is retained;
- whether acknowledgement means received, validated or completed;
- how partial failure is recovered;
- who owns reconciliation after disagreement.
Interoperability therefore requires behavioural agreement, not only shared data structure.
9. Standards reduce pairwise translation—but profiles matter
Without shared standards, every pair of systems may require a custom translation. As the number of systems grows, bilateral mappings can form a brittle web of hidden assumptions.
Shared standards reduce this complexity, but real standards often allow options. Interoperability profiles narrow those options for a particular use case: required fields, value sets, transport, security and workflow conventions.
A system can therefore be “standards compliant” in isolation and still fail to interoperate with another compliant system if they implement incompatible optional choices.
10. Conformance testing ≠ interoperability testing
Verification can show that each implementation conforms to its declared specification. Interoperability testing goes further: put independent implementations together and observe whether they exchange and use information successfully.
The IETF has long treated independent implementations as strong evidence of protocol maturity. Its current implementation-report pages describe a standards-process expectation for multiple independent, interoperable implementations when specifications advance.
This is an important principle: a specification that only its original author can implement correctly has not yet demonstrated broad interoperability.
11. Round-trip testing exposes hidden loss
A useful hostile test is round-trip conversion.
SYSTEM A → SHARED / TRANSLATED REPRESENTATION → SYSTEM B → TRANSLATE BACK → COMPARE WITH ORIGINAL
Round trips can reveal:
- lost precision;
- collapsed categories;
- unit conversions;
- timezone shifts;
- missing identifiers;
- ambiguous null values;
- unsupported fields;
- semantic drift.
Not every interoperable exchange needs perfect reversibility. Sometimes intentional loss is acceptable. But the loss should be declared and appropriate for the receiver’s job.
12. Permissions and privacy are part of the boundary
Technical ability to exchange data does not create permission to exchange it. A system may be perfectly interoperable technically while the transfer is unauthorised, privacy-invasive or outside the receiver’s legitimate role.
Interoperability design should therefore preserve:
- authentication;
- authorisation;
- purpose limitations;
- data minimisation;
- consent or other lawful basis where required;
- access logging;
- revocation;
- downstream-use restrictions.
Can exchange ≠ may exchange ≠ may use for every purpose.
13. Worked example: two school systems exchange assessment results
System A sends:
{ student_id: 4182, subject: "Math", score: 75 }
System B can parse the JSON. Is interoperability complete? Not yet.
- Is
student_idglobally meaningful or only local to System A? - Does “Math” identify the same curriculum and level?
- Is 75 raw marks, percentage, standard score or percentile?
- Which assessment generated it?
- When was it taken?
- Was it timed?
- What is the maximum score?
- May System B use it for placement, or only display it?
The correct exchange might therefore require assessment identifier, scale, date, curriculum context, provenance and use constraints. A technically successful transfer can otherwise produce a confidently wrong educational decision.
14. Worked example: accessibility routing
A transport feed says a station lift is available. A mapping service consumes the feed and generates an accessible route. The route is only interoperable in the meaningful sense if:
- the lift identifier maps to the correct physical asset;
- availability uses the same status semantics;
- timestamps are current;
- outage updates propagate;
- the route engine knows which platforms depend on that lift;
- the user receives a corrected route when the lift fails.
The receiver is the traveller, not merely the mapping software. End-to-end receipt is therefore stronger than message delivery.
15. Interoperability across domains
| Domain | Interoperability challenge | Boundary |
|---|---|---|
| Software | APIs, schemas, protocols, versions | Successful call does not prove shared semantics. |
| Health | Clinical data, codes, identity, workflow | Clinical meaning, privacy and authority remain specialist-governed. |
| Education | Curriculum, assessment and learner records | Equivalent fields may represent different constructs. |
| Finance | Messages, identifiers, settlement states | Timing, legal finality and jurisdiction matter. |
| Transport | Schedules, locations, status and routing | Staleness can turn valid data into bad action. |
| Manufacturing | Machines, digital models, work orders | Units, versions and process state must align. |
| AI | Tools, agents, model outputs, schemas | Tool compatibility does not guarantee truth, safety or authority. |
16. Common interoperability failures
| Failure | What goes wrong | Repair |
|---|---|---|
| Connectivity illusion | Systems can connect but cannot use each other’s outputs. | Test end-to-end receiver action. |
| Syntax-only success | Message parses but meaning differs. | Use shared semantics and test edge cases. |
| Identifier mismatch | Same identifier points to different entities. | Govern identity and mapping. |
| Unit mismatch | Values transfer without unit agreement. | Carry explicit units and conversion rules. |
| Version drift | Independent evolution breaks compatibility. | Negotiate versions and test migrations. |
| Optional-feature divergence | Both systems comply but implement different options. | Use constrained interoperability profiles. |
| Brittle pairwise mappings | Custom translations multiply and hide assumptions. | Use governed shared models where justified. |
| Permission collapse | Technical exchange is mistaken for authority to use data. | Enforce purpose, role and privacy constraints. |
| No acknowledgement semantics | Sender cannot tell whether data was merely received or actually applied. | Define receipt states explicitly. |
17. Hostile test: independent systems, edge cases, real receiver
A strong interoperability test uses at least two genuinely independent implementations and intentionally difficult cases:
- Can they establish communication?
- Can they parse each other’s messages?
- Do shared identifiers resolve to the same entities?
- Do units and code values mean the same thing?
- Do null, unknown and exceptional states survive?
- Do retries and duplicates behave safely?
- Do version differences fail or degrade predictably?
- Can information round-trip without unacceptable semantic loss?
- Is the exchange authorised?
- Can the final receiver correctly use the result?
If the final answer to question ten is no, the system may be connected, conformant or partially compatible—but the intended interoperability job has not been completed.
18. Where Interoperability fits in the wider How Things Work map
Interoperability connects Standards, Protocols, Encoding, Metadata, APIs, Verification and Communication.
Its distinctive job is the cross-boundary receipt: independent systems exchange something, preserve meaning and authority sufficiently, and the receiver can use the result correctly.
19. What this article does not claim
- Connectivity is not interoperability.
- Syntactic compatibility is not automatically semantic compatibility.
- Standards compliance does not guarantee interoperability across every optional profile.
- Successful transfer does not prove correct downstream use.
- Technical interoperability does not create legal permission, consent or authority.
- Mapping between vocabularies can lose meaning.
- Two systems can interoperate technically while still producing a harmful receiver outcome.
20. Observable mastery test
You understand interoperability when you can take two unfamiliar systems and separate connectivity, syntax, semantics, protocol state, identifiers, workflow, versions, permissions and receiver use; identify where translation can lose meaning; and design an independent end-to-end test that proves more than “the file arrived.”
Authoritative source corridor
- NIST CSRC: Interoperating System — exchange plus use of exchanged information.
- NIST CSRC: Interoperability — current terminology source.
- IETF Implementation Reports — current evidence of independent interoperable protocol implementations used in the standards process.
- IETF RFC 9110: HTTP Semantics — a live example of shared protocol semantics supporting interoperability.
- How Protocols Work and How Standards Work — neighbouring public mechanism owners.
Governing idea: Systems truly interoperate when the boundary becomes traversable without making the receiver guess what the sender meant.