Conformance corpus

This directory contains 118 focused conformance cases for testing the carrier, structural, and semantic requirements of Judgment Pack Core 0.2.0-draft. It is versioned with the draft but is not yet a complete or normative conformance suite. Evaluator behavior is out of scope here: it has its own corpus, in evaluation/, which is normative for the evaluator conformance class of §3.4. A document-conformance result never depends on it. Nor is the checkpoint witness statement in scope here: witness/ holds the 54 vectors of its companion document, spec/checkpoint-witness.md, which are staged until the next specVersion opens: in no corpus, and not served by the site. Nor is the dialect: dialect/ holds the reference Runner's 47 preparation vectors for its companion document, spec/dialect.md, staged until the next specVersion opens: in no corpus, and not served by the site. The Policy offline-reader promotion holds 124 agreement vectors for its draft companion class. RFC 0023 has conditional draft approval upon required green CI and PR 218 merge; the default branch remains Review until then. These vectors become a released corpus only under their exact Policy tag and a maintainer-published GitHub release. Passing fixtures alone establishes no Core or Policy conformance claim.

manifest.json is the machine-readable case index. Its shape is defined by manifest.schema.json.

Layers

• carrier/ contains inputs held at the carrier layer, before schema validation: most must be rejected (malformed JSON, trailing data, truncated input; duplicate-member cases must be parsed with duplicate detection), and a few are valid and show what the carrier accepts (trailing whitespace, a valid surrogate pair).
• structural/ contains well-formed JSON documents that fail the normative JSON Schema. JPS testing asserts the schema's uri, date, and date-time formats even though some general-purpose JSON Schema libraries treat format as annotation-only by default.
• semantic/ contains documents that pass structural validation but fail a prose requirement, or cannot be fully interpreted with the case's declared consumer capabilities.
• valid/ contains documents expected to pass carrier, structural, and semantic checks. A valid result does not claim factual truth, authority, operational fitness, or anything about an evaluator: evaluator conformance is claimed against evaluation/, never against this layer.

Validation proceeds in layer order. A runner should stop a case at its target layer rather than reporting downstream diagnostics for content that failed an earlier layer.

Manifest expectations

Each case records:

• layer — the highest layer exercised by the case;
• expectedResult — valid, invalid, or unsupported;
• expectedDiagnostic — the primary provisional diagnostic code and JSON Pointer, or null for a valid case;
• specSection — the draft section that motivates the expectation; and
• optional supportedExtensions — the required-extension capabilities available to the consumer for that case. When omitted, the capability set is empty.

unsupported is distinct from invalid: the document is structurally readable and semantically well-formed, but the consumer lacks a capability named by metadata.requiredExtensions.

Diagnostic codes in this corpus are test metadata, not yet a normative cross-implementation diagnostic contract. The recorded diagnostic is the primary expected result; implementations may also report additional detail. A pointer to a missing member identifies the location the member would have occupied.

Semantic checks represented here

The semantic cases exercise collection-local identifier uniqueness; declared outcome, evidence, source, and exception-target references; reference-kind checking; recursive traversal of every condition position for evidence-present; required-extension declaration consistency; and required-extension capability negotiation.

Reference traversal must inspect every condition position, including root applicability, rule conditions, exception conditions, and arbitrarily nested all, any, and not nodes. The focused recursive fixture demonstrates the traversal requirement without defining an implementation algorithm.

Current boundary

This corpus does not test condition evaluation, resolution results, resource limits, canonicalization, signatures, imports, or migration behavior. Condition and resolution results are covered — as a seed corpus with stated gaps — by evaluation/. Future expansion here should remain focused: one primary expectation per negative fixture, with positive, boundary, and adversarial counterparts added when the corresponding semantics become normative.

Every fixture declares specVersion 0.2.0-draft, which is exact. structural/invalid-spec-version.json still declares 0.1.0-draft, which is now the negative case: an unedited 0.1.0-draft pack is unchanged in representation and document-conformance meaning but must be re-declared to be structurally conforming to this draft, and re-declaring it also opts it into this draft's evaluator semantics without conferring conformance on any implementation (§11).

View manifest View manifest schema