Judgment Pack Specification 0.2.0-draft

This release publishes the second research preview of the Judgment Pack Specification (JPS) under the immutable tag v0.2.0-draft.

It is intended for design review, synthetic pack authoring, carrier, structural, and semantic conformance experiments, and — new in this release — evaluator conformance work. It is not an industry standard, carries no compatibility guarantee, and must not be represented as sufficient for consequential production decisions.

Scope of the change

0.2.0-draft is the first normative change to Core since the specification was seeded. It adds one conformance class and changes no part of the document format.

• Evaluator conformance (§3.4). An implementation that, given a conformant pack, a facts document, an evidence-availability document, and its own supported-extension set, produces the portable disposition of §8.3 under the semantics of §§7–8, reports evaluation errors per §8.4, defines the §10 limits, and passes the evaluation corpus for the exact specVersion it names.
• §3.4.1 permits exactly one form of claim — against the class and the corpus, for one exact specVersion, with the results stated and with the claim itself saying that every row of the named corpus version passed. The claim's scope is the whole §§7–10 contract for every input the implementation admits; corpus results are required evidence of that and are not the boundary of it. A failed row blocks the claim unless a project-issued, versioned erratum (conformance/evaluation/errata.md) marks that row defective for that corpus version, in which case the claim must name the row and cite the erratum. A claimant does not get to call a row defective on its own authority. Partial claims, claims from prototyping, and claims without corpus results remain forbidden, as does any claim under 0.1.0-draft.
• §§7–8 are now normative for that class and informative for everyone else. §7.5's undefined "complete evidence manifest" is replaced by the §8.2 tri-state; §8 step 2 is restated in three-valued terms; §7.4 defines ordered comparison of decimal strings, excludes units and date/time explicitly, requires every operator of an implementation claiming the class, and states that equality of decimal strings is string equality and deliberately not decimal-aware.
• The portable disposition (§8.3) — kind, outcomeId iff kind is outcome, reasons as a sorted set, and a handoff object carrying state and, when requested, triggeredBy. It does not echo the escalation target. Two conforming implementations must produce byte-identical dispositions after canonicalization, with exactly one stated seam: equality involving a JSON number an implementation cannot represent exactly, which §13 leaves open and §8.3 names.
• Input preflight (§8.2). The inputs are admitted before §8 runs: pack, then facts, then evidence availability, with an omitted evidence document meaning the implicit empty object. Any violation of §8.2's shape — a non-object evidence input, an undeclared key, a value outside the tri-state — is malformed-input. Because preflight completes before step 1, an input error can never be outraced by a not-applicable result.
• The error contract (§8.4). An evaluation error is not a disposition: it terminates evaluation wherever §8 had reached and yields no result. Every error carries exactly one class — one of the four Core classes pack-not-conformant, malformed-input, unsupported-required-extension, resource-exhaustion, reported in that fixed precedence order where more than one applies, or a documented implementation-defined class for a condition no Core class covers, which uses §9's reverse-domain form and never displaces a Core class that applies.
• §10 uplift, split by phase. For implementations claiming the evaluator class, defining collection-size and evaluation-work limits is a MUST, and reaching one during evaluation is resource-exhaustion rather than a result. A document or carrier limit reached while admitting an input is malformed-input instead: §2.1 refuses that document, so preflight never admits it. Either way the outcome is an explicit error.

Document conformance is untouched. Nothing above changes whether a document is carrier, structurally, or semantically conforming.

Included

• Core prose at 0.2.0-draft and a JSON Schema Draft 2020-12 structural schema pinned to it.
• The 0.1.0-draft schemas, preserved for packs and manifests that keep the older value and served at the $id each was published under: the Core structural schema at schema/judgment-pack-core-0.1.0-draft.schema.json and the document-conformance manifest schema at schema/conformance-manifest-0.1.0-draft.schema.json. See the preservation note below for exactly what "preserved" means here.
• Five synthetic examples, re-declared at 0.2.0-draft.
• The 47-case carrier, structural, semantic, and capability corpus, re-pinned to 0.2.0-draft.
• A new 20-case seed evaluation corpus in conformance/evaluation/, with its case carrier and four pack fixtures: thirteen rows imported from the cross-implementation exercise (ten over the nine walked RFC 0006 appendix instances, counting both variants of instance 7, plus three probes) and seven constructed here from the specification text.
• A short external-user testing exercise and feedback template.
• Automated repository integrity, corpus, and evaluation-carrier checks.
• Versioned .tar.gz and .zip artifact bundles, SHA-256 checksums, and GitHub build-provenance attestations.

What "preserved" means for the 0.1.0-draft schemas

