E07 — Cross-paper promises and historical evidence

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

Cross-paper promises refer to particular delivered sections and historical artifacts. A later correction does not retroactively change what an earlier reader saw.

Governing checklist snapshot

E07 — Cross-paper promises and historical evidence. PARTIAL: companion referent ruling exists. Pin actual delivered formal/experimental sections; locate or explicitly dispose of missing historical artifacts, correct stale proof counts and unsupported validation wording, including the still-stale fundamentals table generated from the September 5 census. The fetched PLoP snapshot claimed two sorry declarations while the September 15 audit found nine; claude-20 reports paper correction 7080b18, which is not retroactive correction of the retained page snapshot.

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

E07-1 — Resolve promises to exact sections

Pattern: wm-purpose-and-account/each-paper-claim-keeps-its-evidence-kind

Use the companion referent ruling and pin actual delivered formal and experimental sections. Produce source/page/version mappings for each promise, including generated tables and supporting certificates.

E07-2 — Recover or bound historical evidence

Pattern: wm-purpose-and-account/irrecoverable-history-stays-historical

Locate original artifacts where possible and label unavailable preimages, missing experiments and reconstructed accounts distinctly. New demonstrations receive new dates and scope; no synthetic replacement is historical recovery.

E07-3 — Recompute current source-backed statements

Pattern: wm-purpose-and-account/each-paper-claim-keeps-its-evidence-kind

Count the relevant current formal obligations at a pinned source and reconcile generated fundamentals against its real data revision. Preserve the historical two-versus-nine sorry discrepancy as dated evidence, not an eternal current count.

E07-4 — Correct publication with provenance

Pattern: wm-purpose-and-account/irrecoverable-history-stays-historical

Publish reviewed corrections and retain old snapshots, supersession and still-open promises. Verify the delivered pages and table inputs; explicit disposal of an unavailable historical claim must not delete the underlying capability requirement.

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 fetched page said two sorries; later source inspection found nine and another commit corrected the paper. Preserve all three objects and dates. The new page cannot be cited as proof that the old claim was true.

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 stale generated census, wrong companion destination, synthetic missing preimage, proof count without source pin and unpublished correction treated as delivered.

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

E06 · E10 · WM-01

Current counts require fresh inspection when implemented. This design does not repeat a historical count as today’s state.

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.