#Unified Comparison Mechanism (CPM)

A.19.CPM · Stable · Architectural (A) · Normative (unless explicitly marked informative) · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A, CN-Spec cluster (A.19), CHR mechanism-governing patterns Source: FPF, CHR mechanism-governing patterns Modified: 2026‑01‑20

Governing-pattern note: this pattern governs the canonical U.Mechanism.Intension for CPM.IntensionRef (CHR suite stage compare). Mechanism-intension semantics are governed by explicitly designated governing patterns (E.20). A.6.1 governs the semantic content of a U.Mechanism declaration. This pattern specialises that content for CPM through the exact EntityOfConcernRef, effective U.ReferenceScheme, direct signature components, SlotSpecs, OperationAlgebra, LawSet, AdmissibilityConditions, Applicability, and an optional SignatureManifest. An F.9 bridge relation, dated comparison U.Work, actual Compare operation application with its ComparisonResultSlot binding, A.10 evidence-provenance graph relation, G.11 currentness relation, and optional G.9 ParityPlan and ParityReport remain neighboring objects and relations. Other descriptions of CPM cite A.19.CPM:4.1 rather than restating its declaration content or absorbing those named neighboring objects and relations into mechanism fields.

CPM is the CHR comparison kernel: it compares two admitted profiles under an explicit, admissibility‑gated comparator and returns a set‑valued comparison outcome.

#Keywords

• comparison
• comparator
• ComparatorSpecRef
• ComparatorSet
• set-valued comparison outcome
• partial order
• tri-state admissibility (pass|degrade|abstain)
• MinimalEvidence
• “no hidden scalarization/totalization”
• Bridge+CL transport
• penalties→R_eff only.

#Relations

#Content

#At a glance (didactic, informative)

CPM is the CHR comparison kernel: it compares two admitted profiles under an explicit, admissibility‑gated comparator and returns a set‑valued comparison outcome.

One-screen purpose (manager-first). CPM answers: "Given two admitted profiles and an explicit comparator, what relation holds under the declared admissibility frame?" It does not answer: "Which one should we pick?" (selection) nor "What is the score?" (scoring).

Use this when. Use CPM when the current project question is comparison under one declared comparator, not scoring, folding, selection, publication, or work authorization.

What this buys. The practitioner gets one set-valued comparison outcome that downstream selection can consume. The actual Compare application keeps the profile pair, comparator, claim scope and selected context slices, optional A.19 predicate, reference plane, evaluation window, policies, and output binding recoverable. Partial order, incomparability, missing evidence, and scale limits remain explicit instead of becoming a hidden scalar winner.

First output. Read the by-value set bound to ComparisonResultSlot: only the relation or poset tokens. Read comparator, comparison scope, predicate when used, plane, window, eligibility value, and evidence use from the actual operation application and their direct neighboring relations; they are not fields hidden inside the output.

Manager quick checklist (before you trust a comparison):

• Comparator is explicit: do we have a ComparatorSpecRef, and is it admitted by CG‑Spec.ComparatorSet?

• Admissibility is declared: do we cite CG‑Spec (and SCP when numeric ops exist) and treat violations as degrade|abstain?

• Evidence is not faked: are missing or unknown inputs treated as degrade|abstain under the effective MinimalEvidence policy (never as pass)?

• Partiality is preserved: are we willing to accept incomparability and ties as first‑class outcomes (set‑valued result), rather than forcing a winner?

• Suite stage: compare (pipeline order lives in A.19.CHR:4.5, not in the mechanisms[] enumeration).

• Input (conceptual): left profile, right profile, CN-Spec, CG-Spec, an explicit ComparatorSpec, one U.ClaimScope with selected A.2.6 U.ContextSlice members, an optional A.19 CharacteristicSpacePredicate when the comparison depends on one, effective reference plane, explicit evaluation window, and optional explicit MinimalEvidence override.

• Output (conceptual): the by-value ComparisonResultSlot set of relation or poset tokens. It is not a score, selected set, result episteme, work-result relation, evidence record, or container for replay metadata.

• Planned slot fillings: concrete ComparatorSpecRef.edition and policy ids are planned fillers only under the exact A.15.3 planned-filling declaration and are carried by SlotFillingsPlanItem rows (A.15.3 plus A.19.CHR:4.7.2). CPM's declaration does not fill project-specific slots. A dated comparison U.Work has separately governed occurrence-parameter bindings; an actual A.6.1 Compare operation application binds the set-valued result to ComparisonResultSlot; and its A.10 evidence-provenance path records the evidence and source-currentness basis used for replay.

