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.
A run is not qualifying because it ends, produces a certificate, or exercises a complicated route. Joe's September 12 completion rule requires every required node to be defined, validated and working, provably, together with the required connections. The run must therefore tell a coherent story about real work, and the validation must check that story at the specified meanings.
Return to the mission with the disputed handoff. Before executing anything, the run needs an authorized work target and an explicit criterion for success. “Improve the handoff” is too vague to support a qualifying claim. The account must explain what responsible continuation would mean and how an independent observer could distinguish it from a polished but misleading summary.
The participants, observation roles, input revision and admissible evidence must be known before later outcomes tempt us to reinterpret the task. This does not mean we can turn an arbitrary criterion into an acceptable one merely by preregistering it. The criterion must itself answer to the mission and controlling specification. Preregistration addresses some selection bias; it does not supply missing semantics.
We also need the actual initial belief, model, candidate policies, interpretation sources and preferences. If one is missing, a made-up replacement can support a demonstration of software plumbing but not the required run. Honest refusal is useful evidence that a boundary works. It is not evidence of successful use beyond that boundary.
The machine receives the real situation and constructs its predictions. It compares actual candidate designs or continuations at their declared scope. It selects using the required computation and retains the alternatives needed to understand that choice. In the handoff example, the record should show why inspecting the disputed evidence was preferred over merely restating the conclusion, if that is what it selected.
The chosen interpretation is enacted by identified actors. Guards, dependencies and relevant execution history must agree with the interpretation that was evaluated. A source-code reference proves which implementation is being discussed; serving identity and an invocation record establish whether that implementation actually ran. Neither alone establishes that it did the intended work.
An independent observation then concerns the resulting work at its exact occurrence and revision. The machine updates the appropriate beliefs or model state. Where a continuation is required, that updated information influences the next decision in the same recorded episode. A second timestamp is not automatically a meaningful second step. Effective depth and feedback need their actual branches and consumers.
The certificate should bind the facts just described: the commission, source and model identities, observations, selection, enactment, required node evidence and connections. Its validator must reject a record whose identities disagree, whose mandatory connection did not fire, or whose claim is unsupported. It must also positively validate a real record that meets the whole contract.
There are two distinct questions. Does the Lean computation establish the formal predicate for the supplied certificate? And does the certificate faithfully represent the actual run? A proof over a fabricated table can answer the first while failing the second. Conversely, an apparently successful real episode can lack evidence needed for formal validation. The build owes both sides and their correspondence.
A certificate whose answer is false can be entirely correct. It may identify a missing observation or unwitnessed connection. That is diagnostic success, not qualification. The same applies to a negative control: successfully rejecting a tampered record proves a particular detector works; it does not prove the untampered machine satisfies every other obligation.
Suppose the handoff was delivered, but the reviewer cannot access the evidence store. The observation is insufficient to establish the substantive criterion. The system should retain that limit, not count the review's acceptance of the insufficiency report as a successful categorical observation. If it substitutes the author's belief or the registry's complete flag, the certificate is now telling a different story.
Suppose instead the observer can inspect the record and finds the handoff sound, but the run used the transitional action scorer rather than cascade G. The work may have helped the mission. It still does not qualify as the specified War Machine run. That distinction avoids both denying useful work and overclaiming the system that produced it.
A third case is a correct dispatch and duplicate refusal with no full lifecycle evidence. The checklist already credits bounded R10 dispatch evidence. We should preserve that accomplishment while leaving the remaining assurance obligations open. Otherwise “nothing works” is as misleading as “the machine is complete.”
This post is a description of the required future episode, not authorization to execute it. Dispatch is currently held while these narratives are reviewed. Scheduler activation is an operator-controlled matter, and restoring cron is not a new prerequisite for an on-demand qualifying run. Earlier language that every click needed a fresh operator decision should not be used to invent a blanket permission barrier; authorization must be established from the actual commission and current instructions.
A future run plan must name the prerequisites it relies on and show that their required acceptance has happened. It cannot trade away a difficult node because the rest of the pipeline is ready. Nor can it hide a reported failure in another route: the relevance of that failure must be checked and assigned, rather than guessed either way.
Can we describe one complete episode without switching targets, models or observation meanings halfway through? Can we identify who supplies every assertion and who independently checks it? Can we explain how a false certificate differs from a qualifying one using the same predicate? Can the evidence establish both successful execution and the prediction-to-enactment connection? Can we name every required node in the run, rather than use the end result as a proxy for all of them?
This walkthrough elaborates E02–05, R9/R10/R16 and TRACE. Its completion authority is RULINGS-walkthrough-2026-09-12.md, Items 4 and 5, retained under futon2/holes/labs/wm-contract/. Revision 4's checklist records the current gaps. The handoff episode is an explanatory scenario; no qualifying run or certificate is claimed here.
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.