Compute
Adapter compatibility levels
The four compatibility levels an adapter can declare, and the exact facts its published conformance matrix must state before you plan a release against it.
The four levels
Every released adapter declares exactly one of these:
import_compatiblewire_subset_compatibleofficial_sdk_compatiblefull_endpoint_compatible
These four names are the only compatibility vocabulary used in Compute documentation. No other phrasing is a claim.
The level is a label, not a specification
A level names which conformance matrix applies. The matrix carries the meaning.
Two adapters at the same level are not interchangeable. They differ in tested version, covered fields and error coverage, and the matrix is where those differences are written down.
So read the matrix, not the badge. A level with no matrix version beside it is incomplete and should not be planned against.
What every conformance matrix states
Each matrix is versioned and states all six of these for the adapter it covers:
| Item | What it tells you |
|---|---|
| Supported upstream version | The exact provider product version that was tested |
| Field coverage | Which request and response fields are supported, and which are ignored |
| Lifecycle coverage | Which operations in the object's life are supported end to end |
| Error coverage | Which upstream errors are mapped to typed Compute outcomes |
| Limit coverage | The size, count and rate bounds that were measured, not assumed |
| Unsupported behavior | What is explicitly out of scope, named rather than omitted |
The last row is the one to read first. An omission is ambiguous; a named exclusion is a fact.
What a bare compatibility claim is missing
A sentence such as "S3-compatible" or "OpenAI-compatible", with no level and no matrix, is forbidden in Compute documentation for a practical reason.
It does not say which version was tested. It does not say which fields are covered. It does not say which errors map, or what was left out.
If you read that phrasing anywhere, treat it as unverified until you find the level and the matrix version behind it.
How to compare two adapters
Work through these in order, and stop at the first one that fails your requirement:
- Confirm both declare a level and name a matrix version.
- Compare the tested upstream version against the version you actually run.
- Compare field coverage against the fields your client sets today.
- Compare lifecycle coverage against the operations your client performs.
- Compare error coverage against the failures you already handle.
- Read the unsupported behavior list on both, in full.
A higher-sounding level does not win this comparison. The matrix that covers your fields does.
What compatibility never covers
Some properties are decided by Compute, not by an adapter's level:
- Admission. A supported call is still refused if policy, spend authority or capacity says no.
- Immutability. Input is snapshotted with a
version_idand acontent_sha256regardless of adapter. - Delivery. Results are written once, to a new location, and verified before they are committed.
- Credentials. A secret reference or a federated grant is required, whatever the upstream product accepts.
Do not read a compatibility level as permission to skip any of those.
When the matrix does not answer your question
Test the narrowest real case rather than inferring from the level.
- Use the source or destination family's
testoperation on one object. - Read the typed result, including the reason and next action on any refusal.
- Record the matrix version you tested against, next to your own integration notes.
If the behavior you need is neither supported nor named as unsupported, treat it as untested and plan for it to refuse.