Frequently asked questions

A portable, vendor-neutral JSON document that declares a single decision — the evidence it requires, when it applies, its rules, exceptions, possible outcomes, how uncertainty and escalation are handled, and where its claims came from — so the reasoning can be inspected, tested, versioned, and moved between tools.

Coding agents work because their environment can already judge their output — compilers, tests, CI. Most business agents have no such harness. A pack makes the judgment behind a business decision explicit enough to test, the way a test suite makes "correct code" explicit. See Why Judgment Pack?.

No. It is a research preview at 0.2.0-draft with no compatibility guarantee; any 0.x release may change incompatibly.

Tool and runtime implementers; standards and architecture reviewers; enterprise architects evaluating governable AI decisioning; AI researchers studying testable judgment; and domain experts who author packs.

It specifies a document, and — new in 0.2.0-draft — what evaluating that document means, not an engine. Document conformance means a document agrees with a contract; evaluator conformance (§3.4) means an implementation complies with the §§7–10 evaluation contract for every input it admits, evidenced by the corpus published for the exact version claimed. Neither is ever a claim that the pack is true, authorized, safe, or fit for use.

Four conformance classes for a single decision. Three are about the document: carrier (valid JSON and encoding), structural (the schema), and semantic (local references and cross-field rules). The fourth, new in 0.2.0-draft, is evaluator conformance (§3.4): what an evaluation of a pack means and the one portable result it produces (§8.3). §§7–8 are normative for that class and informative for everyone else, and the evaluation corpus is normative for it and for nothing else. Normative status stops there: outside the prose, the schema, and that corpus, nothing in the repository is normative (§1.1). See the core specification.

Nowhere in the specification — they appear nowhere in it. The graph and composite result are proposals; the planner is product; the runtime is a separate implementation. The architecture vision shows how they would relate, clearly labeled and non-normative.

Because a standard earns trust by standardizing only what independent tools must agree on, and only after two implementations prove it. A layer with no format and no second implementation is a roadmap item, not a specification.

Authority hygiene. If a specification and its runtime share a home, the runtime's behavior silently becomes the standard. Separation lets the prose keep authority when an implementation disagrees, and lets each release on its own cadence.

Atomicity is what makes a pack testable, versionable, and reusable. A giant pack is unauditable and forces unrelated decisions to churn together. Composing small packs is valuable — but composition is its own unsolved problem (RFC 0002), not an argument for one big document.

It is declarative — a pack contains no code and Core executes nothing. What 0.2.0-draft does define is what a runtime's evaluation must mean: §§7–8 are normative for the evaluator conformance class of §3.4, and §8.3 pins one portable result, the disposition. Applying an outcome is still outside Core, and a disposition authorizes nothing.

One per atomic decision an organization wants applied consistently. If two decisions have different evidence, outcomes, or escalation, they are two packs.

By an id (a URI) plus a version; a published (id, version) pair should be immutable. The pack's version is independent of specVersion. See versioning.

A decision (intent and question), evidence requirements, sources, outcomes, rules, exceptions, escalation configuration, metadata, and namespaced extensions.

Against the document-conformance corpus — carrier, structural, and semantic cases. Evaluation behavior has its own corpus, conformance/evaluation/, which is what an evaluator-conformance claim is made against (§3.4.1). It is a seed corpus with stated gaps, and passing it says nothing about inputs it does not contain.

A proposed way to compose multiple packs into a larger decision structure. The interchange format would be RFC 0002. It does not exist in the specification today.

It raises every question a single pack avoids: ordering, conflict when two packs disagree, a shared fact and evidence namespace, cyclic dependencies, and partial failure. Presenting it as a finished layer invites a question with no answer yet.

When a composition format is drafted, prototyped, and shown to interoperate across two independent implementations — the same evidence gate every feature faces. No date.

A knowledge graph answers "what is known?" A pack declares "which decision is this, when does it apply, which evidence changes it, and when must a human take over?" The knowledge graph is one evidence source feeding a pack — not the parent of the judgment layer.

No. Evidence may come from SQL, APIs, documents, an ERP or CRM, a data lake, a knowledge graph, or nothing structured at all.

Declared requirements and references — the pack names what evidence it needs and points at sources. It is not fetched data and not a query. The pack says what it needs, never how to get it.

Not in the specification. An integration layer that connects to real systems is a runtime or product concern. Only the reference/adapter contract — how a pack names the evidence it expects — is a candidate for standardization (RFC 0003).

Today it does not on its own — the integrator selects the pack. A standard answer needs a discovery and selection contract (RFC 0001, RFC 0005). Note the recursion: selecting a pack is itself a judgment, which is exactly why an autonomous selector is either governed by its own pack or is product logic (RFC 0004).

