Conceptual review draft. Joe has paused build dispatch so these explanations can be challenged first. The handoff scenario is illustrative; it is not a recorded experiment or an adopted model.
Joe has accepted the completion checklist in substance, but has stopped build dispatch until its proposed stages have been explained well enough to reveal conceptual errors. This is the first of five such explanations. It examines the proposed prediction foundation; it does not approve the recently proposed mission-status model.
Consider a reviewer trying to resume an unfinished mission after its author leaves. The reviewer needs to know what the author tried, which conclusions have evidence, and what is still uncertain. The library's Handoff Preserves Context pattern addresses this recurring situation. Its response is to preserve the working hypothesis, reasons for decisions, open questions, scope and evidence so another person or agent can continue. That is a reason for organizing work a particular way. It is not merely an instruction to write a file.
For this walkthrough, imagine comparing an immediate handoff with a handoff preceded by resolving a disputed claim. This is a proposed teaching situation drawn from an actual library pattern, not a report of an executed mission. Before predicting either design, we need to say what could differ in the world. Could the next reviewer find the relevant evidence? Could they identify a remaining contradiction? Could they continue without repeating the whole investigation? The presence of a handoff document is observable, but it does not by itself answer those questions.
A hidden state is the condition we are uncertain about; a belief is our distribution over possible conditions. An observation is something we can actually inspect. These three objects must remain distinct. A mission marked complete in a registry is an observation about the registry. Whether the work meets its criterion is another question. The machine's confidence that it meets the criterion is another again.
The concrete P1 proposal exposed a real conceptual trap. Claude-20 reports that the retained belief contains stack-section IDs while the controller chooses mission and ticket IDs. Even if this mismatch is reproduced, inserting mission IDs into a seven-status table is not automatically a repair. We must explain what each status means for a mission, which observations distinguish statuses, and why the existing update law applies. A type accepted by a function is not yet a useful description of the problem.
The library's State Is Hypothesis pattern supplies a helpful discipline: internal state should be revisable and have conditions under which it is contradicted. It does not supply a probability distribution for missions. The proposed declared initial distribution and registry-to-event mapping remain proposals. Calling them declared makes their origin visible; it does not make their meanings correct.
Suppose the current belief assigns uncertainty to whether the disputed claim is supported. The proposed work design first inspects the underlying evidence, then revises the handoff. The transition model, conventionally called B, describes how those interpreted actions may change the situation. Reading evidence might change what the agent knows without repairing the underlying work. Revising a document might make that knowledge communicable without making the claim true. A model that treats both as a generic progress increment has erased the distinction the design was meant to address.
The observation model, A, describes what we would expect to observe given a state. For example, a test result may be informative about one acceptance condition and silent about another. A passing syntax check cannot be assigned the likelihood of successful reviewer resumption. We need an observation procedure whose result actually bears on the declared state, with its sampling, limitations and independence explained.
From the current belief and B, the machine constructs predictions of states under a proposed policy: Q(s|π). Through A it predicts observations: Q(o|π). Here π must identify the interpreted design and its relevant continuation, not just the mission name. Two designs for the same mission can predict different outcomes. If the code takes only a mission ID where it needs that distinction, the missing information cannot be repaired by a better score downstream.
Preferences, C, must concern the same outcomes that Q predicts. If C describes terminal dispositions while Q predicts document features, a justified connection is needed. A constant adapter that ignores the predicted features cannot demonstrate that connection. Nor should we invent a preference for flattering evidence: the existence of a communicable account can matter while its content must remain free to report failure.
We may be uncertain about the situation and also about the model itself. Perhaps the handoff is incomplete; perhaps our assumption that a certain review procedure detects incompleteness is wrong. The latter uncertainty concerns model parameters, often written θ. Predicting how an observation would change beliefs about θ requires compatible parameter priors, likelihoods and posteriors. Normalizing a vector of accumulated counts is not, by itself, constructing that whole uncertainty model.
The proposed foundation therefore includes more than allocating rows: sound probability carriers, current belief, action-conditioned dynamics, observation authority, policy-conditioned prediction and parameter learning. Some corresponding mathematical modules exist. The accepted checklist leaves their real producer-to-consumer connections open. This post does not update their deployment status.
We should be able to tell the handoff story twice: once where the work helps, and once where it produces a polished but misleading document. The proposed state, observations and predictions must distinguish them for reasons grounded in the problem. We must also explain what the machine does when evidence is unavailable, rather than filling a missing row with convenient certainty or a silent uniform distribution.
The unresolved questions are specific: Does the seven-status carrier express these differences? What makes a registry transition informative about them? Who can make the independent observation? How does the chosen design enter the predictor? Which parameter uncertainty could further work reduce? Until these questions have coherent answers, the first implementation target is not settled. The missing-ID report identifies where to look; it does not choose the model.
This account follows checklist WM-01–07, R1–R4 and join-2. Its concrete pattern sources are futon3/library/agent/handoff-preserves-context.flexiarg and agent/state-is-hypothesis.flexiarg. The model obligations are explicit in futon2/holes/labs/wm-contract/SPEC-fundamentals-build-2026-09-12.md, especially its common acceptance and unresolved-definition sections. The mission-ID diagnosis is claude-20's retained P1 proposal, not an independently reproduced result here. No numerical likelihood, mission-state mapping or construction commission is adopted by this narrative.
Read this walkthrough’s flexiargs · Download the independent collection.
Reference: accepted-in-substance checklist, revision 4 at p4ng b2c7d1d. The checklist remains a historical snapshot of its review; these narratives do not change its obligations.