zone.hyperreal.enterprises
War Machine · explanations before construction

E09 — Staged capability-zone/native-currency scope reconciled

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 staged capability-zone result can be historically accepted while current demand or currency claims remain unresolved. Presentation must not promote, rebuild or discard it by implication.

Governing checklist snapshot

E09 — Staged capability-zone/native-currency scope reconciled. UNRESOLVED: retain historical S1.5 acceptance, staged paper status and remaining load/demand/currency claims separately. No automatic rebuild, promotion or exclusion by presentation.

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

E09-1 — Separate historical and current scope

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

Pin S1.5 acceptance, its actual object and limits, the staged paper presentation and the remaining load/demand/currency claims. Produce separate claim rows rather than a single capability-ready label.

E09-2 — Declare units and selection authority

Pattern: aif/currency-before-merge

Identify native quantities, their producers and permitted comparisons. Where lanes differ, require justified exchange authority or an explicitly authorized tuple selection rule. Do not normalize arbitrary scores until they look comparable.

E09-3 — Examine real demand and load evidence

Pattern: aif/currency-before-merge

Bind actual demand, supply, load and choice records to the scoped claims. Distinguish simulated inputs from observed demand and source mechanisms from effective consumer use. Retain constants and what their scales favor.

E09-4 — Reconcile acceptance and presentation

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

Obtain the scoped decision on what is accepted, staged or still required; bind it to paper claims and consumer obligations. Do not automatically rebuild a historical result or remove a required capability merely by changing the label.

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.

From To Relation Reason
E09-1 E09-2 requires-result Separated scope determines which currency and demand claims are still live.
E09-2 E09-3 requires-result Declared units constrain what comparisons observed evidence can justify.
E09-3 E09-4 requires-result Scoped evidence supports a reconciliation decision, not automatic promotion.
E09-4 E09-1 revision-feedback A failed distinguishing control or consumer mismatch reopens the original scope/meaning; retain the failed claim rather than weakening it. Relevant controls: Reject silent unit conversion, constant-score insertion, simulated-as-real demand, historical acceptance promoted to current deployment and removal of a promise through editorial staging.

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

Two native lanes enter one arena with incomparable units; one always wins because its values are numerically larger. A historical accepted component does not justify the merged score or supply an exchange rate.

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 silent unit conversion, constant-score insertion, simulated-as-real demand, historical acceptance promoted to current deployment and removal of a promise through editorial staging.

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-06 · WM-10 · E06 · E07 · E10

No blended G, conversion coefficient, expansion of capability scope or automatic rebuild is selected by this cascade.

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.

Existing pattern source snapshots

Reference text; historical examples and prescriptions retain the scope stated above.

aif/currency-before-merge
@flexiarg aif/currency-before-merge
@title Currency Before Merge
@keywords valuation, units, commensurability, exchange-rate, multi-objective, score
@audience aif implementers, scorer designers, futon developers
@tone technical
@style pattern
@references [aif/declare-the-conditioning aif/placeholder-is-load-bearing]

@see-also aif/expected-free-energy-scorecard
@why no matching problem dossier node (@holds-at absent; not among the twenty dossier nodes R1-R17, R20, TRACE). Negative claim per the committed check futon2 holes labs library-loop runs l3_no_dossier_check.py, receipt runs L3-no-dossier-check.edn (enumerates every aif pattern's @holds-at against the dossier node set extracted from PROBLEMS-*.md headings). Rationale not invented (L3 rationale-backfill pilot, zai-1, 2026-09-05)
@how own mechanism: Never sum value-signals from different lanes without an explicit exchange rate; a constant standing in for a missing exchange rate IS the smell. (source: this pattern's ! conclusion line; L3 rationale-backfill pilot, zai-1, 2026-09-05)
! conclusion: Never sum value-signals from different lanes without an explicit exchange rate; a constant standing in for a missing exchange rate IS the smell.

  + context: A system accumulates valuation lanes over time (an EFE blend, a wholeness score, a rollout ΔG, heuristic bonuses), and selection wants one number to rank by.

  + IF:
    You need candidates valued by different subsystems to compete in one arena.

  + HOWEVER:
    The lanes are in incommensurate units, and the cheap move — projecting everything into one linear sum at hand-set weights, or gluing unscored rows in with a constant — hides the incommensurability instead of resolving it. The weights silently absorb the units problem; the constants silently become behaviour.

  + THEN:
    Before any cross-lane merge, either establish a real exchange rate (a shared unit like nats, a fitted calibration with stated evidence) or keep the lanes separate and declare the selection rule over the tuple. Audit every constant in the arena: ask what it beats and what beats it.

  + BECAUSE:
    A merged score with no exchange rate optimizes an accident of scale, not a judgment; behaviour is then dominated by whichever lane happens to have the largest dispersion.

    + evidence: M-evaluate-policies (futon2, 2026-07-03): the WM blend flattened C/E/Π-slot terms into one sum — measured result: the epistemic pole had 0% decision influence over 674 ticks while high-dispersion analogical terms steered (47.9%/44.5% flip-rates); cascade rows entered at a 0.0 constant and never won (293/293). E4: every naive renormalisation just moved winners without warrant (11.4%–93.8%).

  + NEXT-STEPS:
    - Inventory each lane's unit and dispersion (within-decision dispersion, not corpus-wide).
    - Name the exchange rate or refuse the merge; record the decision as IF/HOWEVER/THEN/BECAUSE.
    - Add an invariant: every summand entering the merged score is persisted with it (no silent steering).