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 0017 is accepted and its text landed in the same merge, beside Core rather than in it: the normative statement of the checkpoint witness statement is the companion document spec/checkpoint-witness.md, not this directory. Its vectors are staged, as RFC 0013's rows are, until a later specVersion opens. RFC 0018 is accepted in the same form: the normative statement of the dialect and its preparation verifier is the companion document spec/dialect.md, not this directory, and its forty-seven vectors are staged until a later specVersion opens; it was amended in place on 2026-10-15 and 2026-10-16, its status unchanged. 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 0018 states how a pack's facts and evidence are obtained and derived, and what a preparation establishes per part. Its companion, spec/dialect.md, defines the preparation-verifier class; the reference Runner's 47 preparation vectors are staged for the next specVersion, in no corpus. It was amended on 2026-10-15 for every gateway source shape in version 2, the unbound source form in version 3 and version 3 as the reference Runner reads it; on 2026-10-16 for the name an unbound operation's record carries, the research vectors staged and the skipped source's form.

RFC 0019 is a cross-project record outside the specification: a catalog's entry format, manifest, tests and contribution rules, and a desk's browse. Amended 2026-10-15 for issue #166 and issue #172: entry version 2 distinguishes kind dialect from pack-free kind preset; the seven enforcement sentences are settled. Amended 2026-10-16 for issue #192, option A: entry version 3 checks named-format references and artifact identities under RFC 0021, with immutable pairs across catalog history and unchanged manifest rows. Catalog CI fetches tags and reads every previous release's manifest and pinned entries as blobs, refusing unreadable history as artifact-history-invalid, with no form-only fallback. Only a consumer checks form alone when it does not hold the previous manifest, reporting artifact-history-unchecked. Identical content under a pair is admitted in another entry under its kind's rules; presets stay integer-only. The catalog's checker and fixtures follow in their own pull request on judgment-pack-exchange. RFC 0019 stays a Draft; a hosted registry remains out of scope (Unresolved question 4).

RFC 0020 proposes spec/workflow.md beside Core, with a reader class and fixtures from a two-stage run, none recorded yet.

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.

RFC 0021 adds named Dialect artifact identities through exact formatVersion selectors, with unchanged historical formats and separate binding digests.

RFC 0023 has conditional maintainer approval for the bounded Policy draft, effective upon required green CI and PR 218 merge. The default branch remains Review until then; no immutable Policy release or consumer adoption is claimed.