C.19:4 - Solution

Decide which lines remain worth exploring, which remain worth retaining without new probing, and which no longer warrant a place in the live pool. Use the pool’s intended contribution and horizon, the resources and opportunity window still available, and what keeping each line displaces. State the resulting treatment and the change that would make it worth reconsidering.

Judge readiness for exploitation separately. A line may warrant further research or cheap retention before it supports deployment or transfer. Conversely, neither missing readiness nor past expenditure justifies keeping it indefinitely. Retaining an archive record under C.18 need not keep the line active or fund another experiment.

C.19:4.1a - Causal data and causal-policy exploration hook

When exploration collects data for a causal claim, learns or evaluates a causal policy, or uses counterfactual replay as a reason to treat a live line, the pool-policy result stays within C.19 and cites C.28 for the causal-support conclusion.

Optional PoolPolicyResult.causalUseSpec?:

PoolPolicyResult.causalUseSpec?:
  causalUseQuestionRef?: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalSupportComponentRefs?: CausalSupportComponentRefs
  causalUseEvidenceDesignRef?
  offPolicyCausalEvaluationResultRef?
  causalUseSupportResultRef?: CausalUseSupportResultRef
  supportedUse
  unsupportedUse

Omit this tail when the pool treatment makes no causal claim and consumes no causal-support result. Include it when effect, counterfactual replay, causal-policy support, or causal evidence changes the treatment. The C.28 result remains evidence support; it does not authorize ranking, retirement, deployment, or graduation. C.19 makes the pool-treatment decision under its own policy.

Policy fields. EmitterPolicy is a context-local, versioned policy with canonical fields: { emitterPolicyId, name?, regimeKey ∈ {UCB, Thompson, BO-EI, GP-UCB, PES, InformationGain, …}, params, explore_share∈[0,1], temperature τ≥0, rebalance_period, wild_bet_quota≥0, graduationConditionRef?, assuranceResultRef?, epsilon_dominance ε, cell_capacity K, insertionPolicyRef, dedupThreshold, deduplicationBasisRef, deduplicationUnit }.

graduationConditionRef cites the direct domain or policy condition for moving a line into exploitation or extending an already supported use. assuranceResultRef is present only when satisfying that condition relies on one exact B.3 result for a named assurance use and bounded scope. Neither field is an assurance level. The pool policy separately states why active exploration or retention is worthwhile, what continuing commitments it needs, and what would defeat that basis. An exploration horizon may extend beyond the next local decision; it still needs a defensible prospective contribution and obtainable resources. emitterPolicyId is cited as emitterPolicyRef; the profile is not a U-kind, generation operator, staffing instruction, budget approval, or Work record.

Decision-subject clarification. Attribute any later choice to one declared DecisionSubject at explicit DecisionSubjectGranularity. Record measurement spaces and admissible policies in the semantic-frame epistemes that state them. Use LOG to describe lenses and policies; that description does not enact a choice.

EmitterPolicy use. The canonical profile and its assurance boundary are defined above. A C.18 generation or archive record cites it only when pool treatment, insertion, or deduplication actually uses that profile. The profile is not a staffing or budget instruction.

Use the ordinary default tokens defined in G.Core and G.5. The rules below explain their pool-policy consequences without defining a rival default family.

Decision-theory bridge. Use C.11 for theory-side choice among already-available options and for the meaning of ProbeBudget, ValueOfInformation, and ValueOfComputation. A pool-policy record may use those outputs as inputs to its treatment judgement. A probe’s lack of value for the next local choice does not by itself settle the value of longer-horizon exploration; that prospective contribution and its opportunity cost belong to the pool policy. A worthwhile research line need not become a prerequisite for the present decision.

Ordinary default references (if policy is unspecified):

