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