#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. Declare 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. Use C.22 to constitute one CHR-grounded U.Signature and, when a receiving use is current, relate the exact problem-side episteme to that signature through TaskSignatureAssignmentRelation. Typed characteristics and unknowns stay visible. The declaration includes scope and only those basis, currentness, evidence-use, or crossing relations on which the receiving use relies; none adds 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 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 an exact admission predicate and current subject assertion establish another kind.

Primary EntityOfConcern. This pattern defines or constrains 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 proceeds from a shared name, scheme, plane, or package instead of two exact local senses, a tested F.9 relation, and a separate claim about the proposed use.

What this buys. The downstream selection question gets one separately constituted TaskSignature with typed vocabulary, laws, applicability, unknown handling, and ClaimScope. Evidence, freshness, and cross-semantic relations are added only when that receiving use actually needs them. 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 U.ClaimScope value 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 subject 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 subject pattern.

The corresponding claims remain with their named subject patterns.

#Problem Frame

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 defines or constrains 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 relation. The ordinary needed value is a use-bounded TaskSignature that (i) establishes MM-CHR admissibility for Scale, Unit, and Polarity before aggregation, (ii) carries tri-state unknowns explicitly, and (iii) states the exact scheme, scope, and only the basis and currentness relations needed by the current use. Open A.10 only when the use relies on a bounded evidence or provenance question. Open B.3 only when a named assurance claim about an exact target claim is current for this receiving use, including when a material-reliance rule requires that assurance claim; its assurance result is not a TaskSignature field.

#Problem

Without typed descriptors, Eligibility and Acceptance degenerate into prose and inadmissible operations creep in, such as ordinal means or mixed units. Without the F.9 split, a cross-scheme comparison can also equate unlike local meanings or import an assurance penalty even though no current assurance policy selected it.

#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, scope, and any basis or currentness relation the use relies on; 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.

Apply that formula as follows:

1. Confirm that the problem-side representation is stable enough for selector-facing use; otherwise use 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 on which later use relies. When cross-semantic reuse is current, resolve the two local senses and test the F.9 Bridge separately; a shared label, scheme, or plane does not establish it.
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 the assignment obtains under C.22:5.2. Its assertion identifies 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, or edition relation is named. When cross-semantic reuse is current, its exact local senses, obtaining F.9 Bridge, and separate bounded-use claim are recoverable. 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, or edition changes. Recheck the F.9 endpoint senses, Bridge predicate, bounded-use claim, or reliance result only when that exact dependency changed. Keep the upstream ProblemCard and downstream selection history unchanged unless that exact change invalidates them under their own subject patterns.

Worked local repair. A machining TaskSignature originally records surface finish as an ordinal visual grade. The named 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; state the new result under the exact downstream predicate with its subject-pattern locator.

#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 relied-on field-basis relation with its subject pattern, qualification window, review trigger, and any current evidence or currentness relation. When this use crosses local meanings, test F.9. Add an actual Bridge and separate bounded-use claim only if its predicate is true; otherwise keep the local values separate and stop that reuse.
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-constrained 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 only when its exact value rule permits it; the cited downstream policy states 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), admissible order relations (lexicographic, Pareto), and medoid or median operations 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 the uses of dominance and telemetry 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.
• Evidence and assurance (conditional). Include an exact A.10 evidence-use or provenance relation only when the receiving use relies on it. State source edition, currentness, or freshness only to the degree that reliance requires. Open B.3 only for a named assurance claim about an exact target claim and receiving use, including when a material-reliance rule requires it, and use only the assurance lanes and fold that its declared policy requires. A TaskSignature by itself requires neither all TA/VA/LA lanes nor a Gamma-fold.
• ScopeSlice(G) — the A.2.6 U.ClaimScope value that bounds this declaration's claims about EntityOfConcernRef (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 (conditional) — the validity window for a descriptor only when the receiving use relies on its currentness.
• 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 only when the receiving use relies on them
  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 subject 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
  exact F.17 local senses, an obtaining F.9 Bridge, and a separate bounded-use claim only when cross-semantic reuse is current

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 that exact TaskSignature is actually adopted as the task-typing declaration for the exact problem-side episteme and the use stated in the exact receiving-use 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 identifies another episteme. Admit it as a TaskSignature only if it satisfies A.6.0; relate it as a revised signature edition only when C.2.1:4.5's source-use and continuation conditions obtain. 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 subject 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 exact problem-side episteme, exact TaskSignature, exact receiving-use episteme, obtaining conditions, and occurrence extent of the assignment relation are recoverable.
3. Every live field has an admitted filler kind or scale discipline and, under reliance, an exact basis relation with a subject pattern.
4. A live but unrecovered value is unknown only where the field's exact value rule permits it and a downstream policy states how the named 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. Use C.22.2 only when the problem-side representation itself is no longer stable enough.