• Dominance: consume DefaultId.DominanceRegime from G.Core and G.5; in ordinary Q-front use this means {Q components} with ConstraintFit=pass as eligibility gate.
• Tie-breakers: the current policy may use a Novelty coordinate, DeltaDiversity_P/ΔDiversity_P, Surprise, or Illumination only when it names that tie-breaker. It need not fabricate results for optional tie-breakers it does not use.
  • For Novelty, cite each bearer’s exact coordinate-result episteme: a complete C.16 measurement result for a measured value, or a C.2.1 ascription when the declared rule permits a non-measurement reading. Before comparing bearers, confirm compatible Novelty Characteristic and Scale editions, corpus/reference set and inclusion rule, similarity Method and encoder/model editions, ClaimScope, window, uncertainty, and evidence.
  • For Surprise, cite the exact coordinate result and its generative-model and training-basis editions, Scale, ClaimScope, window, uncertainty, and evidence.
  • For DeltaDiversity_P, cite the retained set, candidate, measurement-policy and Scale editions, descriptor or distance basis, window, evidence, and resulting marginal reading.
  • Illumination remains telemetry over Diversity_P unless the named policy explicitly promotes it. A promoted use still cites the report and its measurement basis. The words Novelty, Surprise, and diversity alone are not executable policy inputs.
• Archive: K=1, ε=0, deduplication in CharacteristicSpace.
• Policy family: one uncertainty-aware explore policy family with one declared regime key and explicit change triggers; UCB-class with moderate temperature and explore_share ≈ 0.3–0.5 is one didactic starter profile, not the semantic default family.
• Provenance (minimum): record DescriptorMapRef.edition, DistanceDefRef.edition, DHCMethodRef.edition, emitterPolicyRef, insertionPolicyRef, scalar dedupThreshold, deduplicationBasisRef, deduplicationUnit, timeWindow, and seeds.

Use-value and declared-Q boundary. C.16.Q is the pattern for the selector-context meaning of use-value and its Objective form. When use-value participates in the current Q, declare QS.UseValue as an objective head in that exact Q and cite the current Q/comparator basis. When it does not participate in the current Q, keep the use-value criterion explicitly outside Q as a declared side condition or tie-breaker. A pool-policy record may use either declared position but cannot silently promote use-value into Q or construct the Q model.

Scalarization lenses (policy‑level). A lens J_ℓ declares: (a) hard eligibility conditions (e.g., ConstraintFit=pass), (b) soft aggregation (weights or curves), (c) trust policy (how any applicable assurance result and any declared CL discount enter). Conformance. A pool-policy record MUST name the lens used to pick from a frontier; scalarized rankings MUST NOT be presented as “the frontier”; the lens id MUST be recorded in provenance of each selection.

Promotion rules (policy).

• Tie-breaks. Use only the constituted and compatible results named by the current policy. Promotion of Surprise or Illumination into the dominance set MUST be declared by lens or policy id and captured in provenance.
• Graduation. A candidate line or pool member moves from Explore to Exploit only when eligibility holds and the direct condition cited by graduationConditionRef is satisfied. When that condition relies on assurance, assuranceResultRef cites the exact B.3 result whose named use and bounded scope support the judgement. An optional profile may supply evidence; neither the profile nor a label graduates the line.
• Continue, retain, narrow or sunset. At rebalance_period, judge the line’s prospective exploration or stepping-stone contribution against the remaining opportunity, obtainable resources, retention burden and displaced lines. Keep active exploration only while that commitment is warranted; cheaper retention may remain worthwhile without new probing. Narrow, pivot or sunset when the applicable continuation basis no longer warrants the current treatment. An unsatisfied graduation condition blocks the use it governs, not continuation by itself. A defeated continuation basis can justify retirement even if much has already been spent. The optional profile remains evidence, not the treated object. Policy logic is not generation or work. In one C.19 use, compute and record a treatment over an already identified live pool. It does not recompute a C.18 front or archive, update a generator, seed a candidate, constitute dated U.Work, create or classify a local system-role kind, create or change an assignment occurrence or its state, establish responsibility, authority, or permission, approve a budget or plan, or authorize enactment. At enactment, recover only the branches that independently obtain; send unresolved claim-bearing “role” wording through E.10.ROLE.

