#Task Typing and TaskSignature Assignment (Problem-CHR)

C.22 · Cluster C.IV - Composite & Macro-Scale · Stable · Calculus (C) · 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.

Status: Stable Type: Calculus (C)

Purpose. Give FPF an admissible, minimal, and portable TaskSignature declaration for selector-facing use after the problem-side episteme is stable enough for Principles-to-Work, eligibility, acceptance, or policy-governed choice. C.22.2 carries the first problem-framing episteme for a messy signal. C.22 constitutes one CHR-grounded U.Signature and, when a receiving use is current, relates the exact problem-side episteme to that signature through TaskSignatureAssignmentRelation. Typed characteristics, unknowns, evidence-use relations, scope, currentness, and any scheme or plane crossings stay visible without adding a generic setting, carrier, or organization as a participant.

Body-level kind boundary. TaskSignature is a C.2.1 episteme and a species of existing U.Signature, conformant to A.6.0 direct declaration fields, Vocabulary, Laws, and Applicability. It is not a record format and introduces no new root U-kind. TaskSignatureAssignmentRelation is a separate obtaining relation among one exact problem-side episteme, one exact TaskSignature episteme, and one exact receiving-use episteme. ProblemCard is the C.22.2 problem-side episteme used before that assignment. KindSet contains C.3 U.Kind values for selected entities. Descriptor maps, telemetry hooks, policy ids, and selector fields remain signature vocabulary or projections unless a direct governing pattern admits another kind.

Primary EntityOfConcern. This pattern governs one TaskSignature episteme. Inside it, EntityOfConcernRef identifies the exact task or work target declared for the receiving use; it does not identify the signature, TaskKind, carrier, organization, or publication. TaskKind, optional TaskFamilyRef, KindSet, characteristic bindings, and scope relations are declaration content. A later SelectorOutcome remains a downstream result.

Placement. Part C (Kernel Extensions Specifications) -> Cluster C.I (Core CHRs and CALs). Depends on: C.16 MM-CHR (measurement admissibility), G.5 (selector S2 and S3), G.0 (CG-Spec invariants). Coordinates with: G.4 (Acceptance and Evidence profiles), C.23 (MethodFamily admissibility and maturity), C.18 NQD-CAL (QD and illumination), C.19 E/E-LOG (emitters and policies), E.10 (LEX).

Use this pattern when one stabilized problem-side episteme must be related to a selector-facing TaskSignature for eligibility, acceptance, or policy-governed selection. Typical cases include solver choice, method-family eligibility, QD archive selection, open-ended generator selection, or specialization claims that need a declared task family or work target.

#Relations

#Content

#Use This When

Use this pattern when one stabilized problem-side episteme must be related to a selector-facing TaskSignature for eligibility, acceptance, or policy-governed selection. Typical cases include solver choice, method-family eligibility, QD archive selection, open-ended generator selection, or specialization claims that need a declared task family or work target.

The working moment often sounds like this: "We are about to compare possible ways of doing, but which facts about this problem make a method family eligible, comparable, or unacceptable for this use?" Construct the smallest A.6.0 TaskSignature that a later selector can consume without selecting a method in advance, then assign it to the exact problem-side episteme and receiving use. If problem framing remains contested or stale, use C.22.2. If a sufficient signature and assignment already exist and the current question is selection, use G.5. If a method is selected and dated enactment is being prepared, use A.15.2.

What goes wrong if missed. A problem remains a paragraph: selector inputs drift, ordinals and units get mixed, unknowns are coerced, acceptance thresholds leak into CHR fields, and reuse happens by name rather than through exact scheme, scope, currentness, and any required Bridge.

What this buys. The downstream selection question gets one separately constituted TaskSignature with typed vocabulary, laws, applicability, unknown handling, evidence relations, ClaimScope, freshness, and crossing conditions visible before any method family is admitted or compared. Its assignment is replayable while publication and serialization can vary without changing the signature.

#Intent

Operationalise No-Free-Lunch discipline in selection by making each selector decision use a typed TaskSignature, not a paragraph. A problem reaches C.22 when its problem-side episteme is stable enough to constitute and assign that declaration without selecting a method in advance. The signature is the smallest CHR-typed A.6.0 declaration sufficient for eligibility, acceptance, and policy-governed selection without inadmissible arithmetic or silent coercions.

#Term split used in this pattern

• TaskSignature assignment means one obtaining TaskSignatureAssignmentRelation among an exact problem-side episteme, exact TaskSignature, and exact receiving-use episteme; it does not pre-bind a method.
• ScopeSlice(G) means the exact A.2.6 claim-scope relation used by this declaration; it is not an evidence-path slice, baseline-set slice, container, or assignment participant.
• threshold is not one undifferentiated family here:
  • articulation and closure thresholds stay with cue or prompt governing patterns such as B.4.1 and B.5.2.0;
  • acceptance-gate thresholds stay with G.4;
  • a work-measure threshold target used in a specialization claim is only the declared success mark for that task family or work target.

Name and kind map for code-shaped heads. The names below identify different structural positions; capitalization does not make them peer kinds.

#ProblemCard relation

ProblemCard is the C.22.2 C.2.1 episteme used to stabilize one problem-side representation before downstream Principles-to-Work.

A ProblemCard can prepare TaskKind, scope, and characteristic bindings for a candidate TaskSignature. Assignment obtains only when one signature is adequate for the named receiving use. If several signatures remain plausible, keep them as candidates under the selection or problem-framing pattern rather than asserting one assignment occurrence.

TaskSignatureAssignmentRelation moves no card claim into the TaskSignature. The signature keeps only its A.6.0 declaration content; the card remains the reviewable problem-side episteme that explains why this problem can proceed to characterization, comparison, search, refresh, retirement, or another governing pattern.

