DM Explains · No. 035 · Architecture
Model interchange protocols: a common plug for AI models, not a universal translator
Several standards now let AI models be packaged, registered and called the same way across vendors. None of them promise that swapping models gives you the same answers.
· 14 min read
Read me first
Several standards now let you package a model, push it to a registry and call it through one convention instead of a different one for every vendor. None of them promise the new model will answer like the old one.
Swapping a self-hosted model into a multi-vendor pipeline → 1 packaged with --format=cncf as a ModelPack OCI artifact → 2 pushed to an OCI registry → 3 called through UPP 1.3's uniform interface → 4 translated through Apache Ossie's hub rather than vendor-specific converters → 5 drift check flags a new engine behind the same chassis → 6 round-trip import test confirms the export unpacks correctly → swapped in with a shared calling convention, not identical answers
A team has wired their app directly into one model provider's API. A new provider turns up with better pricing, and someone is told to "just swap it in" over a weekend. By Monday they are rewriting request shapes, config files and loaders by hand, because nothing about the first integration assumed a second one would ever exist. Even once the swap compiles, the harder question is still open: does the new model actually behave like the old one.
Everyday picture. Papa buys a universal travel adapter so Bruno's old torch charger, bought in one country, can plug into a wall socket in another without changing the torch itself.
Where the picture breaks. The adapter standardises the plug shape, not the electricity. Swapping providers through a protocol doesn't make their models behave the same, since provider-native configuration is deliberately preserved rather than flattened away.
Why it exists now
Most organisations today wire each application straight to one model provider's API. That works until there are two providers, or a self-hosted model alongside a hosted one, or a model that needs to move from a training tool into a serving tool. Each new pair of systems needs its own translation code, so N tools talking to M providers becomes N times M pieces of custom glue — the "NxM problem".
Three separate efforts have surfaced at once to chip away at this, each at a different layer. The CNCF's ModelPack project defines how a model's weights, metadata and configuration assemble into an OCI (Open Container Initiative) artifact, and in August 2026 Docker Model Runner added a --format=cncf option so models produced with Docker can be output as ModelPack artifacts and pushed to any OCI registry (CNCF, 2026). Separately, the Unified Provider Protocol (UPP) has reached version 1.3 as a specification for calling large language models, embedding models and image-generation models through one uniform interface (GitHub / ProviderProtocol). And Apache Ossie, a project for making semantic and business-logic models portable between data platforms, has drawn backing from more than 60 companies, including Microsoft and Google (DevFeed). None of these are one vendor's SDK being pushed as a universal standard; each is a committee-style effort with multiple backers, and none of them have finished winning.
How it works
Illustrative: a self-hosted model is packaged with --format=cncf, pushed to an OCI registry, pulled at deploy, then called through UPP v1.3 alongside a vendor API — the plug fits but a divergence check still flags different answers to the same prompt.
Package as artifact
One box shape, any truck can carry it.
What it is. ModelPack describes how a model's weights, tokenizer and configuration are assembled into a standard OCI artifact — the same artifact mechanics used for container images, but with model-specific content types.
Why it exists. A shared artifact structure means any compliant runtime can unpack and run a model without a custom loader written specifically for that model's source tool.
Where it breaks. The artifact format says nothing about whether the model inside performs well. It describes a box, not what's in it.
How that's handled. Packaging is treated as a distribution problem, separate from evaluation; a well-formed artifact still has to be benchmarked before anyone trusts it.
In technical terms
In technical terms: ModelPack defines how a model's weights, metadata and configuration assemble into an OCI artifact, reusing OCI's container mechanics but with model-specific content types.
Push to registry
Reuse the shelves everyone already has.
What it is. Once packaged, the artifact is pushed to a standard OCI registry — the same kind of registry used to store container images.
Why it exists. Reusing existing registry infrastructure avoids building a bespoke model hub from scratch, and lets existing container tooling serve models.
Where it breaks. A registry entry only proves the package is well-formed and present. It proves nothing about whether two models sitting on the same shelf are interchangeable in practice.
How that's handled. Docker Model Runner's --format=cncf option, added in August 2026, outputs ModelPack artifacts specifically so they can be published to an OCI registry and picked up by other compatible serving frameworks (CNCF, 2026).
In technical terms
In technical terms: the packaged artifact is pushed to a standard OCI registry for distribution, the same registry mechanism used for container images.
Call uniformly
Same socket, different current behind it.
What it is. The Unified Provider Protocol defines one calling convention across large language model, embedding and image-generation providers.
Why it exists. A single calling convention means client code can switch providers, or call several at once, without rewriting request and response handling for each vendor's API shape.
Where it breaks. UPP deliberately preserves provider-native configuration rather than flattening it away, so some code paths still branch per provider; the specification explicitly avoids pretending all models are interchangeable black boxes (Provider Protocol).
How that's handled. UPP's own documentation names this trade-off directly — it standardises the calling shape, not the configuration underneath, which it calls avoiding "abstraction leakage".
In technical terms
In technical terms: UPP, now at version 1.3, is a language-agnostic specification defining protocol semantics, data structures and implementation requirements for UPP-compliant clients and providers (GitHub / ProviderProtocol).
Translate via a hub
One converter in, one converter out, not N×M.
What it is. Apache Ossie expresses semantic models — datasets, fields, relationships, metrics, AI context — in a common JSON/YAML format, with each platform writing one converter to and from that hub rather than a separate converter for every other platform.
Why it exists. A hub format turns an N times M integration problem into N converters, one per platform, instead of one per pair of platforms.
Where it breaks. A hub format is only as useful as the number of real converters built. More than 60 companies back the project, but backing is not the same as a shipped converter (DevFeed).
How that's handled. Concrete converters are already in progress: Microsoft is building a two-way converter between Power BI semantic models and Ossie, and pushing for Ossie to recognise DAX as a query language, which gives the format a real test case rather than a paper spec.
In technical terms
In technical terms: Apache Ossie uses a hub-and-spoke architecture, where semantic models in a common JSON/YAML format are translated to and from each vendor's native semantic layer via per-platform converters.
Check version drift
A new engine, the same chassis, maybe.
What it is. A compatibility-adapter approach, described in a Google patent application, trains a new adapter layer using parameters from the old one and computes a divergence metric between the two models' output probability distributions.
Why it exists. When a base model is upgraded, this lets a system check behavioural drift before switching, rather than retraining everything or discovering drift after deployment.
Where it breaks. A divergence check only flags drift after the fact; it does not eliminate behavioural change, and it is not a substitute for evaluating the new model properly.
How that's handled. The divergence metric is computed before deployment, as a gate rather than a guarantee.
In technical terms
In technical terms: a compatibility adapter module trains a second adapter using parameters from a first adapter layer, then computes a divergence metric between the two models' output probability distributions before deployment (Google Patents).
Validate by round-trip
Trust the export, but test the import.
What it is. Interchange claims get proven by exporting a model from one tool and importing it into another, not by reading the specification.
Why it exists. A format can look complete on paper and still fail the moment a real vendor tool tries to read it.
Where it breaks. OMG's Model Interchange Working Group, formed on 8 July 2009 to test UML, SysML and UPDM tool interoperability via XMI export/import round-trips, completed its first test case — a UML Class Model — and the public record does not show further test cases completed after that (Object Management Group, 2009). One successful demonstration, then stall.
How that's handled. The lesson carried forward by later efforts is to keep testing round-trips as the project matures, rather than treating an early success as proof the standard has arrived.
In technical terms
In technical terms: the working group used XMI (XML Metadata Interchange), an OMG file format, to export models from each vendor's tool and import them into every other tool, validating interoperability test case by test case.
Compared with what came before
| Point-to-point integration | Interchange protocol | |
|---|---|---|
| Who writes glue code | Every pair of tools, separately | Each tool, once, against the shared format |
| Switching provider | Rewrite request/response handling | Call through the same convention (UPP) |
| Moving a model between tools | Custom loader per source/target | Standard OCI artifact (ModelPack) |
| Moving a semantic model | Custom converter per platform pair | One converter per platform, via a hub (Ossie) |
| Proof it works | Assumed from working in production | Needs round-trip testing, as OMG's working group showed |
| Guarantees on behaviour | None, implicit | None, explicit — UPP states it preserves provider-native configuration |
The honest reading of that table is that these protocols cut integration labour, not integration risk. They mean fewer bespoke adapters to write and maintain, which is real and worth having. They do not mean a model swapped in through a standard format will answer the way its predecessor did.
Where it breaks
Even where a protocol is adopted cleanly, it solves a narrower problem than "interoperability" suggests.
Not a guarantee of equivalent output
UPP standardises how you call a provider, not what the provider returns. It explicitly preserves provider-native configuration rather than abstracting it away, so two providers reached through the same UPP call can still behave differently; the protocol's own documentation calls the opposite failure "abstraction leakage" and designs against it rather than against behavioural difference (Provider Protocol).
The packaging layer and the calling layer solve different problems and neither one checks the other's work. ModelPack and OCI registries get a model artifact from one tool to another; they say nothing about request-time behaviour. UPP gets a request to the right provider in the right shape; it says nothing about how that model was packaged or trained. Treating either as proof of "interoperability" in the everyday sense — same inputs, same kind of outputs — mixes up two separate guarantees.
Version drift is a related trap. Even within one vendor's own lineage, upgrading a base model can change downstream behaviour; the compatibility-adapter patent's divergence metric is built precisely because that drift is common enough to need a formal check before deployment. A standard interchange format does not prevent drift between versions of the same model, let alone between two different vendors' models.
And adoption itself is still young and plural rather than settled. ModelPack, UPP and Ossie are separate efforts from separate communities, each still maturing — Ossie's roster of 60-plus backing companies is a strong signal of intent, but intent is not the same as a finished, battle-tested converter for every platform on that list. A reader deciding whether to depend on any one of these should expect the specifications themselves to keep changing.
Numbers to carry
| Figure | Detail |
|---|---|
--format=cncf | Docker Model Runner option producing ModelPack OCI artifacts, added August 2026 |
| UPP version | 1.3, as published on GitHub |
| Ossie backers | over 60 companies, including Databricks, Informatica, Mistral AI, Nvidia, Oracle, Salesforce, Snowflake |
| OMG working group formed | 8 July 2009 |
| OMG test cases completed | first case (UML Class Model) completed; no further completions documented publicly |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "A model interchange protocol means any model becomes a drop-in replacement for any other." | UPP standardises the calling convention; it preserves provider-native configuration precisely because models are not treated as equivalent black boxes. |
| "Packaging a model as an OCI artifact proves it will run the same everywhere." | ModelPack standardises the container format, not the model's performance; a well-formed artifact still needs evaluation. |
| "These are competing attempts at one universal standard, and one will win." | ModelPack, UPP and Ossie operate at different layers — packaging, calling, and semantic translation — and can coexist rather than compete directly. |
| "Having 60-plus companies back a format means it already works everywhere." | Backing a project is a statement of intent; Ossie's actual interoperability depends on converters being built and shipped, such as Microsoft's in-progress Power BI converter. |
| "Interchange efforts always succeed once a working group forms." | OMG's Model Interchange Working Group completed its first UML test case in 2009 and the public record shows no further completed cases after that. |
Worked example
- Papa's team currently calls one hosted model provider directly from application code, with request shapes specific to that vendor's API.
- A self-hosted model, trained separately, needs to join the same pipeline alongside the hosted one.
- Packaging: the self-hosted model is assembled into a ModelPack-style OCI artifact, bundling weights, tokenizer and configuration into one standard container.
- Distribution: that artifact is pushed to an OCI registry, the same kind of registry the team already uses for container images, so any compliant runtime can pull it.
- Calling: application code is rewritten once, against UPP's uniform interface, instead of once per provider; the hosted provider and the newly self-hosted model are both called through the same shape of request.
- Configuration leakage: provider-specific settings — a sampling parameter unique to one model, say — still need separate handling in code, because UPP preserves provider-native configuration rather than hiding it.
- Drift check (illustrative): before switching production traffic to the self-hosted model, the team computes a divergence metric between its output distribution and the hosted model's, following the adapter-layer approach described in the dossier's patent reference, and only proceeds once the number looks acceptable to them — the dossier does not give a numeric threshold, so this judgement call is theirs to make.
- Verification: the team treats the swap as provisional until they have run real queries through both models side by side and compared answers directly, rather than trusting the packaging and calling layers alone to prove equivalence.
Should you use it?
Reach for these standards when you are running, or plan to run, more than one model provider, or moving models between separate training and serving tools, and want to stop writing a new adapter for every new pair. They fit well when the bottleneck is genuinely integration labour: rewriting request shapes, loaders and config by hand for each tool pair. They fit badly as a substitute for evaluating whether a new model performs the way you need it to — no packaging or calling standard checks that for you. The cheapest first experiment is small: package one existing self-hosted model as an OCI artifact and push it to a registry you already run, without touching any calling code yet, to see how much of the "weekend rewrite" problem the packaging layer alone removes.
Say it in the room
"Use these when you need fewer integrations to maintain across providers; don't expect them to make two different models answer the same question the same way."
Lines to carry
- "A common box, not a common mind."
- "Standardising the plug is not standardising the current."
- "One converter to the hub beats a converter for everyone else."
- "The format proves it unpacks, not that it performs."
- "Interoperability here means a shared calling convention, not identical answers."
FAQ
Is ModelPack the same thing as a container image format?
No. It reuses OCI artifact mechanics — the same underlying packaging system used for container images — but defines model-specific content types for weights, tokenizer and configuration that a generic container image format does not describe.
Does UPP mean I can switch providers with zero code changes?
Not entirely. UPP gives you one calling convention, but it deliberately preserves provider-native configuration rather than flattening it away, so some provider-specific handling still remains in your code.
How is Apache Ossie different from ModelPack or UPP?
Ossie operates at the semantic-model layer — datasets, fields, metrics and business meaning in analytics platforms — rather than at the level of packaging model weights (ModelPack) or calling a model provider at request time (UPP). They solve different problems that happen to sit near each other.
If a model is upgraded to a new version, will these protocols catch behavioural changes?
Not directly. A separate mechanism — the compatibility-adapter and divergence-metric approach described in a Google patent — is built specifically to flag drift between model versions before deployment; packaging and calling standards don't do this on their own.
Are any of these protocols finished and stable?
No. UPP is at version 1.3 and still evolving, Ossie's backer list and converter set are still growing, and ModelPack's Docker integration only arrived in August 2026. Treat all of them as moving targets, not settled standards.
Glossary
- Model interchange protocol — a shared specification for packaging, describing or calling AI models so they move between tools, runtimes or providers without custom integration for each pair.
- OCI artifact — a standard package format from the Open Container Initiative, originally for container images, reused to bundle other content such as AI models.
- Registry — a server that stores and serves packaged artifacts so other systems can pull and run them.
- NxM problem — the situation where N tools each need a separate integration for M providers, producing N times M pieces of custom code instead of one shared standard.
- Semantic model — a structured definition of an organisation's data, including datasets, fields, relationships and metrics, giving data consistent meaning across tools.
- Hub-and-spoke model — an architecture where every system converts to and from one common central format instead of needing a converter for every pair of systems.
- Adapter layer — a small set of trainable parameters attached to a base model that customises its behaviour for a task without retraining the whole model.
- Divergence metric — a measurement of how different two models' output probability distributions are, used to judge whether an upgraded model behaves too differently from the one it replaces.
- Abstraction leakage — when a supposedly uniform interface still exposes underlying provider-specific details, undermining the point of a clean common interface.
- XMI (XML Metadata Interchange) — an OMG standard file format used to export and import UML and related models between modelling tools.
- Provider-native configuration — settings specific to one AI provider's model or API that a protocol passes through rather than flattening into a generic form.
- Model Context Protocol (MCP) — a protocol standardising how AI agents connect to and use external tools and data sources during a task.
Sources
- UPP Specification | Provider Protocol — Provider Protocol
- Advancing AI model interoperability with Docker and ModelPack — CNCF, 2026
- A Survey of Agent Interoperability Protocols: Model Context Protocol (MCP) and Beyond — arXiv, 2025
- UPP-1.3.spec.md — GitHub / ProviderProtocol
- Microsoft, Google back Apache Ossie to make enterprise data and AI platforms more interoperable — DevFeed
- US20250315731A1 - Model compatibility for large language models — Google Patents
- OMG Announces Model Interchange Working Group — Object Management Group, 2009