zone.hyperreal.enterprises
War Machine · explanations before construction

R6 action/policy space

Authored design — 2026-09-15. Section 3. This cascade elaborates the existing checklist item. It is not a dispatch, implementation receipt or completion verdict. Work outside WM-01–14 still requires Joe’s explicit greenlight; having a cascade is necessary but not permission.

Section 3/4 index · Exact TODO · Cascade JSON

Situation and design problem

Target eligibility and full policy identity are different responsibilities. All open missions and live tickets must be represented without collapsing multiple designs for one target into one score row.

Governing checklist snapshot

R6 action/policy space. PARTIAL: WM-08–WM-11, complete candidate authority over all open missions and live T-tickets, actual choice/enactment and a regression guard against restoring the old three-mission restriction. Ticket source handoff explicitly did not claim deployment. Built evidence: Retrieval, action ranking, posterior components; September 15 controller/ticket source changes

This is the checklist’s dated evidence account, not a new deployment census. Existing source/test evidence keeps its bounded credit. The acceptance obligation above governs this design.

Pattern applications

R6-1 — Acquire the authorized target field

Pattern: aif/candidate-pattern-action-space

Use strict registry/authority inputs for all open missions and live T-tickets. Retain included targets and explicit exclusions at the cutoff. Do not restore the old three-mission allow-list through an optimization or test fixture.

R6-2 — Construct full candidate designs

Pattern: aif/candidate-pattern-action-space

Use real retrieved patterns and attributed organisation from WM-08/09/14. Record each cascade, precedence and interpretation; bounded retrieval must preserve the reason and authority for its bounds.

R6-3 — Keep identities through comparison

Pattern: wm-pattern-design/same-policy-through-comparison

Carry all candidates into prediction, G, applicable F, prior/posterior and choice. Produce a coverage join; a target ID alone cannot identify two alternative cascades.

R6-4 — Bind the chosen policy to actuation

Pattern: wm-pattern-design/same-policy-through-comparison

Retain the selected full identity, actual enactor and rejected/unselected alternatives. Add a regression control for mission/ticket coverage and the prohibited allow-list. Selection source presence alone is not live choice evidence.

Composition and interfaces

Each node’s stated artifact is the input or constraint for the related node below. These are design dependencies, not a claim that a runtime scheduler automatically fires patterns. Existing WM producers are reused through the linked contracts; no second implementation is implied.

From To Relation Reason
R6-1 R6-2 requires-result Authorized target coverage bounds the candidate construction obligation.
R6-2 R6-3 requires-result Full designs determine the identities that scoring must preserve.
R6-3 R6-4 requires-result The same identity must survive from comparison into actual actuation.
R6-4 R6-1 revision-feedback A failed distinguishing control or consumer mismatch reopens the original scope/meaning; retain the failed claim rather than weakening it. Relevant controls: Reject missing eligible target, mission-only key collision, dropped candidate and selected/enacted mismatch. Test tickets and missions outside the old canary set.

Retain the actual subject, source/model revision, task/occurrence, cutoff, producer and consumer for each interface. A missing field is a named gap; a default that changes the meaning is not an adapter. Reuse existing records where they satisfy these obligations. If a new component is indispensable, identify its exact TODO/cascade clause before seeking a separately bounded implementation instruction.

Worked situation

One ticket has two plausible response orders. Collapsing them under its T-id hides their different predictions. A second eligible mission must not disappear because an old canary list omits it.

This is a distinguishing design example, not a claimed production experiment.

Implementation sequence and closure evidence

  1. Bind the first application to the actual source, task and authority. Resolve the decisions below before their dependent change; do not reproduce a known gap merely to claim activity.
  2. Implement only the specifically dispatched producer/consumer change from the middle applications. Retain the meaningful pre-change failure and relevant post-change controls; do not start a general infrastructure project.
  3. Acquire the final application’s evidence and independent review. Compare it against every clause of the exact TODO, identifying any still-open dependency. Source, tests, serving state, ordinary use and whole-run validation receive different credit.

Distinguishing controls: Reject missing eligible target, mission-only key collision, dropped candidate and selected/enacted mismatch. Test tickets and missions outside the old canary set.

