zone.hyperreal.enterprises
War Machine · explanations before construction

R17-variants — R17', R17'', R17''', R16→R6

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

The catalogue lists several distinct learning claims. One successful pattern generation cannot discharge exploration controls, embedding reduction, genesis review and outcome-driven later selection.

Governing checklist snapshot

R17-variants — R17', R17'', R17''', R16→R6. UNRESOLVED: separately establish exploration-bonus/core separation controls (P095), exact embedding-proposal→BMR verdict (P096), genesis/admission/repeated review (P097–P099, WM-14), and live outcome→proposal→later selection (P100–P105); generation alone is not validated structure learning. Built evidence: P095–P105 separately inventory these claims: exploration bonus source, proposal/reduction machinery, missing connected genesis and outcome-to-proposal learning, and historical comparison claims

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

R17-variants-1 — Separate the claim families

Pattern: wm-connected-learning/proposal-earns-later-use

Create distinct subjects for P095 exploration/core separation, P096 embedding proposal/BMR, P097–P099 genesis/admission/repeated review, and P100–P105 outcome-to-proposal-to-choice. Preserve different evidence requirements; do not collapse them into one learning flag.

R17-variants-2 — Test exploration and embedding alternatives

Pattern: wm-connected-learning/proposal-earns-later-use

For P095 retain the unchanged core objective alongside the separately governed bonus. For P096 bind the exact embedding proposal to its BMR verdict. These are separate branches with separate control populations, not serial proof of one another.

R17-variants-3 — Review genesis and repeated relations

Pattern: cascades/edges-earn-permanence

Bind generated sources to admission and later independent reviews. For relation promotion retain distinct contexts and reviewer reasons; repeated use is evidence for review, not automatic permanence.

R17-variants-4 — Join live outcomes to later proposals

Pattern: wm-connected-learning/proposal-earns-later-use

Retain the actual R16 outcome, resulting proposal, independent verdict and later R6 selection for P100–P105. Preserve rejected proposals and later failures. Report each claim’s status independently.

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
R17-variants-1 R17-variants-2 requires-scope Separate P095–P105 claim identities govern this independently evidenced branch.
R17-variants-1 R17-variants-3 requires-scope Separate P095–P105 claim identities govern this independently evidenced branch.
R17-variants-1 R17-variants-4 requires-scope Separate P095–P105 claim identities govern this independently evidenced branch.
R17-variants-3 R17-variants-4 requires-result Later consumption of a generated pattern requires its actual admission; P095/P096 controls remain separate claims.
R17-variants-4 R17-variants-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: Use bonus-off/core-invariant controls, wrong embedding hashes, absent independent review, repeated-context inflation and later-choice mismatch. Retain separate results for all four claim groups.

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

An embedding proposal is accepted, but no later selection reads it. P096 may have a bounded verdict while P100–P105 remain missing. A promoted edge used repeatedly in one copied context does not establish cross-context usefulness.

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 bonus-off/core-invariant controls, wrong embedding hashes, absent independent review, repeated-context inflation and later-choice mismatch. Retain separate results for all four claim groups.

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

R17 · R16 · R6 · WM-14 · E06

Exact P095–P105 source scope comes from the pinned completion inventory. No generation, promotion or new bonus law is authorized here.

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.

cascades/edges-earn-permanence
@flexiarg cascades/edges-earn-permanence
@title Edges Earn Permanence
@sigils [🪙/功]
@keywords cascade, promotion, demand-side, use-receipt, review, declared, derived, bridge, evidence
@audience knowledge-base designers, agent-system builders
@tone design
@factor Discernment (paññā)
@provenance M-apm-demonstration W.70; whitepaper-v3 §6 (demand-side memory); W.24 attach-then-review economy
@why no problem-corpus source matched (@holds-at absent; holds-token and id-text searches over every library/problems node -- legacy 6, L5 dossier 20 incl. TRACE, L5 record/ruling 6 -- found no match). Negative claim per the committed check futon2 holes labs library-loop runs l6_no_source_check.py, receipt runs/L6-no-source-check.edn. Rationale not invented (L6 rationale-backfill, zai-1, 2026-09-05)
@how own mechanism: A derived edge becomes a declared edge by the same economy as everything else durable: evidence of use, then judged review. Receipt every derived edge that feeds a dispatch; edges accumulating use-receipts become promotion candidates for the declared skeleton. (source: this pattern's ! conclusion line; L6 rationale-backfill, zai-1, 2026-09-05)

! conclusion:
  A derived edge becomes a declared edge by the same economy as everything else durable:
  evidence of use, then judged review. Receipt every derived edge that feeds a dispatch;
  edges accumulating use-receipts become promotion candidates for the declared skeleton.

  + context: Declared and derived cascade layers coexist (cascades/declared-skeleton,
    cascades/on-the-fly-cascade) and something must govern movement between them — neither
    editorial fiat (skeleton rots into a wall chart) nor automatic accretion (skeleton bloats
    into noise).

  + IF:
      A derived edge keeps reappearing in used slices across distinct problems and contexts.

  + HOWEVER:
      Use is evidence, not proof: the reviewer must still judge whether the relation
      generalizes beyond the contexts that used it, with power to reject — a rejected candidate
      simply remains derivable. And the reviewer must be a seat that acts as itself
      (reviewer-must-act), not a name passed along.

  + THEN:
      Log slice edges into dispatch receipts (the eligibility-provenance idiom); periodically
      collect edges above a use threshold as a promotion manifest; review with reasons;
      declare the approved edges in the pattern files with their becauses.

  + BECAUSE:
      This is the demand-side principle — kept because used — applied to structure instead of
      content, and it makes the cascade grow exactly as fast as its usefulness is demonstrated.
      The store's first promotion round showed the alternative failure: judged-in-isolation
      attachments produced high per-item fit and zero connective structure.

  + NEXT-STEPS:
    next[Implement the use-receipts FIRST, before any declared edges or derivation engine.]
    next[Run several cycles; if receipts are mostly one-shot noise, this pattern is falsified.]
    next[Promote by manifest and review, never by threshold alone.]