C.19:7 - 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.