• Reproducible comparisons: for parity and benchmark style runs that require a stable run package plus report record (editions, windows, parity pins), use G.9 (Parity and Benchmark Harness). CPM stays kernel-only.

• What CPM does not do (strict distinction):

  • does not normalize (UNM);
  • does not choose indicators (UINDM);
  • does not score (USCM);
  • does not fold or aggregate (ULSAM);
  • does not select (“pick best”) — that is SelectorMechanism.

• Core safety commitments: admissibility gate via CG-Spec.ComparatorSet + CG-Spec.SCP + CSLC; tri-state admissibility (pass|degrade|abstain); unknown never coerces to “pass” or to a fabricated outcome; no silent scalarization or totalization.

• Where method details live: in editions of ComparatorSpec and their SoTA wiring (Part G packs and extensions), not inside CPM’s kernel semantics.

• Quick rule of thumb: if you need numbers, that’s USCM; if you need a selection or selected-set result, that’s SelectorMechanism. CPM’s job is only: compare → relation tokens.

#Problem frame

FPF's Characterization (CHR) suite treats comparison as a distinct mechanism stage (compare) with suite‑wide obligations that forbid hidden scalarization or totalization, require tri‑state guards, and enforce admissibility declarations for numeric operations. Comparison must therefore be described as:

• a mechanism (in the U.Mechanism.Intension sense, per A.6.1 and slot discipline A.6.5),
• that is suite‑conformant (per CHR obligations and protocol closure in A.19.CHR),
• and governing-spec-ref-respecting (comparability and admission are governed by CN-Spec and admissibility is gated by CG-Spec rather than re-invented locally).

Within suite protocols, CPM appears as the explicit compare stage: it consumes admitted left and right profiles, including scores and folded measures when those upstream stages are present, and produces an admissible, replayable comparison result that downstream selection can consume without CPM smuggling selection or scoring semantics into comparison.

#Problem

Engineering teams frequently need to compare two options (designs, methods, vendors, trajectories, hypotheses, etc.) across multiple measures and under incomplete evidence. Without a canonical comparison mechanism, teams predictably fall into one or more of these failure modes:

• Hidden scalarization: forcing a single number (or a single winner) from multi‑criteria reality, erasing incomparability and ties.
• Silent totalization: inventing an implied total order by convenience tie‑breakers or implicit thresholds, even when only a partial order is warranted.
• Inadmissible arithmetic: comparing across measures using operations that are not scale-admissible (CSLC‑violating) or not admitted by the declared admissibility frame.
• Comparator drift: “the comparator” exists only as prose or code intuition; different teams compare the same option set and measure set differently because the comparator spec is not explicit and edition‑pinned.
• Unknown coercion: missing or unknown evidence is coerced into an outcome (e.g., missing = equal), producing comparisons that look decisive but are epistemically unsafe.
• Comparison-boundary drift: the same result label is reused after the profile pair, comparator, A.19 predicate, claim scope, selected context slices, reference plane, or evaluation window changed.
• Cross-scheme or cross-plane leakage: values are compared without an F.9 Bridge that makes exact endpoints, preserved and lost meaning, and crossing loss explicit.

CPM exists to make comparison explicit, admissibility-gated, set-valued, and replayable, so downstream selection can remain a separate policy-bound step.

#Forces

1. Usability vs correctness: engineers want a "simple compare" function; correctness demands explicit admissibility, explicit comparator choice, and explicit handling of incomparability and unknown evidence.
2. Total order convenience vs partial order truth: total orders simplify downstream selection; partial orders are often the faithful representation (especially in multi‑criteria settings).
3. Evolvability vs stability: comparator methods evolve (SoTA churn); kernel semantics and slot field sets must remain stable and wiring‑friendly.
4. Replayability vs speed of discussion: teams want fast decisions; replay requires the dated comparison U.Work, the actual Compare operation application with exact edition, policy, argument, and result bindings, and an A.10 evidence-provenance path.
5. Cross-scheme reasoning vs Bridge discipline: useful comparisons across reference schemes or planes require an explicit F.9 Bridge and cannot obtain scope, predicate, plane, or time from an umbrella context label.
6. Avoiding “second centers of gravity”: mechanism semantics must have a governing pattern; otherwise the suite, A.6.1 archetypes, and Part‑G wiring drift apart.

