Entity SEO learning

Entity version compatibility matrix

State exactly what works together, under which conditions, and on what evidence.

A compatibility claim describes a relationship between specific entities or releases in a stated environment. A product name alone leaves too much unresolved: the release, plan, dependencies, market and effective period can change the answer. A compatibility matrix makes those limits visible beside the evidence and the next action.

Compare the compatibility states

By Kevin Maguire · Entity SEO library

Separate each variant and its applicable conditions.

Define the claim before assigning a status

Use it before publishing claims about connected systems, choosing a path to a newer release or describing support across different variants. Keep the technical result distinct from the provider’s support policy. A combination can still function after support ends; a successful local test can also fall outside the provider’s declared support.

Source entity and exact release → relationship and operation → target entity and exact release → environment and prerequisites → effective period → evidence.

A workshop model beside two blank blue tags and an ivory card sleeve. — Record the entity family and the exact version being assessed.

Identify both ends

Name both entities and their stable identifiers, then specify the releases being compared. Include the edition or plan when it changes access to the feature. A product family is not an exact release, and a newer release does not automatically inherit an older compatibility result.

Name the operation and its direction

“Connector sends orders to Platform” is narrower than “Connector works with Platform.” Sending orders does not establish that refunds, attachments or return messages work. Record each operation separately when the evidence differs. The reverse operation needs its own evidence; the relationship is not automatically symmetric.

State the environment

Record the operating platform, runtime, required modules, configuration, permissions, account plan and market that affect the operation. Distinguish an installation with one site from one with two or more sites if the sources or tests treat them differently. A prerequisite is part of the claim, not a footnote to hide elsewhere.

Bound the period

Keep the source publication or revision date, the date you observed it and any stated effective or end date. These dates answer different questions. Observing an old document today does not turn its content into a current support statement. Use “no end date stated” when the source supplies none, rather than assuming permanent support.

Five statuses, with evidence and a next action

Use these labels for the scoped claim, not for the entire product. Preserve both the provider’s support statement and the observed technical result when they differ. Deprecated describes lifecycle policy and can coexist with a result that still passes a test.

Supported: EvidenceA provider statement covers the exact pair and environment. If the finding rests only on a test, name the result as tested rather than implying provider support.; Wording and next actionSupported for the named operation, pair and environment, according to the cited source. Keep the limits beside the claim and recheck when a relevant condition changes.
Conditional: EvidenceThe source or test identifies a prerequisite such as a module, configuration, plan or permitted market.; Wording and next actionWorks under the stated conditions; no broader claim is established. Check each prerequisite before use. Treat a materially different configuration as a separate claim.
Unknown: EvidenceThe available source or test does not cover the proposed operation, release pair or environment.; Wording and next actionCompatibility is unconfirmed for this scope. Request documentation or conduct a scoped test. Do not convert missing evidence into either success or failure.
Incompatible: EvidenceA requirement conflicts with the target environment, an explicit statement excludes the pair, or a reproducible scoped test fails after the stated prerequisites and configuration have been checked. A failed local attempt alone does not prove that the release pair is intrinsically incompatible.; Wording and next actionThe specified combination cannot satisfy the stated operation or requirement on the available evidence. Identify a supported alternative, change the conflicting requirement or plan a migration. Preserve the failure conditions.
Deprecated: EvidenceThe provider has announced withdrawal, replacement or an end to support for the operation or interface.; Wording and next actionThe combination is being retired or is no longer supported under the stated policy. It may still function. Record the announced timeline and replacement. Plan migration without relabelling a working but retired interface as technically incompatible.

If a retired interface also fails, record both facts. “Deprecated; test fails in this environment” is more precise than forcing lifecycle and technical behaviour into one label.

Documentation and tests answer different questions

Read the declared support boundary

Documentation can establish the provider’s stated minimum release, supported range, required plan and exclusions. Preserve the exact wording and source URL. “Minimum release 4” does not establish that every later major release is supported unless the statement explicitly covers that range.

Describe what the test exercised

A test establishes an observed result for the inputs, configuration and operation it exercised. Retain the exact versions, environment, test procedure, expected result, observed result and test date. Passing an order submission test does not establish refund handling, load tolerance or support for every deployment.

A blue desk lamp beside a workshop model, an unmarked ruler and a blank reference book. — Attach product attributes and source context to the assertion.

Keep disagreement visible

