#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. Govern exploration and exploitation policy over still-live candidate pools so frontier treatment, graduation, narrowing, and sunset treatment stay explicit, auditable, and stated as one pool-policy result without taking over local choice, enactment, or publication questions.

Export relation. C.19 does not export generation operators. It governs 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 and G.11 for selected-set publication and refresh.

Coordinates with. C.11 for local choice among already-available options, C.24 for enactment planning after choice, G.5 for selector-facing publication, C.17, and G.9.

• 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 governing 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.

#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 governing pattern and the reason that pattern now applies
• the governing lens or policy state must be explicit rather than inferred from vague exploration language

#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, and published shortlist semantics 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 governing pattern now applies, and why is the question no longer pool policy?
• What event or threshold would justify changing that treatment next?

#First output

For loop-engineering practice, use this first output only when the live question is pool policy over still-live loop, harness, workflow, method-family, or framework-seed candidates. C.19 may state that the pool should widen, keep its frontier, narrow to an internal subset, or sunset a line under a declared lens. It does not improve one object version, publish a selected set, choose one option, authorize work, or perform refresh; those exits go to E.23, G.5, C.11, the A.15 family, or G.11.

The first useful output is one explicit pool-policy record that names the live pool, governingLens, one currentTreatment token from widen | keep_frontier | narrow_to_subset | sunset_line, and the exact event that would justify changing that treatment next. If the current question has become local choice, enactment planning, selected-set publication, or refresh, the record names C.11, C.24, G.5, or G.11 as the next governing pattern 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 says how the pool is to be treated under the current exploration and exploitation policy. It does not replace one local C.11 choice record, one C.24 enactment plan, one G.5 published selector result, or any dated work occurrence. 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 provides named, versioned policies and lenses that govern still-live pool treatment 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 it is governing
• 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 question is still which single option should survive now, apply C.11. If the next artifact must already be one enactment-facing plan, apply C.24. If the retained set must be published for downstream consumption, apply G.5.

#Problem

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

#Forces

• Trust gates vs. discovery — graduation requires backstop confidence while maintaining explore_share. • 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

#Causal data and causal-policy exploration hook

When an exploration and exploitation policy collects data to support a causal claim, changes intervention budget, learns a causal policy, evaluates a policy from behavior-policy data or logging-policy data, or treats a counterfactual strategy as a candidate line, the pool-policy result keeps C.19 authority and cites C.28 for causal-use support.

Optional PoolPolicyResult.causalUseSpec?:

PoolPolicyResult.causalUseSpec? {
  causalUseQuestionRef?: U.CausalUseQuestion
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalEvidenceSupportBasis?: CausalEvidenceSupportBasis
  causalUseEvidenceDesignRef?
  offPolicyCausalEvaluationProfileRef?
  causalUseSupportRecordRef?: CausalUseSupportRecordRef
  causalUseSupportVerdict?: CausalUseSupportVerdict
  supportedUse: CausalUseSupportStatement
  unsupportedUse: CausalUseUnsupportedStatement
}

The causal-use support tail may be omitted only when the pool-policy result does not reach CausalUseActivation: it does not make, publish, rank, retire, deploy, or reuse a causal claim. If exploration or exploitation is justified by effect, counterfactual replay, causal policy support, or causal data collection, the support tail is present or the result is downgraded to a non-causal pool-policy reason.

What changes in practice: a frontier policy that explores "to learn what works", exploits a causal policy, or graduates a line because counterfactual replay looks better must declare the causal-use question, CausalUseClaimKind, causality-ladder rung, causal evidence support basis, and supported use and unsupported use before the pool-policy result can carry a causal claim.

What this does not authorize: [C.19](/generated/patterns/C.19) does not become causal identification, causal fairness, off-policy causal evaluation, or counterfactual-realizability authority; it governs pool treatment and redirects causal-use support to [C.28](/generated/patterns/C.28).

Define EmitterPolicy (regime key, params, ε, K, insertion policy, and deduplication threshold) and selection lenses with a fixed pipeline (Eligibility → Dominance → Tie‑breakers); bind provenance (policy id, lens id) and guard promotions of Surprise or Illumination to dominance to explicit policy declarations.