#Solution

CPM is specified as a canonical U.Mechanism.Intension whose core commitments are:

• Comparator admissibility is declared and gated (CG-Spec.ComparatorSet, and CG-Spec.SCP when numeric operations are involved; scale admissibility via CSLC).
• Results are set‑valued relation or poset tokens; partial orders remain partial; no silent scalarization or totalization.
• Admissibility is tri‑state and fail‑closed on missing admissibility and evidence; unknown never coerces into a fabricated outcome.
• Comparison remains distinct from selection; CPM produces relation outcomes; SelectorMechanism consumes them.

This pattern defines (governing-pattern, wiring‑friendly):

1. a stable mechanism boundary for admissible comparison: Compare(...) → ComparisonResultSlot plus a tri‑state CompareEligibility guard;
2. a stable SlotKind field set (by suite lexicon tokens) that downstream selection and Part‑G wiring can rely on without SlotKind drift;
3. an admissibility and evidence responsibility split: admissibility is gated by CG-Spec (and CSLC), while admission and comparability relations are cited from CN-Spec;
4. a minimal replay basis: dated comparison work, the effective refs and editions bound in the actual Compare operation application, its ComparisonResultSlot binding, and the A.10 evidence-provenance path needed to replay the comparison;
5. explicit planned-filling separation: SlotFillingsPlanItem rows carry planned edition and policy fillings; dated comparison U.Work remains the occurrence, the actual operation application carries argument and result bindings, and A.10 supplies the evidence-provenance path;
6. an explicit comparison-use boundary: claim scope, selected A.2.6 context slices, optional A.19 predicate, reference plane, and evaluation window are occurrence bindings, not generic context, comparator content, output fields, or an optional model-use structure.

#Mechanism.Intension (canonical; normative)

This is the canonical U.Mechanism.Intension for CPM.IntensionRef. It is intended to be cited by CHR suite publications and by any wiring layers.

• Declaration boundary: this A.6.1 mechanism intension declares Compare and CompareEligibility; it does not publish telemetry or create dated work, an actual operation application, comparison scope, result episteme, evidence use, provenance path, currentness relation, or publication relation. Each neighboring object or relation uses its direct governor.

  • Planned slot fillings: this intension does not fill project-specific slots for editions, policy ids, bridge ids, or similar pins. Planned fillers live in SlotFillingsPlanItem rows (A.15.3 plus A.19.CHR:4.7.2); dated comparison U.Work binds effective values as occurrence parameters.

• IntensionHeader: id = CPM, version = 1.0.0, status = stable.

• IntensionRef: CPM.IntensionRef designates this U.Mechanism episteme as the canonical suite member named in A.19.CHR:4.2; it is not the EntityOfConcernRef of the declared operation family.

• SignatureManifest (optional; importability): if a CPM publication is intended for reuse beyond the CHR suite, author SHOULD publish a SignatureManifest that records (i) the declared Compare stage‑op signature, (ii) the SlotKind field set (by lexicon tokens), and (iii) the explicit set‑valued output commitment (no silent scalarization or totalization).

• Tell. Lawful comparison producing set‑valued parity or poset outcomes (not a single scalar).

• Purpose: admissible comparison producing set‑valued parity or poset outcomes (not a single scalar).

• Imports: G.0 (CG‑Spec.ComparatorSet, CG‑Spec.SCP, CG‑Spec.MinimalEvidence), A.18 (CSLC), A.19.CN (comparability and admission declarations), A.19.CHR:4.2.1 (CHR SlotKind Lexicon).

• EntityOfConcernRef: the comparison operation family declared by Compare and CompareEligibility in this section.

• Effective U.ReferenceScheme: the CHR suite reference scheme in which the A.19.CHR SlotKind lexicon, CN-Spec, CG-Spec, and ComparatorSpec tokens are interpreted.

• Direct signature components:

  • SubjectKind: Comparison.
  • RangedValueKind: CHR-typed profile values in a CG-Frame (see CG-Spec.ComparatorSet).
  • ResultKind: U.Set of relation or poset tokens; the comparison result is set-valued by default.
  • SliceSet: U.ContextSliceSet.
  • ExtentRule: comparison ranges over admitted left and right profiles in one exact U.ClaimScope; selected U.ContextSlice values are members of that scope under A.2.6 and do not create a duplicate membership relation.

  These are direct A.6.0 declaration components. They do not form an additional comparison-content container, and they do not absorb comparator admission, evaluation, evidence-use, or replay relations.

