Judgment Pack Specification v0.3.0-rc.1

v0.3.0-rc.1

This is the single release candidate for Core 0.3.0, distributed under tag
v0.3.0-rc.1 as a GitHub pre-release. Preparation and a draft GitHub release do not publish it.
Once published, it gives adopters about one week to check the renamed manifest maturity status
before the final v0.3.0 release. The final release has not been established by this candidate.

Scope and identity

The proposed format remains exact specVersion 0.3.0, and both corpus manifests name
suiteVersion 0.3.0; packs do not declare 0.3.0-rc.1. Both manifests remain maturity draft,
not the independent-evidence maturity candidate or the 1.0.0 standards maturity release.
Each bundle includes the closed distribution-to-format map and a generated release-identity.json
with this exact RC tag and resolved source commit. Archive checksums and build provenance cover
those bytes. The map creates no compatibility rule for other prereleases.

Included work and reader/writer/semantic migration guidance are described in the prepared
0.3.0 notes. In particular, the historical 0.2.0-draft identifier
and frozen schemas keep their names; readers compare full version selectors. There is no automatic
migration promise or compatibility guarantee for this pre-1.0 draft. The independent Policy
companion keeps its own release route and is excluded from the Core schema/corpus bundle paths.

Adopter checks and claim limits

Check that tooling reads the manifest status value draft in place of the retired
research-preview, independently from the exact specVersion, and preserves/refuses versions
according to its declared reader support. Runtime vendoring must retain historical releases and
record this candidate's exact source identity rather than label it a published final release.
Report incompatible readers, schema/corpus disagreements and migration problems before final
publication; the maintainer reviews that feedback after about one week of public RC availability.

Results against this candidate name its tag and commit and remain provisional. This candidate does
not establish a final 0.3.0 conformance claim or standards maturity. Conformance never proves
truth, authorization, safety or operational fitness.

The accepted Dialect companion prose is included, but conformance/dialect/ vectors remain staged,
export-ignored and absent from the bundles. No preparation-verifier conformance claim becomes
available through this RC. Staged witness and future evaluation rows likewise remain excluded.
This says nothing by itself about a product's separate tool-certification evidence; downstream
claims need their own exact checks and disposition.

Recovery provenance

The signed RC tag and artifact source remain 495535f29a517dc6a36075b77238634011e7371e (annotated tag object c0ddd58e507ce42891947929acb1ad0330faa038). The recovery workflow run used workflow commit dc8825c41b1f834fce63b798a92ef4a115d5bfb6 to check and package that unchanged source. The attestations identify that actual workflow commit, rather than claiming the old tag supplied the recovery workflow.

The attached recovery-evidence.json records both identities, the genuine workflow run, actual toolchains and hashes of the validation logs and artifacts. The original source passed all seven required checks (463 tests), without skipped checks. Both archives contain the same 217 original-source files plus their release identity. Checksums and all three attestations were independently verified before publication.

Recovery and the draft-absence correction are recorded in PR #262, PR #263 and issue #261. The guard correction does not replace these assets or change their provenance.