Pool-policy pass (per rebalance_period).

1. Read the current C.18 archive/front reference and its replay boundary; do not recompute either object inside C.19.
2. Record the governing lens and desired policy values, such as explore_share, emitter-profile preference, wild_bet_quota, or an admitted heterogeneity constraint. These are policy values, not generation actions.
3. Apply the conditions for the proposed treatment. For exploitation or a wider supported use, apply eligibility and graduationConditionRef, citing the bounded B.3 result when assurance is needed. For exploration or retention, assess the continuation basis and the whole pool’s competing commitments. Choose exactly one currentTreatment from widen | keep_frontier | narrow_to_subset | sunset_line and state whether the retained line warrants active probing or only lower-burden retention.
4. If that judgement requires fresh candidates, a changed emitter mix or temperature, archive insertion, or front recomputation, set nextQuestionPatternLocator = C.18 and pass only the desired emitter profile, quota or constraint, and the exact generation/archive/front reason. Apply C.18 to decide and record the generation, archive, and front operations.
5. If carrying out the treatment requires dated implementation, planning, staffing, or budget use, pass the policy record to the A.15 family; the policy record itself grants none of them.
6. Emit one PoolPolicyResult with livePool, governingLens, currentTreatment, changeTrigger, and any inputs required by the next subject pattern. The result may justify keeping, narrowing, graduating, or sunsetting a line without taking over the named next subject pattern’s operation.

Named lenses (heuristics; policy‑level, not norms) The following lens profiles are illustrative heuristics. Practitioners MAY reuse or modify them; they are not normative.

• Frontier‑sweeper — maintain attention on the full front; promote only when the direct graduation condition holds.
• Barbell — enforce explore_share ≥ θ with a wild_bet_quota; otherwise exploit top‑trust region.
• Spike‑first — pick highest Use‑Value subject to ConstraintFit=pass and a small Cost‑to‑Probe cap.
• Safety‑first — minimize SafetyRisk subject to Use‑Value ≥ θ and ConstraintFit=pass.
• Platform‑option — maximize Option‑Value under probe cost bounds.
• Pilot-then-scale — optimize Use-Value on the declared pilot scope. Set currentTreatment = widen only when assuranceResultRef cites the exact B.3 assurance result whose supported scope includes the proposed wider pool, and changeTrigger names the satisfied assurance condition and that newly supported scope; otherwise keep the pilot scope.
• Heterogeneity-first (illustrative profile). Use only when the applicable policy already admits a heterogeneity constraint or sampler policy. The applicable policy may declare a FamilyCoverage or MinInterFamilyDistance gate, a family or subfamily quota, or a diversity-promoting sampler; no universal k, δ_family, quota vector, sampler class, DPP rule, or max-min rule is supplied here. Record only the admitted policy values and ids actually used. Conformance (lens recording). A pool-policy record that uses a lens MUST record its lens id alongside emitterPolicyRef. (This restates and localizes C19-3.)

C.19:4.1 - Explicit pool-policy result

Canonical record vocabulary. A serialized PoolPolicyResult uses the field governingLens and exactly one currentTreatment token from widen | keep_frontier | narrow_to_subset | sunset_line. Reader prose may say widen, keep the frontier, narrow to a subset, or sunset a line, but those phrases are labels, not alternate serialized values. Do not use lens as a second field name.

At the end of a C.19 use, write one explicit pool-policy record rather than one atmospheric statement that exploration will continue somehow.

That result should state:

• the still-live pool, frontier, or family scope under governance now;
• the governing lens id or policy state;
• currentTreatment, chosen from widen | keep_frontier | narrow_to_subset | sunset_line;
• the event or threshold that would justify changing that treatment next.

A compact result may therefore state, for example:

• livePool = frontier_F
• governingLens = barbell_policy_v2
• currentTreatment = keep_frontier
• changeTrigger = graduation_condition_v3 is satisfied for one retained line

or, for one narrower family region:

• livePool = family_region_beta
• governingLens = heterogeneity_first
• currentTreatment = narrow_to_subset
• changeTrigger = quota satisfaction plus a compatible cited C.17 Novelty coordinate result clearing novelty_floor_policy_v2

Those fields define the result: live pool, governing lens, current treatment, and change trigger.

C.19:4.2 - Closure rule over the live pool

A C.19 pass may close only when one explicit pool and one explicit next treatment are both visible.

• Close as widen when wider exploration is warranted under the pool’s contribution, horizon and resource conditions. If widening also asserts a wider supported use, satisfy that use’s graduation and assurance conditions.
• Close as keep_frontier when keeping the live lines is warranted under the current policy. A line retained for later reconsideration need not receive a new probe.
• Close as narrow_to_subset when the continuation basis warrants a smaller internal live set, without pretending that one scalar winner has already been chosen.
• Close as sunset_line when a line’s prospective contribution, feasible continuation or retention no longer warrants its burden under the pool policy. Failure to graduate is not enough. Its archived result may still be retained under C.18 when that separate retention remains useful.

When the question has stopped being pool policy, finish the pool-policy result and use the exact handoff in C.19:4.4; the next pattern is recorded outside currentTreatment.

One internal retained subset here is still one pool-treatment result. It is not yet a declared Shortlist or RankedShortlist, and it has no ShortlistId merely by being retained. When a downstream use needs declaration or audience availability, use C.19:4.4.

If the result still cannot say which pool remains live, which lens and policy apply, and which event would justify changing the treatment, it is still unfinished pool policy rather than one finished C.19 result.

C.19:4.3 - Minimal pool-policy record

The smallest useful C.19 record usually states:

• livePool = ...
• governingLens = ...
• currentTreatment = widen | keep_frontier | narrow_to_subset | sunset_line
• changeTrigger = ...
• nextQuestionPatternLocator? = ... only when the question is no longer pool policy
• one or more native direct-owner reference fields only when an already constituted result or claim supports the treatment; retain the field name, kind, identity, claim episteme when applicable, and subject-pattern locator supplied by that owner—for example the A.2.2 capabilityHolderRef and capabilityStatementRef; an information-gain or articulated-endpoint use keeps the ref name and kind defined by its own direct owner—rather than replacing them with one C.19 signal or cue
• a10RelianceRef? = ... only when the pool treatment actually relies on one evidence-bearing or source-bearing claim; the cited A.10 account keeps the exact relied-on claim, bounded pool-treatment use, evidence-provenance path, window, and RelianceDisposition
• competenceModelRef? = ... only when it cites one exact model episteme used by the pool policy; that model is neither the capability, the owner-defined result, nor proof that the treatment may rely on either
• goalSpaceExpansionPolicyRef? = ... only when one independently declared archive or curriculum expansion policy governs goal- or task-space growth
• assuranceResultRef? = ... when graduation, scaling, or widening relies on one exact B.3 assurance result and its bounded supported scope
• whyNotLocalChoice = ... when the result might otherwise be mistaken for C.11

An admissible short record may therefore read:

livePool = frontier_F
governingLens = barbell_policy_v2
currentTreatment = keep_frontier
changeTrigger = graduation_condition_v3 is satisfied for one retained line
whyNotLocalChoice = several family regions remain live

When currentTreatment = narrow_to_subset, livePool still names one internal retained subset or one live pool subset. It does not yet mint one public Shortlist, one public RankedShortlist, or one ShortlistId. If selector-facing result declaration is now required, the admissible C.19 record leaves currentTreatment as the last pool treatment and fills nextQuestionPatternLocator = G.5, with the reason that result declaration rather than pool policy is now current.