• SlotIndex (derived projection from SlotSpecs and guard SlotSpecs; uses A.19.CHR:4.2.1 SlotKind tokens; no independent semantics):

  • LeftProfileSlot : ⟨ValueKind = U.Set (of U.Measure), refMode = ByValue⟩,
  • RightProfileSlot : ⟨ValueKind = U.Set (of U.Measure), refMode = ByValue⟩,
  • CNSpecSlot : ⟨ValueKind = CN‑Spec, refMode = CNSpecRef⟩,
  • CGSpecSlot : ⟨ValueKind = CG‑Spec, refMode = CGSpecRef⟩,
  • ComparatorSpecSlot : ⟨ValueKind = ComparatorSpec, refMode = ComparatorSpecRef⟩,
  • MinimalEvidenceSlot? : ⟨ValueKind = MinimalEvidence, refMode = MinimalEvidenceRef⟩ (optional override; otherwise cite CGSpecSlot.MinimalEvidence),
  • ComparisonResultSlot : ⟨ValueKind = U.Set (relation or poset tokens), refMode = ByValue⟩.

• OperationAlgebra (suite stage = compare, per A.19.CHR:4.5; canonical stage‑op = Compare):

  • Compare(LeftProfileSlot, RightProfileSlot, CNSpecSlot, CGSpecSlot, ComparatorSpecSlot, MinimalEvidenceSlot?) → ComparisonResultSlot.

• Comparison-use bindings for each actual application (required A.6.1 occurrence arguments; not CHR SlotKinds and not another container kind):

  • exact U.ClaimScope for the admitted profile pair and comparison claim;
  • selected U.ContextSlice members of that scope under A.2.6, without copying its membership relation;
  • optional by-value A.19 CharacteristicSpacePredicate, explicitly absent when comparison does not depend on one;
  • effective U.ReferenceScheme and reference plane; and
  • explicit comparison-evaluation point or interval.

  Together the profile pair and these bindings delimit the comparison scope. They do not form another U-kind, generic context input, model-use-structure field, or replay record. The comparator remains the separately declared ComparatorSpecSlot; evidence use retains its own A.2.4 claim scope and relevance window.

• LawSet (minimum; set-valued comparison, no hidden scalarization):

  1. ComparatorSet gate: ComparatorSpecSlot MUST be an element of CGSpecSlot.ComparatorSet (admissibility gate; cite G.0).
  2. Set‑valued semantics: ComparisonResultSlot is set‑valued (parity or poset tokens); partial orders remain partial — no silent totalization or scalarization.
  3. CSLC+SCP admissibility: any numeric ops implied by the comparator MUST be admissible under CGSpecSlot.SCP and CSLC-admissible (cite G.0 + A.18).
  4. Unknown is not coerced: missing or unknown evidence MUST NOT be mapped to a comparison outcome; use tri‑state guards.
  5. No hidden thresholds or tie-breakers: any thresholds, epsilons, priority orders, or tie-break logic MUST live in the declared ComparatorSpecSlot, or in CNSpecSlot.acceptance as explicit acceptance clauses, and be edition-pinned for replay; CPM MUST NOT smuggle constants.
  6. No implicit UNM: CPM does not normalize or align internally. Normalization-based comparability requires already-normalized inputs plus exact upstream normalization refs; otherwise eligibility is degrade or abstain.
  7. No silent boundary change: a Compare application does not silently change its profile pair, U.ClaimScope, selected context slices, optional A.19 predicate, comparator, reference scheme or plane, or evaluation window. A changed binding is a different application and requires a newly evaluated outcome.

