zone.hyperreal.enterprises
War Machine · explanations before construction

WM-02: carry the actual belief into prediction

Authored build-design cascade, 2026-09-15. Exactly WM-02. The task is to make the actual post-update entity/context distribution reach the production cascade predictor, without fabricated joint state or a uniform fallback. This is a complete proposed build path with explicit unresolved decisions. It does not claim a connected production belief, admit a new prior, or authorize implementation dispatch.

The problem behind the missing row

The machine selects work, but the belief used to predict that work must describe the same subject at the same time. A successful map lookup is not enough. It could retrieve a hypothesis about another kind of entity, a prior that never received observations, or yesterday's posterior. A normalized row cannot establish its own meaning or freshness.

The existing row-7 reader, machine-belief/belief-state-distribution, explicitly accepts a single-entity context, checks the canonical seven-status order, requires every supplied policy entity to match, checks masses and returns the posterior unchanged. It refuses missing entities and joint requests. This is useful bounded source behavior; it does not prove the selected mission or ticket has a justified current row, or that the production predictor calls it.

Row 13's Dirichlet accumulation and retained update-input seam are a different computation. They cannot be renamed as the row-7 state reader or substituted for its output. The historical report that selected targets were missing from a retained trace motivates a check; it is not a fresh deployment census here.

The recurring handoff example exposes the semantic issue. A registry says “complete” while the successor cannot resume the work. Which hypotheses should the belief distinguish? How could evidence change them? The earlier proposal to add mission and ticket IDs to the existing seven-status domain does not answer those questions by itself. The corresponding review commissions were withdrawn, and this document does not revive or ratify their proposed mapping.

Ten pattern applications

Q1 — Explain the state before choosing its carrier

Pattern: wm-prediction/meaning-before-carrier.

Describe two situations that the policy must distinguish, what each proposed state means, and what observations could challenge it. Bind entity type, target identity, context and temporal grain. Output: the reviewed state interpretation shared with WM-03's dynamics and WM-04's observation model.

The existing seven-status carrier constrains the current interface; it does not prove it is adequate for every mission, ticket or joint policy. If it erases a required distinction, raise a structural model change with its downstream consequences. Do not introduce a second private meaning for the same state names to make the reader pass.

Q2 — Name the conditioning and snapshot boundary

Pattern: aif/declare-the-conditioning.

Identify the selected target, candidate-policy context, model revision and exact tick/occurrence whose post-update belief is required. Define the logical boundary after admitted updates and carry reconciliation, before prediction reads it. Output: a snapshot request with all required identities and an explicit missing-input result.

Concurrent observations arriving after that boundary belong to a later snapshot. The design must state the allowed freshness condition and current-tick selection order rather than invent a universal age threshold. All candidates in a comparison must use the same admitted information boundary unless a different conditioning is explicitly justified.

Q3 — Keep beliefs as revisable hypotheses

Pattern: aif/belief-state-operational-hypotheses.

Represent uncertainty about Q1's state distinctions and retain how it can change. Separate a state posterior from registry metadata, observer labels, Dirichlet parameters, parameter beliefs and a policy posterior. Output: a declared belief schema and authorized initialization/update interfaces.

A prior is a prior even if the first read calls it mu-post. An event declaring work addressed is not automatically an independently measured state label. Reuse the existing AIF pattern's revisable-hypothesis discipline, not its example schema or historical implementation claims as proof of this machine's behavior.

Q4 — Preserve initialization, updates and carry lineage

New pattern: wm-prediction/belief-keeps-its-lineage.

Retain the authorized entity domain and prior D, predecessor snapshot, ordered admitted update occurrences, model identity and carry decision. Distinguish first introduction, surviving entity, archived entity, reopened entity, explicit migration, cold start and unavailable history. Output: the posterior with enough provenance to reproduce its construction.

An entity absent from a live selection set is not necessarily absent from the model's historical domain. The domain authority must explain retention and retirement; this design does not silently choose all registry entries as the answer. An unreadable registry or missing carry is different from a confirmed new entity. Do not reset either to a default prior.

