Draft · 0.3.0

A `0.x` draft in production use by adopters: pin the exact draft and runtime release; no compatibility guarantee between drafts.

Judgment Pack Specification
Informative View current source

v0.4.0

On this page

v0.4.0 carries specVersion 0.3.0 unchanged. It is a release of work beside Core: a recording set, a Draft RFC and a record-shape catalog. It is not a new specification version.

  • Packs keep declaring exact specVersion 0.3.0. A pack declaring 0.4.0 is refused, because the Core schema's specVersion constant is still 0.3.0.
  • The tag name is not a selector. 0.4.0 is this distribution's identity, as releases/v0.4.0.json and each bundle's generated release-identity.json record it. No reader, pack or claim selects it.
  • Tag v0.3.0 still identifies Core 0.3.0, and it is not changed or superseded.
  • Consumers pinned to v0.3.0 need do nothing.
  • The Core prose, schemas, examples and both corpora in this release's bundles are byte for byte those of the v0.3.0 bundle, and the corpora's suiteVersion stays 0.3.0.

Included work

  • A Core 0.3.0 dialect recording set (#249). 46 recordings of the historical scenarios, made by the reference Runner under Core 0.3.0, in conformance/dialect/vectors-0.3.0/ with conformance/dialect/manifest-0.3.0.json. They sit beside the 47 historical recordings, whose bytes do not change. One scenario, unbound-record, is not recorded again, and two rows now read binding matches where the historical rows read absent; the directory's README gives the provenance and both differences. The set is staged as the historical one is: it is in no corpus and no bundle, the site does not serve it, no Core conformance claim may cite it, and spec/dialect.md is not changed to name it.
  • RFC 0030 at Draft (#280). A proposal for agent principals and delegated authority, proposed for Spec 0.5.0. It is normative for nothing, claims no conformance class and commits nothing for 0.5.0.
  • A record-shape catalog (#256). catalog/ gives every JSON Schema the specification defines, in a stated normalized form, with its SHA-256 digest, change records for every digest, and a format-status record per family. It is in this release's bundles and not on the site. Its check runs on every pull request. Comparing an implementation's own catalog with it is optional and is not part of a conformance claim. Formats defined in prose alone (the decision record and audit chain, dialect recordings, receipts) have no schema and are not catalogued; #286 proposes schemas for them.

RFC 0019, the Judgment Exchange, stays at Draft maturity (#142). It is a cross-project exploratory record outside the specification, and nothing in Core or a profile follows from it. This release's chore closes #142, whose acceptance asked for that record and for the maintainer's decision on it; neither establishes a release of the Exchange.

Compatibility

Nothing in Core moves, so each dimension VERSIONING.md names has the same answer between v0.3.0 and v0.4.0:

  • Reader compatibility: unchanged. A 0.3.0 reader reads what it read.
  • Writer compatibility: unchanged. Writers emit specVersion 0.3.0.
  • Semantic compatibility: unchanged. Conforming consumers assign the same portable meaning.
  • Migration compatibility: no document transformation applies, because no document changes.

Migration note

None. There is no specVersion to migrate to. A conformance claim stays against exact specVersion 0.3.0 and its corpora, and is neither widened nor renewed by this release. Adopting the catalog comparison or the new recording set is optional.

The selected retained-column leaf

Stay on the v0.3.0 bundle for the retained-column/1 leaf. That release is the leaf's normative support distribution, a leaf support claim is made against a v0.3.0 installation, and support version 0.3.0 does not change.

This release's bundles are not a drop-in for it. They hold the leaf's schema, corpus and companion text with unchanged bytes, but not the two offline readers (tools/), requirements-dev.txt, the inventory releases/v0.3.0.retained-column.json that the companion text names, or the v0.3.0 notes. A tool that follows the latest release instead of an exact tag would lose those files, so pin the tag.

What is in the bundles

The .tar.gz and .zip bundles, with their checksums and build-provenance attestations, hold:

  • the Core and companion prose under spec/, without the Draft spec/workflow.md;
  • schema/ and conformance/, without the Policy companion's directories or the staged directories (conformance/dialect/, conformance/witness/, conformance/evaluation/staged/);
  • examples/;
  • catalog/, which joins the bundles for this tag only;
  • README.md, LICENSE, NOTICE, CHANGELOG.md, VERSIONING.md, TESTING.md and SECURITY.md;
  • this file, the mapping releases/v0.4.0.json and the generated release-identity.json.

Of the files this bundle and the v0.3.0 bundle both hold, only these differ: README.md, CHANGELOG.md, VERSIONING.md, one sentence of conformance/README.md that names the new recording set, and the generated release-identity.json.

They do not hold:

  • rfcs/, so RFC 0030 and RFC 0019 are read at the tag or on the site;
  • either dialect recording set;
  • tools/, so tools/record_shapes.py and the retained-column readers are read at the tag;
  • requirements-dev.txt, the other files in releases/, or the leaf inventories; or
  • the Policy companion's schemas and corpus, which keep their own policy-v route. The catalog fingerprints those schemas and names their paths, so those paths are absent from these bundles.

The workflow contributor model

https://judgmentpack.org/schema/0.4.0/workflow-contributors-2.schema.json is not published by this release, although its path says 0.4.0. That $id is draft staging from RFC 0028, which targets Spec 0.5.0, and the identifier is left as it stands. The file schema/workflow-contributors-2.schema.json is in these bundles as it was in the v0.3.0 bundles, and the site serves it at that path. Neither establishes a release of it: its format-status record stays baseline null and lastReleased null.

Versioning and maturity

Conformance manifest status stays draft. In catalog/format-status.json this release is lastReleased for the four families whose $id is under 0.3.0: judgment-pack-core, conformance/manifest, conformance/evaluation/manifest and workflow. It is not a compatibility baseline, and their baseline stays v0.3.0. The retained-column and policy families keep their records.

The mapping releases/v0.4.0.json is this tag's alone. The builder refuses any other content in it and refuses any other tag using a mapping of this kind. VERSIONING.md introduces no general rule that a tag may differ from its artifacts' specVersion.

What this release pins

  • Format: exact specVersion 0.3.0, the Core schema's specVersion constant and the selector both corpus manifests name.
  • Frozen corpora: conformance/manifest.json and conformance/evaluation/manifest.json, both suiteVersion 0.3.0 at maturity draft.
  • Core schema $id: https://judgmentpack.org/schema/0.3.0/judgment-pack-core.schema.json.
  • Distribution identity: releaseVersion 0.4.0, tag v0.4.0, distribution specification-unchanged, with the source commit in each bundle's release-identity.json.

Checks run for this release

The release reuses main's repository-conformance evidence for this exact commit through the release evidence gate (scripts/dev/release_evidence.py, configured by .github/ci-evidence.json) instead of running the repository suite again. The milestone, tag, artifact-pin and bundle checks run again at the tag. The reused run's id and attempt are in the gate's decision record, which the release run keeps as its release-evidence-<attempt> artifact (web/DEPLOYMENT.md, "Release evidence").

The range from v0.3.0 had a pre-release read, recorded with its dispositions on this release's chore pull request. That read is same-vendor review, not a cross-vendor claim.

Results against this release name its tag and commit. Conformance never proves truth, authorization, safety or operational fitness.