Decision-subject clarification. Later choices are attributed to one declared DecisionSubject at explicit DecisionSubjectGranularity. Contexts publish measurement spaces and admissible policies as semantic frames; LOG profiles lenses and policies but does not enact choices. 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 and G.11 for selected-set publication and refresh.

EmitterPolicy (named profile). 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, backstop_confidence (assurance level), epsilon_dominance ε, cell_capacity K, insertionPolicyRef, dedupThreshold, deduplicationBasisRef, deduplicationUnit }. emitterPolicyId is cited from a consuming record as emitterPolicyRef; insertionPolicyRef is a reference to the governed insertion policy; dedupThreshold is a declared scalar on the basis and unit named by deduplicationBasisRef and deduplicationUnit. Casing does not create a second field family. EmitterPolicy is a context-local named policy profile, not a U-kind or a generation operator. A C.18 generation or archive record cites it only when that profile actually governs the current pool treatment or its insertion and deduplication policy; C.18 retains generation, archive, and front ownership. The profile is not a staffing or budget instruction. Ordinary default tokens remain governed by G.Core and [G.5](/generated/patterns/G.5); [C.19](/generated/patterns/C.19) explains their pool-policy consequences but does not become one rival default authority.

Decision-theory bridge. [C.11](/generated/patterns/C.11) governs theory-side choice among already-available options and the meaning of ProbeBudget, ValueOfInformation, and ValueOfComputation. [C.19](/generated/patterns/C.19) may consume such outputs only as criteria for pool policy, graduation, keep-frontier, or sunset treatment; it does not re-govern local choice doctrine.

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: Novelty@context, ΔDiversity_P, Surprise; Illumination (telemetry over Diversity_P, including coverage and QD‑score) MAY be used as a tie‑breaker but is not in the dominance set. • 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) owns 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 named C.19 lens may consume 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 assurance and CL discounts enter). Conformance. A Context 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. Surprise and Illumination MAY act as tie‑breakers; promotion into the dominance set MUST be declared by lens or policy id and captured in provenance.
• Graduation. Profiles graduate from Explore→Exploit only when eligibility holds and assuranceResultRef cites the exact B.3 assurance result whose bounded use supports the profile's declared backstop_confidence threshold for the current scope.
• Sunset or pivot. Profiles failing VOI or backstop thresholds are sunset or pivoted at rebalance_period.

Policy logic is not generation or work. One C.19 pass computes and records 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, assign a role, approve a budget, or authorize enactment.

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 eligibility and backstop_confidence to the pool-policy question: record graduation pressure and choose exactly one currentTreatment from widen | keep_frontier | narrow_to_subset | sunset_line. C.19 owns this graduation and treatment judgement.
4. If that judgement requires fresh candidates, a changed emitter mix or temperature, archive insertion, or front recomputation, set nextGoverningPatternRef = [C.18](/generated/patterns/C.18) and pass only the desired emitter profile, quota or constraint, and the exact generation/archive/front reason. C.18 decides and records 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 next-owner inputs. The result may justify keeping, narrowing, graduating, or sunsetting a line without taking over the named next owner's operation.

Named lenses (heuristics; policy‑level, not norms) The following lens profiles are illustrative heuristics. Contexts MAY reuse or modify them; they are not normative. • Frontier‑sweeper — maintain attention on the full front; promote only when backstop_confidence 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 current Context already admits a heterogeneity constraint or sampler policy. The profile may apply a declared FamilyCoverage or MinInterFamilyDistance gate, a declared family or subfamily quota, or a diversity-promoting sampler; C.19 supplies no universal k, δ_family, quota vector, sampler class, DPP rule, or max-min rule. 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.

A finished C.19 pass should 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 = backstop_confidence reaches L1 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 one explicit novelty floor

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 the current frontier is too narrow for the declared exploration policy or when the evidence basis is too thin to justify current narrowing.
• Close as keep_frontier when several lines must remain live under the current lens and no narrower admissible subset is yet justified.
• Close as narrow_to_subset when one declared lens now justifies retaining one smaller internal live set without pretending that one scalar winner has already been chosen.
• Close as sunset_line when one line or family region no longer clears the current lens, quota, or backstop requirements.

When the question has stopped being pool policy, C.19 closes by naming the next governing pattern outside currentTreatment: C.11 for local choice, C.24 for enactment planning, G.5 for selector-facing publication, G.11 for refresh, or another direct governing pattern when the recovered relation is different.

