#Explore-Exploit Live-Pool Governor

C.19 · Cluster C.IV - Composite & Macro-Scale · Stable · C-pattern · Normative · Part C - Kernel Extension Specifications

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: C-pattern Status: Stable Normativity: Normative

Plain-name. Explore-exploit governor.

Intent. State and test exploration and exploitation policy over still-live candidate pools so frontier treatment, graduation, narrowing, and sunset treatment stay explicit and auditable. A C.19 result governs pool treatment only; C.19:4.4 routes a question that has moved to another operation or result.

Export relation. C.19 defines no generation operation. Use it to state and test live-pool treatment records over candidate pools, fronts, archive regions, family regions, and cultural live pools.

Depends on. C.18 for archive and front stewardship, C.16 for characteristic and measurement claims, A.19.CPM and A.19.SelectorMechanism for comparison and selection kernels, B.3 for assurance-sensitive confidence claims, and G.5 for ordinary selector and default tokens.

Coordinates with. E.10.LRN only while learning-family wording hides an input's exact identity; C.17 for compatible characteristic results; C.11.CRC for a missing finite configuration-relative comparison; and G.9 for parity comparison. C.19:4.4 names the exact next-pattern coordination when the live question changes.

• several candidate lines, family regions, or frontier segments remain live under one declared exploration and exploitation policy and the question is now policy over that pool rather than one more local choice result
• the next result should say whether to widen, keep the frontier, narrow to a subset, or sunset a line
• if the question is no longer pool policy, the C.19 use closes by naming the next subject pattern and the reason that pattern now applies
• the governing lens or policy state must be explicit rather than inferred from vague exploration language

#Keywords

• explore-exploit
• already-live candidate pool
• pool-policy result
• governing lens
• widen
• keep frontier
• narrow to subset
• sunset line
• change trigger
• selector-facing declaration
• publication face
• publication occurrence
• audience availability.

#Relations

#Content

#Use this when

• several candidate lines, family regions, or frontier segments remain live under one declared exploration and exploitation policy and the question is now policy over that pool rather than one more local choice result
• the next result should say whether to widen, keep the frontier, narrow to a subset, or sunset a line
• if the question is no longer pool policy, the C.19 use closes by naming the next subject pattern and the reason that pattern now applies
• the governing lens or policy state must be explicit rather than inferred from vague exploration language

If a proposed pool-policy premise is expressed as learning progress, information gain, novelty, or an articulated former cue, recover its exact result owner first. Use E.10.LRN only while learning wording hides that result, A.10 only when an evidence-bearing or source-bearing claim is actually relied on, C.17 or C.18 only when characterization or possibility-space change is current, C.11.CRC only when a finite configuration-relative comparison is missing, and C.11 for local option or probe choice. Stop before C.19 unless the remaining question is policy over a still-live pool.

#What goes wrong if missed

• scalarized top-1 picks are mislabeled as "the frontier", so it becomes unclear whether the result names one lens-ranked winner or the admissible live set
• exploration continues without one named pool, one named governing lens, or one explicit next treatment
• local option choice, pool policy, enactment planning, selector-result declaration, and publication availability collapse into one blurred result

#What this buys

• one explicit pool-governance result for exploration, graduation, narrowing, and sunset treatment
• one explicit link from lens or policy state to the next pool-side treatment
• one repeatable way to preserve heterogeneity and frontier discipline without forcing inadmissible totalization

#First-minute questions

• Which still-live pool, frontier segment, or family region is actually under governance now?
• Which lens or policy state is governing it?
• Is the next admissible pool treatment to widen, keep the frontier, narrow to a subset, or sunset a line?
• If none of those treatments is current, which subject pattern now applies, and why is the question no longer pool policy?
• What justifies active exploration or cheaper retention now, and what change would end that justification? Readiness for exploitation is a separate question.

#First output

For loop-engineering practice, use this first output only when the live question is pool policy over still-live candidates such as loops, harnesses, workflows, method families, or framework seeds. A C.19 record may say that the pool should widen, keep its frontier, narrow to an internal subset, or sunset a line under a declared lens. If the question leaves pool policy, finish this record and use the handoff in C.19:4.4.

The first useful output is one explicit pool-policy record that names the live pool, governingLens, one currentTreatment token from the closed set widen | keep_frontier | narrow_to_subset | sunset_line, and the exact event that would justify changing that treatment next. If another question has become current, set nextQuestionPatternLocator from C.19:4.4 instead of inventing another currentTreatment.