Each preserved file matches the schema published at the immutable v0.1.0-draft tag in every byte except its $id member. That member was re-pointed to the project's neutral domain when the retired pre-publication identifier was withdrawn, so that the identifier a 0.1.0-draft document resolves today is one this project controls and keeps serving. Nothing else was edited: no keyword, no constraint, no specVersion constant. The tagged v0.1.0-draft release remains the authoritative record of its own bytes; this release preserves a schema for continued use, and does not restate the tag.

Both forms are published here so the difference is checkable rather than asserted:

Compatibility

• Reader: a 0.1.0-draft reader rejects a 0.2.0-draft document, on the exact specVersion value and on nothing else. No member was added, removed, or redefined, so such a reader can parse and preserve everything else in the document once it gets past that value.
• Writer: a 0.2.0-draft writer's output is rejected by a 0.1.0-draft reader, for that same one reason. Both directions are negative; the exact-version rule is deliberate (§11) and the format being unchanged does not soften it.
• Migration: specVersion is exact, so a 0.1.0-draft pack must be re-declared as 0.2.0-draft — that one value, no other edit — to be structurally conforming here. A pack that keeps the older value stays valid against the preserved 0.1.0-draft schema. The pack is unchanged in representation and in document-conformance meaning; re-declaring it is not semantically inert, because it opts the pack into this draft's evaluator semantics, which existed for no consumer under 0.1.0-draft, and it confers no conformance on any implementation.
• Semantic: results that were informative in 0.1.0-draft are normative for the evaluator class, which is a new obligation for evaluators and none at all for validators. Two 0.1.0-draft evaluators could legitimately disagree on the same inputs; two 0.2.0-draft evaluator-conforming implementations must not.
• Claims: an evaluator-conformance claim attaches to one exact specVersion and to the corpus published with it. Nothing is inherited, and no claim is acquired by re-declaring a pack.
• This is a 0.x release. The next one may be incompatible again.

The independence caveat

The evidence behind this change is two implementations and a 13/13 agreement corpus. Both implementations trace to one maintainer's direction. The second was written clean-room, inside an information barrier, by a different model family, but from reference texts the same maintainer chose, including RFC 0006's own implementation-experience notes. Their agreement corroborates the semantics; it does not independently confirm them.

Acceptance of RFC 0006 is design approval at draft maturity. It is not a stability claim. The RFC 0000 bar for a stable normative feature — two independent implementations — is not met, and it is re-tested at stabilization rather than treated as satisfied. The project also has one maintainer and no independent contributors; see the interim review regime in GOVERNANCE.md.

Limitations

• No implementation ships an evaluator-conformance claim with this release. The reference runtime's evaluator remains experimental and claims nothing; whether it claims the class is a runtime decision, made in that repository, not here.
• The evaluation corpus is a seed: four packs, twenty rows, no error rows, no rule-order permutations, no hostile-extension rows, and no number-representability row — that last one deliberately, because the question it would pin is open (§13). conformance/evaluation/README.md lists the gaps.
• The corpus carrier cannot yet express every error row it advertises. facts is embedded parsed JSON and evidenceAvailability is schema-constrained to the tri-state, so a malformed-JSON, duplicate-member, non-object-evidence, or invalid-state input has no fixture form; a raw-document fixture form is deferred to the next suiteVersion. The optional workBudget and expectedErrorPhase case members are defined in this version's carrier and used by no row, so a later row can carry them without another carrier change (§3.4.1).
• The erratum mechanism §3.4 defines is in place and empty: conformance/evaluation/errata.md records no erratum for suiteVersion 0.2.0-draft.
• Only the thirteen imported rows carry the two-implementation agreement. The seven constructed rows were read off the specification by the same maintainer and reproduced on one of those two implementations, which is a check on the derivation rather than agreement between two of them. A divergence against one of those rows is as likely to be a defect in the row as in an implementation (§3.4).
• Passing the corpus does not establish that an implementation is correct on inputs the corpus does not contain.
• Conformance of any class still does not establish factual truth, evidence authenticity, authority, permissibility, or operational fitness (§3.5). The one narrow exception is stated there and nowhere else.
• Still undefined: units, date/time, and normalization semantics; number representability; an evidence interchange form beyond the tri-state; the minimum contents of a trace; a machine-readable diagnostic contract for validation and for the §8.4 error classes; imports; signatures.

Testing guidance

• Validators: revalidate your packs against the 0.2.0-draft schema after re-declaring specVersion, and confirm your tool reports the exact-version mismatch rather than accepting an unedited 0.1.0-draft pack.
• Evaluators: run conformance/evaluation/manifest.json and compare dispositions by §8.3 equality. Report a divergence against the specification text, not against another implementation — a disagreement between two evaluators is a candidate specification defect until the text says otherwise.
• Do not automate a real outcome from a pack, and do not describe agreement between evaluators as evaluator conformance: the corpus is what a claim is made against (§3.4.1).

See TESTING.md, VERSIONING.md, conformance/README.md, and conformance/evaluation/README.md in this release for details.