The corresponding claims remain with their named governing patterns.

#Problem Frame (DesignRunTag split; crossing-visible)

Selector-facing problem case For selector-facing C.22 use, a problem case applies when the problem-side episteme is stable enough to construct a minimal TaskSignature and assert its TaskSignatureAssignmentRelation for eligibility, acceptance, or policy-governed selection. Method absence or contestability is a common downstream reason, but not the ontology of problemhood. When the live question remains a symptom, contested framing, stale ReferenceScheme or ClaimScope, set-derived candidate, opportunity cue, or preselected work item, use C.22.2 before asserting one assignment. When selection becomes current, cite the A.19.SelectorMechanism relation and exact G.5 policy refs rather than moving selection policy into the signature. Unknown-first discipline. Author S2 with unknown traits rather than coercions. Name the exact downstream policy that interprets a live unknown for the receiving use. C.22 introduces no universal outcome enum; C.23, G.4, G.5, or another direct pattern governs the resulting eligibility, acceptance, or selection disposition.

Untyped "problems" collapse into informal prose; selectors cannot filter or abstain admissibly; acceptance-gate thresholds leak into scoring; and cross-scheme reuse proceeds by name rather than by an exact Bridge. The needed value is a use-bounded TaskSignature that (i) establishes MM-CHR admissibility for Scale, Unit, and Polarity before aggregation, (ii) records Assurance lanes TA, VA, and LA per A.10 and ReferencePlane, (iii) carries tri-state unknowns explicitly, and (iv) records any Bridge and crossing attestations with Φ(CL) and Φ_plane policy ids.

#Problem

Without typed descriptors, Eligibility and Acceptance degenerate into prose; inadmissible operations creep in (ordinal means; unit mixing); cross-plane comparisons lose CL and Φ penalty assignment (penalties to R_eff only).

#Forces

#Solution — Problem CHR, TaskSignature, and assignment relation

Local TaskSignature mantra. Stabilize the problem; name the receiving selection question and task kind; keep only traits that can change eligibility, acceptance, or selection; type each live trait; preserve unknowns, evidence relations, scope, and currentness; declare the TaskSignature, assign it to the problem-side episteme for that use, and stop before selecting a method. This is a short repeatable rendering of the C.22 Solution. It is not a selector algorithm, method recommendation, work plan, dated selection occurrence, or DemonstrativeUnfoldingSlice@Context.

Apply that formula as follows:

1. Confirm that the problem-side representation is stable enough for selector-facing use; otherwise return to C.22.2.
2. Name the receiving eligibility, acceptance, or selection question and the TaskKind, optional task family, or work target that the signature will declare.
3. Include only the problem traits whose values can change that receiving use. Leave a non-current optional extension absent.
4. Type each live characteristic by scale, unit, polarity, reference plane, and admitted comparison relation before aggregation or comparison.
5. Preserve a live but unknown value as unknown; include or reference the exact scope, evidence relation, freshness or edition condition, and crossing relation on which later use relies.
6. Close with one minimal TaskSignature. Pass later eligibility and acceptance claims to C.23 and G.4, and actual method-family selection to G.5; do not put their outcomes back into the signature as if they were problem traits.

#Positive closure, bounded non-use, and local return

Close the C.22 use positively when the direct TaskSignature fields, Vocabulary, Laws, and Applicability are complete and TaskSignatureAssignmentRelation recovers the exact problem-side episteme, TaskSignature, receiving-use episteme, effective ReferenceScheme, ClaimScope, and current qualification conditions. Each live characteristic has its scale, unit, polarity, reference plane, admitted comparison relation, and value or explicit unknown; every relied-on evidence, freshness, edition, or crossing relation is named. A downstream selector can now consume the assigned signature without guessing, but no eligibility verdict, acceptance result, method recommendation, selector outcome, WorkPlan, or dated Work is claimed.

Close by bounded non-use when problem framing is not stable enough for a TaskSignature declaration, when no selector-facing receiving use is current, or when the current question has already become eligibility, acceptance, selection, planning, or performed work. A non-current optional extension remains absent. If several signatures or assignment relations remain plausible, preserve them as candidates under the governing problem or selection pattern rather than asserting one assignment.

Return to the smallest affected TaskSignature position when its receiving question, exact target, effective ReferenceScheme, ClaimScope, TaskKind, task-family reference, characteristic meaning, scale, unit, polarity, reference plane, unknown status, evidence-use relation, freshness condition, edition, or crossing relation changes. Keep the upstream ProblemCard and downstream selection history unchanged unless that exact change invalidates them under their own governing patterns.

Worked local repair. A machining TaskSignature originally records surface finish as an ordinal visual grade. The receiving use later adopts measured roughness Ra on a ratio scale in micrometres with a named measurement and evidence relation. Repair the affected characteristic head, scale, unit, admitted comparisons, and evidence relation. Keep the machining TaskKind, unaffected constraints, scope, and prior work history. Reopen eligibility, acceptance, or method-family selection only when its earlier result relied on the replaced finish head; the direct downstream pattern decides the new result.

#Apparatus proportionality

Use the lightest signature declaration and assignment relation that the named receiving use can consume:

1. Minimal selector-facing use. Materialize one TaskSignature with only the live fields needed by the current eligibility, acceptance, or selection question. This is the ordinary positive result of C.22.
2. Reliance-bearing use. Add an addressable ProblemProfile episteme only when delayed feedback, audit, transfer, automation, expensive reversal, or another named use relies on replay beyond the local assignment relation. Pin the exact problem-side episteme and edition, TaskSignature edition, receiving use, every field-basis relation with its direct governing pattern, qualification window, review trigger, and any current evidence, currentness, or crossing relation.
3. Extension-bearing use. Add QD, OEE, archive, generator, parity, or specialization positions only when that exact downstream relation is current and its direct pattern requires those values.

