Judgment Pack

judgment-pack

Status: pre-1.0

Tagged binaries are official only when they appear on this repository's GitHub Releases page

with checksums.txt. Development checkouts may temporarily embed unreleased JPS snapshots, but

the release workflow rejects them.

judgment-pack is the vendor-neutral reference runtime for the Judgment Pack Specification (JPS). It is a reference implementation, not the only valid one: the normative specification, schemas, and conformance corpus are owned by the separate judgment-pack-spec repository, and an independent implementation is judged against the complete normative requirements of the conformance class it claims — not against this runtime. Results from the corpus published for the exact version it names are required evidence for such a claim and are not exhaustive evidence of it (§3.4.1).

The runtime validates documents. It does not fetch a source, authorize an action, or establish truth, organizational authority, safety, or operational fitness. It bundles 0.1.0-draft, 0.2.0-draft, and Core 0.3.0, and validates a document against its exact declaration. Core 0.3.0 resources are imported from the published Spec tag v0.3.0, commit 27cb29bf13e4a2d58d69fe19c7ebfeb762b014fc. Core 0.3.0 support is base-only. Runtime discovery reports evaluatorCapabilities separately from document supportedSpecVersions, with supportedProfiles: ["base"] scoped to the Core 0.3.0 evaluator entry. This says nothing about Policy or Dialect profile support.

For the version covered by the claim in CONFORMANCE.md, one shared evaluator applies the specification's §§7–8 resolution model per ADR-0007, and ten surfaces reach it: jpack experimental evaluate and evaluate-corpus, the project walk jpack packs test, the graph verbs jpack experimental graph evaluate and graph test, the version comparison jpack experimental compare, and the experimental_evaluate, experimental_test_packs, experimental_test_cases and experimental_test_graphs MCP tools. The experimental namespace is a stability statement: such a surface may change or be removed without compatibility promise. It is not a statement about conformance. That evaluator implements the evaluator conformance class Core 0.2.0-draft adds — the §8.2 input preflight, the §8.3 portable disposition with its RFC 8785 byte agreement, the §8.4 error classes and their fixed precedence, and the §10 limits — per ADR-0010 and ADR-0011.

Pack-aware operations select the evaluator contract from the exact pack's specVersion: 0.2.0-draft or 0.3.0. Internal legacy entry points and standalone authoring tools retain their 0.2.0-draft default; standalone tools accept explicit spec_version: "0.3.0". Selection never infers a version from a routes member. See ADR-0063 for the compatibility decisions.

This runtime's conformance claim is stated, in full and only, in [CONFORMANCE.md](CONFORMANCE.md). JPS §3.4.1 fixes the entire form such a claim may take — the class, one exact specVersion, the corpus version, the results obtained, and in the claim's own words that every row of that corpus version passed — so this README states no part of it and neither does any other surface: a partial restatement would be the partial claim §3.4.1 forbids. Read that file for the claim, its version scope, its evidence, and everything it does not assert, which includes anything at all about a pack, its facts, or the wisdom of acting on a disposition (§3.5). jpack experimental evaluate-corpus runs the bundled evaluation corpus and reports its rows — the evidence §3.4.1 requires of a claim of this class, and explicitly not exhaustive evidence of one; see CONFORMANCE.md.

That command carries one further opt-in, --rfc0008-quantifiers, which is a draft-RFC prototype per ADR-0009: it admits the collection quantifiers exists, every, and uniform proposed by the specification's RFC 0008 (Draft). Those operators belong to no published JPS version. A pack using one is not valid under JPS 0.1.0-draft, spec validate rejects it, the evaluator without the flag refuses it, and every successful evaluation payload produced under the flag says so in band through a draftPrototype member — a refusal is an operational error and carries none. The flag is CLI only; the MCP tool does not expose it.

A second opt-in, --rfc0016-outcome-values, is a draft-RFC prototype on the same terms, per ADR-0039. It admits the value declarations proposed by the specification's RFC 0016 (Draft): an outcome declares named values under org.judgmentpack.outcome-values, each a constant or a copy of one fact, and the disposition of that outcome carries them in a value member. That member is the draft's and no member of §8.3. A declared value that does not resolve withholds the outcome, and the result is unresolved with reason unknown. The name is reserved, so a pack carrying a declaration is not valid under any published JPS version, spec validate rejects it, and the evaluator without the flag refuses it. A value drawn from a fact is a copy of that fact and is not verified. The two flags are mutually exclusive, and this one is CLI only too.

The command binary is jpack. The project, repository, and release archives keep the judgment-pack name; the executable they carry is jpack.

Implemented commands

jpack version