• AdmissibilityConditions (tri‑state guard; fail‑closed on missing admissibility and evidence):

  • CompareEligibility(LeftProfileSlot, RightProfileSlot, CNSpecSlot, CGSpecSlot, ComparatorSpecSlot, MinimalEvidenceSlot?; comparison-use bindings) → GuardDecision ∈ {pass|degrade|abstain}.
  • pass requires: (i) comparator admission; (ii) scale-admissible operations; (iii) admitted and comparable profiles under the exact claim scope and selected A.2.6 context slices; (iv) an explicit evaluation point or interval and reference plane; (v) the same by-value A.19 predicate when one is used; and (vi) satisfaction of the effective MinimalEvidence policy.
  • If CNSpecSlot.comparability is normalization‑based (compare‑on‑invariants), pass additionally requires that the inputs are already in the required invariant and normalization regime; CPM MUST NOT “make them comparable” by silent normalization.
  • If MinimalEvidenceSlot is absent, the guard MUST evaluate evidence against CGSpecSlot.MinimalEvidence (by explicit rule), and MUST NOT return pass when evidence is missing or unknown or fails the effective MinimalEvidence gate.

• Applicability:

  • Intended for the CHR stage compare: it may follow indicatorization or scoring and optional folding when those stages are present, and it precedes selection wherever selection occurs. It remains distinct from selection.
  • Applicable only when CGSpecSlot supplies the current admissibility and evidence-policy declarations. Missing declarations fail closed.
  • Inside the CHR suite, A.19.CHR:4.5 alone determines stage ordering and optionality; CPM does not infer order from mechanisms[].
  • Every actual comparison binds one exact U.ClaimScope, selected A.2.6 U.ContextSlice members, optional A.19 predicate, effective reference plane, and explicit evaluation point or interval. There is no implicit latest value and no default window inherited from the predicate.
  • Cross-reference-scheme or cross-plane use requires an explicit F.9 Bridge. The Bridge does not supply claim scope, selected slices, predicate, comparator, or evaluation time.

• Neighboring bridge relation:

  When the two profiles require interpretation across reference schemes or planes, state the F.9 bridge relation separately. Name its exact endpoints, preserved and lost comparison meaning, applicable use, CL value, and any R_eff penalty. Adding or changing that bridge does not by itself change the CPM declaration.

• Neighboring dated work, operation application, result binding, and evidence relations:

  A dated comparison run is A.15.1 U.Work. Its actual A.6.1 Compare application binds the profile pair, comparator, comparison-use arguments, policies, and set-valued ComparisonResultSlot. A.2.4 separately governs evidence use with its own evidence claim scope and relevance window; A.10 governs provenance; G.11 governs source or assertion-edition currentness. A durable result episteme, when needed, is governed by C.2.1, and any current entity-identity inception claim by A.15.PROD. No universal work-result or comparison-result relation is presumed. To replay the comparison, recover:

  • the two profile values or exact upstream refs, one U.ClaimScope, selected A.2.6 context slices, optional A.19 predicate, effective reference scheme and plane, and evaluation point or interval;
  • CNSpecRef.edition, CGSpecRef.edition, and the effective ComparatorSpecRef;
  • the effective MinimalEvidence policy, either the explicit override or CGSpecSlot.MinimalEvidence;
  • the realized GuardDecision and, for degrade or abstain, any current downstream-handling policy;
  • the effective upstream normalization dependency, or the explicit absence that caused degradation or abstention;
  • the comparison result and any bridge, CL, and ReferencePlane refs used by this occurrence.

  Use G.9 when a parity or benchmark use requires a stable run package and report record. These neighboring records support replay; none is CPM declaration content.

#Interpretation notes — informative

• The output is a value, not a replay container. The by-value set bound to ComparisonResultSlot contains relation or poset tokens only. Comparator, scope, predicate, plane, window, eligibility, evidence use, provenance, and currentness remain separate bindings or relations.
• Set-valued output is the default, not a loophole. “Set‑valued” means CPM preserves incomparability, ties, and partiality as first‑class outcomes; it does not authorize silent post‑processing into a scalar or a single winner.
• Total orders are allowed only if declared by the comparator. If a ComparatorSpec defines a total order, CPM still outputs a (singleton) set of relation tokens; the totalization is a property of the declared comparator, not an implicit kernel default.
• Normalization is not smuggled into comparison. If CN‑Spec.comparability declares normalization‑based invariants for comparison, that dependence must be represented explicitly via the suite protocol and, where needed, explicit Uses contours (CPM consumes admitted profiles; it does not silently normalize them).
• Thresholds and tie-breakers are never kernel constants. If thresholds exist, they belong to explicit policies or specs such as ComparatorSpec and AcceptanceClauses, are edition-pinned, and are recorded by the dated comparison occurrence for replay.

#Archetypal Grounding — informative

#Tell