More fields, publication packaging, name cards, or telemetry do not make the problem better formulated, the TaskSignature more true, or a method more suitable. If no selector-facing receiving use needs a TaskSignature, close by bounded non-use rather than publishing a thin declaration for its own sake.

#Minimal CHR fields (tri‑state aware).

Selector-side field boundary. The fields below are live only after problem framing has been stabilized enough to ask eligibility, acceptance, selection, method-family, or policy-governed choice questions. They are not a universal problem-framing checklist and do not replace the C.22.2 Thin ProblemCard pass for a messy signal. Each live characteristic field is CHR-typed by Characteristic, Scale, Unit, and Polarity under MM-CHR discipline. A live predicate may preserve unknown when its direct pattern admits that value; the cited downstream policy governs what follows. This aligns G.4 and G.6 without making their results C.22 values.

Optional extension absence rule. If QD, OEE, archive, generator, parity, specialization, or another optional relation is not live for the current case, the corresponding optional fields are absent, not unknown. Use unknown only for a live field whose value is currently unknown. An absent non-live extension triggers no downstream disposition.

• DataShape — data regime and admissible transforms (e.g., tabular, sequence, graph; density; stationarity claims).
• NoiseModel — uncertainty class and robustness envelope (e.g., iid Gaussian; heavy‑tailed; adversarial budget).
• ObjectiveProfile — objective heads (Scale, Unit, Polarity and ReferencePlane declared), polarity, and admissible order relations (lexicographic, Pareto, medoid or median where admissible). Weighted sums across mixed scale types are inadmissible; ordinal heads use order-only guards. For QD tasks, explicitly enumerate quality heads, diversity or descriptor-space heads, and any policy-authorized QD contribution heads; see DominanceRegime below. Do not introduce a default QD score. If a scalar or set-scalarization policy is live, cite the governing CAL policy and keep dominance and telemetry roles explicit.
• RegularityTraits — method-relevant structure (convexity, differentiability, separability, monotonicity) as CHR-typed predicates with guard macros (for example, ORD_COMPARE_ONLY, UNIT_CHECK, POLARITY_CHECK). Include ConditionClass such as stiffness or kappa proxies where applicable.
• Constraints — explicit hard and soft constraint classes (feasibility predicates; ResourceEnvelope and RiskEnvelope). Acceptance-gate thresholds live in G.4 only; never inside CHR or code paths.
• ShiftClass and stationarity — CHR‑typed claims about regime stability (iid | covariate‑shift | concept‑drift | adversarial). Default=unknown. The cited acceptance or selector policy governs the consequence of that unknown for its receiving use.
• EvidenceGraphRef (A.10) — evidence carriers and lane tags TA, VA, and LA with freshness windows; no self-evidence; default Γ-fold = weakest-link unless CAL establishes an alternative.
• ScopeSlice(G) — the USM claim-bounding scope cut over EntityOfConcernRef and scope (discipline governance in CG‑Spec; Domain is a catalog mark only).
• SizeAndConditionProfile — size and condition proxies (n, m, kappa, sparsity) with declared units; a unit mismatch makes the current comparison unsupported until the direct acceptance or selector policy supplies its governed result.
• Freshness — validity window for descriptors.
• Missingness — MCAR, MAR, or MNAR (or mapped equivalents) per CHR.Missingness; Acceptance and flow use preserve the declared missingness semantics.
• KindSet — selected C.3 U.Kind values for the entities addressed by the TaskKind; separates EntityOfConcern kind from Scope (USM).

QD and Illumination extensions (normative; ties to C.18 and C.19).

Use this extension block only when QD, illumination archive, set-return, or OEE generator relation is live for the current case. It is not part of every TaskSignature.

• CharacteristicSpaceRef — reference to U.CharacteristicSpace, with declared d≥2; characteristics are CHR‑typed; ReferencePlane per characteristic; pin edition via CharacteristicSpaceRef.edition.
• ArchiveConfig — archive topology (grid, CVT, or graph), resolution (bins or centroids), K‑capacity, InsertionPolicyRef (elite replacement, dedup, or novelty), and DistanceDefRef.edition (declare metric or pseudometric status and invariances; normalisation is admissible only when the applied scale transform is admitted by CG-Spec); admissibility follows CG‑Spec.
• EmitterPolicyRef — reference to the emitter policy governed by C.19 and applicable to this TaskSignature; edition id recorded.
• DominanceRegime — {ParetoOnly | ParetoPlusIllumination}. Default = ParetoOnly (illumination remains report‑only telemetry unless CAL explicitly authorises ParetoPlusIllumination, policy‑id cited).
• IlluminationSummary — a telemetry summary over Diversity_P; reported by default; excluded from dominance unless a CAL enables ParetoPlusIllumination (policy‑id cited).
• IlluminationMap (parity-run) — parity-run publication is complete when an IlluminationMap publication (grid, CVT, or graph per ArchiveConfig) records coverage per niche or cell with DescriptorMapRef and DistanceDefRef.edition. A single-score leaderboard does not satisfy this comparison use; compare under the declared CG-frame.
• PortfolioMode — {Pareto | Archive}. Default = Archive: selectors preserve archive evidence (QD archives) rather than a single “best” set; ε‑fronts remain admissible for local decisions under CG‑Spec.
• Budgeting — evaluation, time, and batch budgets, including E/E‑LOG exploration budget id; units declared (CG‑Spec).
• TelemetryHooks — PathSliceId only when an E.18 path-slice reference is current, plus decay and refresh policy ids, edition counters, descriptor-map updates, and policy-id updates upon illumination gains.
• GeneratorIntent (OEE) — optional intent to use a registered GeneratorFamily (G.5), with pointers to EnvironmentValidityRegion, TransferRulesRef, and coverage and regret reporting expectations.