jpack artifact version --base [--candidate ] jpack dialect contract jpack dialect init [--dialect-version 2|3] jpack dialect canonicalize jpack dialect digest jpack dialect validate jpack dialect schema [--dialect-version 2|3] jpack dialect reference jpack dialect check --pack jpack spec validate jpack spec test-conformance [suite] [--strict] jpack spec schema jpack spec examples [name] [--spec-version V] jpack packs list (jpack.json project convention; ADR-0012, not part of the spec) jpack packs validate [--id X] jpack packs test [--id X] [--require-matrix] (EXPERIMENTAL SURFACE; claim: CONFORMANCE.md) jpack packs suggest [--id X] [--base ROW] [--write F|-] [--max N] [--include-hugs] (candidate row INPUTS, never rows; ADR-0024) jpack packs lock (declare the current documents as the project's reviewed set; ADR-0019) jpack packs verify (check the project against that reviewed set) jpack packs lint [--producers M] (every consulted pointer has a producer; ADR-0022) jpack packs schema jpack mcp jpack experimental evaluate (EXPERIMENTAL SURFACE; claim: CONFORMANCE.md) jpack experimental evaluate --pack-id X (EXPERIMENTAL SURFACE; resolves one decision id through jpack.json) jpack experimental evaluate --rfc0008-quantifiers (DRAFT-RFC PROTOTYPE; not an input the class defines) jpack experimental evaluate --rfc0016-outcome-values (DRAFT-RFC PROTOTYPE; a pack that declares values is not an input the class defines) jpack experimental evaluate-corpus (EXPERIMENTAL SURFACE; corpus results, the evidence §3.4.1 requires) jpack experimental compare --inputs (EXPERIMENTAL SURFACE; the inputs two versions decide differently; ADR-0045) jpack experimental graph list (EXPERIMENTAL: the configured graphs, resolved; ADR-0029) jpack experimental graph validate (EXPERIMENTAL composition prototype; spec RFC 0002, Draft; ADR-0015) jpack experimental graph evaluate [--inputs ] [--rehearsal] (EXPERIMENTAL SURFACE; claim: CONFORMANCE.md) jpack experimental graph explain (the evaluation plan; nothing is evaluated) jpack experimental graph test --rows (EXPERIMENTAL SURFACE; claim: CONFORMANCE.md) jpack experimental graph schema jpack experimental policy contract jpack experimental policy init --kind policy --format-version 0.0.2 --id --version jpack experimental policy schema --kind policy --format-version 0.0.2 jpack experimental policy canonicalize jpack experimental policy digest jpack experimental policy validate jpack experimental policy check --materials

The pack argument and --pack-id are mutually exclusive: one pack, one source, and supplying both or neither is an invocation error rather than a precedence rule. --pack-id honors --config and JPACK_CONFIG like every other command that reads a configuration.

The namespace is jpack spec, not jpack jps. JPS remains the name of the specification and the prefix of its provisional diagnostic codes.

The mcp command serves the same offline operations to a Model Context Protocol client over stdio, so an agent can validate documents as a tool call; see docs/mcp-clients.md for per-client setup and docs/agent-testing.md for the agent-driven testing protocol.

Install a tagged release

Download the archive for your operating system and architecture from GitHub Releases. Each archive includes the jpack binary, README, the CONFORMANCE.md claim the source it was built from carries, Apache-2.0 license, attribution notice, and third-party notices.

Asset names follow this pattern:

judgment-pack_<version>_<os>_<arch>.tar.gz

judgment-pack_ _windows_ .zip

For example, release v0.1.0 uses judgment-pack_0.1.0_linux_amd64.tar.gz. Linux and macOS users can extract an archive and install the binary into a user-owned directory already on PATH:

tar -xzf judgment-pack_0.1.0_linux_amd64.tar.gz

install -m 0755 jpack "$HOME/.local/bin/jpack" jpack version

On Windows, expand the .zip, move jpack.exe into a directory on your user PATH, and run:

jpack version

Verify the archive before extracting it. On Linux:

grep ' judgment-pack_0.1.0_linux_amd64.tar.gz$' checksums.txt | sha256sum --check

On macOS:

grep ' judgment-pack_0.1.0_darwin_arm64.tar.gz$' checksums.txt | shasum -a 256 --check

On Windows PowerShell:

(Get-FileHash .\judgment-pack_0.1.0_windows_amd64.zip -Algorithm SHA256).Hash

Select-String -Path .\checksums.txt -Pattern ' judgment-pack_0.1.0_windows_amd64.zip$'

The two Windows hashes must match. Release archives also carry GitHub build-provenance attestations, which a current GitHub CLI can verify:

gh attestation verify judgment-pack_0.1.0_linux_amd64.tar.gz --repo Judgment-Pack/judgment-pack-runtime

Packages for Homebrew, Scoop, apt, and go install are not published yet. In particular, source installation with go install does not receive the release linker metadata, so use a release archive when you need an accurately reported runtime version.

Evaluate one decision

With jpack on your PATH, this is the whole loop: a pack, a facts document, and a disposition. Save a pack that approves an expense unless its amount is over 5000:

cat > pack.json <<'EOF'

{ "specVersion": "0.2.0-draft", "id": "https://example.invalid/judgment-packs/expense-approval", "version": "0.1.0", "title": "Expense approval", "decision": { "intent": "Approve ordinary expenses without review.", "question": "May this expense be approved?" }, "outcomes": [ { "id": "approve", "label": "Approve" }, { "id": "decline", "label": "Decline" } ], "rules": [ { "id": "over-limit",