Architecture vision (non-normative)

For what the specification actually defines, read the core specification.

People often picture Judgment Pack as a multi-layer system: an agent consults a planner, which selects a graph of packs, which are evaluated by a runtime into a composite result. That picture is useful for understanding where the project is headed. It is not what the specification defines today, and most of it is deliberately outside the specification's scope.

This page draws the whole picture and then labels every part by what it actually is — shipped, proposed, runtime, or product — so the vision can be discussed without being mistaken for the standard.

What is shipped today

The specification defines exactly one thing: a Judgment Pack — a portable JSON document that declares a single decision (its evidence requirements, applicability, rules, exceptions, outcomes, uncertainty handling, escalation, and sources) — together with how to check that a document conforms at the carrier, structural, and semantic layers.

As of 0.2.0-draft it also defines what an evaluation of one pack means — the semantics an implementation must follow to claim the evaluator conformance class, and the one portable result it produces. It still ships no evaluator, and it defines no execution, no composition, no discovery, and no runtime. Those exclusions are intentional; see the non-goals.

The layered picture, labeled

Only the green core — the Judgment Pack document and its conformance classes — is the standard. Everything else is proposed, runtime, or product.

The Judgment Pack row is the standard, and the Runtime row is now half of one: the meaning of an evaluation is specified, while the engine that performs it is not. Everything else above and below is a proposal, a runtime behavior, or product territory.

How to read the picture

A format goes to the specification, an engine to the runtime, a service to a product — and no consumer owns the standard.

Three tests decide where each part belongs, and they are worth stating plainly:

• A format that two independent tools must agree on is a candidate for the specification — as an optional profile, only after two implementations prove it. Pack manifest, graph composition, and evidence reference are formats.
• An algorithm or engine — how a pack is validated, or how a graph is evaluated into a composite result — belongs to a runtime. That migration has already happened once, in the direction this test predicts: the meaning of an evaluation is now a normative claim of the document, in Core §§7–8 for the evaluator conformance class, with its result pinned as the §8.3 disposition — while the engine that computes it still belongs to a runtime. That is the split the Runtime row above states.
• A hosted service or business logic — a running registry, a planner that weighs cost, latency, and tenant context — is product. Standardizing it would re-couple a neutral format to one vendor.

Knowledge is an input, not a parent

A knowledge graph, a database, an API, or a document store answers what is known. A pack declares which decision is being made, when it applies, which evidence changes it, and when a human must take over. Evidence sources feed a pack; they do not sit above it.

Evidence sources answer “what is known.” The pack decides which of it matters — so knowledge feeds the pack rather than sitting above it.

The Why Judgment Pack? page develops this distinction, and the comparison page contrasts the format with DMN, policy engines, and rule engines.

Where those inputs come from is a separate, open question

A pack says which evidence matters. It says nothing about whether the bytes an agent presents as that evidence are the bytes a source actually returned — and an agent that can assert a fact can also invent one. That is a real gap, it is deliberately outside this specification, and the project is researching it in the open rather than specifying it early: judgment-pack-evaluator-experiments holds the studies and reference-adjacent prototypes, and judgment-pack-gateway holds the later hosted reference shape. They are distinct artifacts, not one interoperable interface:

• The inline acquisition proxy wraps a downstream MCP server and issues version-1 HMAC receipts with retained, content-addressed results. Verification needs the same secret that can mint a receipt, and replay and tail rollback remain outside what the store can prove about itself.
• The gateway's incompatible version-2 format signs receipts and session seals with Ed25519. A verifier with a separately pinned public key can check a store against the registry obtained from the key holder without gaining the power to forge. Version 2 deliberately rejects version 1.
• A portable derivation rule maps attested bytes into facts and evidence availability, and the experimental admission gate passes only that deterministic result to evaluation. The gateway alone does not remove caller-supplied facts, and the JPS reference runtime consumes none of these formats today.

Its ceiling is stated up front and is worth repeating here, because it is the kind of claim that inflates in retelling: the mechanism proves byte-lineage, not truth. It establishes what a judgment was computed over. It establishes nothing about whether those bytes are accurate, whether the named source produced them, or whether acting on the result is authorized — the same three things conformance never establishes. Nothing in this research line is part of JPS, and no RFC proposes the acquisition, receipt, seal, or admission formats as JPS today. The derivation-rule evidence is also bounded: a later probe showed that the set of fields a short-circuiting rule happened to read is not necessarily a sufficient policy basis. No portable repair has been selected.

The point of labeling

A standard earns trust by shipping a small, testable core and being honest about what is still a proposal. Presenting the full layered stack as "the architecture" would over-claim and would blur the line between the neutral specification and the products that implement it. The proposals that make the vision concrete are tracked openly as RFCs; the FAQ answers the questions this picture usually raises.