One internal retained subset here is still one pool-treatment result. It is not yet one public Shortlist, RankedShortlist, or ShortlistId-bearing selector artifact. If the retained subset must be published for downstream comparison, selector-facing publication, or registry-facing consumption, C.19 closes only by using G.5.

If the result still cannot say which pool remains live, which lens governs it, 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 = ...
• nextGoverningPatternRef? = ... only when the question is no longer pool policy
• learningProgressSignal? = ... when an autotelic or capability-discovery reason materially supports widening, keeping the frontier live, or probing one goal region further
• competenceModelRef? = ... when the pool policy depends on a model of what the system or method family can learn next
• goalSpaceExpansionCue? = ... when the admissible next treatment widens the goal and task palette rather than merely re-ranking current candidates
• goalSpaceExpansionPolicyRef? = ... when goal and task space growth is itself governed by one declared archive or curriculum expansion policy
• 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 = backstop_confidence reaches L1 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 publication is now required, the admissible [C.19](/generated/patterns/C.19) record leaves currentTreatment as the last pool treatment and fills nextGoverningPatternRef = [G.5](/generated/patterns/G.5), with the reason that publication 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 together with the supporting learningProgressSignal, competenceModelRef, or goalSpaceExpansionCue; that doctrine may justify widen, keep_frontier, or one further probe decision value, but it does not become default Q, does not rename the front, and does not publish one selector-facing shortlist without [G.5](/generated/patterns/G.5).

If the record does not already state which pool remains live, what governs it, and what would change that policy treatment next, it is still one unfinished [C.19](/generated/patterns/C.19) result.

#Worked closure slice

Three 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, C.19 should not pretend it has already made one local choice:

livePool = frontier_F
governingLens = frontier_sweeper_v3
currentTreatment = keep_frontier
changeTrigger = one retained line reaches backstop_confidence L1
whyNotLocalChoice = three family regions remain live

One region should now be sunset. When one region no longer clears the active novelty floor or backstop, [C.19](/generated/patterns/C.19) should say so directly rather than leaving that retirement implicit:

livePool = family_region_beta
governingLens = barbell_policy_v2
currentTreatment = sunset_line
changeTrigger = reopen only if new evidence or quota deficit reactivates the region
whyNotLocalChoice = other regions still remain live under the same pool policy

The pool has already been narrowed and the next question is selector-facing publication. When one internal retained subset is already explicit and the next question is to publish it for downstream use, [C.19](/generated/patterns/C.19) closes by naming the governing pattern instead of naming that subset as though it were already one public shortlist artifact:

livePool = retained_subset_{option_B, option_C}
governingLens = pool_policy_completed
currentTreatment = narrow_to_subset
changeTrigger = retained subset is explicit; pool policy is complete
nextGoverningPatternRef = G.5 because selector-facing publication 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.

CulturalLivePoolPolicyResult@Context:
  livePool:
  governingLens:
  currentTreatment:
  changeTrigger:
  termBridgeRefs?:
  culturalEvolutionCaseRef?:
  selectedSetPublicationRef?:
  refreshRef?:

The record governs pool treatment only. If the label itself is unstable across communities, use [F.17](/generated/patterns/F.17), [F.18](/generated/patterns/F.18), and [F.9](/generated/patterns/F.9). If the question is the cultural-evolution case, use [C.36](/generated/patterns/C.36). If the internal retained subset must become public, use [G.5](/generated/patterns/G.5). If the issue is source or edition currentness, use [G.11](/generated/patterns/G.11).

#Exit From Pool Treatment To Publication Or Choice

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 C.19 does not emit any of those objects. Front and Archive retain their C.18 meanings; a scalarized pick does not rename either one.

When the retained set must be published for downstream comparison, registry use, or selector-facing consumption, close C.19 and pass G.5 the exact declared source set, lens or policy id, eligibility conditions, dominance set, tie-breakers, promotion policy, and provenance pins. G.5 governs the selected-set publication and any public shortlist identity. C.19 supplies only the preceding pool treatment and the reason publication is now current.

When the live question becomes which option to choose, close C.19 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 backstop_confidence may explain a pool treatment, but they do not authorize a budget, role, plan, or work occurrence. 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 owner. Do not duplicate publication, choice, work, or refresh semantics inside C.19.

#System grounding