Identify the resulting episteme and apply C.22:5.2's signature-membership and edition-continuity checks 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 subject 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 subject 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

Use C.22 to revise the smallest affected identity or declaration-content component; identify the resulting episteme and claim a new TaskSignature edition only under the identity, membership, and continuity conditions in C.22:5.2. A changed problem formulation requires 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. They remain declaration content, distinct from a selected method or selector result.

DesignRunTag hygiene. Do not mix DesignRunTag positions in one signature edition. If design-side information is reused in run-time Work, identify the actual receiving Work and its relations independently. Cite an E.18 structural GateCrossing only when a selected transformation-flow use contains that occurrence; it does not require a package and does not establish an F.9 Bridge.

#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 any ReferencePlane needed to interpret a relied-on value. A difference in scheme or plane opens a comparison question; it does not by itself establish a Bridge, forbid use, or impose a penalty.

For cross-semantic reuse, recover the two exact F.17 local senses and test the direct F.9 predicate. Cite a Bridge only when that predicate is true. Then state the proposed use separately: the action, direction, correspondence rule, tolerated loss, and polarity. If no Bridge obtains, keep the local values separate and return the missing comparison or translation question instead of manufacturing correspondence.

Open A.10 only when evidence or provenance for that bounded use is current. Open B.3 only for a named assurance claim about an exact target claim and bounded use, including when a material-reliance rule requires it; only that B.3 result may use edge-scoped CL and the policy it actually declares. An optional local F.9 CL note is evidence shorthand, not a use threshold or automatic penalty. A card, gate check, reusable package, or publication is required only when its own receiving pattern independently needs it. The assignment receives no generic setting participant, and a domain, organization, location label, or shared carrier supplies none of these relations.

#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 only when its exact value rule permits it. The TaskSignature cites the downstream policy that defines or constrains the consequence; C.22 performs no implicit coercion and declares no universal outcome set.

#Publication.

When a named receiving use needs a reader-facing publication of the ProblemProfile specified in C.22:5.0b, publish that accepted C.2.1-conformant episteme through E.17. Use E.24.PUB when that use depends on publication availability, its declared boundary, or publication-occurrence identity. The profile references the bound TaskSignature and only the evidence, currentness, F.9 bounded-use, 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 a card merely because a local field or Bridge is present. Keep vendor or tool examples in Plain explanatory use rather than letting them become normative selector inputs. When no replay beyond the local assignment relation is needed, 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): in Show‑1 (continuous ODE) and Show‑2 (MIP) below, CHR guard‑macros and scale rules show which field supplied which Eligibility or Acceptance input. For the receiving use, 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 eligibility conditions require 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 the lexicographic guard (assumption-fit before evidence-fit before resource). If this receiving use makes a named assurance claim about an exact target claim, including when a material-reliance rule requires it, use B.3 to obtain its separate assurance result from the relied-on evidence relations and the declared policy; otherwise this example adds no assurance fold. If the admissible comparison remains partial, 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=…}. Include PathSliceId only when an E.18 path slice is current. 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 exact signature is actually adopted as the task-typing declaration for that exact card and the use stated in FinishingMethodEligibilityUse-E1, 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, and ScopeSlice(G)=Cohort-2026-Q3 in the declared care setting during [2026-08-01T00:00Z, 2026-11-01T00:00Z). It also declares outcome characteristics with their scale kinds, contraindication and resource constraints, and unknown tolerance or comorbidity values preserved as unknown. Include the evidence relations and follow-up windows only because this comparison use relies on them.

C.22 makes the comparison inputs explicit. Diagnosis and treatment recommendations remain claims governed by the applicable clinical patterns. For a separately current evidence or benefit claim, apply its evidence or clinical evaluation pattern; for a named gate decision, use A.21; for a care-permission claim, use A.2.8.PER and its GrantedPermissionRelation@Context predicate; for decision authority, recover the applicable authority predicate. Return missing-governor under A.6.RCD only when no governing rule can state or test that exact needed relation claim.