The current source defines initial-prior-v1 as uniform. Naming it does not authorize using it for a new target model. Equally, this design does not forbid a uniform distribution merely because of its values: an explicitly justified D and a silent uniform repair have different authority. WM-02's prohibition on uniform fallback remains intact.

Q5 — Admit update evidence without turning belief into truth

Pattern: wm-prediction/observation-can-disagree.

Tie updates to their authorized evidence origin, occurrence, model and ordering. Registry changes may be declared observations under a reviewed interpretation; they are not thereby WM-04 categorical truth. Preserve insufficient/conflicting evidence and impossible-update conditions under the declared update contract. Output: an admitted update sequence or a typed refusal.

Prevent duplicate application and future evidence leakage. Retain whether B propagation has already happened so the predictor or belief update cannot advance the state twice. WM-03 supplies the transition semantics; WM-04 supplies the observation authority. WM-02 connects and accounts for these inputs rather than inventing a replacement filter.

Q6 — Preserve the policy's actual scope

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

Resolve the complete candidate's target and required context, including additional entities and history needed by guards or effects. Output: the state scope required at prediction, bound to the actual policy/model identities.

Exact target keys must agree with the controller. Any alias or migration needs a declared, auditable mapping; string conversion cannot silently merge different subjects. A policy involving several entities must not be narrowed to one to satisfy row 7. This uses policy identity at WM-02's interface without taking over WM-11's posterior work.

Q7 — Justify joint belief when the scope needs it

New pattern: wm-prediction/joint-belief-needs-dependence-authority.

Compare Q6's scope with the available state distribution. For a legitimate single-entity request, the existing reader may suffice after its producer/consumer connection is established. For multiple entities, context factors or execution history, declare their joint meaning and dependence, and provide the corresponding constructor and update/carry semantics.

Output: a justified joint distribution or explicit missing-joint obligation. Marginals do not determine a joint distribution. A product requires authorized factorization and evidence of applicability; averaging marginals is not a joint construction at all. A refusal correctly exposes missing work but does not complete that part of WM-02.

Q8 — Admit probability representation without repairing meaning

Pattern: wm-prediction/probability-laws-with-runtime-meaning.

Check complete support and order, finite nonnegative values, normalization under the declared exact/float admission, model identity and the correspondence between retained representation and the predictor's input. Output: an admitted belief-input envelope, preserving the values actually constructed.

Do not renormalize, clip, fill absent states, replace a failed row with uniform mass, or introduce a new numerical tolerance inside the reader. Any warranted conversion or model migration has its own reviewed contract and provenance. Probability-law validation and state/observation authority remain distinct checks.

Q9 — Keep state meaning across the predictor boundary

Pattern: wm-prediction/outcome-meaning-across-models.

Bind the admitted distribution to WM-05's initial state distribution under the same B/A domain, policy context and information boundary. For the existing single-entity case, retain that row 7's returned posterior is the one supplied to the policy-conditioned state constructor. For a larger state, retain the explicit justified mapping rather than relying on equal vector lengths.

Output: a producer-to-predictor receipt with snapshot, supports and model identities. WM-02 supplies the current starting belief; it must not replace it with a rollout's predicted next belief or turn an argmax into a point mass. WM-05 owns subsequent propagation over the full policy.

Q10 — Follow the belief into the actual decision

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

Show which actual call site consumes Q9's input and what happens when an admitted observation changes it. Output: retained consumer evidence, plus a counterexample where stale or substituted belief is rejected.

A changed belief need not change the winning candidate; several policies can remain equivalent or the ordering can remain stable. Acceptance must establish that the value reaches and is used by the predictor, using a distinguishing controlled test where appropriate, rather than requiring every observation to reverse a choice. Unit tests do not establish ordinary production use.

Composition and feedback

Q1 and Q2 constrain Q3's schema. Q3, Q2 and Q5's evidence contract constrain Q4's lineage. Q4 retains the prior/carry context in which Q5's updates are applied; these are interacting design constraints, not two independent beliefs. Q1 and Q6 jointly determine Q7's scope. Q4, Q5 and Q7 supply Q8's actual distribution and provenance. Q8 and Q6 supply Q9's predictor input, which Q10 follows into actual use.

