Draft · 0.2.0-draft

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

Informative

Implementations

Independent tools that implement one or more JPS conformance classes or test the specification's semantics. A listing here is not certification, endorsement, or authority over the specification.

The specification is the authority. No implementation — including the reference runtime — is normative. A claim belongs to its claimant, one conformance class, and one exact specVersion. Corpus results are required but non-exhaustive evidence; they are not certification. Any implementation that satisfies the complete requirements of the same class for the same exact version is equally valid. No conformance class establishes factual grounding, authorization, safety, or operational fitness.

Available implementations

Open source · Apache-2.0 · maintained with the specification

judgment-pack

The project's vendor-neutral reference runtime; the command it installs is jpack. It validates the carrier, structural schema, and semantic references of a JPS document against an immutable specification release. Its evaluator produces a disposition from supplied inputs, and the runtime states an evaluator-conformance claim in full in its own repository. Evaluating surfaces stay labelled experimental, which reports their stability, never their conformance. A disposition never establishes truth, authorization, safety, or fitness, does not authorize an action, and the runtime fetches no source.

  • CLI and stdio MCP surfaces for validation, schemas, fixtures, project inventory, evaluation, and six static method prompts.
  • Project-owned pack matrices with informative, non-gating coverage, plus an experimental graph-composition workflow with its own matrices.
  • Opt-in JSONL evaluation records and a deterministic reviewed-set lock that detects drift. Both are runtime conventions, not JPS audit or approval formats.
  • Since v0.26.0, evaluation records are chained over their exact bytes by default wherever a project keeps them, can be signed in a sidecar with key rotation, can have their checkpoints stamped by an RFC 3161 time-stamping authority, and can be checked with jpack audit verify against the checkpoints a holder keeps; v0.27.0 refuses a signing key kept where another user could remove or replace it. The guide's Checking a trail, and handing over a checkpoint says what each establishes and what it does not; these are runtime conventions too, not JPS audit or approval formats.

Reference runtime · one implementation among peers · source

Open source · Apache-2.0 · experimental, claims no conformance

clean-room Python evaluator

A second evaluator, written from the specification text alone inside an information barrier and published with its interpretation log, clean-room protocol, and agreement harness. It exists to test whether the prose pins the semantics: where two independent readings diverge, the divergence locates an ambiguity in the specification rather than a defect in either reader. It claims no JPS conformance of any kind.

Agreement evidence · not a conformance claim

Two implementations, one author. Both listings above trace to the same maintainer's direction, so their agreement corroborates that the specification is precise — it is not independent evidence of interoperability, and the project does not present it as such. See governance for the interim review regime this sits under.

Companion projects

These projects exercise the implementation around JPS. They are not additional JPS implementations, and none of their interfaces or artifacts becomes part of the specification by being listed here.

Cloneable sandbox · Slack-app source · non-normative

judgment-pack demo

A browser workspace and enterprise-shaped synthetic project with the runtime pre-wired over MCP, plus a self-serve Slack implementation. It demonstrates pack authoring and matrices, evaluation and honest refusal, experimental graphs, attested inputs, project-owned evaluation records, and reviewed-set drift detection. The runtime computes every disposition; the model may gather inputs, draft, and narrate, but cannot change the runtime result. Use synthetic, non-sensitive material only.

Demo material · never authorization or production guidance

Open source · runs its sources and receipts them apart from the runtime; since v0.9.0 a decision policy can hold a write to a record signed by a runtime key it trusts (ADR-0012)

open reference gateway

The gateway acquires JSON results from operator-configured sources, content-addresses them, signs version-2 receipts with Ed25519, chains them per session, and seals the final count. A verifier with a separately pinned public key can check a store against the gateway-held registry. Since v0.9.0, a decision policy can require the record it relies on to be signed by a runtime key it trusts (ADR-0012). What it establishes: a writer who cannot use a trusted key cannot satisfy the policy with a record written by hand. What it does not: anything against the operator, who holds the key. This is a localhost-only, single-operator reference with no authentication, high availability, or key rotation. It proves byte-lineage, never truth, source identity, authorization, or production readiness.

Receipt and seal specification · frozen corpus

Open source · Apache-2.0

judgment-pack desk

A local web desk for a Judgment Pack project: one Go binary that serves a browser application and relays MCP messages between the page and a jpack mcp subprocess in the project directory. The runtime computes every validation and disposition; the desk shows them and computes none. An optional assistant can draft a pack through a model endpoint the operator configures. It is a local, single-user tool, not a hosted service.

Local desk · separately governed · non-normative

Open source · Apache-2.0 · single-owner local Jobs runner

judgment-pack runner

A local jobs runner. It turns a pack snapshot into a durable job: it checks a release, takes facts and evidence availability, runs the pinned runtime through its public CLI, and keeps the result and audit history on the local filesystem. It embeds no evaluator of its own. External actions, graph execution, shared-user permissions, and agent loops are not implemented. Since v0.5.0 it keeps a chain of the runs it completes, by the runtime's rules, and can have each run's record signed with the installation's key; verify-run checks both. A chain or a signature establishes nothing against the operator on its own: the chain needs a checkpoint held by someone else, and the operator holds the signing key.

Local jobs · separately governed · non-normative

Adding an implementation

This list is open to independent tools tested against the public conformance artifacts. Presence here does not confer certification, official-validator status, endorsement, or authority over the specification. A submission should say which class and exact version it claims, if any, and link to the complete claim rather than asking this project to restate it.