If clinical Work occurs, recover each exact actual performer System through A.13 and let A.15.1 independently admit the dated Work and its enacted Method. Add an assignment occurrence, its declared species, and F.6 only when this clinical account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. A local system-role kind, classification, or assignment can remain a neighboring fact, but it establishes none of the permission or authority relations above. 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 exact signature is actually adopted for that exact card and the use stated in RehabilitationInterventionFamilyComparisonUse-E1, 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 uses the exact ReferenceScheme, ClaimScope, characteristic meanings, and U.Discipline relation when current. A Domain label is only a catalog mark; it supplies no norm, Bridge, scope, or comparison rule.
• 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 and assurance are conditional. When the receiving use relies on evidence or provenance, cite the exact A.10 relation and only the source edition, currentness, and freshness conditions that reliance needs. When a named assurance claim about an exact target claim is current for this receiving use, including when a material-reliance rule requires it, cite its separate B.3 result, applicable assurance lanes, and declared fold. Otherwise the TaskSignature needs neither an evidence dossier nor an assurance fold.

5. Cross-semantic use is separated. Declare ReferencePlane for a value or objective head when its interpretation or comparison needs it. A scheme or plane difference alone creates neither a Bridge nor a penalty. Resolve two exact F.17 local senses, test the F.9 predicate, and state any proposed use separately.

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. Bridge and use claims remain distinct. For current cross-semantic reuse, cite the two exact local senses and an actual F.9 Bridge only when its predicate is true. State the action, direction, correspondence rule, tolerated loss, and polarity in a separate bounded-use claim; if the predicate is false, keep the local values separate.

9. Packaging is conditional. Create an F.9 card, terminology row, Name Card, or reusable package only when a named receiving pattern independently needs that artifact. Packaging describes an already tested relation and separate use claim; it establishes neither.

10. Structure and gates are conditional. Apply E.18 crossing checks only when a selected transformation-flow structure and exact GateCrossing are current. Apply A.21 only when a named gate decision is current. Each pattern supplies its own result; neither a structure nor a gate makes F.9 obtain, and C.22 requires no crossing or gate package otherwise.

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 defines or constrains any downstream abstention or returned-set result.

17. Planes. QD heads and characteristics declare a ReferencePlane when their meaning or comparison depends on it. A plane difference alone creates neither correspondence nor an assurance adjustment. Use item 8 for a current cross-semantic claim and item 4 for any separately current B.3 assurance result.

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. One stabilized problem-side episteme and CG-Spec ids; a ProblemProfile (...Description) only when C.22:5.0b's replay need is current; an A.10 evidence-use or provenance relation only when the receiving use relies on it; D.CTX only when that separate context relation is current; the QD values or references named by CharacteristicSpaceRef, ArchiveConfig, and EmitterPolicyRef only when QD is live; GeneratorIntent only when OEE is live. Produces. Declare one TaskSignature episteme as the U.Signature species specified in C.22:5.2. When that signature is actually adopted for the problem-side episteme and receiving use, one separate TaskSignatureAssignmentRelation obtains among that signature, the exact problem-side episteme, and exact receiving-use episteme under C.22:5.2. 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 episteme identity; signature membership and edition continuity follow C.22:5.2, 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 the TaskSignature positions and CHR rules on which it relied. When a separate B.3 assurance result is current, that result cites its own evidence relations, applicable assurance lanes, and declared fold.
• Use-bounded first, cross-semantic use explicit. The exact EntityOfConcern, effective ReferenceScheme, ClaimScope, and receiving use are primary. When local meanings differ, an obtaining F.9 Bridge and a separate bounded-use claim make the proposed reuse inspectable; evidence reliance, assurance, gates, and packaging remain optional neighboring questions.
• Frictionless downstream. G.1-G.5 use one single, typed TaskSignature; acceptance-gate 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

Selecting a method before the relevant eligibility, acceptance, unknown-handling, and admissible-comparison relations are explicit invalidates the selector-facing problem record. When the selection use relies on evidence, provenance, currentness, or assurance, those separate relations and results must also be explicit; C.22 does not require them otherwise.

#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 for selected EntityOfConcern, Description-episteme, specification-use, and publication-lane wording. Coordinate with E.18 only when a named receiving use depends on a selected transformation-flow crossing or gate position; E.18 supplies neither the F.9 Bridge nor a mandatory publication package.

#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 question, the task-family reference, threshold target, adaptation budget, and freshness or 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: neither trivial nor impossible); this aligns with G.1 (goldilocks target, abductive provenance) and ensures the TaskSignature is informative for G.5 selection.

#C.22:End

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