C.19:4.3a - Worked closure slice
Four short contrasts keep the closure law practical.
Several family regions remain live. When the point is to keep several lines active under one declared lens, the pool-policy result must not imply that one local choice has already been made:
livePool = frontier_F
governingLens = frontier_sweeper_v3
currentTreatment = keep_frontier
changeTrigger = one retained line satisfies graduation_condition_v3
whyNotLocalChoice = three family regions remain live
An exact capability claim supports pool treatment.
An A.2.2 statement about holder diagnostic_agent_v4 supports its qualified ability in task region alpha; it does not establish transfer into region beta. In this constructed case, a declared curriculum-expansion policy warrants keeping both regions live while beta’s prospective contribution and retention burden remain acceptable. That policy does not establish transfer. Because the pool treatment actually relies on the capability statement, the record cites its exact A.10 reliance account:
livePool = diagnosis_task_regions_{alpha,beta}
governingLens = curriculum_expansion_policy_v3
currentTreatment = keep_frontier
changeTrigger = beta obtains qualified transfer support, its opportunity window closes, or its continuation burden changes
capabilityHolderRef = diagnostic_agent_v4
capabilityStatementRef = capability_statement_CS-44
a10RelianceRef = A10_CS-44_keep-frontier_W8
goalSpaceExpansionPolicyRef = curriculum_expansion_policy_v3
whyNotLocalChoice = both regions remain live; no individual task or probe is selected
capabilityHolderRef identifies the holder System; capabilityStatementRef identifies the C.2.1 episteme asserting that System’s bounded ability; and a10RelianceRef qualifies only the stated bounded reliance. None is renamed as a signal or cue, entered into the declared dominance set, or emitted as a ChoiceResult.
The same missing beta qualification permits different continuation decisions.
Hold the alpha-only capability evidence fixed in these three hypothetical policy conditions. None supports deployment in beta.
| Continuation basis | Pool-policy result | What that result supports |
|---|---|---|
| An informative beta simulation fits the available qualified setup and this month’s allocation; its prospective contribution warrants the work it displaces. | keep_frontier, with active exploration of beta. | Keep both regions live. Use C.11 for the particular probe choice and the relevant planning and authority rules for actual work. The simulation has not yet been performed. |
| No new beta probe now warrants its cost, but keeping the existing result and lineage costs little and preserves a named later reuse. | keep_frontier, with beta retained for reconsideration and no new beta probe. | Preserve the stepping stone under the existing retention basis. Reconsider when the reuse opportunity or maintenance burden changes; the retention decision creates no study assignment. |
| Further beta work would displace a better-supported line’s use of the only available setup; its prospective contribution does not warrant that displacement, and no useful lower-burden live commitment remains. | sunset_line for beta. | End beta’s live-pool commitment. Keep an archived result only if its separate C.18 retention remains useful. Reopen if a feasible route or changed contribution warrants the cost. |
A compatible Novelty floor or quota may affect these judgements when the policy justifies it for this continuation use. Its failure is not a universal retirement rule, and the unsatisfied transfer condition is unchanged across all three cases.
For the third condition, the record can state:
livePool = family_region_beta
governingLens = curriculum_expansion_policy_v3
currentTreatment = sunset_line
changeTrigger = a feasible beta route or changed prospective contribution warrants its continuation cost
whyNotLocalChoice = other regions still remain live under the same pool policy
The pool has already been narrowed and the next question is selector-facing result declaration. When one internal retained subset is already explicit and the next question is to declare it for downstream use, close the pool-policy question by naming the applicable pattern instead of presenting that subset as though it were already one selector result:
livePool = retained_subset_{option_B, option_C}
governingLens = selection_preparation_policy_v2
currentTreatment = narrow_to_subset
changeTrigger = eligibility, comparison basis, or retention burden changes for option_B or option_C
nextQuestionPatternLocator = G.5 because selector-facing result declaration is now current
whyNotLocalChoice = the next use needs declaration of the retained set, not a choice among its members