R2 observation

Authored design — 2026-09-15. Section 3. 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

Observation earns authority by what was independently inspected and when, not by fitting a prediction. R2 carries that authority all the way into updating and learning.

Governing checklist snapshot

R2 observation. PARTIAL: independent observed authority, currency, complete observation-to-update/learn joins. WM-04. Built evidence: Structured observations and retained update envelopes

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

R2-1 — Declare what can be observed

Pattern: wm-prediction/observation-can-disagree

Take WM-04’s authorized observer, criterion, entity and time boundary. Keep the observer blind to posterior and disposition where required. Produce an observation request whose literal evidence can contradict the prediction.

R2-2 — Acquire and review the exact finding

Pattern: wm-prediction/observation-can-disagree

Retain the admitted source bytes, occurrence and cutoff, observation proposal and distinct exact-subject review. Produce an accepted finding or explicit insufficiency; an independence flag without provenance is not independent acquisition.

R2-3 — Preserve missingness and eligibility

Pattern: wm-prediction/unobserved-is-not-zero

Keep categorical labels separate from ambiguous, conflicting and insufficient findings. Produce denominators and eligibility decisions so unobserved rows are not interpreted as zero-frequency cells or supplied invented mass.

R2-4 — Deliver to update and learning

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

Pass eligible observations with their identity to R3 and R17/WM-07 consumers. Record every admission/rejection and prevent recounting. Preserve noncategorical findings for follow-on acquisition without feeding them as labels.

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 reviewer accepts that a handoff lacks sufficient criterion evidence. That is an accepted insufficiency finding. R2 retains it and requests further observation; it must not add an addressed count simply because the review itself passed.

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 leaked posterior, wrong reviewed subject, late evidence, duplicated observations and insufficiency-as-label. Verify both consumer admission and explicit rejection paths.

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-04 · R3 · R17 · WM-07 · E02

Acquisition authority, freshness windows and coverage requirements come from WM-04 and the actual task; this node does not invent them.

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.