| Primary-EntityOfConcern drift | The draft appears to govern one thing in the opening, another in the declaration block, and a third in the examples or related-pattern or companion guidance named by value. | Review cannot tell whether the pattern defines or constrains a PublicationUnit, an interpretive move, a work-result record, or a whole process, so later naming and boundary decisions become unstable. | Stabilise one primary EntityOfConcern early, keep its head kind explicit, and mark note, sheet, UI, rendering, or process labels as either examples of that object or separate related entities rather than stylistic substitutes. |
| Reader-fit clean but pragmatically foggy | The draft is addressed to the right reader in principle, but cold working readers still cannot recognise the situation, practical payoff, primary EntityOfConcern, relation named by value, claim record, or first useful move early enough. | The run passes reader-fit hygiene while still failing pragmatic fit and first-minute usability. | Pull a recognisable working situation upward, add one minimally viable worked case, make the practical payoff explicit in nearby user-facing prose, expose the primary EntityOfConcern and any minimal modeling lens in plain terms, add plain glosses for early claim-bearing terms, and require SoTA-Echoing rows that carry claim kind, admissible-use boundary, or explanatory work to name the practitioner or manager implication plus the case they discipline. |
| Architecture-clean but domain-thin | The text is internally well placed in the package, but the primary EntityOfConcern, narrowed branch, or practical payoff are justified mainly through package architecture while the problem-owning domain, practice, or SoTA appears late or decoratively. | The pattern passes internal architecture checks while drifting away from the domain whose work it claims to improve. | Pull the problem-owning domain moment into the recognition text, make the narrowed branch and primary EntityOfConcern answerable to the relevant domain or practice, and require FPF-governed SoTA-Echoing to discipline the practical cases rather than merely bless them after the fact. |
| Type-correct but inert precise-language repair | A F.19 repair, located or routed with E.10 when needed, restores kind language but leaves the reader unable to say why the distinction matters, what use remains, which definition, constraint, or test carries a formal claim, or how Plain wording maps back to the Tech reading when both registers are used. | The review accepts typed wording while losing action guidance. | Restore the working situation, reader use, and the contributing pattern or rule; map Plain wording back to the Tech reading when both are used. Keep the explanation ordinary unless a live contrast or named reliance needs an exact assertion, predicate, ClaimGraph, or displayed identity. Apply CC-E19-0 only if the repaired claim asserts dated Work. |
| Expressive overread rebound after precise-language repair | The pass makes the text more engaging, but the added Plain or didactic wording carries an ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim not recoverable from the Tech reading or cited rule. | The review mistakes readability for recovered semantic work. | Keep the line ordinary when it only helps recognition. Otherwise recover the claim kind or admissible-use boundary through the Tech reading and cite the pattern or rule that defines or tests it; use a grounded non-use disposition only when the receiving use needs it, or return an incomplete rewrite. |
| Profile or record as reviewer. | A selected PCP, checklist, findings form, result episteme, or review record is said to have performed the review, repaired the pattern, admitted it, supplied assurance, or authorized downstream use. | Reviewer action, repair, result, evidence, and decision authority collapse. | Say ordinarily that a reviewer applies the questions and name the action actually performed. Profiles and checklists declare questions; findings and records state review claims. Apply CC-E19-0 only when the claim deliberately asserts dated Work; add evidence, assurance, or decision relations only when they independently obtain. |
| Verdict-only review | Independent review ends with pass/fail or prose complaints but no complete actionable finding set, or repair-mode review reports defects without repairing and rechecking them. | Leaves later work to rediscover diagnosis or mistakes an intention to repair for a completed repair. | In independent review, record every actionable in-scope defect and blocker with precise direction; in inspect-repair-verify, repair and verify them. Questions with no defect get no durable pass recital. |
| Single giant checklist | Review becomes a long, unfocused ritual that few complete. | Increases cost; reduces fit and rigor in practice. | Use a minimal baseline plus risk-selected profiles; use E.21 only when a pattern-version quality value is being evaluated. |
| Template-only compliance | All headings exist, but requirements are vague and untestable. | Looks uniform; fails enforceability and auditability. | Enforce normative clause hygiene and CC/Solution coherence. |
| SoTA name-dropping | SoTA-Echoing is a list of buzzwords with no stance. | Breaks evidence lineage; invites monoculture. | Require adopt/adapt/reject with reasons per item. |
| Terminology drift by “synonym” | Authors swap kernel terms for nicer-sounding words. | Increases ambiguity; harms cross-pattern composability. | Apply PCP-TERM and preserve established kernel terms. For a genuinely introduced term, use E.8 S-3’s first-appearance gloss; use F.18 when a durable reusable name is needed. |
| Lexical substitution accepted as repair | The reviewed text no longer contains the trigger word, but the replacement changes the FPF kind, relation, current ontic slot, relation position, use relation, or claim kind, admissible use, or scope. | The review rewards surface cleanup while ontology drift remains or gets worse. | Apply F.19’s KindPreservationCheck comparison; its separate result form is optional. If pre/post kinds or slots, relation positions, use relations, or claim kinds do not match and no accepted split/change decision supplies the change, keep the finding blocking. |
| Form-only review | Review time goes to formatting and micro-edits while the normative content, terms, Bridges, modularity, slot discipline and SoTA stance are barely checked. | Raises editorial cost without raising semantic trust. | Use the triage rule: treat FPF-governed sections as depth loci and keep mechanical cleanup subordinate to semantic correction. |
| Checklist-clean but content-wrong | The named profiles, lexical checks, and conformance rows are marked complete, but the repaired text no longer solves the stated problem, assigns a claim to the wrong locus, creates shadow authority, loses a selected companion or projection function, or adds needless boilerplate or support material. | Review accepts a locally tidy pattern while weakening the actual FPF guidance. | Apply substantive solution and locus adequacy: name local content questions, check the actual problem and governing loci named by value, ask what became worse, and widen the declared boundary by value when the fix belongs outside the initial reviewed pattern or subset. |
| Architecturally right, didactically thin | The family is admissible, but readers still need project notes to understand what the pattern really governs. | Trust in the pattern depends on external context rather than the pattern text. | Add the missing problem frame, worked slices, local definitions, and guidance naming the concrete contribution of a relevant pattern or the project-side FPF kind and reference before admission. |
| Scenario-name grounding | Grounding names a situation but does not show what the source and resulting publication actually look like. | Readers cannot tell why the case stays in the family or where it leaves the family. | Add concrete source and resulting-publication slices, especially for transform families and easy boundary confusions. |
| Generic-head underspecification | An FPF-governed phrase uses a generic head such as note, view, guidance, output, or artifact, but the run leaves that head uninterpreted. | Review discusses the sentence before the object kind is even stable. | Use the F.19:4 head-kind and precision-before-coarsening rules, with the object’s defining pattern where its kind remains unresolved. |
| Qualifier-smuggled claim kind or admissible-use boundary | A modifier such as comparative, safe, interactive, reliable, or faithful is doing the semantic work while the run treats the phrase as already precise. | The review blesses apparent precision without recovering the actual claim kind or admissible-use boundary. | Use F.19:4 to unpack the qualifier’s claim kind, comparison criterion, and admissible or downstream-use boundary before accepting the phrase. |
| Mixed comparison criterion | One sentence compares or ranks publication-form, carrier, process, authority-reference, or project-record values without a shared governed comparison basis. | The ranking’s criterion or condition remains unjustified; different object kinds alone do not invalidate a shared criterion. | Use F.19:4’s precision-before-coarsening rule and its comparison/condition-basis test. |
| Sentence-level shorthand drift | A few innocent-looking words (“species”, “branch”, “flow”, “input/output”) quietly carry the claim kind or admissible-use boundary. | Review passes while key relations remain implicit or wrong. | Read the complete affected span through F.19. Recover any missing claim, relation, definition, constraint, test, package relation, or publication meaning only where it changes the current use. |
| Package-form, pattern-contribution, and package-relation drift | The text slides between family, bundle, cluster, profile, overlay, suite, kit, or record without showing that the ontology changed. | Reviews miss the difference between a concrete pattern-to-claim contribution, an authority reference, and a package relation because each local sentence still sounds plausible. | Require one intended package-function word, name the definition, constraint, test, or other pattern contribution actually used, check the package relation explicitly, and treat stylistic noun-swapping as a semantic defect. |
| Reader-fit leakage | Pattern sections explain why the pattern was isolated, what landing form is safest, or why merge or freeze is premature. | Review accepts a package memo disguised as a user pattern. | Move current-version package-development reasoning to its companion or governing publication, integration, or release result. Keep the user’s action and any warranted applicability boundary; cite the subject pattern only for an actual separate release, policy, assurance, gate, action-selection, or adjudication claim. |
| Quality-carrier leakage | Pattern prose explains corpus projection, retrieval evidence, publication parity, integration evidence, PatternQualityStatus, all-4/all-5 posture, or development correspondence about its own current version as if it were user guidance. | Review accepts quality proof or package evidence disguised as pattern content. | Move it to the governing E.21 result, E.19 findings, README/ToC/E.11, or projection, publication, integration, or release result; keep only the user-facing move or boundary justified by that evidence. |
| Apparatus overwrap | A simple claim, relation, object, action, or placement is wrapped in role-word, carrier, locus, flow, state, status, text, package, or process language that adds no new kind or user-facing action. | Review accepts bureaucratic prose as precision, or replaces it with prettier prose that loses the FPF kind. | Use F.19’s apparatus/content distinction, contribution test, and KindPreservationCheck comparison. Retain content-bearing apparatus under its defining pattern; otherwise remove the wrapper and preserve the same EntityOfConcern, head kind, relation or claim kind, admissible use, and established FPF term. |
| Companion material retained by inertia | A companion note, profile, check sheet, companion row, or review harness remains attached to a pattern family after the pattern body already carries the usable guidance, but the text does not say what real breakage returns if that companion material is absent. | Companion material becomes permanent local folklore, hidden authority, or reader cost without a corresponding use gain. | State the companion-use question, governing source, companion-only use, real breakage if absent, and retention, accepted-source-material-only, or removal condition; otherwise fold the useful example into the pattern or keep it only in the accepted source material. |
| Pattern-quality result as project certificate | An E.19 pass is cited as proof that a project release, safety claim, compliance state, work result, publication, or gate has passed. | Collapses FPF pattern-quality review into project-world evidence or gate authority. | Keep E.19 as pattern-quality review; open A.10, B.3, A.20, A.21, A.15, or the pattern that defines or constrains the project-side claim being made. |