A.19.CPM:8 - 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: select intended editions and policies in the A.15.2 baseline; use A.15.3 typed filling only for independently declared positions. Establish actual Compare bindings under §4.1 and cite Work/provenance only under their own grounds.

• 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: Using one F.9 Bridge rule for both semantic and ReferencePlane crossings. Symptom: an F.9 Bridge is required merely because reference schemes or planes differ; the separate C.2.1 bounded-use claim is absent; or CL and a bare R_eff penalty are treated as mandatory. Avoid: cite an obtaining F.9 Bridge and separate bounded-use claim only for the semantic branch; cite the applicable ReferencePlane relation and policy for the plane branch; state both when both facts are current. Make only actually consumed refs recoverable with the dated U.Work and actual Compare application. Add CL only when needed. Open B.3 only for an actual named assurance claim, and use a local R_eff only if its declared domain model and calculation define it. Use A.10 for evidence provenance and ordinary bounded reliance, not to establish either crossing relation.