Admissibility. Before any numeric comparison or aggregation, establish CSLC admissibility for Scale, Unit, and Polarity and cite CG-Spec.Characteristics; record ReferencePlane. Preserve unknown for the downstream policy; do not coerce it to 0 or false, and do not invent a C.22-local disposition.

#TaskSignature declaration and assignment

TaskSignature is a C.2.1 episteme and a species of A.6.0 U.Signature. It uses A.6.0 identity and declaration content directly rather than a flat record schema. Add an optional SignatureManifest only when dependency replay requires actual imports and provided names; SignatureId and edition are designators and currentness handles, not substitutes for identity.

TaskSignature <: U.Signature

EntityOfConcernRef = exact task or work target declared for the named receiving use
effectiveReferenceScheme = exact scheme in which TaskKind, TaskFamilyRef?, KindSet, and characteristic values are interpreted
SubjectKind = TaskKind, one exact C.3 U.Kind value
RangedValueKind = U.Entity
SliceSet = declared A.2.6 claim-scope slices
ExtentRule = entities admitted by KindSet inside those slices
ResultKind = absent; selector outcomes are not TaskSignature values

Vocabulary:
  TaskFamilyRef?
  KindSet
  characteristic bindings with Scale, Unit, Polarity, ReferencePlane, admitted comparison relation, and value or admitted unknown
  constraint relation references
  evidence-use relation references
  optional QD, OEE, archive, generator, parity, budget, telemetry, and specialization vocabulary only when current

Laws:
  include only positions that can change eligibility, acceptance, or selection for the declared use
  preserve admitted unknown and distinguish it from absent non-current vocabulary
  apply CHR scale, unit, polarity, ReferencePlane, and comparison legality before aggregation
  keep acceptance verdicts, selector outcomes, selected methods, plans, Work, and performed results outside the signature
  keep each reliance-bearing field connected to its exact basis relation and direct governing pattern

Applicability:
  exact U.ClaimScope and any required A.2.6 membership
  declared qualification or use window when current
  qualification, freshness, edition, and evidence-use conditions on which use relies
  named F.9 Bridge and plane conditions when meanings or ReferencePlanes differ

The field families in C.22:5.1 are projections of Vocabulary and Applicability. They are not extra conceptual rows and do not redefine A.6.0.

The assignment is a separate relation with exactly three direct participants:

TaskSignatureAssignmentRelation <: U.Relation
  ProblemSideEpistemeSlot = <ProblemSideEpistemeSlot, U.Episteme, U.EpistemeRef>
  TaskSignatureSlot = <TaskSignatureSlot, U.Signature, U.EntityRef constrained to TaskSignature>
  ReceivingUseEpistemeSlot = <ReceivingUseEpistemeSlot, U.Episteme, U.EpistemeRef>

The relation obtains while the exact receiving use actually adopts that exact TaskSignature as the task-typing declaration for the exact problem-side episteme under the stated scheme, scope, and qualification conditions. Co-publication, a card field, a shared label, or one record row does not make it obtain. One occurrence is identified by the three participants plus its maximal continuous actual assignment extent. A participant change yields another occurrence; actual withdrawal and later readoption yield distinct occurrences even when the same three participants return.

TaskSignature identity and publication. The tuple <declaration content, EntityOfConcernRef, effectiveReferenceScheme> determines TaskSignature episteme identity under A.6.0 and C.2.1. SignatureId and edition designate and track that episteme. A semantic change to direct declaration fields, Vocabulary, Laws, Applicability, the exact target, or the effective scheme creates a revised signature edition. Two E.17 publications, database rows, cards, or files may present the same edition when they resolve to the same tuple and add no new claim. ProblemProfile may reference the signature and assignment relation but contains or becomes neither.

Minimality rule. Include only declaration positions needed to determine eligibility, acceptance, or admissible selection for the named use. Additional traits remain outside Vocabulary until a later use makes them current.

Values are CHR-typed and tied to the exact measurement, evidence-use, source-use, representation, or scope relation that justifies their use when such a relation is current. Each reliance-bearing field basis names that relation and its direct governing pattern; generic provenance or support wording is not a replay basis. Unknowns preserve their direct missingness semantics.

TaskSignature invariants. A positive assignment satisfies all six conditions:

1. The TaskSignature exposes its exact EntityOfConcernRef, effective U.ReferenceScheme, direct declaration fields, Vocabulary, Laws, and Applicability.
2. The assignment relation recovers its exact problem-side episteme, exact TaskSignature, exact receiving-use episteme, obtaining conditions, and occurrence extent.
3. Every live field has an admitted filler kind or scale discipline and, under reliance, an exact basis relation with a direct governing pattern.
4. A live but unrecovered value is unknown only where the field's direct pattern admits it and a downstream policy states how the receiving use handles it.
5. A non-current optional extension is absent; absence and unknown are not interchangeable.
6. Eligibility verdicts, acceptance results, selected methods, selector outcomes, WorkPlans, and Work occurrences are absent from the TaskSignature and remain with their direct patterns.

#Lowering and withdrawal conditions

