Proposals (RFCs)
This directory holds Requests for Comments (RFCs) — design records for material changes to the Judgment Pack Specification. An RFC is a proposal opened for public comment, in the sense used by projects such as Rust and React. An RFC is not part of the specification. Nothing here is normative, and no conformance class depends on any of it.
An accepted RFC is the exception, and only in one direction: the design record stays here and stays
non-normative, while the governing text — text the proposal produced, or, for a retrospective
record, text that preceded it — lives where the record says it lands: for a
standards-track RFC, the specification; for a cross-project exploratory record, the repository that
owns the artifact (see the closing note below). RFC 0006
is accepted and landed in Core 0.2.0-draft; the normative statement of the evaluator conformance
class is §3.4 of the Core specification, not this directory.
RFC 0014 is the first accepted cross-project record,
and a retrospective one: the gateway's SPEC.md and the runtime's decision records govern what it
describes, and they did so before it was written.
Acceptance and incorporation are different events. RFC 0000 makes acceptance
the approval of a design at the maturity the RFC names; RFC 0006's text landed in the same merge,
which is a precedent and not a rule. RFC 0013 is
accepted and awaits incorporation: its rows are staged for the suiteVersion after 0.2.0-draft,
are in no released corpus, and land when a later specVersion opens.
The purpose of this directory is to make the project's open design questions visible rather than to imply they are settled. Concepts that are frequently assumed to be part of Judgment Pack — a graph that composes packs, a planner that selects them, an evidence-integration layer, a discovery registry — are design questions, not shipped features. They live here as drafts until they are prototyped and shown to interoperate across independent implementations, or until one is dispositioned: the planner's record, RFC 0004, is rejected as product behavior and stays here as the record of why.
Process
See RFC 0000 — Request for Comments process for required sections, statuses, and the evidence bar. Material or normative changes require an RFC and a public review period; a stable feature requires two independent implementations and conformance cases.
Index
| RFC | Title | Status | Belongs to |
|---|---|---|---|
| 0000 | Request for Comments process | Active | Process |
| 0001 | Pack manifest | Draft | Specification (format) |
| 0002 | Judgment Graph composition | Draft | Specification (format) — scoped to the dataflow seam: one decision's outcome as another's input |
| 0003 | Evidence reference | Draft | Specification (format) |
| 0004 | Planner interface | Rejected | Product — the specification standardizes no part of a planner |
| 0005 | Pack discovery | Draft | Specification (format) + product (service) |
| 0006 | Evaluator conformance | Accepted | Specification (Core 0.2.0-draft: semantics + conformance class) |
| 0007 | The determination boundary — what a pack cannot hold | Draft | Specification (Core or profile) — undecided |
| 0008 | Bounded collection quantifiers for conditions | Draft | Specification (condition schema + semantics) — Core or profile undecided |
| 0009 | The interim review regime | Accepted | Process (governance) |
| 0010 | The gateway signing identity — custody, rotation, and anchoring | Draft | Research line (gateway repository: code, SPEC.md, guidance, corpus) — outside the specification |
| 0011 | A currency anchor for pack versions — detecting stale and retired policy | Draft | Research line (cross-project artifact: a runtime currency registry + verifier, consumer protocols) — outside the specification |
| 0012 | What a witness contract would have to specify — candidate clauses for a signed-history comparison | Draft | Research line (cross-project artifact: a witness format + verifier, consumer protocols) — outside the specification |
| 0013 | The first evaluation-suite rows that use expectedErrorClass, including two where several §8.4 classes apply and the order decides |
Accepted | Specification-track (evaluation conformance suite) — rows staged for the suiteVersion after 0.2.0-draft, in no released corpus |
| 0014 | The lineage record and the action binding — how a decision cites what it read, and an action cites what it decided | Accepted | Research line (cross-project artifact: gateway receipt version 3 + verifier join, runtime record and row citations; outside the specification) — a retrospective record; acceptance endorses the record only |
| 0015 | What a reported receipt would have to specify — the engine signing a call it did not make | Draft | Research line (cross-project artifact: gateway receipt format, verifier and surface; a reporting plugin in an MCP gateway; outside the specification) |
| 0016 | Outcome values — a decision that states a quantity | Draft | Specification (a specification-defined extension, or Core — undecided) |
The "Belongs to" column records where each proposal would land if accepted. A format that independent tools must agree on is a candidate for the specification. An algorithm or engine belongs to a runtime. A hosted service belongs to a product. Several of these proposals split across that boundary, and saying so early is part of the design. A record whose every part lands in another repository of the project is a cross-project exploratory record (see RFC 0000): acceptance endorses the record, and adoption stays with that repository.