Platform matrix and parity

Documentation status: architecture. A platform is not claimed as supported merely because an ABI, container pattern or Runtime Identifier can represent it.

Three separate claims

Portability means the Runtime/application can be deployed on a target. Binding availability means the required public client package exists for that target. Functional parity means the required published capabilities behave equivalently for the documented scenario. These are different claims.

Currently grounded statements

Target / mode	What this documentation can currently state
Windows local .NET	A local managed process and native Runtime must match process architecture; explicit targets such as win-x64 are the documented packaging pattern.
RPC / remote .NET	The managed application can use IClientRuntime through a remote adapter without loading the native engine in the application process.
Containers	Remote mode is naturally container-friendly; local mode additionally requires matching native Runtime assets in the image.
Other native targets	Do not infer certification. Add a row only when a release artifact, smoke test and capability result are available.

Required evidence for a certified row

Record Runtime version, target/RID, binding version, local or RPC mode, startup test, capability negotiation result, contract-test result, known gaps, and date.

Rule: no platform without a matrix.

Single source of truth

This page is the canonical public platform matrix for developer support claims. Product and marketing pages should link here rather than duplicate platform rows. The governing claims policy is logiCells.com — Claims.