Yes — authoring a pack is a fine use of a model. But a generated pack is only a candidate document. Structural conformance says it is well-formed; it says nothing about whether the judgment is correct or whether anyone with authority approved it.

Not portably yet. Single-pack evaluation semantics are normative for the evaluator class as of 0.2.0-draft, but the graph format is still a proposal, and a composite result has no defined shape. An implementation can compose privately; it cannot claim JPS conformance for the composite.

A prompt couples intent to one model and phrasing; it is not a structured document a second tool can validate, diff, or version. MCP is a runtime transport for tools and context between a model and its host. JPS is a static, versioned, testable artifact describing judgment. They are complementary and sit at different layers — you might ship a pack over MCP.

No — the three sit at different layers and are complementary. A tool exposes a capability an agent can use (fetch a record, run a search, create a vendor). A skill guides or implements how a task is performed. A Judgment Pack makes a consequential judgment explicit, testable, portable, versioned, and independently governable. Skills may call or embed Judgment Packs; the intended relationship is complementary, not competitive.

Tools:          What can the agent do?
Skills:         How should the agent perform the task?
Judgment Packs: What conclusion is justified, based on which evidence and rules?

See what a Judgment Pack is and the architecture vision.

They often are. A skill can absolutely contain judgment instructions — the limitation is not the absence of judgment, but whether the judgment is exposed as a strong enough contract. For a low-risk, local, single-agent task, a well-designed skill may be completely sufficient. The differences appear when the judgment must be relied on beyond the skill that carries it:

• prose interpreted by a model, versus runtime-enforced semantics;
• implicit, versus typed, evidence requirements (RFC 0003);
• implicit, versus explicit, applicability conditions;
• ad-hoc handling of exceptions and overrides;
• abstention and escalation as first-class states, not asides;
• a standardized judgment output that other tools can read;
• evidence provenance that travels with the conclusion;
• versioning independent of the agent's implementation (versioning);
• reusable conformance cases that ship with the artifact;
• portability across agents and runtimes;
• governance by an independent business or policy owner (governance).

None of this says skills are weak. It says a pack turns judgment into a contract precisely when that contract has to hold outside a single skill.

This is the sharpest form of the question, and the honest answer depends on how the judgment is expressed.

Judgment written in SKILL.md. The skill genuinely contains judgment — but a model may still interpret its natural-language conditions differently from run to run, and enforcement, provenance, expected outputs, and conformance tend to remain framework-specific or implicit. The judgment exists; the contract around it may not.

Judgment implemented in code. Coded judgment can already be deterministic, testable, versioned, enforceable, and production-ready. JPS is not automatically better than working code. A pack adds value only when the judgment needs to become a first-class artifact with: a portable input and output contract; explicit evidence and provenance semantics; policy versioning independent of code releases; conformance cases that travel with the artifact; cross-runtime interoperability; composability with judgments owned by other teams; and independent inspection and approval.

Application code may implement an API.
OpenAPI exposes a portable API contract.

Skill code may implement a judgment.
Judgment Pack exposes a portable judgment contract.

The analogy has a limit worth stating: organizational judgments are often less stable and less uniform than API boundaries, so JPS has to prove useful interoperability rather than lean on the conceptual resemblance. See How Judgment Pack compares.

Often. A skill alone is a reasonable choice when:

• only one agent or application uses the logic;
• the same engineering team owns the skill and the runtime;
• portability across runtimes is not required;
• the decision is low-risk;
• ordinary unit tests are adequate;
• no separate policy-owner approval is needed;
• no regulator, customer, or auditor needs an inspectable decision contract;
• the judgment does not need to compose with independently owned judgments.

Do not add a pack merely for architectural purity. A pack earns its place when: multiple agents must reach consistent decisions; multiple runtimes must execute the same policy; evidence and provenance must be standardized; policy versions must be traced independently from code releases; different teams own separate parts of the final judgment; abstention and escalation must be enforced; or external review or audit is required.

The skill owns task execution and tool use; the Judgment Pack owns the decision contract; the agent or workflow runtime owns the authorized actions taken after the judgment. A skill references a pack — remotely by (id, version) or by embedding it in the skill package — and maps each result to an action:

skill:
  id: supplier-onboarding

  tools:
    - fetch_supplier_record
    - run_sanctions_search
    - create_vendor

  judgments:
    - pack: supplier-approval@2.1.0

  actions:
    approved:
      - create_vendor
    rejected:
      - close_request
    escalated:
      - open_legal_review

Tools retrieve data and perform actions; the skill coordinates the task; the Judgment Pack evaluates whether a conclusion is justified; the runtime performs the authorized action afterward.