Withdraw the assignment for the current receiving use when its problem-side episteme, TaskSignature, receiving-use episteme, scheme, scope, or qualification conditions cannot be recovered. The TaskSignature may remain a valid declaration for another assignment. Return to C.22.2 only when the problem-side representation itself is no longer stable enough.

Revise the TaskSignature edition when a direct declaration field, Vocabulary, Law, Applicability claim, EntityOfConcernRef, or effective U.ReferenceScheme changes. Lower or remove one vocabulary position when its filler kind, scale, unit, polarity, reference plane, direct basis relation, or governing pattern cannot support the claimed use. Preserve unknown only when the position remains live and admitted. Split any selected method, selector outcome, acceptance result, plan, or Work occurrence into its direct governing pattern.

A changed or invalid signature position reopens an earlier downstream result only when that result relied on the changed position. The downstream pattern repairs or supersedes its own result. A revised signature does not imply that the actual Problem disappeared or that prior Work did not occur.

#Evolution and currentness boundaries

C.22 revises the smallest affected identity or declaration-content component and issues a new TaskSignature edition when semantic content changes. A changed problem formulation returns to C.22.2 before a replacement assignment is made. G.11 governs relied-on source edition, freshness, decay, telemetry, and currentness relations; its result may trigger signature review but does not rewrite the signature by itself. C.18 and C.19 govern archive, front, lineage, and live-pool evolution. G.5 governs selected-set and method-family selector results. E.23 governs repeated object-version improvement. C.22 introduces no local refresh object and does not rewrite earlier selector results or dated Work without an explicit dependency.

TaskKind fills SubjectKind. TaskFamilyRef? names one comparison-relevant family in Vocabulary when specialization, transfer, or parity is live. KindSet and A.2.6 scope slices determine the ranged extent. None is a record-format field, selected method, or selector result.

DesignRunTag hygiene. Do not mix DesignRunTag in one signature edition; record GateCrossings as CrossingBundles under their direct patterns when design-time claims are reused in run-time Work.

#Specialization-claim reference discipline (normative)

A claim that one holder, dyad, team, or explicitly scoped specialist portfolio acquired usable specialization is complete only when it states one declared TaskFamilyRef or TaskSignature, one named work-measure threshold target, an adaptation budget, and the freshness or provenance basis for reuse. A method may be selected, refined, or retired as part of that story, but it is not the subject of the specialization claim. The TaskSignature declaration and assignment remain rich enough for the same task family and work target to stay admissible in C.22.1 adaptation signatures, G.5 specialization profiles, and G.9 adaptation parity without reconstructing the claim from narrative prose.

Low-human-overlap or newly discovered task families remain admissible when those task-family or signature references are explicit by value.

#Provenance, schemes, and planes

Record the effective U.ReferenceScheme, U.ClaimScope, and ReferencePlane for every relied-on value. When meanings or planes differ, cite the exact F.9 Bridge, endpoint senses, admitted use, and loss; apply CL and, when planes differ, CL^plane penalties to R_eff only under the governing policy. The assignment receives no generic setting participant, and a domain, organization, location label, or shared carrier supplies none of these relations. Record policy ids in SCR and cite Bridge ids on actual crossings.

#Attachment & use.

The bullets below state which TaskSignature fields and relations each downstream use reads. C.22 does not execute eligibility, acceptance, selection, archive treatment, or generator-family choice. Their verdicts and returned sets remain results of the named direct patterns.

• Eligibility gates read TaskSignature against each MethodFamily.Eligibility (C.23) and CG‑Spec.MinimalEvidence for referenced characteristics.
• Acceptance clauses (G.4) use these fields for acceptance-gate threshold predicates (acceptance-gate thresholds live in Acceptance only).
• Selection kernel (G.5.S3) applies an admissible order (often partial); weighted sums across mixed scale types are inadmissible. If only a partial order remains, return a Pareto (non‑dominated) set with tie notes. If PortfolioMode=Archive, the selector may return a QD archive (per ArchiveConfig) in addition to or instead of a Pareto set. Illumination enters dominance only if DominanceRegime=ParetoPlusIllumination is enabled by CAL (policy id cited); otherwise, QD telemetry values are reported but excluded from dominance.
• When GeneratorIntent is present, G.5-governed selection may use a registered GeneratorFamily (POET‑class); the selection domain becomes pairs {environment, method}, with Environment guarded by EnvironmentValidityRegion and TransferRulesRef (C.23 wiring). Report IlluminationSummary as a telemetry summary over Diversity_P (report‑only by default) in telemetry; dominance remains unaffected unless policy changes as above.

#Unknowns.

An identity position needed for positive closure cannot be replaced by unknown. A live characteristic or predicate may preserve unknown when its direct pattern admits it. The TaskSignature cites the downstream policy that governs the consequence; C.22 performs no implicit coercion and declares no universal outcome set.

#Publication.

When a named receiving use needs an addressable publication episteme, output a C.2.1-conformant ProblemProfile that carries the bound TaskSignature and only the evidence, currentness, crossing, and representation relations on which that use relies. Apply F.18 and F.17 Name Cards when a durable new name is actually being admitted; do not create name cards merely because a local field is present. Keep any vendor or tool examples in Plain explanatory use rather than letting them become normative selector inputs. When no publication reliance is current, the TaskSignature closes without a separate ProblemProfile.

#Open‑Ended tasks (GeneratorFamily) (normative).

When open-ended generation of tasks or environments is current, S2 is complete only when it includes GeneratorIntent with pointers to EnvironmentValidityRegion (admissible region for generated environments), TransferRulesRef (cross‑environment transfer constraints), and coverage and regret telemetry expectations. Selector outputs are then declared sets over {environment, method}; coverage and regret are reported telemetry values and IlluminationSummary is a telemetry summary (reported), excluded from dominance unless a CAL policy promotes them (policy‑id recorded in SCR; see DominanceRegime). Edition increments of CharacteristicSpaceRef.edition, DescriptorMapRef.edition, DistanceDefRef.edition, and (OEE) TransferRulesRef.edition, and the policy id associated with an illumination increase form part of the SCR change record.

