R1 belief

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

A readable belief can still be irrelevant to the selected work. This node must connect the current, justified hypothesis to the model that actually compares policies.

Governing checklist snapshot

R1 belief. PARTIAL: current real belief used by the same admitted model and subsequent selection. WM-02/WM-05. Built evidence: Categorical state/carry and pinned correspondence records

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

R1-1 — Locate the hypothesis

Pattern: aif/belief-state-operational-hypotheses

Start with the selected entity and context, not whichever belief map is easiest to read. Name the claim represented by each state and its possible contradiction. Produce a target/model binding; a registry status is context, not an observed label.

R1-2 — Establish the current distribution

Pattern: aif/belief-state-operational-hypotheses

Use WM-02 to retain introduction, predecessor, admitted updates and cutoff. Produce the post-update distribution under its declared model. A prior-only row must remain labelled prior-only; missing carry cannot be repaired with uniform mass.

R1-3 — Pass that distribution into prediction

Pattern: wm-connected-learning/observation-to-next-choice

Bind the actual WM-05 input to the same entity, support and model revision. Produce a reader-to-predictor receipt including rejected mismatches. Logging the row beside a predictor that reads the legacy map does not establish this edge.

R1-4 — Follow the consequence into choice

Pattern: wm-connected-learning/observation-to-next-choice

Retain the candidate predictions, selected policy and next observation boundary. Explain an unchanged choice when appropriate. Produce same-occurrence consumer evidence, without requiring every legitimate posterior change to flip the winner.

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

A completed-looking mission has unresolved evidence. The registry says complete while independently reviewed evidence supports uncertainty. The predictor must use the admitted uncertain belief. If it reads a prior or another mission, a successful lookup has hidden the broken edge.

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 wrong target, stale cutoff, lost lineage and support permutation without identity mapping. Compare consumed input hashes; include a changed belief that legitimately leaves the winner unchanged.

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-02 · WM-05 · R3 · R6

No new persistence system is prescribed. If current retention cannot supply the required lineage, identify the exact missing WM/E02 obligation before any separately authorized change.

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/belief-state-operational-hypotheses
@title Belief State as Operational Hypotheses
@sigils [〰️/双]
@audience fulab agents, aif implementers
@tone technical
@style pattern
@holds-at R1   ;; pegged 2026-08-30 (claude-15): the catalogue paragraph numbered R1 in p4ng/sec-catalog.tex; see PREREG-war-machine §1b
@why R1 dossier problem: R1 solves how the loop keeps revisable hypotheses rather than repeatedly reasoning from raw history: the roster places **“Belief state”** in BELIEVE (`p4ng/empirics-futon/control-stages.edn:17`; control-stage numbering). (source: futon2 holes labs wm-contract PROBLEMS-r1-r3-r3a-batch3.md, R1, The problem it solves; L3 rationale-backfill pilot, zai-1, 2026-09-05)
@how own mechanism: Maintain a compact belief map of operational hypotheses that is updated each step. (source: this pattern's ! conclusion line; L3 rationale-backfill pilot, zai-1, 2026-09-05)
@why problems/r1-belief-state (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: Maintain a compact belief map of operational hypotheses that is updated each step.

  + context: The agent needs an internal state about what it is doing and why, beyond the raw trace.

  + IF:
    You want decisions to depend on tractable hypotheses (progress, blockers, pattern fit, uncertainty) rather than raw conversation history.

  + HOWEVER:
    If the belief state is just the conversation, the agent cannot cleanly update, compare, or falsify its own assumptions.

  + THEN:
    Represent (mu) as a belief map of operational hypotheses (for example: :goal, :subgoals, :current-hypothesis, :blockers, :pattern-fit, :expected-next-observation, :uncertainty), updated at each step using observation and outcomes.

  + BECAUSE:
    A compact belief state makes predict -> observe -> update implementable and testable.

  + NEXT-STEPS:
    - Define :aif/belief-state schema in tatami_schema.clj with keys [:goal :subgoals :current-hypothesis :blockers :pattern-fit :expected-next-observation :uncertainty].
    - Extend aif_bridge/aif-step->event to validate mu against the schema before emitting :aif/tick events.
    - Add (mu-diff prev-mu next-mu) helper and log diffs as :aif/belief-delta events in pattern_competence.clj.
    - DONE (UKRN v3 HO-01, 2026-05-14): per-institution BeliefState schema with mean+variance per coordinate, named handle (not inlined), centralised initialisation via initial-belief-state. Evidence: notebooks/ukrn_v2_contracts.clj:22-30; notebooks/ukrn_v2_substrate.clj:286-298. Validation: handoffs/v3_runner/validation_HO-01.md.
    - DONE (UKRN v3 HO-01): trajectory-CSV emission of belief means and variances per tick, enabling visible belief evolution in the output stream. Evidence: notebooks/ukrn_v2_runner.clj:110-140.
    - Practice refinement: prefer a *named schema handle* (e.g. BeliefState) over inlining belief shape inside agent/instance schemas — keeps the schema stable across update-rule changes and reusable by predictive-forward-model code. Surfaced 2026-05-14 in HO-01 review.
    - Practice refinement: centralise initialisation in a single helper (e.g. initial-belief-state) rather than duplicating tick-0 values across constructors. Surfaced 2026-05-14 in HO-01 review.