Think of CPM as a declaration for a replayable, relation-producing comparison operation:

• Input: "two admitted profiles + an explicit comparator spec + declared admissibility and evidence declarations"
• Output: “a set‑valued relation outcome that preserves incomparability and uncertainty”

The key didactic boundary is: CPM compares; it does not decide.

#Show (U.System) — comparing two supplier options without faking a total order

A program manager compares Supplier‑A vs Supplier‑B for a safety‑critical component. The team tracks a profile of measures (cost, lead time, defect rate, assurance, sustainability), but not all measures are strictly comparable across regions (different reporting regimes, different units).

• The project has a declared CN‑Spec (admission and comparability declarations) and a declared CG‑Spec that lists admissible comparators in ComparatorSet and evidence rules in MinimalEvidence.

• The comparator is ParetoDominanceComparatorSpecRef@edition, declared in CG-Spec.ComparatorSet.

• The actual application binds the two supplier profiles; the claim scope supplier options for the named component and procurement decision; its selected regulatory and reporting U.ContextSlice members under A.2.6; ComparisonPredicate = none because Pareto dominance is supplied by the comparator; the stated procurement reference plane; and the explicit comparison interval.

• CPM runs Compare(...); a changed component, scope member, comparator, plane, or interval is another comparison rather than an update to the same output.

  • If Supplier‑A is better in cost but worse in defect rate and incomparable on assurance due to missing evidence, CPM does not invent “A wins” or “A loses”.
  • CompareEligibility returns degrade or abstain under the evidence policy. On abstain, no comparison tokens are fabricated. When an explicit degrade policy permits a bounded partial comparison, ComparisonResultSlot contains only the justified relation tokens and preserves incomparability.

• The downstream SelectorMechanism can then return a selected set (e.g., keep both suppliers in the candidate set) rather than forcing a single winner by hidden tie‑break rules.

#Show (U.Episteme) — uncertainty‑aware comparison with set‑valued outcomes

A research lead compares two proposed methods for a system component. Both methods have performance estimates with uncertainty bounds (e.g., distributions or prediction intervals). The team uses a SoTA uncertainty quantification package (post‑2015 conformal families are a common example) to avoid overstating confidence.

• USCM produces score profiles that are interval‑valued (or otherwise uncertainty‑annotated) rather than point estimates.
• The chosen comparator is uncertainty‑aware and declared as a ComparatorSpec (edition‑pinned) in CG‑Spec.ComparatorSet.
• CompareEligibility returns its guard value separately. If comparison proceeds, CPM returns justified relation tokens such as not worse or incomparable; if it abstains, no abstain token is smuggled into ComparisonResultSlot.
• The dated comparison U.Work, actual Compare application with its effective comparator, evidence-policy, and ComparisonResultSlot bindings, and A.10 evidence-provenance path let later readers reproduce why the comparison abstained or degraded instead of mistaking missing evidence for equality.

#Bias-Annotation — informative

CPM is a comparison kernel; it does not remove bias by itself, but it prevents the most common bias‑amplifying failure modes (hidden thresholds, hidden tie‑breakers, unknown coercion).

Typical bias risks and mitigations:

• Comparator choice encodes value judgments. Weights, priority orders, thresholds, and “tie‑break” conventions can encode organizational bias. CPM forces these to live in explicit, edition‑pinned ComparatorSpec records or policy records rather than in invisible code or informal reasoning.
• Missing evidence is rarely random. If evidence is systematically missing for certain contexts or groups, naive “unknown → worse” is a bias amplifier. CPM’s tri‑state guard avoids coercion; but teams must still define policy‑bound failure behavior and be explicit when abstention is acceptable.
• Cross-scheme comparisons can embed structural unfairness. CPM requires an explicit F.9 Bridge when reference schemes or planes differ. The Bridge exposes preserved and lost meaning; it cannot silently replace comparison scope, predicate, comparator, or time.
• Overconfidence via scalarization. Collapsing partial orders into scalars often overstates certainty and hides tradeoffs. CPM makes set‑valued outcomes first‑class, so the human or managerial decision can remain honest about tradeoffs.

#Conformance Checklist

A CPM publication or use is conformant if it satisfies the checks below together with the A.6.1 mechanism conformance checklist and the CHR suite obligations in A.19.CHR:4.3:

#Common Anti‑Patterns and How to Avoid Them