#Archetypal Grounding (Tell–Show–Show)

Tell–Show–Show hook (per E.8): label examples as Show‑1 (continuous ODE) and Show‑2 (MIP) and cite CHR guard‑macros in‑line so engineers can see which field supplied which Eligibility or Acceptance input. Explicitly annotate which S2 fields triggered each Eligibility and Acceptance decision (e.g., service_level@ordinal → ORD_COMPARE_ONLY, budget@ratio → unit alignment check).

A. Differential equations (continuous systems, solver choice). ProblemProfile. DataShape=ODE, stiff?=unknown, SizeAndConditionProfile={n≈10^3}, ObjectiveProfile={↓error@ratio, ↑throughput@ratio}, ConstraintRefs={budget-envelope relation, safety-predicate relation}, RegularityTraits={Lipschitz known?=unknown, Jacobian sparsity=high}, Missingness=MAR. Attachment. Selector consumes TaskSignature; eligibility filters MethodFamilies whose acceptance conditions include known stiffness or differentiability, with unknown yielding degrade or abstain per family. Acceptance treats safety_gate as an ordinal predicate, not an average (ORD_COMPARE_ONLY), and treats budgets with unit-aligned sums on ratio scales. The selector returns a Pareto set; no cross-ordinal weighting.

B. Mixed‑integer optimisation (planning and scheduling). ProblemProfile. DataShape=MIP, NoiseModel=deterministic, ObjectiveProfile={↓cost@ratio, ↑service_level@ordinal}, Constraints={SLA hard, workforce soft}, RegularityTraits={convex_relaxation=available}, SizeAndConditionProfile={vars~10^5}, Missingness=MCAR. Attachment. CG‑Spec forbids means over service_level (ordinal); Acceptance holds acceptance-gate thresholds; Eligibility checks convex‑relaxation availability; Selection applies lexicographic guard (assumption‑fit ≻ evidence‑fit ≻ resource), compute R_eff with Γ‑fold, apply CL penalty to R only; if partial order remains, return a Pareto set.

Current practice anchor: the 2026 SciML Problem Interface constructs an immutable problem value before solver use and supports explicit remake when problem fields change. C.22 adapts only that problem-before-selector separation; it does not import Julia types as FPF ontology.

C. Quality-Diversity archive and declared set (illumination). ProblemProfile. DataShape=policy‑search; ObjectiveProfile={↑reward@ratio, ↑coverage@ratio (report‑only)}, DominanceRegime=ParetoOnly, PortfolioMode=Archive, CharacteristicSpaceRef(d=3, characteristics=CHR‑typed), ArchiveConfig(grid, res=32×32×16, K=1, InsertionPolicyRef=elite‑replace, DistanceDefRef.edition=v1), EmitterPolicyRef=v2, Budgeting{eval=1e6}, TelemetryHooks{PathSliceId=…}. Selection result. Selector may return an archive; coverage and illumination are reported but excluded from dominance (default). Any change of DistanceDefRef.edition or Emitter policy is editioned and logged in SCR.

D. Open‑ended environment generation (POET‑class). ProblemProfile. GeneratorIntent{GeneratorFamilyRef=…, EnvironmentValidityRegion=… (CHR‑typed), TransferRulesRef=…, CoverageMetric=…}, PortfolioMode=Archive. Selection result. Selector outputs {environment, method} pairs that pass Eligibility; TransferRules govern cross‑environment policy reuse; telemetry reports coverage and regret and IlluminationSummary with edition and policy‑id when improved.

E. Physical manufacturing method-family eligibility. Problem-side episteme. PartFamilyFinishingProblemCard-E2 : U.Episteme is the exact C.22.2 ProblemCard for a shop that must finish AlloyPartFamily-17 on one machine under ShopInspectionScheme-E4 and a production-window ClaimScope. The receiving question is which available finishing-method families can be compared without presuming one of them. TaskSignature. SurfaceFinishingEligibilitySignature-E1 declares EntityOfConcernRef=AlloyPartFamilyFinishingTarget-17, effectiveReferenceScheme=ShopFinishing-Scheme-A, TaskKind=surface-finishing work, ScopeSlice(G)=AlloyPartFamily-17 during [2026-09-01T00:00Z, 2026-10-01T00:00Z), ObjectiveProfile={surface roughness Ra@ratio in micrometres with downward polarity, throughput@ratio}, ConstraintRefs={geometric-tolerance relation, heat-distortion relation, resource-envelope relation}, and material-hardness condition as a live unknown with an explicit measurement relation and unknown-handling policy. The TaskSignature makes eligibility reviewable; it does not select grinding, honing, polishing, or another method and does not establish that any part was finished. Assignment. FinishingMethodEligibilityUse-E1 : U.Episteme states the exact receiving eligibility-comparison use. TaskSignatureAssignmentRelation(PartFamilyFinishingProblemCard-E2, SurfaceFinishingEligibilitySignature-E1, FinishingMethodEligibilityUse-E1) has exactly the problem-side episteme, signature, and receiving-use episteme as participants. It obtains only while that receiving use actually adopts that exact signature as the task-typing declaration for that exact card under ShopFinishing-Scheme-A, the declared part-family scope, ShopInspectionScheme-E4, and the production window above. Withdrawal of that adoption or change of a participant or qualification ends this assignment occurrence; a shared row, carrier, or publication does not make it obtain.