The word result in PoolPolicyResult means the stated conclusion of this pool-policy pass; it does not mint a universal result kind. The record and its inputs create neither an actual Problem nor a ProblematicForRelation, improvement-result or work-result identity, project Work or work parthood, ChoiceResult, public shortlist, work permission, nor refreshed edition. When a durable claim episteme about the pool treatment is needed, constitute that episteme separately under C.2.1 and keep its exact EntityOfConcern and claim content explicit.

That record states pool treatment only. Use C.19:4.4 for the next result rather than adding its fields or claims to PoolPolicyResult. If the output still cannot name the pool, governing lens, current treatment, and change trigger honestly, the current C.19 pass is unfinished.

#Problem frame

C.19 describes named, versioned policies and lenses for treating a still-live pool after C.18 generation, archive, or front records exist.

When C.11 has already made local choice among one fixed OptionSet explicit, C.19 begins where the question becomes policy over several still-live candidate lines, family regions, or frontier segments rather than one more local ChoiceResult record.

Immediate failure indicators for this pattern:

• the current pool-policy result cannot name the still-live candidate pool whose treatment it states
• the governing lens or policy state is missing
• the next pool-side treatment exists only as one vague promise to continue exploration later

If the live question is not treatment of a still-live pool, use the exact exit in C.19:4.4. C.19 begins or continues only while the pool-policy question is current.

#Problem

Ad-hoc exploration mixes ordinal and interval claims, silently scalarizes partial orders, and loses lens or policy provenance, undermining admissibility and reproducibility.

#Forces

• Readiness vs. continuation — exploitation needs its direct qualification, while active exploration and cheaper retention need their own prospective contribution and affordable commitments. None of these judgements follows from the others.
• Heterogeneity vs. focus — fairness quotas by family vs. depth on proven lines.
• Lens expressiveness vs. audit — scalarised choices must not be called 'the frontier' and MUST record lens ids.

#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.

#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](/generated/patterns/G.5). The rules below explain their pool-policy consequences without defining a rival default family.

Decision-theory bridge. Use [C.11](/generated/patterns/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](/generated/patterns/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](/generated/patterns/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](/generated/patterns/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](/generated/patterns/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.)

#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.

#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.

#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 capabilityInstanceRef and its 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](/generated/patterns/C.19) record leaves currentTreatment as the last pool treatment and fills nextQuestionPatternLocator = [G.5](/generated/patterns/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](/generated/patterns/C.19) result.

#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 capability instance for diagnostic_agent_v4 is qualified for task region alpha, while its current statement 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
capabilityInstanceRef = diagnostic_agent_capability_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

capabilityInstanceRef retains the A.2.2 U.Capability identity; capabilityStatementRef retains its governed episteme identity; 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 = pool_policy_completed
currentTreatment = narrow_to_subset
changeTrigger = retained subset is explicit; pool policy is complete
nextQuestionPatternLocator = G.5 because selector-facing result declaration is now current
whyNotLocalChoice = pool governance is already complete

#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](/generated/patterns/F.17) and use [F.18](/generated/patterns/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](/generated/patterns/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.

#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.

#System grounding

A product-search or architecture-search team can keep several family regions alive even after one line looks best locally. keep_frontier under frontier_sweeper_v3 is warranted while those regions' prospective contribution and commitments fit the pool policy. Graduation is reconsidered when graduation_condition_v3 is satisfied; continued exploration or retention is reconsidered when its own basis changes. The team need not choose between premature exploitation and indefinite funded search.

#Episteme grounding

A SoTA pack often compares traditions that stay non-dominated for different reasons: one clears current evidence quality, one keeps broader transfer value, one preserves family coverage. The admissible C.19 result is then often keep_frontier or narrow_to_subset, not one fake scalar champion.

#Collective and contextual grounding

A regional or stakeholder-diverse pool may have to sunset one line while keeping others alive to preserve coverage, fairness quotas, or contextual fit. Use C.19 to state and test that pool-treatment decision only while the question is still about the live set. Once the result must become one local choice, one enactment plan, or one declared selected set, apply the pattern that defines and tests that result.

#Bias-Annotation

No global scalarisation of partial orders; ordinal scales excluded from arithmetic; all selections record lens id and policy id; notation and tool neutrality.

#Conformance Checklist

• C19-1 When a C.18 generation or archive record relies on a named C.19 EmitterPolicy, it SHALL cite that profile in emitterPolicyRef?. If the active insertion policy is not inherited, record it in insertionPolicyRef?. If the deduplication threshold is not inherited, record scalar dedupThreshold? together with its deduplicationBasisRef? and deduplicationUnit?; never encode that scalar as a reference. A record with no such policy dependence need not fabricate these fields.

