# Release evidence contract A release is promotable only when every supported helper target has one passing, machine-readable record. The immutable v1 source schema is [`release/evidence-v1.schema.json`](https://github.com/BigscreenVR/omp-spt/blob/main/release/evidence-v1.schema.json). The documentation build publishes the same bytes at the stable `contracts/release-evidence-v1.schema.json` URL. An incompatible contract must use a new schema version and filename; it must not rewrite v1. ## Record custody Name each record `release-evidence-v-.json`. While the candidate remains a prerelease, attach all three validated records and every inventoried log they reference to the same GitHub release as `adapter.spt`. Verify the complete attachment set and its log digests before promotion. Keep one record for each supported target, including the `x86_64-unknown-linux-musl` static-helper compatibility tier. A musl record proves that spt-core selected and installed the tagged archive's musl helper on a real OMP-capable host; it is not a generic Alpine support claim. Do not overwrite a record after promotion. A rebuilt candidate has a different artifact digest or source identity and therefore needs a new release candidate and a complete acceptance run. ## Required evidence Each target record binds all results to one release source identity: - the canonical manifest version, conventional `vX.Y.Z` tag, full source commit, and source tree; - the target triple plus bare canonical SemVer for OMP and spt-core on the acceptance host; - SHA-256 digests for the acquired `adapter.spt`, exact selected target helper, and every referenced release log; - a passing tagged-release acquisition result; and - passing fresh, resume, message/reply, lifecycle, shutdown, ReadyAgent, and LiveAgent outcomes. OMP must be at least `16.3.15`; spt-core must be at least the canonical `[adapter].min_spt_core_version`. Versions do not carry a leading `v`. Fresh and resume outcomes retain non-whitespace opaque endpoint and native OMP session IDs. Every outcome names durable log evidence as `#sha256=<64 lowercase hex digits>`; URLs and directory paths are not release-asset basenames. The exact `(name, sha256)` pair must also exist in that record's `artifacts` inventory, binding every evidence reference to an attached log. The schema admits only `passed: true`; a failed or incomplete run cannot be represented as promotable evidence. ## Validate records Run the validator against all records for one candidate in a single command: ```bash python ci/release/validate-release-evidence.py \ release/evidence-v1.schema.json adapter/omp-spt.toml \ dist/evidence/release-evidence-vX.Y.Z-*.json ``` Validation rejects schema violations, below-floor host versions, whitespace IDs, unbound or path-shaped evidence references, an incomplete or duplicate supported-target set, disagreement with the canonical manifest version, a tag that is not exactly `v`, duplicate artifact names, a missing `adapter.spt` or selected-helper digest, mixed release source identities, and different `adapter.spt` digests across targets. Passing schema validation does not replace native acceptance; it makes the already-completed acceptance outcomes durable and reviewable.