A product-search or architecture-search team often keeps several family regions alive even after one tempting line starts to look best locally. An admissible C.19 result might therefore keep the frontier live under frontier_sweeper_v3 until one retained line actually clears the declared backstop_confidence, instead of collapsing the whole pool into one premature winner.

#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. The practical point is that C.19 governs that pool-treatment decision only while the question under repair is still about the live set; once the result must become one local choice, one enactment plan, or one published selected set, apply the governing pattern for that result immediately.

#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 role state, assignment, permission, plan, budget, or work occurrence. When implementation follows, cite the independently obtaining context/scope and role or assignment gates plus the direct planning or Work governor; C.19 establishes none of them.

• C19-6 Each pool-treatment lens MUST document the pipeline Eligibility (ConstraintFit=pass) → Dominance (declared set) → Tie-breakers (declared). Any promotion of Surprise or Illumination into the dominance set MUST be named by lens or policy id and recorded in provenance.

• C19-7 (LEX-AUTH trigger). When a context adopts or changes an EmitterPolicy profile that includes domain-family quotas or a sampler, or changes DescriptorMap family coordinates, DistanceDef, or a δ_family threshold, author that context-local change via E.15 LEX-AUTH. C.19 establishes no default heterogeneity quota or sampler. Any resulting LAT lives in the relevant LAT and evidence authority; the DRR need only carry the content decision itself plus any decisive evidence or validation consequence by value when that consequence materially shaped the choice (see CC-DRR.6). Record policy and card ids in SCR.

• 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 still local option choice, already one enactment-facing plan, or already one selector-facing publication result, C.19 MUST name the governing pattern rather than restate C.11, C.24, or G.5.

• C19-11 If autotelic or capability-discovery evidence is used, the record MUST name goalSpaceExpansionPolicyRef when one governs widening and the learningProgressSignal, competenceModelRef, or goalSpaceExpansionCue that supports the pool treatment, and it MUST keep those signals outside default dominance unless an explicit promotion policy is recorded.

• C19-12 If an exploration and exploitation policy collects data for a causal claim, changes intervention budget, learns a causal policy, evaluates a policy from behavior data or logging data, or treats counterfactual replay as support, PoolPolicyResult.causalUseSpec? MUST carry targetCausalityLadderRung, causalUseClaimKind: CausalUseClaimKind, causal evidence support basis when known, supported use and unsupported use, and relevant C.28 support refs.

• C19-13 If a pool-policy record concerns loop, agent-harness, workflow, or DPF-seed candidates, it names the still-live pool, governing lens, current treatment, and change trigger. A need for candidate generation, archive update, or front recomputation exits to C.18 with desired policy values and a reason only; improvement, publication, choice, work, or refresh exits to E.23, G.5, C.11, the A.15 family, or G.11.

• 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 If graduation, scaling, or widening relies on assurance, assuranceResultRef? MUST cite the exact B.3 assurance result, and changeTrigger MUST name the satisfied condition and the bounded scope that result supports. A C.19 policy threshold or label does not create that assurance result.

#Common Anti-Patterns and How to Avoid Them

• 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 governing 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 other governing questions. Avoid by applying C.11 for fixed-option choice, C.24 for enactment-facing planning, and G.5 for selector-facing publication.

#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 governing pattern separately
• heterogeneity can remain admissible without pretending every frontier is 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 a context independently admits coverage or heterogeneity pressure, C.19 keeps that pressure explicit until one declared reason justifies retirement or use of a different governing pattern. The practical implication is simple: sunset or name the next governing pattern only when the current pool-policy result can already say why the pool no longer belongs to C.19.

#SoTA-Echoing

Source-currentness boundary (reviewed through 2026-08-01). 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 owns that refresh. These sources inform policy pressures and owner 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: C.22.PFR for actual Problem identity, E.23 for declared improvement loops, C.11 for local choice among already-available options, C.18 for candidate generation and archive/front stewardship, C.32.P2S when pool policy preserves architecture alternatives for problem-to-structure carry-through, C.32 for candidate palette ownership, C.35 when generated or discovered structure-bearing outputs need admission support before pool policy can use them, C.24 and the A.15 family for planning and performed work, G.5 for selector-facing publication, G.11 for refresh, C.28 for causal-use support, C.17, and G.9.

#C.19:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)