F. Clinical rehabilitation method-family eligibility. Problem-side episteme. CohortRehabilitationProblemCard-E3 : U.Episteme is the exact C.22.2 ProblemCard for a rehabilitation service with Cohort-2026-Q3 and a stated capability-change question under clinical safety constraints. TaskSignature. RehabilitationFamilyComparisonSignature-E1 declares EntityOfConcernRef=RehabilitationCapabilityChangeTarget-4, effectiveReferenceScheme=ClinicalRehabilitation-Scheme-C, TaskKind=rehabilitation-method-family comparison, ScopeSlice(G)=Cohort-2026-Q3 in the declared care setting during [2026-08-01T00:00Z, 2026-11-01T00:00Z), outcome characteristics with their actual scale kinds and follow-up windows, contraindication and resource constraints, current evidence relations, and unknown tolerance or comorbidity values preserved as unknown. C.22 makes the comparison inputs explicit. It does not diagnose a person, recommend treatment, authorize care, prove benefit, or record performed clinical work; those claims remain with their clinical, evidence, gate, role, and work patterns. Assignment. RehabilitationInterventionFamilyComparisonUse-E1 : U.Episteme states the exact receiving comparison use. TaskSignatureAssignmentRelation(CohortRehabilitationProblemCard-E3, RehabilitationFamilyComparisonSignature-E1, RehabilitationInterventionFamilyComparisonUse-E1) has exactly the problem-side episteme, signature, and receiving-use episteme as participants. It obtains only while that receiving use actually adopts that exact signature for that exact card under ClinicalRehabilitation-Scheme-C, the declared cohort and care ClaimScope, the qualification window above, and the stated evidence-use conditions. Withdrawal of that adoption or loss of a participant or qualification ends this assignment occurrence; cohort labels, records, carriers, and organizations add no signature field or fourth participant.

#Bias-Annotation (lexical and discipline guards)

• Selector and policy relation precision. When a source calls selection behavior a strategy, keep the Plain wording only for recognition. The governed claim cites the A.19.SelectorMechanism relation and the exact G.5 criteria, policy ref, or SelectorOutcome; no durable Strategy U-kind is introduced.
• Transdiscipline vs domain. Comparability flows through U.Discipline CG‑Spec; “Domain” is a catalog mark stitched to D.CTX + UTS; do not attach norms to Domain labels.
• Plain twins and head selection. Use Description and Spec morphology correctly (I, D, S; E.10.D2).

#Conformance Checklist (normative)

0. Minimal A.6.0 declaration. TaskSignature exposes exact EntityOfConcernRef, effective U.ReferenceScheme, SubjectKind, RangedValueKind, optional ResultKind, SliceSet, and ExtentRule, plus Vocabulary, Laws, and Applicability. Add SignatureManifest only when dependency replay needs actual imports and provided names; it does not supply signature identity.

1. Signature and assignment present. Every exported selector-facing case names one TaskSignature identity and edition plus one TaskSignatureAssignmentRelation whose exact problem-side episteme, TaskSignature, receiving-use episteme, obtaining conditions, and occurrence extent are recoverable. No setting, carrier, or organization is added as a fourth participant. Current characteristic bindings are CHR-typed; a live unknown preserves unknown, while a non-current optional vocabulary item remains absent. 1a. Publication and designators do not define identity. Two E.17 publications or serialized records that resolve to the same <declaration content, EntityOfConcernRef, effectiveReferenceScheme> identify the same TaskSignature episteme. Carrier, layout, serialization, SignatureId, or edition label alone does not create a new identity component.

2. CHR admissibility proven. Any numeric comparison or aggregation cites CG-Spec by Characteristic id and proves CSLC admissibility; no mean on ordinals; no unit mixing.

3. Unknowns remain typed. A live unknown remains unknown, cites the direct downstream policy, and is not coerced. The acceptance, eligibility, or selector pattern records its own governed result.

4. Evidence lanes. A.10 evidence relations, Assurance lanes TA, VA, and LA, and freshness windows are recorded; Gamma-fold defaults to weakest-link unless the governing CAL establishes an alternative.

5. ReferencePlane guarded. ReferencePlane is noted per value and per ObjectiveProfile head; crossings apply CL and CL^plane when planes differ. Φ(CL) and Φ_plane are monotone, bounded, table-backed, and documented in the CG-Spec; penalties affect R_eff only, preserving F and G invariants.

6. Acceptance thresholds live in CAL. No acceptance-gate thresholds in CHR or code paths; only in G.4 AcceptanceClauses.

7. Selector-use support. The TaskSignature exposes the scales, units, polarities, and admitted order relations needed by G.5; it carries no mixed-scale scalarization or local selector verdict. G.5 governs any Pareto-set result when its admissible relation remains partial.

8. Crossings visible. Any cross-stance, cross-scheme, or cross-plane reuse records BridgeCard or BridgeDescription plus UTS row with CL notes and, when planes differ, CL^plane plus Φ_plane.

9. UTS twin labels. All exported cards include Name Cards with twin labels; Bridges carry loss notes.

10. GateCrossing checks. Exported TaskSignature and referenced crossings satisfy: (i) stance tagging when used, as informative only; (ii) CrossingBundle presence and consistency under E.18, F.9, F.17, E.17, and A.21 when gate checks are live; (iii) LanePurity, with CL affecting R only, F and G invariants preserved, and Φ tables present; and (iv) Lexical SD under E.10. Failures return a blocking gate result under the active GateProfile and GateChecks governed by A.21.