If documentation declares support but your test fails, retain the declared support and the failed result. Check the prerequisites, reproduce the failure and ask the provider to resolve the discrepancy. Do not silently rewrite the documentation claim or present a failed local attempt as proof that every installation fails.

Separate evidence age from evidence scope

A recent source can still describe the wrong plan or market. An older result can still explain an unchanged release pair, but it needs review when a dependency, policy or environment changes. Record the reason for reopening the claim rather than relying only on a calendar date.

Fictional teaching data

One connector, different answers for different conditions

Every product, release, source label, test result and support policy below is invented for this lesson. None describes a real connection between systems or a real provider’s support.

Parcel Bridge release 2.4 sends order records to Store System release 5.1. The baseline environment uses the Business plan in the Irish market, one store and Token Module 3. The baseline operation is outbound order submission. Each row names the operation or environment that differs from this baseline so the reason for the status stays visible.

Illustrative compatibility matrix: one release pair, five scoped findings
Operation and scope	Invented evidence	Scoped decision
Operation and scopeParcel Bridge 2.4 sends orders to Store System 5.1Baseline environment; Token Module 3 active.	Invented evidenceInvented document D1 explicitly lists this pair and operation. Invented test T1 submits a valid order and receives the expected acknowledgement.	Scoped decisionSupportedDescribe support only for this operation and environment. Retain D1 and T1 separately.
Operation and scopeThe same pair sends orders for two or more storesBaseline environment changed to two or more stores.	Invented evidenceInvented document D2 permits this configuration only with the Enterprise plan and Store Router 2. The proposed installation has neither.	Scoped decisionConditionalState both prerequisites. Do not describe the proposed installation as ready until the conditions are satisfied.
Operation and scopeStore System 5.1 sends refunds back to Parcel Bridge 2.4Baseline environment; reverse direction and a different operation.	Invented evidenceD1 and T1 cover outbound orders only. No invented refund source or test is supplied.	Scoped decisionUnknownRequest evidence for refunds in this direction. Outbound order success does not answer this claim.
Operation and scopeParcel Bridge 2.4 submits orders through Legacy Gateway 1 to Store System 5.1Baseline environment with Legacy Gateway 1 replacing the required interface.	Invented evidenceInvented document D3 states that Store System 5.1 no longer accepts this gateway. Invented test T3 returns the stated unsupported interface error.	Scoped decisionIncompatibleReplace the gateway or choose a different supported pair. Retrying the same unsupported interface does not remove the conflict.
Operation and scopeParcel Bridge 2.4 sends orders to Store System 5.1 through Classic ModeBaseline environment with Classic Mode active.	Invented evidenceInvented notice D4 announces retirement of Classic Mode and names Current Mode as its replacement. Invented test T4 still passes.	Scoped decisionDeprecatedRecord that the operation still passes but the mode is being retired. Plan and test the move to Current Mode.

The matrix does not give Parcel Bridge one universal compatibility label. It distinguishes the supported outbound operation, a conditional deployment, an unconfirmed reverse operation, an excluded interface and a working mode scheduled for retirement. Changing the operation or environment can change the status even when the two release numbers stay the same.

Recheck changes and plan the replacement

Name a person responsible for reviewing affected claims and recording the next check. Keep the provider contact separate from your own review responsibility.

Either entity receives a release that could affect the operation.
A dependency, permission, configuration, account plan or market changes.
The provider revises documentation, support policy or retirement dates.
A previously passing operation fails, or a new test contradicts the published claim.

A blue sheet clipped into an open binder beside separate blank record cards. — Recheck the claim when its version or evidence changes.

Find the affected claimsIdentify the rows that depend on the changed release, interface or condition. Keep unrelated results intact. Mark affected claims as needing review instead of presenting the earlier result as current evidence.
Compare the proposed replacementName the destination release or interface, its prerequisites and the operations it must preserve. Check intermediate dependencies too. Compatibility with one component does not establish compatibility with every component in the chain.
Test the migration and fallbackExercise representative inputs and the operations the website or service needs. Check transformed data and return responses, not only installation success. Establish a practical fallback for the change and identify any data that cannot be restored by reverting software alone.
Update the published descriptionRevise the status, evidence and effective period after review. Keep the previous result as history. Make the visible page text, support notes and any schema relationships agree with the scoped claim; resolve entity identities before adding schema.