• C19-2 The characteristic set and indicators used for dominance MUST be declared and eligibility conditions applied first. If use-value participates in current Q, the record cites the C.16.Q QS.UseValue objective head in that Q; otherwise it states that the criterion remains outside Q. (References to C.18 generator operators are descriptive only; LOG exports no Γ.)

• C19-3 If a lens is used, its id MUST be recorded; do not label scalarized top-1 as "frontier".

• C19-4 Promotion of Surprise or Illumination into dominance MUST be explicit in policy.

• C19-5 A pool-policy record creates no SystemRoleAssignmentStateRelation, system-role assignment, permission, plan, budget, or Work occurrence. When implementation follows, cite the independently obtaining context and scope, exact system-role-kind classification, assignment or assignment-state condition, and direct planning or Work pattern; none of those facts follows from the pool-policy record.

• C19-6 Each pool-treatment lens MUST document the pipeline Eligibility (ConstraintFit=pass) → Dominance (declared set) → Tie-breakers (declared). For every tie-breaker actually used, cite a constituted result with the compatible basis required above; unused optional tie-breakers need no result. Any promotion of Surprise or Illumination into the dominance set MUST be named by lens or policy id and recorded in provenance.

• C19-7 (pattern-change boundary). A project-local choice or revision of an EmitterPolicy, DescriptorMap, DistanceDef, sampler, quota, or δ_family threshold stays under C.19 and the decision or result that consumes it; it does not invoke E.15 merely because a profile changed. When the definition is changed in an existing FPF pattern edition, use E.15 to compare the exact predecessor and candidate, classify the actual effect, and repair dependent consumers. Use C.18/C.19 candidate generation only when several materially plausible definitions remain. No default heterogeneity quota or sampler is defined here. Keep the policy and card ids in the existing decision, change, or SCR result that actually needs them; create no separate authoring trace.

• C19-8 When a heterogeneity-first profile is used, provenance MUST name each admitted heterogeneity constraint and its governing policy id. If a family or subfamily quota applies, record the exact quota vector and family-definition id; if sampling applies, record the sampler class, seed when relevant, and sampler-policy id. Do not fabricate a default triad, quota, or sampler.

• C19-9 A PoolPolicyResult MUST identify livePool, governingLens, changeTrigger, and exactly one currentTreatment token from widen | keep_frontier | narrow_to_subset | sunset_line; lens and space-separated treatment spellings are not alternate record fields or values.

• C19-10 If the question under repair is local option choice, an enactment-facing plan, selector-facing result declaration, or publication availability, C.19 MUST name the applicable pattern rather than restate it: C.11, C.24, G.5, E.17, or E.24.PUB.

• C19-11 If goal- or task-space expansion, autotelic pressure, or capability-discovery support is used, the record MUST cite goalSpaceExpansionPolicyRef only when one independently declared policy governs the treatment; retain each supporting result or claim under its native direct-owner reference, kind, identity, claim episteme when applicable, and subject-pattern locator; add a10RelianceRef only for an evidence-bearing or source-bearing claim on which the pool treatment actually relies; and use competenceModelRef only for one exact model episteme. None of these inputs becomes a generic signal or cue, default dominance coordinate, probe choice, or selector result merely by supporting the treatment; any actual dominance promotion still requires the explicit lens or policy rule and provenance required above.

• C19-12 If exploration collects data for a causal claim, learns or evaluates a causal policy, or treats counterfactual replay as support, PoolPolicyResult.causalUseSpec? MUST carry the target rung, claim kind, available support-component refs, supported use, unsupported use, and the C.28 support-result ref when one is consumed.

• C19-13 A pool-policy record for still-live loop-engineering candidates—for example, loops, agent harnesses, workflows, or DPF seeds—names the pool, governing lens, current treatment, and change trigger. Fresh generation, archive work, or front recomputation uses C.18 as the pool-policy pass specifies. Any other next-result question uses the exact transfer in C.19:4.4; C.19 does not absorb improvement, declaration or publication, choice, Work, or refresh.

• C19-14 A pool-policy record, its evidence, and its treatment constitute neither an actual Problem nor ProblematicForRelation, improvement result, work result, project Work or parthood, ChoiceResult, public selected set, work permission, nor refreshed edition.

