A support matrix is credible when every supported cell points to a named recipe run, while untested and retired combinations remain visibly different from failures.
Define the dimensions before filling cells
List only dimensions that can change the workflow: API version, SDK package and version, runtime, framework adapter, operating system, authentication mode, and optional service dependency. Avoid a giant grid assembled from every version number. Begin with the combinations customers actually use and the combinations the product team intends to support through the next release.
The OpenAPI Specification defines a language-agnostic interface description for HTTP APIs. When one exists, record the specification version and product revision beside the client version rather than assuming the SDK name identifies the server contract. A generated client, handwritten wrapper, and hosted endpoint can change on different schedules, so each needs a visible identifier.
Tie status to evidence
Use states such as tested, expected, held, unsupported, and retired, each with a written definition. A tested cell links to the recipe version, repository commit, environment, and latest passing receipt. Expected means the team believes the path should work but has not run it. Held means a known issue prevents publication. Unsupported is a product decision, not a synonym for an observed failure.
Semantic Versioning provides a shared vocabulary for major, minor, and patch changes when a package follows that contract. Do not infer compatibility solely from the number. Read the release notes and run the recipe. If the provider does not promise semantic versioning, record its actual release policy. A matrix should state what was exercised, not convert naming conventions into evidence.
Make changes reviewable
Store the matrix with the cookbook so a recipe change and support-status change can be reviewed together. Require a reason when a cell changes, such as a passing retest, a product deprecation, an unresolved regression, or a retirement decision. Preserve the previous state and date. That history helps support teams answer whether a path never worked, stopped working, or simply left the maintained surface.
Integration Atlas assembles the matrix through Reality Contact, LLC and reports the clean-environment runs behind supported cells. The buyer approves the public support promise, names the release owner, and decides whether an untested combination is omitted or labeled expected. The matrix does not guarantee behavior in customer environments with different dependencies, permissions, data, or network controls.
Where the service stops
Reality Contact, LLC writes, tests, and packages integration documentation but does not certify the underlying product, guarantee compatibility with untested environments, operate production accounts, provide ongoing support outside the written period, or decide which product behavior the buyer promises. The buyer supplies safe access and the authoritative product contract, chooses the supported environments, resolves product ambiguities, approves each public recipe, and assigns an owner for future release-triggered maintenance. This developer-documentation and example-testing work does not replace the buyer's engineering, security, legal, compliance, or production-operations review, and it is not a promise that every customer environment will behave the same way. The buyer approves public product statements, supported combinations, credentials policy, and release status before any recipe is published.
Sources: OpenAPI Initiative specification index; Semantic Versioning specification.