R13 depth

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

Requested depth is not evaluated depth. R13 must show real continuation computations at effective depth at least two and their connection to the same run.

Governing checklist snapshot

R13 depth. OPEN: legitimate effective depth >=2, actual branch computations and same-run continuations. A requested configuration is insufficient. Built evidence: Definition/reference witness and depth branch source

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

R13-1 — Choose the relevant continuation question

Pattern: aif/temporal-depth-beyond-greedy

Describe why a next-step benefit differs from a longer consequence for this task. Use WM-12’s common observation schedule and admitted models. A dummy repeated state does not demonstrate anticipation.

R13-2 — Resolve effective configuration

Pattern: wm-connected-learning/modulation-needs-an-applicable-consumer

Record requested and effective depth, branch limits, mode and model revisions at the consuming call site. Produce effective configuration evidence, not an environment variable printed by another process.

R13-3 — Evaluate actual branches

Pattern: aif/temporal-depth-beyond-greedy

Retain each branch’s states, observations, transition interpretations and score contributions through the admitted horizon. Do not add a temporal discount merely because the seeded historical example uses one.

R13-4 — Join choice and continuation

Pattern: wm-connected-learning/modulation-needs-an-applicable-consumer

Show which evaluated branches informed choice and how the selected continuation appears in subsequent same-run records. Separate counterfactual branches from enacted steps and retain their exact identities.

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.

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 option produces a quick acknowledgement but strands the receiver; another prepares evidence that enables a later review. A true two-step comparison represents that distinction, not two copies of the immediate score.

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 requested-two/effective-one, synthetic duplicate branches, policy-specific unfair schedules and continuation from another run. Include a meaningful two-step-versus-greedy control.

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-05 · WM-10 · WM-12 · R6 · R14 · R16

Depth evidence depends on real WM-05/10/12 computation; configuring an unfinished scorer cannot close R13.

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.

@flexiarg aif/temporal-depth-beyond-greedy
@title Temporal Depth Beyond the Greedy Step
@sigils [🐜/专]
@audience fulab agents, aif implementers
@tone technical
@style pattern
@holds-at R13   ;; pegged 2026-08-30 (claude-15): the catalogue paragraph numbered R13 in p4ng/sec-catalog.tex; see PREREG-war-machine §1b

@see-also aif/hierarchical-budget-aware-action-selection
@see-also aif/hierarchical-and-temporal-depth
@why R13 dossier problem: R13 solves how delayed consequences can outrank a greedy first move: the roster places **“Temporal policy depth”** in SELECT (`p4ng/empirics-futon/control-stages.edn:24`; control-stage numbering). (source: futon2 holes labs wm-contract PROBLEMS-r16-r13-r14-batch4.md, R13, The problem it solves; L3 rationale-backfill pilot, zai-1, 2026-09-05)
@how own mechanism: Genuine planning (R15) requires evaluating policies G(π) over a horizon and separating timescales; a single rollout step demonstrates the machinery, not the depth. Depth-1 is reactive control wearing planning's clothes. (source: this pattern's ! conclusion line; L3 rationale-backfill pilot, zai-1, 2026-09-05)
@why problems/r13-temporal-policy-depth (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: Genuine planning (R15) requires evaluating policies G(π) over a horizon and separating timescales; a single rollout step demonstrates the machinery, not the depth. Depth-1 is reactive control wearing planning's clothes.

  + context: R15 asks for hierarchical / temporal depth — the agent evaluates policies over a horizon of several ticks (not just the next action), and represents goals that span many ticks via a slow loop that sets priors for a fast loop.

  + IF:
    You want the agent to plan — to prefer an action whose payoff is two or three ticks out over a greedy one-step win, and to pursue goals (like accumulating capability) that no single tick can achieve.

  + HOWEVER:
    A rollout that looks ONE step ahead — even one that passes a "2-step-beats-greedy" witness — demonstrates the MACHINERY (multi-step G(π) is computable) but not DEPTH. The horizon is still shallow, and without a temporal HIERARCHY (a slow loop shaping a fast one) the agent cannot represent a goal whose satisfaction is spread across many ticks. It reacts one step at a time and calls it planning.

  + THEN:
    Extend G(π) evaluation to a horizon H > 1 with a temporal discount, AND introduce a two-timescale hierarchy: a slow (strategic) loop that updates priors/preferences and a fast (tactical) loop that acts against them. The slow loop is where accumulated learning (R12) and prior-preferences (R19) live; the fast loop is the per-tick act-gate. Couple the two so the fast loop's realized outcomes update the slow loop's priors.

  + BECAUSE:
    Active inference plans by minimizing expected free energy over a POLICY (a temporally-extended sequence), not over the next action alone. A depth-1 evaluation cannot distinguish a locally-optimal dead-end from a step toward a distant goal. Temporal hierarchy is also the natural home for the capability curriculum ("work descends into capability") — a payoff that only a slow loop can score.

  + NEXT-STEPS:
    - DONE: rollout apparatus + the 2-step-beats-greedy witness (`futon2.aif.rollout`). Evidence: futon2/docs/futon-aif-completeness.md R13.
    - Extend rollout to a configurable horizon H with a temporal discount; report G(π) per horizon, not just the winning first action.
    - Introduce fast/slow timescale separation: the WM's strategic tick as the slow loop; a faster inner act-gate as the fast loop.
    - Wire the slow loop to R12 (dual-loop hyperparameter inference) and R19 (prior preferences): realized outcomes over a horizon update the priors the fast loop scores against.
    - Guard: report the horizon actually evaluated. A depth-1 evaluation labelled "planning" is the R15 anti-pattern (sibling to R16's re-observe-your-own-construction).