• C19-15 Graduation, scaling, or widening an already supported use MUST cite its direct graduationConditionRef. If that judgement relies on assurance, assuranceResultRef? cites the exact B.3 result and changeTrigger names the satisfied condition and bounded supported scope. Widening exploration, continuing a line, retaining it without new probing, or sunsetting it MUST follow the stated continuation basis, including its contribution, feasible commitments and opportunity cost. Failure to graduate alone supplies neither a retirement decision nor a reason for indefinite continuation. A policy threshold or label does not create an assurance result.

#Common Anti-Patterns and How to Avoid Them

• Using deployment readiness to settle research continuation. Judge active exploration and cheaper retention by their prospective contribution and remaining cost. Keep the actual qualification for deployment or transfer; past expenditure is not a reason to keep funding the line.

• Treating one scalarized top-1 as the frontier. Avoid by naming the governing lens and keeping the live frontier distinct from any lens-ranked pick.

• Running exploration without one explicit next treatment. Avoid by ending each pass with one explicit currentTreatment token: widen, keep_frontier, narrow_to_subset, or sunset_line. If the current question is no longer pool policy, name the next subject pattern instead of inventing another pool treatment.

• Letting Surprise or Illumination quietly become dominance criteria. Avoid by promoting them only through one declared lens or policy id and recording that promotion in provenance.

• Absorbing neighboring questions. Avoid by using the exact handoff values in C.19:4.4 instead of adding a neighboring result's fields or claims to PoolPolicyResult.

#Consequences

• the result states whether the pool is being widened, kept live, narrowed, or sunset; if the question leaves pool policy, the record names the next subject pattern separately
• active exploration, cheap retention and exploitation can receive different justified decisions; heterogeneity need not collapse into one scalar winner
• the cost is stricter provenance and the need to name lenses, policies, and change triggers explicitly

#Rationale

C.19 exists because pool governance is neither local choice nor execution. Once several candidate lines remain live, the key question is no longer which single option should survive now; it is how the pool should be governed next under one explicit lens or policy. That question needs its own explicit pool-policy result, otherwise frontier drift, silent scalarization, and policy amnesia return immediately.

• Post-2015 bandit and Bayesian-optimization practice treats explore and exploit policy as an explicit policy object, not as one hidden side effect of whichever candidate looked best first. The practical implication here is to emit one explicit pool treatment plus one change trigger, not one atmospheric frontier story.
• Contemporary frontier and quality-diversity practice also distinguishes the live frontier from any scalarized pick taken under one declared lens. The practical safeguard is to keep keep_frontier, narrow_to_subset, and sunset_line as visible alternatives rather than silently totalizing the pool.
• When an applicable policy independently admits coverage or heterogeneity pressure, keep that pressure explicit until one declared reason justifies retirement or use of a different subject pattern. The practical implication is simple: sunset a line only when the current pool-policy result states the policy reason for retiring that line; name the next subject pattern only when the next question no longer concerns pool policy under C.19.

#SoTA-Echoing

Source-currentness boundary. The mutable arXiv sources below are pinned to exact editions; the journal QD source is pinned by DOI and publication record. Reopen this source-use judgement when a pinned arXiv record receives a newer version, the journal source is corrected, retracted, or materially superseded, or a proposal would promote a particular heterogeneity quota or sampler into a C.19 norm. G.11 is the pattern for that refresh. These sources inform policy pressures and pattern boundaries; none installs its algorithm, quota, or sampler as the default FPF method.

#Relations

C.27 temporal-claim relation.

• C.27 may flag: a temporal claim that changes exploration, exploitation, narrowing, widening, convergence speed, or search cadence in a way that changes admissible use.
• This pattern keeps: pool-policy result and explore and exploit governance, including keep_frontier, narrow_to_subset, and sunset_line.
• Non-admissible use: faster narrowing is not automatically a positive result; it may collapse exploration health, diversity, archive coverage, or frontier discovery.
• Exit: use C.19 for the pool-policy result; use C.27 only for the temporal-claim adequacy question when speed or change affects admissible use.

Builds on: C.18, C.16, A.19.CPM, A.19.SelectorMechanism, and B.3. Coordinates with: E.10.LRN only for unresolved learning-family wording; A.10 only for actual bounded reliance; C.22.PFR for actual Problem identity; C.18 for generation, Archive, Front, and possibility-space change; C.32.P2S, C.32, and C.35 for architecture-alternative carry-through and candidate admission; C.28 for causal-use support; C.17 and G.9 for evaluation and parity inputs; C.11.CRC only for a missing finite configuration-relative comparison; C.11 for local option or probe choice; and the other next-result patterns and transfer values named in C.19:4.4.

#C.19:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)