In that flow: tools retrieve data or perform actions; skills coordinate the task; Judgment Packs evaluate whether a conclusion is justified; and the runtime or agent performs the authorized action after the judgment. The pack deliberately stops at the judgment — it should not become a general-purpose workflow engine. A pack can live beside the skill it serves, referenced remotely or embedded in the package:

supplier-onboarding/
├── SKILL.md
├── tools/
└── judgments/
    └── supplier-approval.jpack.json

JPS is meant to slot into existing skill ecosystems, not replace them.

This is the fair adversarial question. If a skills framework already provides formal applicability rules, typed evidence contracts, explicit exceptions, deterministic or constrained evaluation, abstention and escalation, provenance, independent versioning, conformance tests, judgment composition, and governance, then it already implements much of what JPS proposes. At that point JPS is only useful if it provides one of two things: (1) an open, shared interoperability standard across skill frameworks, so a judgment authored against one framework stays inspectable and executable in another; or (2) materially better tooling and semantics for authoring, testing, composing, governing, and auditing judgments.

Judgment Pack must earn its place through interoperability and tooling. If it becomes only another Markdown instruction format, the criticism that it is "skills with a new name" would be valid.

That bar is deliberate, and it is why the interoperability formats are tracked openly as RFCs rather than asserted.

No — "official" is the wrong word, deliberately. There is a vendor-neutral reference runtime, and it is one implementation among peers rather than the authority. It validates documents at the carrier, structural, and semantic layers, and it states an evaluator-conformance claim in its own repository, in one file it chose — §3.4.1 fixes the form a claim must take, not the file it lives in. Two cautions about how to read that. First, its evaluating surfaces stay labelled experimental, which is a statement about stability — such a surface may change or be removed — and never a statement about conformance. Second, the claim is that implementation's, not this project's: a claim attaches to an implementation and one exact specVersion, and this project neither issues, verifies, nor certifies one. This site therefore points at that file rather than reproducing the corpus version, the results, and the every-row statement that together make a claim complete. Read it there, in full, or not at all.

No. Passing validation establishes only the document-conformance layers reported. It never establishes truth, authority, safety, or fitness.

The specification defines what an evaluation means, not how to perform one, so there are no execution benchmarks to quote. A pack is a small, static, cacheable JSON document that can be validated offline and distributed like any other static artifact; its actual performance is an implementation claim that needs its own measurements. The cost of evaluating a graph of packs is an open question for a runtime and for RFC 0002.

Proposed: a per-pack manifest plus a registry index format — the OCI / npm / Terraform-registry pattern. The interchange format is standardizable (RFC 0001, RFC 0005); the running registry is not.

Possibly two things that must not be conflated: a registry format (neutral, specification-side) and a hosted registry service (product, with its own auth, billing, and threat model).

SemVer-tagged, immutable releases. Only a maintainer tag and GitHub release is a real release; files on main are work in progress. Reader, writer, semantic, and migration compatibility are stated separately per release. See versioning.

No. There is no compatibility or security SLA for 0.x drafts; behavior may be removed or changed with migration notes.

Its maintainer, in public; there are no independent contributors yet (see governance). No required commercial runtime controls it; conformance is defined by the prose, schema, and corpus, not by any vendor's product. See governance.

Through the RFC process. Editorial fixes are ordinary pull requests; material or normative changes need an RFC with compatibility and security analysis plus positive and negative cases, and a stable feature needs two independent implementations.

Implementations are named and maintained separately from the specification, and naming one never makes it normative. Conformance is defined by the public prose, schema, and corpus. The reference runtime is one implementation among peers; product architecture stays on product properties, not on the specification.

Apache-2.0. Start with the testing exercise, open issues for ambiguities, and file RFCs for material changes.

The proposed aggregated result of evaluating a graph of packs. Core now defines the single-pack result (§8.3's disposition) but nothing about composing several, so it remains a proposal with two halves: the portable composite format (a specification question, if tools must exchange it) and the computed output (a runtime concern). Whether a downstream pack sees an unresolved upstream as absent or unknown evidence is one of the edge semantics still owed. See RFC 0002.

No — and this is the load-bearing distinction. Conformance means the document agrees with the contract. Factual grounding, organizational authorization, and operational fitness are three separate claims a validator must never imply.

No. It is a research preview. Safe uses today are experimentation, authoring, review, and conformance testing. Do not automate a real outcome from a pack.

Treat conformance as document hygiene, not a decision warrant; keep a human accountable for every consequential outcome; pin immutable specification releases and recorded checksums; and keep authorization in your own systems, since the specification explicitly refuses to model it. The non-goals and architecture vision spell out these boundaries.