Q7 can expose a missing state distinction and return to Q1. Q8 can expose an unauthorized reset or conversion and return to Q4. Q10 can reveal that the real consumer uses a different boundary and return to Q2. These revision relations do not automatically execute updates or authorize changing the state model.

Proposed build interfaces

These names describe responsibilities; they are not claims that new modules exist.

Component Inputs Retained result and refusal boundary
Domain/meaning declaration Target kinds, identities, state interpretation, retention/migration authority belief-domain; reject unreviewed aliases or incompatible meaning
Snapshot resolver Tick, selected context, model identity, admitted evidence boundary belief-snapshot-request; distinguish stale, absent and unreadable
Initialization/carry adapter Declared D, authoritative domain, predecessor and migration records Explicit initialization/carry lineage; no silent reset or live-list-driven forgetting
Update adapter Ordered unique admitted events, A/B identities and update rule Post-update snapshot with predecessor and occurrence joins; no duplicate propagation
Scope/joint resolver Complete policy context and available marginals/joint representation Single-entity admission or justified joint construction; no policy narrowing
Probability/representation validator Distribution, support and numeric contract Unmodified admitted values or typed refusal
Predictor binding Admitted current snapshot plus complete model/policy context Exact WM-05 input receipt and actual consumer identity

Each artifact needs schema version, immutable identity, content pins, authority and relevant times. Publish a complete snapshot atomically so domain, posterior and lineage cannot come from different ticks. A reader must detect an unavailable predecessor rather than fabricate one. Retain old model histories through explicit migration; a new model's posterior cannot silently overwrite an old model's interpretation.

Concrete controls and the handoff example

Start with a handoff whose registry status is complete but whose criterion evidence is insufficient. Q1 must explain the relevant hypothesis without equating registry status with success. Q4 identifies whether its distribution comes from D or prior accepted updates. Q5 keeps insufficiency separate from an observed success event. Q9 sends that same uncertain distribution to prediction. No arbitrary probability values are supplied by this illustration.

Next, let the mission leave the live target set and later reopen. The declared domain/retention policy must explain how its belief survives or is explicitly archived and restored. If instead the bootstrap drops its row and silently initializes it when it reappears, a normalized posterior conceals forgotten information. A test must distinguish these cases.

Finally, let a candidate also affect the successor's work. Row 7's single-entity refusal is now useful evidence of a missing joint requirement. It is not permission to remove that effect from the policy or multiply unreviewed marginals.

Build order and acceptance evidence

  1. Settle state, scope and domain authority (Q1–Q3/Q6–Q7). Review concrete contrasting situations and their observations. Identify whether the seven-status single-entity contract fits. Any required joint or carrier change must include its A/B/update/consumer consequences before dependent code is chosen.
  2. Reproduce the selected-target boundary using retained inputs. Capture exact selector targets and model contexts and call the existing reader. Test both a mission and ticket, plus an unrelated identifier. Report the actual result and snapshot; the earlier missing-row report is not a substitute for this check. No such runtime reproduction is claimed in this authoring task.
  3. Build explicit lineage and update/carry integration (Q4–Q5). Tests cover authorized first initialization, surviving and reopened entities, domain retirement, missing/corrupt history, model migration, duplicate/out-of-order events, cutoff leakage and double B propagation. Do not require preservation of an old silent fallback merely because it was historical behavior; resolve the invariant conflict structurally.
  4. Build scope and numeric admission (Q7–Q8). Reject unsupported joints, mismatched entity keys, missing/extra states, invalid mass and unauthorized conversion. Exercise permitted exact/float cases under the existing admission rule. Constructed controls establish mechanics, not model adequacy.
  5. Join the real predictor (Q9–Q10). A stale-snapshot or model-mismatch control must fail at the actual boundary. Retain a controlled example demonstrating sensitivity to the admitted distribution, and later an authorized ordinary use showing exact input/consumer identity. Source-level wiring and a passing fixture do not close this production requirement.

Source findings and authority limits

Read for this design: machine_belief.clj checks single-entity scope and does not rewrite the posterior. belief.clj currently contains uniform initialization, an untracked-entity fallback in update, an unreadable-bootstrap fallback, and carry reconciliation that drops entities absent from bootstrap. These are inspected source behaviors, not evidence that those branches ran for current selected targets, nor permission to use them to satisfy WM-02.