• Anti‑pattern: “Comparison returns a score.” Symptom: Compare(x,y) returns a numeric margin or a single rank position. Avoid: keep numeric scoring in USCM; CPM returns relation tokens (set‑valued). If a numeric comparator is desired, it must be an explicit ComparatorSpec and still yields relation tokens as the kernel output.

• Anti‑pattern: “CPM picks the winner.” Symptom: comparison logic embeds winner selection or selected-set truncation. Avoid: CPM only compares; selection is SelectorMechanism, which consumes comparison outcomes and remains policy‑bound.

• Anti‑pattern: “Comparator by prose or code default.” Symptom: comparator choice is implicit (e.g., “we usually do lexicographic by safety then cost”), not edition‑pinned. Avoid: require an explicit ComparatorSpecRef from CG-Spec.ComparatorSet; dated comparison U.Work binds the effective edition as an occurrence parameter, and A.10 supplies its evidence-provenance path.

• Anti‑pattern: “GateDecision leakage.” Symptom: the compare step emits or assumes GateDecision, GateLog, or DecisionLog records as part of suite closure, or uses reserved gate‑lexemes (…Guard) for mechanism‑level predicates. Avoid: keep CompareEligibility as the mechanism-level tri-state predicate and assign gate decisions to their governing pattern. Keep dated comparison U.Work, the actual Compare operation application and its result binding, any result episteme, A.10 evidence-provenance, G.11 currentness, and publication relations separate from CPM declaration content.

• Anti‑pattern: “SlotKind drift.” Symptom: renaming or re‑purposing LeftProfileSlot, RightProfileSlot, ComparatorSpecSlot, or ComparisonResultSlot across specializations or across CHR layers. Avoid: use the suite SlotKind lexicon (A.19.CHR:4.2.1) and keep SlotIndex as a derived projection.

• Anti‑pattern: “Smuggling plan‑binding into CPM.” Symptom: hard‑coding comparator editions, policy ids, or “launch values” inside the CPM intension or pattern prose. Avoid: put edition and policy fillers only in SlotFillingsPlanItem rows; dated comparison U.Work binds effective refs as occurrence parameters, and A.10 supplies the evidence-provenance path.

• Anti‑pattern: “Tie‑breakers as hidden constants.” Symptom: forced total order via untracked thresholds, epsilons, or “if equal then compare cost” logic. Avoid: make tie-break policy part of explicit comparator and acceptance policies, pin their editions, and record their effective use in the dated comparison occurrence.

• Anti‑pattern: “Unknown coerces to outcome.” Symptom: missing evidence treated as equal, zero, or worse, producing decisive comparisons from absent information. Avoid: tri‑state guard; fail‑closed on missing evidence; explicit failure behavior via evidence policy.

• Anti-pattern: ComparisonResultSlot as a replay record. Symptom: comparator, scope, predicate, window, evidence, or currentness fields are placed inside the set-valued output. Avoid: keep the output to relation or poset tokens; recover effective arguments from the actual operation application and direct neighboring relations.

• Anti-pattern: Cross-reference-scheme or cross-plane comparison without a bridge. Symptom: profiles interpreted under different reference schemes or planes are compared without an F.9 bridge, preserved and lost meaning, CL value, and reference-plane conditions. Avoid: state the F.9 bridge relation, assign any penalty to R_eff, bind its effective ref on the dated comparison U.Work, and cite it from the A.10 evidence-provenance path.

#Consequences

• Improved usability (didactic): CPM gives a single, engineer‑readable place to learn “what admissible comparison means” and what it does not mean.
• Higher replayability: comparison results remain traceable through dated comparison U.Work, the actual Compare application and its ComparisonResultSlot binding, the A.10 evidence-provenance path, and any current F.9 bridge relation.
• Reduced semantic drift: teams cannot silently shift from Pareto to lexicographic to “weighted sum” without changing explicit comparator specs and pins.
• Explicit tradeoffs: set‑valued outcomes force downstream reasoning to acknowledge incomparability and uncertainty rather than hiding them.
• Cost: downstream consumers (notably selection) must handle sets, abstentions, and partial orders explicitly. This is intentional: it moves complexity from hidden heuristics into explicit policy‑bound mechanisms.

#Rationale

