Architecture vision (non-normative)
On this page
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.
That is the entire standard. It defines no evaluator, 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.
| Layer in the common picture | What it really is | Status | Where it lives |
|---|---|---|---|
| Agent | The caller. Any AI system that uses a pack. | Out of scope | Product |
| Judgment Planner | Selects which pack(s) apply to a context. | Proposed / likely product | RFC 0004 |
| Judgment Graph | A format for composing several packs. | Proposed | RFC 0002 |
| Judgment Pack | A single-decision document. | Shipped | The specification |
| Evidence (sources) | What a pack references; supplied by any system. | Reference shipped; integration out of scope | RFC 0003 |
| Runtime | Validates today; may evaluate later. | Validator shipped; evaluator experimental | Reference runtime |
| Composite Judgment | The aggregated result of evaluating a graph. | Proposed | RFC 0002 |
| Discovery / registry | Finding and selecting packs across catalogs. | Proposed (format) / product (service) | RFC 0001, RFC 0005 |
Only the Judgment Pack row is the standard. Everything above and below it 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. The specification's experimental resolution model is where evaluation semantics would migrate as a runtime implements them, never a normative claim of the document.
- 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.
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.