The checklist distinguishes row 7 from row 13. The fundamentals specification requires the real machine belief and shared model contract. The source-pinned companion JSON records this inspection. The new lineage and joint-dependence patterns are drafts in the prediction sublibrary, with existing AIF arguments cross-referenced rather than duplicated.

WM-02 remains open. This design provides its reviewable construction and evidence path; it does not ratify the withdrawn target-row proposal or claim that the machine now consumes the right belief.

Q11 — Interpret unchanged belief through its update context (P1 extension)

Pattern: wm-connected-learning/unchanged-belief-needs-update-context.

Claude-2's retained P1 reproducer found nil before/after target rows. Subsequent call-chain inspection located the belief comparison in the one-record compatibility branch; production uses the sequence/outcome branch. The original production-scoring attribution was incorrect. Introducing equal priors would leave the unsupported progress inference unresolved. Q4's lineage and Q10's consumer trace therefore jointly constrain Q11: distinguish missing or non-informative belief comparisons from evidence that the work failed to progress. A score consumer that cannot express that distinction needs an explicit contract decision; no neutral number is supplied here. Q11 feeds back to Q2's information-boundary declaration.

The P1 design response adopts a documented work-target rubric interpretation, candidate-admission domain, named first-introduction uniform prior and no observation updates in P1, with independent review and explicit limits. This is a new design decision, not retroactive acceptance of the withdrawn proposal, empirical validation or completion. The declared prior is not a uniform fallback, and unchanged prior-only carry is not an informative posterior. D4/D5 remain for subsequent packets.

P1 follow-up — distinct models and corrected consumer scope

The Q-A/Q-B decision approves a separately identified work-target belief with its own model context. Adding its priors to the legacy strategic map would alter channel averages without a justified model interpretation. Q1/Q2/Q4/Q8/Q9 require explicit model identity and actual row-7 integration; separate storage does not establish WM-05 consumption. Q11's compatibility defect is recorded outside P1. Candidate admission covers advance-mission/advance-ticket only in this packet, with other candidate scopes retained as unresolved. Genesis must be established from reliable history or an explicit new-model initialization, never inferred from a missing immediate predecessor field alone.

P1 persistence extension — Q4/Q2 and acquisition completeness

The Q-C persistence decision establishes a dedicated model store because success-only traces cannot establish the committed predecessor. It applies belief-keeps-its-lineage, declare-the-conditioning, same-policy-through-comparison and complete-acquisition-universe: use an explicit durable head, predecessor checks at commit, idempotent operation identities, a documented crash-recovery protocol and ancestor-aware references. Established/no-snapshots is distinct from absent genesis or a valid empty snapshot. Production genesis is not yet authorized. The decision explicitly limits what local hash chains can establish under coordinated rollback.

P1 caller/failure extension — Q2/Q4/Q9

The Q-D–Q-G decision requires an established-model persistence failure to stop the attempt before construction/enactment. Inert pre-rollout behavior is distinct from damage after activation. Stale proposals are not rebased inside an attempt; lost-response resolution preserves operation identity. A generic trace? flag confers no production write authority. Explicit coordinator authority, stable occurrence identity and the retained model history apply the existing conditioning, lineage and policy-identity patterns.

Explicit design relations