Closure rule: every part of the quoted obligation must be supported by the indicated artifacts and actual connections. A useful rejection proves the rejecting boundary only. One accepted subclause does not tick the whole item. A bellback must supply the exact reviewed subject, executed checks, independent verdict and remaining clauses.

Dependencies and authority boundaries

WM-08 · WM-09 · WM-10 · WM-11 · WM-14 · R16

Candidate-generation limits require explicit authority; refusing an unsupported policy does not permanently exempt its target.

Dependency links describe required interfaces; they do not authorize work on those items. No implementation outside the existing TODO list is approved. Publication does not select a numerical law, settle an unresolved operator ruling or authorize a run.

Pattern and source scope

All seeded patterns are applied above. The JSON pins their source bytes and the governing checklist/rulings. Historical formulas, thresholds and examples in a pattern remain scoped examples unless the governing contract adopts them. This draft adds no pattern-library entries and claims no independent semantic ratification.

Existing pattern source snapshots

Reference text; historical examples and prescriptions retain the scope stated above.

aif/candidate-pattern-action-space
@flexiarg aif/candidate-pattern-action-space
@title Candidate Pattern Action Space
@sigils [📥/力]
@audience fulab agents, aif implementers
@tone technical
@style pattern
@why war-room/wr-19-tension-must-generate-not-only-rank   ;; editorial, claude-13 2026-08-23: retrospective sense-making, NOT a causal
;; claim -- WR-19 did not produce this pattern. See README-flexiarg 5a.
@holds-at R6   ;; pegged 2026-08-30 (claude-15): the catalogue paragraph numbered R6 in p4ng/sec-catalog.tex; see PREREG-war-machine §1b

@see-also aif/evidence-precision-registry
@why R6 dossier problem: Control-stage R6 occupies SELECT and is labelled **“Candidate action space”** (`p4ng/empirics-futon/control-stages.edn:23`; control-stage numbering), although the original contract R6 criterion is the adjacent operation: softmax selection with temperature and an abstain branch, where **“the agent declines to act”** under too much predictive uncertainty (`docs/futon-aif-completeness.md:147-157`; contract R6). (source: futon2 holes labs wm-contract PROBLEMS-r4-r5-r6-pilot.md, R6, The problem it solves; L3 rationale-backfill pilot, zai-1, 2026-09-05)
@how own mechanism: Treat action selection as choosing from a bounded candidate set of pattern IDs. (source: this pattern's ! conclusion line; L3 rationale-backfill pilot, zai-1, 2026-09-05)
@why problems/r6-candidate-action-space-and-selection (L14 edge-resolution; basis: holds -- the problem node's own holds-at token covers this pattern; source: receipt runs/L14-edge-resolution.edn; zai-1, 2026-09-05)
@why problems/tension-proposes-candidates (L14 edge-resolution; basis: holds -- the problem node's own holds-at token covers this pattern; source: receipt runs/L14-edge-resolution.edn; zai-1, 2026-09-05)
! conclusion: Treat action selection as choosing from a bounded candidate set of pattern IDs.

  + context: Action selection in fulab often means selecting (and committing to) a pattern to apply next.

  + IF:
    You want pattern choice to be legible and comparable, and you want to avoid collapse into one habitual pattern.

  + HOWEVER:
    If the action space is any pattern at any time, evaluation becomes unstructured and selection becomes arbitrary or dominated by recency.

  + THEN:
    Define (a) as a constructed candidate set of pattern IDs produced by retrieval plus gating rules, with bounded size and explicit reasons for inclusion and exclusion.

  + BECAUSE:
    Constraining the action space makes downstream scoring meaningful rather than performative.

  + NEXT-STEPS:
    - Add :aif/candidate-entry and :aif/candidate-chosen event types to tatami_schema.clj.
    - In learn_or_act/expand-hints, emit :aif/candidate-entry for each pattern in :search/candidates.
    - In learn_or_act/decide success path, emit :aif/candidate-chosen with pattern-id and runner stats.
    - Create aif_coverage.clj with (coverage-report session-id) that computes entered-vs-chosen ratios per pattern.