RFC 0004: Planner interface

• Status: Rejected
• Type: Exploratory (likely product-only)
• Created: 2026-07-24
• Rejected: 2026-09-21

Disposition record. This RFC is rejected by the single maintainer under the interim review regime (RFC 0009). The review of this disposition, with a written disposition for every finding, is recorded on the pull request that makes it and under rfcs/reviews/. Rejected is the outcome this RFC named as most likely on the day it was opened, and it answers the RFC's own third unresolved question: a planner is product, and the specification standardizes no part of one — the narrow selection query included.

What the rejection rests on, with its limits:

• To the maintainer's knowledge, nobody has asked for the one candidate surface. The sketch offered a selection query "if two products want to interoperate on discovery". The maintainer knows of no such pair; this repository cannot show that none exists anywhere. The discovery index the query would read (RFC 0005) and the manifest that index would reference (RFC 0001) are both drafts, and no producer of either format was found in this project's repositories, so there is no implementation or interoperability evidence for the proposed query. (The reference runtime does list a project's configured packs, through packs list and the list_packs tool, as an explicitly non-normative inventory; that is neither format, and it takes no decision context.) This is absence of demand in a project whose governance text says a public review period today "means a change sits in public and no one comments"; it is weak evidence, and it is the evidence there is.
• The reference runtime deliberately leaves selection with the application. Its ADR-0012 keeps selection with the application — its configuration "does not choose a pack for a request, and this runtime never will" — and gives this RFC's reason: applicability is not authorization. Its ADR-0007 scopes planner selection out of the evaluator. That is one runtime, by this project's maintainer: a recorded position, not independent evidence.
• Declining avoids adding a surface the RFC itself worried about. Its second unresolved question asked whether standardizing selection would encourage reading applicability as authorization. Declining adds no standardized selection surface; it does not remove the confusion, since Core still defines applicability and a product may still build a selector, and whether standardizing would have made the confusion worse stays untested. The statement under Security and privacy — authorization for which pack may run stays with the product — does not depend on this RFC's status: RFC 0005 says the same of selection metadata, and the non-goals already exclude orchestration.

What the rejection does not decide. The first unresolved question — whether a selection query could be portable at all — stays unanswered, because nothing was built to test it. RFC 0005's question about how discovery relates to a selection interface now refers to an interface this project declines to standardize; restating it is RFC 0005's to do when it is next amended. RFC 0006's adoption record said the selection probe would "stay with" this RFC; that record is amended in the same pull request to say that no active proposal now carries it, and its note stands as advice to a product that builds a selector. Two products that do want to interoperate on selection would bring a new RFC with that evidence; this record would be its prior art, not its obstacle.

This record replaces the banner that marked the RFC an open proposal, which said it existed "to test whether any of a planner is standardizable; its most likely outcome is 'product-only.'" Nothing here was ever part of the specification; see RFC 0000 for the process. Every section below is the proposal as it stood, retained unedited as the record.

Summary

Examine whether the interface by which an agent selects and invokes Judgment Packs — a "planner" — has any portable, standardizable surface, or whether it is entirely product behavior.

Problem

Integrators keep asking "how does an agent know which pack to run?" That question hides a recursion: selecting a pack is itself a judgment. A component that decides which judgment to apply is either governed by its own pack or is bespoke product logic. Either way, most of a planner is orchestration — which the non-goals place outside the specification.

Evidence

Across experiments, "pick the right pack" is consistently entangled with product context (user, tenant, workflow, cost, latency), none of which is portable. What is sometimes shared is a thin selection query: "which packs govern this decision context?"

Specification (sketch)

The only candidate portable surface is a selection query interface: given a decision context, return candidate pack references (from RFC 0005) ranked by declared applicability — with ranking, tie-breaking, and side effects left to the product. Everything beyond returning candidates is product behavior.

Alternatives

• No change / product-only — the most likely correct outcome. The planner is a product; the specification stays out of orchestration.
• Standardize a selection interface only — the narrow surface above, if two products want to interoperate on discovery.
• Standardize the full planner — rejected; it is orchestration and business logic.

Compatibility

No effect on the core document. Any accepted surface would be an optional profile layered on discovery.

Security and privacy

A selector influences which judgment is applied — a high-value target. Authorization for which pack may run must remain with the product, never inferred from applicability.

Conformance

If a selection interface is standardized: positive — a context returns the packs whose applicability matches; negative — a context returns a pack whose applicability excludes it.

Implementation

Two discovery services should return the same candidate set for a shared context and pack corpus.

Unresolved questions

• Is even the selection query portable, or is "decision context" irreducibly product-specific?
• Does standardizing selection encourage treating applicability as authorization? How is that prevented?
• Should this RFC be closed as Rejected with a rationale rather than accepted — i.e. is the honest answer "this is product"?