Repository navigation
Define a portable Policy companion and governing adoption boundary #211
Description
Problem
Desk needs a domain-neutral policy workspace: import or author source documents, review and publish policy versions, and develop their executable interpretations as packs/graphs. A policy may be Desk-managed or externally managed. Consumers need to exchange exact source/provenance, policy and interpretation identities without treating a citation, passing test or historical receipt as current authority.
Today Core source/review metadata, pinned execution releases and Dialect preparation do not express governing policy adoption. Product-private metadata alone would make those relationships nonportable. This proposal must keep the pack/graph as executable authority and avoid creating another condition language or requiring a Framework artifact.
Examples
- Data access: a data platform team imports a sharing policy, reviews a draft, publishes an approved version and implements eligibility in a pack. A later withdrawal must hold new governed runs/actions; an old digest-matching receipt cannot grant permission again.
- Procurement: an externally published procurement policy is retained at an exact revision. A changed file is observed without inferring external approval. A consuming workspace explicitly adopts a reviewed interpretation; existing jobs stay pinned until an upgrade is reviewed.
- Refunds: customer support authors policy clauses and optionally readable structured requirements. Pack rules remain authoritative for executable decisions. Some clauses can remain manual with an accountable handoff; passing tests do not certify complete policy coverage.
These motivate the contract; no production governance or independent implementation evidence is claimed.
Proposed scope
Create a standards-track Draft RFC for a minimal Policy companion and exact governing-adoption references. Define identity/version/content/source/section bindings and the boundary of portable review assertions. Keep live IAM, workflow execution, publication transactions, automatic sync, current eligibility and UI in their owning products. No changes to released Core or Dialect documents are proposed in this first PR.
Record four integration boundaries: source observations (Gateway→Desk), governing adoption (Desk→Runtime/Runner), run/action admission (Desk authority→execution host) and review/publication transactions (shared Desk UI/chat service). Separate non-normative host integration guidance from proposed portable semantics.
RFC 0011 already explores pack-version currency and offline snapshots. Reconcile the relationship explicitly: offline membership at a pinned snapshot is not current execution authorization; this work must not silently adopt that Draft or move a policy authority into Gateway. RFC 0012/0017 witnessing also does not establish policy approval or latest state.
Why a companion rather than only an extension or product behavior
- Core sources remain informational; adding a live approval/lifecycle service to Core would change evaluator scope.
- A product can own team permissions, review routing and source bindings, but independent products still need exact portable policy/consumer references and coverage meanings.
- A separate companion allows capability-negotiated readers without rewriting existing packs/Dialects or forcing a policy artifact on ungoverned jobs.
- OSCAL and other domain-specific formats can be optional import/export adapters; neither a universal control language nor a mandatory framework is required.
Compatibility and migration
Keep existing Core/Dialect versions, canonical identities and job pins unchanged. Proposed documents get an exact format selector separate from x.y.z artifact versions. Unknown required formats refuse. Existing citations must never be silently promoted to governing dependencies. Import is not approval; governed adoption and job upgrades require explicit review under the destination's authority.
Security and privacy
Distinguish raw source bytes from extraction, immutable releases from mutable state, and content identity from trust/access. Prevent omitted-dependency bypass, cross-tenant reference disclosure, stale sign-off carry, replay of recovered admission receipts and old-backup resurrection of revoked state. Required unavailable/freshness-expired authority holds new governed work. Model output and Auto mode do not confer a reviewer's identity. External deletion/read failure is not inferred withdrawal.
Agreement and acceptance criteria
- Draft RFC has the ten RFC 0000 sections, clear repository ownership and explicit relationship to RFC 0011/0012/0017/0018/0020/0021.
- Minimal closed prototype forms and examples cover the three domains without GTM assumptions or executable policy logic.
- Positive/negative cases cover exact identity, byte substitution, unsupported formats, section/consumer references and governing/informational distinctions.
- Two independently authored readers can agree on supplied-document validity and identities; same-team implementations alone are not independent authorship evidence.
- Host integration acceptance cases cover sync ordering, review/publication races, withdrawal-before-start, action rechecks, crash/retry/recovery and current-access enforcement.
- Formal adoption remains subject to Spec's recorded cross-vendor adversarial review and public disposition. Draft prototypes do not advertise conformance.
Implementation ownership: Spec portable contract; Runtime offline tooling; Desk authority/collaboration/Library; Gateway retained provider observations and action enforcement; Runner release closure and admission; Exchange reusable templates after an entry contract is adopted. No new repository is required initially.
Activity
Propose versioned Policy companion contract with portable vectors (#216)
Correct candidate URI checks across Policy and consuming Pack (#217)
kikashy commentedon Oct 18, 2026
Ordered delivery update: the portable candidate work is merged in #216 (
30b0b30a) and its cross-reader URI correction in #217 (a74a440c). The corrected candidate uses exactformatVersion: "1.0.0", separate artifact x.y.z versions, closed Policy/adoption forms, bounded offline checks and explicit migration guidance. The historical prototype and adopted Core/Dialect artifacts remain frozen.All 124 portable vectors and 13 focused candidate tests pass. Runtime PR Judgment-Pack/judgment-pack-runtime#296 is merged and pins exact reviewed Spec
0852c5fa7726e51b36e574a5b110e7f5e012e03d; an additional 124 URI role probes agree. Both readers were Codex-assisted, so this is not independently authored implementation evidence. Same-vendor review records/dispositions are on the PRs under the maintainer's temporary waiver.This issue remains open: RFC 0023 is Review, not Accepted. Public review/formal adoption, independent implementation evidence where required, and actual host admission acceptance remain outstanding. Runtime validation establishes supplied-document consistency, never approval, current authority or permission to run.
kikashy commentedon Oct 22, 2026
Multiple policy sources, and the recommendation for v0.3.0 (the coordinator's, for the maintainer's review)
Yes, in both senses, already in the candidate text. A Policy document holds 0–16 original-source records, and each section cites up to 16
sourceRefs({sourceId, location}), so one policy can be assembled from several source documents at exact revisions. An adoption namesgoverningPoliciesin the plural, so several policies can govern one pack; duplicate references refuse, list order never establishes precedence, andinformationalSourcesadds up to 16 cited-but-not-governing references. What is not supported, by design, is precedence between governing policies: two coverage records that disagree refuse rather than rank.Recommendation for the release. Ship the Policy companion in v0.3.0 as a companion document at draft maturity, the way the dialect shipped under RFC 0018: the text (
spec/policy.md), the1.0.0schemas and the offline-reader class publish with the release; RFC 0023 stays Draft until the acceptance list above is met; the companion keeps its ownpolicy-v1.0.0-draft.Nroute for its format releases. Two things to close before the tag:Everything else in this issue's scope (live IAM, review and publication transactions, current eligibility) stays with the hosts, as written.
kikashy commentedon Oct 22, 2026
Decision (the maintainer's, 2026-10-22): accepted as proposed
The Policy companion ships in v0.3.0 as a companion document at draft maturity, RFC 0023 staying Draft; several source documents per policy and several governing policies per pack, as the candidate text has them; a conflict between governing policies refuses rather than ranks. Before the tag: the second independently authored reader named or the criterion recorded as open, and the precedence rule stated in §4 and the FAQ. The 16-source maximum stays a schema maximum.
On the limits (16 sources, 8 routes). In this specification a bound of a closed form is a schema maximum: hard for every reader, exposed by the capability record for discovery (Policy companion §5), raised only by a specification revision with the evidence of a consumer that needs more. It is not an installation setting, because a document that one reader admits and another refuses would break the exact-identity rules the formats rest on. The workflow (RFC 0020 §2) shows the one configurable shape the specification uses: a document declares its own limits, each at least 1 and at most the ceiling the specification sets. Either pattern keeps the ceiling in the specification.
kikashy commentedon Oct 22, 2026
Addendum (the maintainer's, 2026-10-22): the 16-source and 16-section-reference maxima are the
baseprofile's; a policy that needs more declares theextendedprofile defined in #232, and a reader that lacks it refuses withprofile-unsupported.kikashy commentedon Oct 22, 2026
Moved to v0.4.0 with #160 and #209 (the maintainer's decision, 2026-10-23): they sit on the Codex session's lines (the Policy companion's next version, the workflow execution contract, the admission proofs), and v0.3.0 closes on what is merged: #142, #169, #170, #213, #219, #227, #228, #231, #232, #233.
kikashy commentedon Oct 22, 2026
Correction (the maintainer's, 2026-10-23): #211, #160 and #209 stay in v0.3.0; the move to v0.4.0 noted above is reverted.
kikashy commentedon Oct 22, 2026
Amendment to the decision (the maintainer's, 2026-10-23), after the release gate was read
RFC 0023 stays Accepted at draft maturity:
Acceptedis the RFC process disposition, draft is the artifact's maturity, and the Policy release gate holds the former. The precedence statement for v0.3.0 says only what the 1.0.0 draft does: list order never establishes priority and a duplicate policy identity refuses. A refusal for two governing policies whose coverage disagrees is not defined or checked by 1.0.0; it is the first item of the companion's next format version (a new selector, schema, vectors and release), tracked separately.spec/policy.md, the release manifest, the gate and every 1.0.0 artifact stay byte-identical. The second independently authored reader is recorded OPEN.Record the Policy draft release decision (#243)