Goal and task space growth is one pool-policy doctrine over the archive or curriculum side. When autotelic or capability-discovery pressure is active, cite goalSpaceExpansionPolicyRef only for an independently declared policy. Retain every supporting information-acquisition, capability, novelty, objective, articulated-endpoint, or other result or claim through its native direct-owner reference and kind. Add a10RelianceRef only for an evidence-bearing or source-bearing claim on which this treatment actually relies. Use competenceModelRef only for one exact model episteme, never as an alternative name for the capability, result, or reliance account. These inputs may support widen, keep_frontier, narrow_to_subset, or sunset_line; none becomes a generic signal or cue, default Q, dominance coordinate, probe choice, or selector-facing shortlist by entering the record.

If the record does not already state which pool remains live, which lens and policy apply, and what would change that treatment next, it is still one unfinished C.19 result.

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.

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

C.19:4.3b - Cultural and style live pools

Use the same minimal pool-policy record for cultural or style live pools when the current question is how several style, tradition, method-family, work-family, canon, scene, or technique variants remain live under one lens.

PoolPolicyResult:
  livePool:
  governingLens:
  currentTreatment:
  changeTrigger:
  termBridgeRefs?:
  nextQuestionPatternLocator?:

The record states pool treatment only. If a label is unstable across communities, first recover its exact source-local meanings through F.17 and use F.18 for naming. Include termBridgeRefs only for an actual F.9 relation between exact sense cells. That reference identifies the sense relation; it does not by itself support this pool treatment. Any claim that relies on the Bridge for the treatment stays separate from PoolPolicyResult: state the named use, direction, correspondence rule, and tolerated loss in a C.2.1 claim, and establish the current A.10 or B.3 reliance required by F.18. If the question becomes the cultural-evolution case, finish the pool-policy result and set nextQuestionPatternLocator = C.36. For result declaration, audience availability, or currentness, use the exact exit in C.19:4.4 rather than extending the pool-policy record.

C.19:4.4 - Exit from pool treatment

When fresh candidates, a changed emitter mix or temperature, archive insertion, or front recomputation are current, use C.18 with the desired policy values and exact reason as the pool-policy pass requires. When one evaluation suffices to answer whether one bearer or version should improve, use the applicable object evaluation, with E.22 when its framing is needed. When the object version will be improved through repeated passes under a declared evaluation, use E.23. For either exit, pass the exact bearer or version, objective or criterion, evidence, and pool-policy reason that made improvement current. A C.19 treatment is neither a generation operation nor an improvement result.

An internal subset retained by narrow_to_subset is still the live pool named by one C.19 policy record. It is not a public Shortlist, RankedShortlist, or ShortlistId-bearing selector artefact, and no public selector artefact is emitted by this pool-policy use. Front and Archive retain their C.18 meanings; a scalarized pick does not rename either one.

When the retained set must be declared for downstream comparison, registry use, or another selector-facing use, finish the pool-policy result and pass G.5 the exact declared source set, lens or policy id, eligibility conditions, dominance set, tie-breakers, promotion policy, and provenance pins. Use G.5 to declare the selected-set result and any stable public shortlist identity required by a named use. The C.19 record supplies only the preceding pool treatment and the reason result declaration is now current. If actual audience availability is also current, use E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence and availability.

When the live question becomes which option to choose, finish the pool-policy result and pass the fixed option set and comparison basis to C.11; a C.19 subset is not a ChoiceResult. When the question becomes enactment or performed work, use C.24 and the A.15 family. Resource bounds, CostToProbe, ValueOfInformation, ValueOfComputation, explore_share, and the direct graduation condition may explain a pool treatment, but they establish no budget, plan, Work occurrence, local system-role kind, separate System-classification judgment, assignment occurrence or state, responsibility, authority, permission, or enactment. Recover each needed fact independently, and send unresolved claim-bearing “role” wording through E.10.ROLE. When edition, source, descriptor, policy, or evidence currentness becomes the live question, use G.11; a change trigger in C.19 does not itself perform refresh or create a refreshed edition.

The practical handoff is therefore small: preserve the exact C.18 archive or front reference, the C.19 live-pool treatment and change trigger, and the evidence needed by the named next pattern. Do not duplicate selector-result declaration, publication availability, choice, work, or refresh semantics inside C.19.