11. QD fields (when QD is in scope). A TaskSignature with PortfolioMode=Archive or QD heads is complete only when it carries CHR-typed CharacteristicSpaceRef (d>=2), ArchiveConfig (topology, resolution, K, InsertionPolicyRef, DistanceDefRef.edition), and EmitterPolicyRef fields; every characteristic declares its ReferencePlane.

12. DominanceRegime default. DominanceRegime defaults to ParetoOnly. Illumination enters dominance only through a cited CAL.Acceptance policy enabling that relation; the SCR records the policy id.

13. Telemetry. The telemetry record carries PathSliceId when an E.18 path slice is current, the applicable decay and refresh policy ids, and edition counters for CharacteristicSpaceRef, DistanceDefRef, and EmitterPolicyRef. An illumination increase is traceable to the policy id that admitted it.

14. GeneratorIntent (when OEE is in scope). A TaskSignature supports the claimed OEE generator-family use only when GeneratorIntent cites EnvironmentValidityRegion and TransferRulesRef with ids resolvable in G.5 and C.23. Any downstream abstention is their result, not a C.22 output.

15. Budgets. When Budgeting is live, its evaluation, time, and batch values carry declared units and the applicable E/E-LOG exploration-budget id.

16. Archive-comparison support. A TaskSignature supports the claimed archive comparison only when DistanceDefRef.edition and the applied novelty measures are CSLC-admissible and editioned. The archive or selector pattern governs any downstream abstention or returned-set result.

17. Planes. QD heads and characteristics carry a declared ReferencePlane; a plane crossing applies Phi_plane as a penalty to R only.

18. Unknown QD values. A live unknown QD field remains unknown, cites the policy governing its downstream use, and is not coerced or mapped by C.22 itself.

19. Specialization claims referenced. A declared specialization on this TaskSignature is complete when it names the task family and work target, work-measure threshold target, adaptation budget, freshness or provenance basis for reuse, and the exact TaskSignature edition and assignment relation needed for the same claim to remain admissible in C.22.1, G.5, and G.9 use.

#Common Anti-Patterns and How to Avoid Them

#Selector Fields And Evidence Relations

Inputs. ProblemProfile (...Description), CG-Spec ids, Evidence Graph Ref (A.10), D.CTX; CharacteristicSpaceRef, ArchiveConfig, and EmitterPolicyRef configs when QD is live; GeneratorIntent when OEE is live. Produces. One TaskSignature episteme, declared as the U.Signature species specified in C.22:5.2. When a receiving use is current, C.22 also produces one separate TaskSignatureAssignmentRelation among that signature, the exact problem-side episteme, and exact receiving-use episteme. TaskSignature is neither a new root U-kind nor a record kind: its A.6.0/C.2.1 identity tuple and declaration content determine its semantic edition, while publication, carrier, and serialization remain outside identity. Optional QD, archive, generator, PortfolioMode, and telemetry vocabulary appears only when current. Used by. G.5 (Eligibility and Selection kernel), G.4 (Acceptance and Evidence), C.23 (admit, degrade, and abstain rules and method-family maturity checks).

#Consequences (informative)

• Admissible selection. Selection is explainable and inspectable; every admission or rejection reason cites TaskSignature fields, CG-Spec rows, and Gamma-fold contributors.
• Use-bounded first, Bridge-portable. The exact EntityOfConcern, effective ReferenceScheme, ClaimScope, and receiving use are primary; Bridges make cross-scheme or cross-plane portability deliberate and costed (penalties to R only).
• Frictionless downstream. G.1-G.5 use one single, typed TaskSignature; thresholds are cleanly separated into Acceptance; unknowns are not guessed.
• QD and OEE-ready. Typed QD and GeneratorIntent fields make declared returned-set structure and open-ended generation contexts explicit, with admissible dominance, editioned distances, and policy-aware illumination.

#Rationale

C.22 exists because method selection before eligibility, acceptance, evidence, unknown-handling, and admissible comparison relations are explicit invalidates the selector-facing problem record.

#SoTA-Echoing

Wolpert and Macready's "No Free Lunch Theorems for Optimization", 1997, remains historical lineage for the warning that method superiority is distribution-dependent. It does not by itself supply the current C.22 field set, a selector policy, or evidence that one TaskSignature is adequate. The current sources below change the pattern by value.

#Relations

Builds on: C.16 MM-CHR, G.0 CG-Spec. Coordinates with: G.4 Acceptance, G.5 Selector, C.18 NQD-CAL, C.19 E/E-LOG, C.23 Method-SoS-LOG, and C.32.P2S when typed problem pressure continues into architecture selected structures and synthesis. Constrained by: E.10 (selected EntityOfConcern, Description-episteme, specification-use, and publication-lane wording), E.18 (GateCrossing visibility and publication gating).

#Practical Use Checks

• If two candidate approaches are answering different TaskKinds or different ScopeSlice(G) cuts, a direct comparison is not admissible yet.
• If specialization is the live specialization question, the task-family reference, threshold target, adaptation budget, and provenance basis should already be recoverable from the assigned TaskSignature edition.
• If crossing, normalization, or missingness changes what comparison means, state that in the signature and its cited refs rather than hiding it in code, local memory, or explanatory prose.
• If QD or OEE heads are in scope, archive and generator fields belong in the same typed signature rather than in a detached explanatory appendix.

#Goldilocks Hook (design-time)

When generating candidate solutions for a TaskKind, aim for “goldilocks” slots (feasible‑but‑hard) so that the TaskSignature is informative (neither trivial nor impossible); this aligns with G.1 (goldilocks target, abductive provenance) and ensures the TaskSignature is informative (neither trivial nor impossible) for G.5 selection.

#C.22:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)