Judgment Pack Specification v0.2.0-draft

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:

Artifact	Form	SHA-256
Core structural schema	at the v0.1.0-draft tag	81f6986edc8d2bbf6f49c28a9bbec4f9054f7c72cab5a5028130e01d2e7274d8
Core structural schema	preserved here (schema/judgment-pack-core-0.1.0-draft.schema.json)	c65c559db33d19d2f327858635266fca7fcc049fb75083a7a8d47517e27224fc
Document-conformance manifest schema	at the v0.1.0-draft tag	fa3f55f53712253551d6374ff3f06621e936b56c04dabd399703bbb05285c740
Document-conformance manifest schema	preserved here (schema/conformance-manifest-0.1.0-draft.schema.json)	f073bde8f6f2189edd0334c81c03fecfacf8fae2bd49305a788c75550dcbc2c5

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.