1. Set‑valued by design: partial orders are common in multi‑criteria settings; pretending they are total creates false certainty and brittle decisions.
2. ComparatorSet gating: declaring which comparisons are admissible, and under what scale or evidence rules, prevents “algorithm by convenience”.
3. Tri‑state guards: explicit pass|degrade|abstain preserves epistemic honesty: unknown is not silently converted into an outcome.
4. Strict distinction: separating compare from score and select prevents hidden semantic coupling and improves evolvability (methods change via wiring; kernel stays stable).
5. Single governing pattern: keeping one governing pattern eliminates near-duplicate comparison descriptions that drift apart and destroy usability.

#SoTA-Echoing

SoTA vs popular note. This section records alignment to post‑2015 evidence‑backed practice. It is not a mandate to use fashionable methods; method semantics stay in SoTA packs (G.2) and wiring modules, while this pattern fixes the stable CPM mechanism boundary.

Concrete comparator-family SoTA packages are cited through their current Part G pack or claim sheet when one governs the use. CPM's kernel semantics remain unchanged.

#Currentness and smallest reopen rule

Qualification basis and window. The stable kernel claim is qualified by the current editions of A.6.1/A.6.5 operation and slot discipline, A.19/A.18 space and scale semantics, A.19.CN comparability, G.0 comparator and evidence admissibility, A.2.6 scope semantics, and the exact current G.2 comparator pack or claim sheet cited by an actual use. For that use, the effective qualification window is the intersection of those bound editions' currentness and any validity interval declared by the comparator pack or claim sheet; post-2015 is an orientation label, not an indefinite freshness claim.

Reopen the CPM kernel only when. Reopen the smallest affected CPM rule when a direct governor changes binary Compare application identity or bindings, ComparisonResultSlot kind, comparator admission, scale or normalization admissibility, tri-state eligibility, comparison scope, or the separation of output, evidence, provenance, and result epistemes, or when qualified evidence contradicts one of those kernel commitments. A new algorithm family, learned model, fairness constraint, uncertainty method, threshold, or robustness technique that still satisfies those commitments changes its G.2 pack, ComparatorSpec, CG-Spec, or policy binding rather than CPM.

Smallest affected locus. A signature or result-kind change reopens only the corresponding direct-signature, SlotSpec, or OperationAlgebra passage in A.19.CPM:4.1; an admissibility or failure-semantics change reopens the matching LawSet or AdmissibilityConditions clause. Update only the nearest exercising case in A.19.CPM:5.2 or :5.3 and the corresponding CC-A19CPM row. Source-family churn that changes no kernel commitment updates the direct pack or claim sheet and, when its summary is stale, only the affected row in this SoTA map.

#Relations

Builds on and cites (non‑exhaustive):

• A.6.1 (shape of U.Mechanism.Intension; specialization discipline)
• A.6.5 (slot discipline; SlotIndex as derived projection)
• A.19.CHR (suite membership + obligations + suite_protocols; CHR SlotKind lexicon)
• A.15.3 + A.19.CHR:4.7.2 (planned slot-filling ontic and SlotFillingsPlanItem rows; CPM remains refs-only with respect to planned slot filling)
• A.19 for CharacteristicSpace and the optional by-value CharacteristicSpacePredicate used by one comparison
• A.2.6 for U.ClaimScope identity and exact U.ContextSlice membership
• A.19.CN for CN-Spec comparability plus acceptance and admission declarations
• G.0 (CG‑Spec: ComparatorSet, SCP, MinimalEvidence, CL and ReferencePlane framing)
• A.18 (CSLC scale admissibility)
• C.27.TA for an explicit comparison-evaluation point or interval
• A.2.4, A.10, and G.11 for evidence-use scope, provenance, and currentness, separately from comparison scope and outcome
• E.10 (lexical and ontological authoring rules; kind suffix discipline)
• E.19 (checks; authoring discipline)
• E.20 (governing-pattern discipline)
• F.18 (alias docking; ID continuity)
• E.18 (project transformation-flow structures consume CPM instances; CPM does not create a parallel “card deck”)

Relates to (typical named patterns in the CHR Uses contour):

• UNM.IntensionRef, UINDM.IntensionRef, USCM.IntensionRef, ULSAM.IntensionRef, and SelectorMechanism.IntensionRef (downstream consumer of CPM results).
• G.5 (selection conformance), G.9 (parity and benchmark harness), G.10 and PTM (publication and telemetry outside suite closure).

#A.19.CPM:End

---

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