FromToKindReason
Q1Q3prerequisiteState meaning determines what hypotheses the schema represents.
Q2Q3prerequisiteThe schema must identify the intended information boundary.
Q2Q4prerequisiteLineage must end at the requested snapshot.
Q3Q4prerequisiteInitialization and carry require declared belief semantics.
Q4Q5prerequisiteUpdates require the prior/carry lineage and occurrence history.
Q1Q7prerequisiteJoint variables require compatible state meanings.
Q6Q7prerequisiteThe full policy determines required state scope.
Q4Q8prerequisiteAdmission must bind the actual posterior lineage.
Q5Q8prerequisiteAdmitted update evidence determines the resulting distribution.
Q7Q8prerequisiteSingle or joint scope must be justified before numeric admission.
Q8Q9prerequisitePrediction must receive the admitted distribution unchanged.
Q6Q9prerequisiteThe same policy/context identity must cross the boundary.
Q9Q10prerequisiteActual use must follow this predictor input.
Q5Q4revision-feedbackThe evidence contract constrains how updates are retained in lineage.
Q7Q1revision-feedbackJoint requirements may expose missing state distinctions.
Q8Q4revision-feedbackInvalid values or conversion may expose an unauthorized reset.
Q10Q2revision-feedbackActual use can reveal a different snapshot boundary.
Q4Q11prerequisiteLineage establishes whether a comparison has informative updates.
Q10Q11prerequisiteThe real consumer exposes the interpretation of unchanged belief.
Q11Q2revision-feedbackA missing comparison context requires a corrected information boundary.

Existing AIF source snapshots

Quoted as local library references, not copied into the new sublibrary. Their other claims and examples are not adopted by this cascade.

aif/declare-the-conditioning
@flexiarg aif/declare-the-conditioning
@title Declare the Conditioning (Score the Fit, Not the Form)
@keywords conditioning, situation, context, fit, EFE, curried, referent
@audience aif implementers, pattern authors, futon developers
@tone technical
@style pattern
@references [aif/currency-before-merge aif/valuation-reads-the-paperwork]

@how aif/structured-observation-vector
@see-also aif/term-to-channel-traceability
@why no matching problem dossier node (@holds-at absent; not among the twenty dossier nodes R1-R17, R20, TRACE). Negative claim per the committed check futon2 holes labs library-loop runs l3_no_dossier_check.py, receipt runs L3-no-dossier-check.edn (enumerates every aif pattern's @holds-at against the dossier node set extracted from PROBLEMS-*.md headings). Rationale not invented (L3 rationale-backfill pilot, zai-1, 2026-09-05)
@how own mechanism: Every valuation surface must declare what slice of the situation it consumed; G(candidate) is a lambda — only G(candidate | situation) is a value. (source: this pattern's ! conclusion line; L3 rationale-backfill pilot, zai-1, 2026-09-05)
! conclusion: Every valuation surface must declare what slice of the situation it consumed; G(candidate) is a lambda — only G(candidate | situation) is a value.

  + context: A stack grows multiple valuation surfaces (blend terms, wholeness, ΔG legs, field diagrams), each labelled with the same vocabulary ("EFE", "value", "score").

  + IF:
    You want valuations to be comparable, auditable, and honestly labelled.

  + HOWEVER:
    Different surfaces silently consume different slices of the world — one eats the live observation vector, another a 160-char prose scrap, a third nothing at all — so identical labels name incomparable objects, and cross-surface comparisons are apples-to-oranges without anyone having lied.

  + THEN:
    Give every valuation surface a three-axis declaration: SENSE (which formal object it claims), SELECTION-SEMANTICS (extremum / amortized sample / bound — over what menu), and CONDITIONING (what situation-slice it consumed). Render the declaration where the number is rendered. In pattern terms: Context → (Problem → Solution) — application is modus ponens; the world supplies the antecedent; score the fit, never the form alone.

  + BECAUSE:
    Canonical expected free energy is G(π; Q(s), C) — conditioned on beliefs and preferences by definition; a policy has no value in vacuo, and Alexander says the same of form and context. Surfaces that skip the declaration re-invent the mislabeling one level up.

    + evidence: M-evaluate-policies §9.6–9.7 + exhibit "conditions on" column (futon2, 2026-07-03): the atomic-action lane conditioned on the live observation vector while the cascade lane ate a title+status scrap and two native components consumed no situation at all — one arena, incomparable conditioning. E5 measured the conditioning channel: situation-enriched ψ rebuilt 11/13 cascades. The fold contract already typed circumstance as an argument; the plumbing had starved it.

  + NEXT-STEPS:
    - Add the sense × selection-semantics × conditioning triple to each EFE-labelled surface's declaration (extends the efe-referent-declaration shape).
    - Route all lanes toward ONE situation source (the structured observation vector) where feasible.
aif/belief-state-operational-hypotheses
@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.

Download the source-pinned cascade JSON · WM-05 cascade