Rendered from docs/PLATFORM_INTEROPERABILITY.md at build time without changing its status. The repository source controls if this presentation differs.

Platform interoperability#

Acronyms: 64-bit Arm instruction-set architecture (ARM64); application programming interface (API); Concise Binary Object Representation (CBOR); command-line interface (CLI); CBOR Object Signing and Encryption (COSE); continuous integration (CI); Java unit test report format (JUnit); JavaScript Object Notation (JSON); operating system (OS); reduced instruction set computer (RISC); Supply Chain Integrity, Transparency, and Trust (SCITT); Verifier Standard (VSTD); Windows Subsystem for Linux 2 (WSL2); ZIP archive format (ZIP).

This document records where the Verifier Standard (VSTD) reference repository has platform evidence and where it does not. Its machine-checked reference-component table is separate from the broader evidence-surface summary. Neither is a declaration that every verifier, prover, solver, adapter, or dependency works on every operating system (OS).

Evidence coordinates and freshness#

Three surfaces must stay separate: source-controlled test intent, an exact hosted observation, and the candidate being evaluated now. The generated component table below records intent. Its CONFIGURED_UNRUN labels do not assert that a component has never run; they cannot be promoted to support claims inside a source manifest.

For the current candidate, select its successful repository-checks run from the workflow history. This is a discovery link, not immutable evidence. Require the exact head, base, executed checkout, run identifier and attempt in the retained reports. Retargeting a request or retaining an earlier green check does not establish fresh integration. Publication additionally requires a successful push run on the exact final main commit, as specified in the release procedure.

A changed implementation, catalog, test, workflow or dependency requires reassessment; the prior run remains an observation of its own coordinate. Native results do not inherit another component's tests, and recorded environment metadata is not hardware or runtime attestation.

Recorded candidate observation#

Run 34077770237, attempt 1, completed successfully for head b6b1a82b862219ffc3c44bb2f4b544444d921715, base 499c0613c93232628abfdeb497d907549fd593fc, and executed pull-request merge 884b3cfc9dd36ac0914a5482bece0c13abf33f64. The executed and head trees both equal 5135df58006e602606e9a8f304ac43d4e83d186e. This is a pre-retarget observation, not evidence for a later candidate or the final release commit.

All four component reports were reconstructed byte-for-byte from their retained raw environment and JUnit documents with the repository builder. That is reproducibility of report construction, not a second native execution or an independently implemented checker. Each environment records CPython 3.12.10; all four record zero failures/errors.

Collection placeholders are not executed tests. Parameterized instances are not counts of independent mechanisms. The reports map 18 catalog entries through 13 test modules and 413 mapped instances; shared tests and wrappers do not become independent verifiers. The raw reports retain the exact skip reasons. Unavailable optional mechanisms and platform-specific filesystem cases do not earn passing coverage.

Evidence classes#

• Hosted execution: a CI job executes the named component on the named OS. A successful exact run is still bounded by its runner image and inputs.
• Packaging only: the distribution is built and checked on that OS; this does not exercise every installed mechanism.
• Static or artifact-only: tests inspect source, configuration, or recorded bytes without executing the native mechanism.
• Documented local execution: the repository records a local run and reproduction procedure, but CI does not currently repeat it.
• Unsupported by this repository path: the checked-in procedure does not offer a native path for that OS. This says nothing about what an upstream project might support.
• Unknown: no current repository evidence establishes support or incompatibility.

Evidence-surface summary#

The observations in this table refer only to the recorded candidate above. For another head, apply the freshness rules and inspect its own run. A complete-suite pass covers collected, non-skipped cases, not every possible behavior of every exported function.

Machine-checked reference-component contract intent#

The new stored component format is also exercised by the complete-suite jobs, including a fixed canonical-digest specimen, exact binary-byte round trips and package-selected planning. The recorded observation establishes only those executed cases at its named coordinate; changed candidates require their own reports. Portable storage does not qualify a retained native implementation. Storage is supporting infrastructure, not an extra independent verifier counted in the 43-component inventory below.

The six newly represented experimental families contribute 12 role-specific entries: source grounding, relation-boundary assessment, actual deriver self-status, global-cycle assessment, source-grounded bounded completeness, and runtime-authority correspondence. Assessment or bounded recording and receipt rechecking remain separate roles, not independent implementations. Their native declaration and receipt formats remain direct-submodule experimental contracts; this source-intent table does not add stable wire identifiers. Stored-package detection and planning match exact identifiers only. Readiness does not invoke an entrypoint, grant authorization, or close ordinary or self-closure geometry, and missing native inputs or result mappings remain NOT_ESTABLISHED.

