E01 — Machine-level validity, not just equation arithmetic

Authored design — 2026-09-15. Section 4. 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 model can satisfy every equation while distinguishing the wrong situations. Machine validity requires an argued connection from the real problem through interpreted patterns to computation.

Governing checklist snapshot

E01 — Machine-level validity, not just equation arithmetic. OPEN: show model inputs and policy semantics address the intended real work; bind implementation to those definitions. Finite fixtures and recorded tables alone cannot establish this.

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

E01-1 — State the decisive real-world distinction

Pattern: wm-prediction/meaning-before-carrier

Identify two situations the work must distinguish, who needs the result and what would contradict success. Produce task-grounded state/outcome meanings; an available seven-row table is not its own justification.

E01-2 — Explain the pattern response

Pattern: wm-pattern-design/pattern-before-operation

Read the actual pattern context, tension and rationale, then explain its task-specific interpretation and alternatives. Produce an applicability argument rather than rename code operations as patterns.

E01-3 — Trace meaning through the machine

Pattern: wm-prediction/meaning-before-carrier

Map the agreed distinctions through belief, A/B, Q, C, G and choice, identifying actual implementations and domain bridges. Produce a semantic correspondence account with explicit unsupported assumptions.

E01-4 — Challenge and validate the account

Pattern: wm-qualifying-run/certificate-and-world-must-meet

Use independent task evidence and distinguishing controls to test both model applicability and actual implementation binding. Retain limitations and revision authority; finite fixture arithmetic cannot establish empirical adequacy.

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 handoff file exists in both cases, but only one preserves the unresolved hypothesis needed by its receiver. A model that represents both as done can pass normalization tests and still be invalid for this task.

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: Use same-artifact-count/different-usefulness situations, a constant bridge, an irrelevant pattern and a correct formula over wrong inputs. Require actual binding as well as conceptual agreement.

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-01 · WM-02 · WM-03 · WM-04 · WM-05 · WM-06 · WM-10 · E08

Unresolved domain/criterion authority blocks dependent validity claims. Do not invent a proxy to make a run qualify.

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.