The source-controlled platform-component-contracts.json manifest enumerates exactly the current reference catalog and four separate execution coordinates. CONFIGURED_UNRUN records configured intent only; it is not hosted execution, compatibility, or support evidence. BEHAVIOR means the mapped tests call the component on bounded positive or adversarial cases. It never means the tests cover every native input, dependency, filesystem, trust root, or external implementation.

Intel macOS cryptographic coverage is an experimental source-build target. The pinned cryptography==50.0.0 dependency follows the upstream removal of Intel macOS support. The Intel job explicitly builds cryptography and cbor2 from source with the hosted runner's Rust and C compilers and Homebrew OpenSSL 3, following the upstream source-build prerequisites. It must pass installation and the complete suite before emitting a report. A successful run supplies only evidence for that exact build and runner; it does not restore upstream support or qualify other Intel macOS environments. Apple ARM64 is a separate coordinate.

Raw environment and JUnit files are boundary-checked before artifact upload, including after a failing test command. Missing or prohibited evidence fails the job and is not uploaded. The gate does not redact or rewrite the evidence bytes. The explicit scripts.pytest_public_evidence plugin records skip source locations relative to the declared test root before serialization. It preserves outcomes, reasons, and line numbers; outside-root locations remain unchanged and subject to the upload gate.

After the complete test command succeeds, CI emits a separate, platform-neutral platform-component-contract.json artifact. Its artifact name includes the workflow run identifier, run attempt, and platform coordinate. That runtime report binds the exact Git and workflow coordinate, workflow-file digest, test command, runner image, interpreter, catalog version and digest, source manifest digest, the exact raw environment-document digest, JUnit result, component identifiers, test modules, dependency profiles, and bounded test scopes. The builder also requires at least one successful, non-skipped test case from every mapped module and rejects malformed or contradictory JUnit suite counts; a green unrelated subset or summary-only failure cannot populate all component rows. The environment loader rejects unknown or duplicate fields before binding the raw document bytes. The raw environment record is uploaded after later-step failures, and the JUnit report is included whenever the test command produced it. The component report is not created or uploaded after failure. These hosted artifacts are retained for 30 days; their presence during that window is not the long-term release record.

For a release, the owner supplies the exact successful repository-checks push-run identifier. The release workflow requires that run to target the tagged commit on the protected default branch and contain one successful conformance-gate. It downloads all four component reports plus their raw environment and JUnit evidence, independently reconstructs every report from those raw inputs, and rejects a missing coordinate, mixed run or attempt, pull-request synthetic merge, changed workflow/catalog/manifest, failed or contradictory test evidence, altered environment bytes, or byte-altered report. The resulting deterministic platform-evidence ZIP contains an internal manifest binding every member digest and byte length to the release tag, repository, commit, run, attempt, and bounded claim. The ZIP is boundary-scanned, attested, and attached to the immutable release. It retains verification_effect = NONE: durable evidence does not strengthen what the mapped tests establish.

<!-- BEGIN GENERATED PLATFORM COMPONENT CONTRACTS -->

<!-- END GENERATED PLATFORM COMPONENT CONTRACTS -->

Reading a platform-comparison result#

The comparator classifies supplied recorded results; it does not certify an OS or a component in the abstract:

• PASS means the complete declared receipt set had matching bound non-platform coordinates and matching declared result projections.
• CONFLICTED means comparable receipts disagreed on a declared result surface.
• NOT_ESTABLISHED means required coverage or comparability evidence was absent or did not isolate the OS dimension.
• INVALID means an input was malformed, canonically inconsistent, or internally contradictory.

A mechanism may be cross-platform compatible even when this repository reports UNKNOWN; the missing fact is evidence, not necessarily capability. Conversely, a successful generic Python example cannot upgrade a native prover, verifier, solver, hardware integration, or third-party adapter from UNKNOWN.

Release maintenance rule#

For each release candidate, update this matrix only from evidence at the exact release coordinate. A new platform claim requires, at minimum, a named component and version, the native or interpreted execution boundary, the OS and machine family, the checking mechanism, positive and adversarial results, and the exact hosted run or reproducible local receipt. When any of those dependencies changes, prior evidence remains historical and current support returns to UNKNOWN until it is re-established.