#Pattern Quality Gates: Review and Refresh Profiles

E.19 · Stable · Architectural pattern · Normative · Part E - The FPF Constitution and Authoring Guides

#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 pattern Status: Stable Normativity: Normative

Use E.19 when one exact new, substantially revised, or aging FPF pattern edition or bounded subset needs a repeatable admission, refresh, or return-for-repair review. E.19 declares profile-based checks and conclusion semantics; actual reviewer systems perform dated review work and separately constitute findings/results and any authority-bearing decision.

#Relations

#Content

#Use this when

Use E.19 when one exact new, substantially revised, or aging FPF pattern edition or bounded subset needs a repeatable admission, refresh, or return-for-repair review. E.19 declares profile-based checks and conclusion semantics; actual reviewer systems perform dated review work and separately constitute findings/results and any authority-bearing decision.

Use it especially when a draft looks structurally compliant but may still fail on first-minute usability, primary EntityOfConcern stability, terminology, SoTA grounding, related-pattern boundaries, examples, anti-patterns, or shipping-facing authority claims.

Not this pattern when. Use E.8 to write the pattern body. Use E.9 to record the content decision that explains why FPF should change. Use E.9.DA when the question is whether one concrete DRR episteme is adequate for a declared downstream authoring use before drafting or host amendment. Use E.21 for ordinal pattern-quality evaluation of one exact pattern version. Use E.23 when the aim is repeated quality improvement against an object-under-improvement evaluation rather than one admission or refresh review profile. Use local patterns for the domain rule or constraint being reviewed. Use project gate or release patterns when the question is whether a project publication, work-result record, or release candidate passes a delivery gate. E.19 governs review of FPF pattern admission/refresh only; its profiles and results do not certify the world, project, publication, or release.

#What goes wrong if missed

Review collapses into heading compliance or personal taste. A draft can pass because it has the right headings while still being hard for a practitioner to recognise, too thin against current practice, unclear about its primary EntityOfConcern, relation record, or claim record, or misleading about related governing patterns and authority claims.

#What this buys

E.19 gives authors, reviewers, and stewards a shared review profile: what must be checked, how deep the check should go, which defects block admission or refresh, and what evidence is needed before a pattern-quality claim is made. It also makes the recognition text visible before the heavier assurance machinery begins.

First useful move. Name the exact reviewed pattern edition or subset, admission/refresh question, U.ClaimScope, qualification window, PCP-BASE plus each risk-selected profile, and the semantic review method. When actual review is claimed, identify the reviewer system, obtaining role assignment, dated review work, and exact check applications before constituting findings or a review-result episteme.

Local-repair boundary. If baseline triage shows that the current review question has no present ontology, usability, SoTA, boundary, naming, or authority risk beyond a small mechanical repair, close with that repair direction. Do not run every profile just because E.19 exists, and do not claim an E.21 quality value unless E.21 has evaluated the pattern version over its required coordinate set.

Primary EntityOfConcern in plain terms. One exact FPF pattern edition or bounded subset under a declared admission or refresh review question. The PCP declarations, review method, reviewer assignment, review/repair/verification work, findings, aggregate result episteme, witnesses/evidence use, and any authority-bearing admission or refresh decision are separate objects.

Primary working reader. The first reader is an FPF reviewer, with the pattern author close behind. The review must still be answerable to the eventual practitioner or manager who will rely on the admitted pattern.

#Problem frame

FPF evolves by adding and revising patterns. Over time, the framework accumulates two kinds of risk:

1. Admission risk — a newly authored pattern can be structurally compliant yet still fail on ontology, semantics, terminology conflicts and vagueness, scope, SoTA in related disciplines, or cross-context hygiene.

2. Staleness risk — older patterns can remain internally consistent while drifting away from contemporary practice and newer parts of FPF, current internal vocabulary, or updated related governing patterns. The result is “quiet decay”: the pattern still appears clear, but becomes misleading, incomplete, or incompatible.

FPF already contains many checklists and constraints, but they are distributed across patterns and suites. Authors and reviewers therefore lack a single, repeatable way to answer: What should be checked, and how deep, before a pattern is admitted or kept?

#Problem

Without a unified, explicit review pattern:

• Different reviewers optimize for formal or template compliance and miss deeper ontological, semantic, and naming issues, producing bureaucratic output that does not improve the enforceable Conformance Checklist.
• Authors “optimize for the visible checklist” and miss hidden requirements (lexical discipline, Bridge hygiene, SoTA‑Echoing quality, scope claims, delta‑class impact).
• Older patterns accumulate conceptual staleness and diverge from current practice, current terminology, or current internal invariants.
• The specification's normative content becomes harder to trust: compliance becomes a matter of reviewer taste rather than a repeatable gate.

#Forces

#Solution — Profile-based gates for admission and refresh

Establish Pattern Quality Gates (PQG): a conceptual family of profile-based declarations for admission and refresh checks rather than a single monolithic checklist.

A Pattern Check Profile (PCP) is a named bundle of check families. Profiles are additive: every review configuration includes the baseline profile and only the risk-driven profiles needed by the declared question. A PCP specifies questions and closure conditions; it is not a reviewer, U.Method, work occurrence, finding, result, or gate decision.

Terminology note (disambiguation). PQG and PCP are editorial review constructs in the authoring plane (Part E). They are distinct from enactment and runtime gating constructs such as OperationalGate(profile), GateProfile, and GateDecision (A.21), which govern Work transitions and gate decision policies elsewhere in FPF.

Mint vs reuse. This pattern mints PQG, PCP, and the profile IDs PCP-BASE, PCP-MOD, PCP-PRAG, PCP-NORM, PCP-SOTA, PCP-BRIDGE, PCP-SUITE, PCP-P2W, PCP-TERM, PCP-DEONT, PCP-REFRESH, and PCP-ENTRY. It reuses existing FPF terms (e.g., Delta-Class, DRR, Bridge, CL, SoTA Synthesis Pack) without changing their meanings.

For one actual E.19 review or refresh, keep independently recoverable:

1. the exact reviewed FPF pattern edition or bounded subset and the declared admission/refresh question;
2. the review configuration: baseline and risk-selected PCP declarations, exact question scope, use, qualification window, and stop boundary;
3. a separately identified semantic review U.Method;
4. the reviewer U.System, obtaining U.RoleAssignment, dated review U.Work, and enacted method;
5. each exact PCP check application and A.6.1 binding to the reviewed loci;
6. any distinct authoring/repair work, changed pattern edition, and focused verification work/application in inspect-repair-verify form;
7. actionable finding or blocker claims, focused-verification claims, and one C.2.1 aggregate E.19 review-result episteme when a durable conclusion is required;
8. any separate authority-bearing admission, refresh, return-for-repair, or waiver decision and its decision work;
9. witnesses and exact A.10 evidence-use/provenance relations, plus any B.3 assurance or reliance result; and
10. any F.10 status value/use/interpretation, publication occurrence/form/carrier, and currentness relation.

The phrase review run is Plain shorthand for that configured set of objects and relations, not a new kind or actor. A profile, checklist, filled findings form, result episteme, or published record performs no review and grants no admission, assurance, authority, status use, or U.View membership.

#Define the reviewed pattern or subset

Name the exact reviewed pattern or landing subset, its edition or other stable version basis, the admission or refresh question, the baseline and risk-selected profile questions in scope, and the exact review configuration. Profile choice narrows review depth; it does not turn the selected questions into a progress record or perform the review.

When actual review is claimed, identify the semantic review method, reviewer system and obtaining role assignment, dated review work, and exact PCP check applications/bindings. If a durable aggregate result is needed, constitute a C.2.1 result episteme whose EntityOfConcern is the exact reviewed pattern edition or subset and whose ClaimGraph states the review scope, applicable profile questions, actionable findings/blockers or aggregate cleared boundary, conclusion, non-use, and reopen condition. Witnesses, evidence use, the optional result record/publication, and any authority-bearing admission or refresh decision remain separate. Choose one review form. An E.19 review has two forms:

1. Inspect, repair, and verify. One bounded portion may coordinate dated review work, authoring/repair work, and focused-verification work; identify them separately whenever their performer, method, affected object, or result differs. Review work applies every selected question, repair work changes each in-scope defect in the pattern/subset, and verification work reapplies the affected checks. The changed edition and focused-verification claims carry the substantive evidence; constitute an aggregate E.19 result episteme only when a receiving admission/refresh decision requires it. A separate findings record is made only for an unresolved blocker, a decision outside current authority, or transfer to another author.
2. Independent findings. Dated reviewer work applies the selected questions but does not change the reviewed pattern/subset. One C.2.1 findings-result episteme or semantic handoff records every actionable defect and blocker, with repair direction precise enough for the author to act without repeating the diagnosis. It is neither review work nor an admission decision.

A selected question that reveals no defect requires no durable pass entry. Independent review does not accumulate positive recitals, and inspect-repair-verify does not duplicate completed repairs in a parallel findings record. If another governing pattern requires a reusable value or decision—such as an E.21 coordinate, a DRR decision, or a landing result—that value belongs to the result required by that pattern rather than to an E.19 progress account. The local work method may provide transient attention markers; E.19 governs the substantive questions and outcomes, not how those markers survive an agent's working context.

Complete the selected scope. Inspect every independently answerable question in the declared baseline and risk-selected scope. The first defect, blocker, or already-negative admission conclusion may prevent a positive verdict, but it does not complete the review and does not suppress findings that remain independently obtainable. Stop before the selected scope is complete only when a missing source, missing authority, unsafe boundary, or equivalent condition makes the remaining questions impossible to judge truthfully or safely. In that case, record the unexamined scope and why it cannot be judged; do not present the partial findings set as complete.

A nontrivial pattern-quality review SHOULD state its quality-evaluation purpose before depth is selected. Use E.22 or an equivalent compact question frame to say whether this review is a floorEvaluation, exceptionalImprovementEvaluation, paretoTradeoffEvaluation, openQuestionDiscoveryEvaluation, absorptionEvaluation, or a declared combination. If the purpose is absent, E.19 treats the review as an admission-refresh blocker read, not as a request to raise every evaluated coordinate toward exceptional expression. When coordinate values, PatternQualityStatus, or all-4/all-5 claims are needed for one pattern version, the review opens or consumes an E.21 result instead of assigning those values inside E.19.

When the review opens or consumes E.21, E.19 treats E.21 as a hard pattern-quality evaluation, not as a selectable profile. The review must not accept an E.21 claim that omits required coordinates, omits ShortRationale, omits PrecisionRestorationProfile, uses inactive/triggered-coordinate language, narrows the requested use to make the result pass, or replaces coordinate values with blocker triage. In inspect-repair-verify, repair or re-evaluate the affected result where that work is in scope; in independent findings, record the exact defect. Baseline triage can answer only the E.19 review boundary when no E.21 quality value, all-4/all-5 claim, landing-quality claim, or pattern-improvement movement claim is being made.

If the aim is repeated improvement against an object-under-improvement evaluation, use E.23 for the repeated method. An E.19 review configuration may supply PCP questions and its result episteme may supply findings inside that loop, but a profile is not the loop method and an E.19 result is not an ordinal quality value. Only a separate E.21 assessment application and result episteme can state the E.21 coordinate values for the changed pattern version.

E.19 reviewer and reviewed-pattern wording is FPF pattern-quality gate wording. It governs FPF admission, refresh, return-for-repair, blocker, and review-profile claims, not E.21 coordinate assignment and not project-side publication interpretation, explanation interpretation, comparative review-unit use, or participation in a named project-side review relation. When those project-side relations are used, use the publication or project-side pattern that names the object being interpreted or reviewed.

Project-side reuse boundary. Use this boundary when an E.19 review-result episteme is cited as project certification, project evidence, safety-assurance material, gate input, release justification, compliance-assurance material, assurance material, work authority, or publication truth. First return it to the exact FPF pattern-quality claim it states: admission, refresh, repair return, or selected pattern-quality boundary. Any project-side reuse opens the exact governing relation for that claim: A.10 for evidence/currentness, B.3 for assurance, F.10 for status use/interpretation, A.20 for a current local CV status when applicable, A.21 for gate decision, A.15 for work, or another direct owner. The E.19 result may be evidence about FPF pattern quality; it is not certification of the project world. Plain wording in the reviewed text remains ordinary unless it changes admissible use, evidence, gate, assurance, work, decision, status use, or FPF pattern application.

Common wrong first interpretation. A favorable E.19 review-result claim means the project, release, publication, safety claim, or compliance claim is certified. First honest entry: that result concerns only the exact FPF pattern edition and review scope; project-side reuse names its own governing relation, evidence/assurance source, and decision authority.

Misuse guard. A pattern-quality caution, return-for-repair result, or selected pattern-quality boundary result cannot be reused as project refusal or project approval unless a project-side governing relation states admissible and non-admissible use for that relation.

Formal or template defects (e.g. non-compliance with E.8 structure or not conforming to RFC deontic terminology) have lower review priority than semantic or ontological defects or non-SoTA Solutions. In inspect-repair-verify, repair them within the declared boundary; in independent findings, record them with concrete repair direction.

E.g. if the header block is missing or incomplete, continue with ontology and semantic review first. Treat missing header fields as one mechanical defect, not as a reason to stop (PCP-BASE #7).

When a proposed or accepted change needs a best-known Delta-Class (Δ-0…Δ-3) and initial impact radius, place them in the governing change, decision, or landing result using existing definitions where available (e.g., the LEX-AUTH protocol). E.19 repairs or reports an omission that matters to the selected gate; it does not copy a successful change account into a second review record.

#Apply the baseline profile to every run

Every run MUST include PCP‑BASE as a triage baseline. Full-depth checking is selected only where the relevant risk is present; reviewer depth SHOULD prioritize the FPF-governed sections and enforceable requirements in E.19:4.2.1.

1. Internal coherence (problem <-> conformance claim <-> solution) The Conformance Checklist matches Problem statement and the Solution (no "orphan requirements" and no "unclaimed requirements").
2. Lexical discipline & reserved vocabulary Terms and registers follow lexical rules; ambiguous "everyday" synonyms do not silently replace kernel vocabulary.
3. SoTA-Echoing minimum compliance (E.8) SoTA-Echoing satisfies the E.8 authoring requirements applicable to the pattern kind (Architectural vs Definitional), including explicit adopt/adapt/reject stances and the E.8 two-part SoTA test: current best-known problem-solving practice for the named practice question, and by-value incorporation into FPF-governed pattern loci. If a SoTA Synthesis Pack exists for the topic, SoTA-Echoing binds to it rather than forking an untracked narrative; any divergence of pattern norms from contemporary practice is explicitly stated as such. SoTA-Echoing MUST be non-decorative, MUST reflect best-known current practice rather than official status, source recency, institutional adoption, or merely popular defaults for the declared problem, and MUST govern the Solution and other FPF-governed sections, or those sections MUST justify divergence explicitly.
4. Cross-pattern compatibility & impact radius Relations are consistent with declared dependencies and dependents; declared scope/impact is compatible or explicitly limited.
5. Didactic grounding Archetypal Grounding is present and teaches the concept with concrete cases or references, not only abstractions.
6. Reader-fit The pattern body stays addressed to the intended FPF user rather than to FPF developers, package architects, reviewers, evaluators, or release/projection carriers. FPF-governed sections explain admissible use, costs, boundaries, FPF governing patterns named by value, project-side FPF kinds and references named by value, and related relations named by value in user terms. Architecture placement, freeze or merge state, package-boundary rationale, reference boilerplate, quality or projection evidence, corpus-entry evidence, PatternQualityStatus, monolith-parity evidence, landing evidence, and broader package-development rationale stay in DRR, architecture documents, review handoff, E.21 result, E.19 findings, README, ToC, E.11, I.2, cards, retrieval or projection carriers, release or landing evidence carriers, companions, or ordinary references unless they change the working reader's first admissible move.
7. Template & section integrity This is lowest priority for review depth and SHOULD NOT consume effort that would displace ontology, semantics, modularity, slot discipline, or SoTA checks.
8. Modularity & contradiction hygiene The pattern SHOULD NOT be overloaded or significantly expand requirements or dependencies without an explicit reason and impact record. Checks include: scope containment, split/refactor recommendations when warranted, and contradiction scans against neighbor patterns in Relations. The pattern SHOULD balance cohesion and coupling across FPF. If the pattern defines specialization or an abstraction stack, it SHOULD NOT mix slot interfaces or parameters from different abstraction positions; use explicit ⊑/⊑⁺ or Uses cuts instead.
9. Substantive solution and locus adequacy Baseline triage includes a small reviewed-pattern-specific question set about the actual problem and current change: does the pattern still solve the stated problem, are decision loci and governing-pattern applications correct, are kind boundaries and selected companion or projection functions preserved, did anything get worse, are SoTA rows current enough for the claim they discipline, and is the support material required by that claim neither too thin nor too heavy?
10. Triggered method, performer, work, and result separation When a method-bearing Solution prescribes actual work or world-side change, the run independently verifies the intended reader, method episteme, admitted performing U.System and current role assignment, a dated Work occurrence admitted under U.Work, and problem-facing result. The run returns a finding when the pattern episteme, checklist, reader role, plan, or prose is made to perform the work, or when work and result are collapsed. Judgment-only guidance does not trigger fictive performer or work requirements.

#Triage: spend depth on FPF-governed sections without making reviews heavier

PQG is meant to increase semantic and ontological trust, not to turn every review into an exhaustive editorial audit on form. To keep reviews feasible while improving the important parts:

• Treat FPF-governed sections and deontic requirements as the primary depth loci:

  • the pattern’s Problem frame, Rationale, and worked slices when a new family, profile, or specialization would otherwise be intelligible only from project context,
  • reader fit in Problem, Solution, Consequences, Rationale, and worked slices whenever the draft risks mixing user guidance with package-development rationale,
  • the pattern’s Conformance Checklist (the enforceable conformance check set): keep items universal, cognitively ergonomic, not overly prohibitive, and avoid duplicating checks that belong to other patterns (modularity),
  • deontic clauses (MUST/SHALL/SHOULD/MAY) that define requirements on the authoring/validation plane (not laws of nature or mathematical facts; ensure an explicit conformance subject),
  • admissibility constraints (Invariant: / Well-formedness constraint:) that define valid models (cardinality, typing/kinds, totality) and are written as non-deontic predicates (no RFC keywords inside the predicate),
  • definitions and mint/reuse decisions (new terms, renamed terms, scope claims baked into names, names that are not overloaded and are properly chosen),
  • cross-context and cross-plane claims (Bridge hygiene and “sameness” assertions),
  • SoTA (when the pattern claims state-of-the-art rather than a popular-but-outdated solution or vocabulary),
  • substantive solution and locus adequacy: one reviewed-pattern-specific content pass checks whether the repaired text still solves the stated problem, assigns claim-bearing material to the correct governing loci named by value, preserves kind boundaries and selected companion or projection functions, keeps quality/projection evidence and executor/reviewer correspondence out of the pattern unless the pattern's own EntityOfConcern and user-facing action are that evaluation/projection work, and has not become either under-grounded or over-bureaucratic,
  • modularity and Slot discipline of A.6.5 that provide evolvability of FPF,
  • absence of contradictions in a pattern,
  • Relations that define compatibility and impact radius.

• Treat low-signal text as “quick-pass” unless it changes meaning: headings, micro-typos, stylistic polish, and non-FPF-governed narrative refactors, including RFC-form deontic cleanup.

• Do not block semantic review on template and RFC compliance defects. Missing header block fields (E.8 H-5), missing canonical sections, or a missing footer marker are fixable integrity defects. Record them as repair items and continue with the FPF-governed section checks in the same run.

• Sentence-level precision matters on FPF-governed prose. Reviewers SHOULD inspect FPF-governed sentences for generic heads, claim-bearing qualifiers, overloaded trigger words, bare relation shorthand, and hidden process/API metaphors. The default repair order is: restore head kind, then qualifier claim kind or admissible-use boundary, then comparison criterion or escalation condition homogeneity, and only then judge whether a later Plain or coarsened rendering is admissible. This is an MG-DA cold-reader check: after repair, a reader without the DRR, campaign notes, or reviewer memory must be able to state the object, kind, relation or claim kind, admissible use, and next governing pattern. Broad replacements such as object, item, value, relation, record, condition, basis, material, or unqualified specialization remain defects unless the specific object, relation position, and governing pattern are named; specialization wording must say what specializes what, by which specialization relation, and which inherited or changed slots or uses matter.

• Precision-restoration distribution must be preserved. When an E.10 scan selects a non-local precision-restoration path, the run checks that E.10 remains the trigger and applicability pattern, E.10.ARCH carries the shared recovery architecture, the relevant realization pattern (A.6.P, C.2.P, C.30.P, C.16.P, C.16.Q, A.19.SPR, or another selected restoration pattern) performs the ontological unpacking, and affected patterns keep thin declarative pointers rather than local trigger registries or duplicate recovery algorithms.

• EntityOfConcern and precision-restoration questions travel with the same triage. When the reviewed change touches EntityOfConcern, same-referent, slot/reference, alignment-path, role-boundary, consumer-disposition wording, description/publication-use guards, phrase apparatus, repeated boundary doctrine, architecture-placement rationale, package-boundary rationale, or quality/projection evidence, the run asks before acceptance: what is the pattern's own EntityOfConcern and first useful move; does the text state its own subject kind, action guidance or ordered first-use actions, practical delta, and bounded non-use before auxiliary material; which governing pattern carries each outside claim/relation/boundary; does the prose need F.19 before word/head/use restoration; do remaining word/head/use problems apply E.10, E.10.ARCH, F.18, or another governing pattern named by value; do role, method, work, evidence, assurance, gate, status, and decision claims remain with their direct governors; and has every current-host consumer of the selected-family repair received a semantic, mechanical, compatibility, or not-triggered disposition. When E.21 is active, its separate result episteme carries these quality effects through PrecisionRestorationProfile; E.19 does not duplicate them as local rows.

• Design-time and run-time both count. The same precision discipline applies to FPF pattern prose and to any reviewed publication text, worked slice, or performed-work exemplar when that text is being assessed for admissibility, guidance, reuse, gating, release, policy, assurance, or action-selection use.

• Report ordering (impact-first). In run outputs and remediation direction, prioritize findings on ontology, semantic, modularity and SoTA-related FPF-governed sections first; group low-signal formatting/typos into one compact tail finding unless they change meaning.

#Add risk-driven profiles

PCP‑PRAG (Pragmatic utility & adoption) — Trigger: the pattern is Normative and claims practice guidance. Checks include: a visible first-reading recognition text early enough for a cold working reader; a recognisable first-minute working situation; one short Use this when or equivalent entry; a plain statement of what goes wrong if the pattern is missed; a plain statement of what the pattern buys in practice; the first admissible action-guiding move the user should take; a visible ordinary not this pattern when boundary; a minimally viable example; non-decorative Consequences/Anti-Patterns; at least one worked slice when the pattern is easy to misuse; a visible assurance text carrying declaration, guidance/check, modeling, and review/check scope; reader-fit consistency so that the assurance text does not silently widen or universalize the recognition-text claim; explicit practical payoff in user-facing prose; a short user-facing statement of the primary EntityOfConcern, relation record, or claim record and any minimal modeling lens when typed declaration material has FPF-governed use; nearby pairwise plain glosses for FPF-governed technical terms that appear before the heavier harness; a short working-reader implication for any SoTA-Echoing rows that carry explanatory work plus visible linkage to the worked cases or boundary slices they discipline; explicit primary working reader, concern, and viewpoint fields when several working-reader situations are being served; an explicit So what? adoption test; and, when the pattern claims universal or transdisciplinary reach, at least three heterogeneous recognition-text situations with F.16 preferred as the compact example-matrix template. If an E.10 trigger scan selects epistemic precision restoration during admission or refresh, PCP-PRAG treats type-correct-but-inert wording as a usability defect governed by E.2 P-2 and E.12: the run must name the remaining admissible reader use or the FPF pattern application and governing ontology that carry the claim, and must confirm any Plain recognition line maps back to the recovered Tech reading when both registers are used. A more expressive recognition line or intentional didactic metaphor may stay ordinary when it carries no FPF-governed use; when it carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim kind or admissible-use boundary, that claim kind or admissible-use boundary must be recoverable through the recovered Tech reading or named FPF pattern application.

For a broad cleanup across several patterns, or any cleanup that touches FPF-governed Problem frames, Problem sections, first-use recognition text, archetypal grounding, examples, or worked slices, check whether the didactic function was harmed. In inspect-repair-verify, restore the working situation and first useful move or the named FPF pattern application and governing ontology that carry the claim; in independent findings, record the exact harm and repair direction. A positive improved or preserved account is required only when another governing evaluation makes that value one of its substantive results, and it belongs in that evaluation.

PCP‑MOD (Modularity and abstraction-boundary discipline) — Trigger: the reviewed pattern or subset shows scope creep or abstraction-boundary mixing (e.g., one pattern bundles universal core rules with frame-specific content and discipline-specific method semantics; or it mixes EntityOfConcern, Description, and Specification positions in one object).

Checks include:

• an explicit core vs extensions cut (universal invariants are factored into one stable “core”, and extensions reference it rather than re-stating or mutating it),
• no conflation of specialization vs dependency: use ⊑/⊑⁺ for refinement/extension and Uses for pipelines; do not mix their semantics,
• no conflation of package-form, governing-pattern relation, and package-relation functions: Pack vs Kit vs Suite vs Family vs Bundle vs Cluster vs Profile vs Overlay vs Record vs Umbrella are not interchanged, and the review states carrier status, governing-pattern relation, and package relation explicitly instead of leaving it implicit or varying it for style,
• description-lane descriptions and their publications do not grow mechanism semantics; for an MVPK face or projected publication form, no-new-claim checks that it introduces no claim beyond the selected episteme and no-shadow-default checks that it introduces no undeclared default. Keep the selected episteme, optional projection/construction, face, publication form, publication occurrence, rendering, and carrier distinct. The selected episteme has U.View membership only when exact E.17.0 conformance independently obtains; face status, projection, profile selection, and compliance with these two checks establish no membership or truth,
• slot-discipline hygiene for any ordered specialization set: SlotKind invariance is preserved and inherited operations do not gain new mandatory inputs (A.6.5 / A.6.1 specialization discipline).

PCP‑REFRESH (Staleness & compatibility refresh) — Trigger: staleness signals are present (e.g., outdated SoTA rows, renamed/superseded Relations entries, terminology drift, or an explicit refresh window in LAT/DRR). Checks include:

• refresh‑sensitive claims are identified (time‑bounded or ecosystem‑bounded) and either (a) updated with post‑2015 evidence and matching Solution changes, or (b) explicitly scope‑limited and labeled as historical lineage,
• Relations are updated to current pattern IDs; deprecations/renames are handled via explicit continuity notes (no silent relabeling),
• when one new or substantially revised pattern subset is being prepared for send or landing, inspect the related governing patterns, governing-pattern constraints, companion patterns, Relations entries, and monolith-backed pattern sections that may require aligned edits. Repair an in-scope mismatch or return it as a finding. Successful alignment remains visible in the changed sources and the governing landing or release result, not in an E.19 pass recital,
• any long-lived companion, profile, check sheet, pattern-local companion row, review harness, or analogous selected non-pattern FPF kind-reference pair kept with the reviewed pattern or subset states its use question, governing pattern or selected non-pattern FPF kind-reference pair, admissible companion-only use, one real breakage if absent, and demotion or deletion condition when no such breakage exists.
• when the refresh causes Δ‑2/Δ‑3, verify that the governing change or decision result carries its Delta‑Class, impact radius, DRR pointer, and any refresh and Bridge obligations required by E.15/F.15/F.9; repair or report an omission rather than copying a successful account into E.19,

Trigger overrides are permitted but intentionally rare. Override a triggered profile only when its risk is genuinely absent in this case and a compensating check covers the live concern. When the override changes an admission, refresh, or other governing decision, place its reason in that decision basis; otherwise E.19 requires no separate positive override account.

PCP‑NORM (Normative guidance integrity) — Trigger: the pattern introduces or changes normative requirements, introduces new conformance items, or shifts downstream requirements. Checks include:

• Delta‑Class (Δ‑0…Δ‑3) and impact radius are explicit (what breaks, who depends on this),
• requirements are testable in principle (conceptually), scoped, and non-contradictory,
• downstream patterns cited in Relations are compatible with the new guidance.
• where the change is Δ‑2/Δ‑3 or a new normative pattern is being admitted: a DRR exists and references the PQG findings (pointer is sufficient; no duplicated prose).

PCP‑SOTA (Evidence and SoTA alignment) — Trigger: the pattern’s Solution asserts “best practice”, “state-of-the-art”, or introduces new synthesis claims. Checks include:

• each “best practice” claim or SoTA claim in the Solution is explicitly bound to SoTA‑Echoing rows (or to SoTA Synthesis Pack identifiers when used), rather than floating as ungrounded prescription, and those rows identify best-known current practice rather than popularity alone,
• the selected SoTA practice or source set answers the declared working problem and the relevant domain or practice tradition rather than merely justifying package placement, naming neatness, or pattern clustering,
• each SoTA row changes at least one FPF-governed outcome for the pattern: what the user may do, what the user must not over-read, which FPF pattern application must be named, or which claim cannot be raised to release, policy, assurance, gate, action-selection, or adjudication use,
• novel synthesis is not presented as established SoTA: it is either (a) framed as a scoped hypothesis with explicit limits, or (b) promoted into or registered as a SoTA Synthesis Pack entry before the pattern is admitted as normative guidance; a merely explanatory SoTA note that leaves the FPF-governed sections untouched is non-conforming,
• where traditions disagree substantively, the pattern makes the disagreement visible and states whether it adopts, adapts, or rejects each relevant source idea instead of silently selecting one tradition,
• retrieval or benchmark methods are used only when the relevant evidence relation is present; their dimensions do not become universal pattern-quality benchmarks,
• refresh‑sensitive claims (those likely to decay) are explicitly marked with scope limits, timespan notes, or lineage labeling when appropriate.

PCP‑BRIDGE (Cross-context or cross-plane reuse integrity) — Trigger: the pattern imports claims, terms, or norms across contexts, disciplines, or reference planes. Checks include:

• explicit Bridge usage where required (no silent identity by spelling),
• Congruence and loss are made explicit where applicable,
• any cross-plane reuse is explicitly acknowledged and its penalties do not leak into unrelated assurances.

PCP‑SUITE (Mechanism-suite integrity) — Trigger: the reviewed pattern or subset introduces or revises a suite-level Description that enumerates multiple distinct mechanisms (e.g., MechSuiteDescription or a suite specialization) and/or changes suite requirements, conformance pins, or suite protocols. Checks include:

• the suite remains a Description-level object: it enumerates member U.Mechanism.EntityOfConcern refs and declares shared requirements/pins, but does not define mechanism blocks (OperationAlgebra, Transport, Audit, …) and is not used as a mechanism node,
• membership has set semantics: mechanisms is duplicates-free and order carries no semantics; any intended ordering is expressed only in suite_protocols,
• suite protocols are closed over membership: if suite_protocols is present, each protocol step references a member mechanism (no “step points outside the suite”),
• the suite is not a family of implementations: it MUST NOT be encoded as a MechFamilyDescription (families remain “many realizations of one mechanism”, not “many mechanisms”),
• the suite does not mint transport exceptions: any cross-context, cross-plane, or cross-kind requirement remains Bridge-only; loss or penalty handling stays with R/R_eff only; the suite does not embed CL/Φ/Ψ/Φ_plane tables (references/pins only),
• CG/CN authority pins remain explicit references to the single governance card and legality gate: if suite protocols include numeric comparison/aggregation/scoring, they cite CG‑Spec (SCP + Γ-fold + MinimalEvidence) and (where applicable) CN‑Spec, rather than duplicating “local CG‑Spec-like” content,
• suite protocols contain no hidden tails: if UNM/UINDM/ULSAM are required, the protocol expresses them as explicit Uses steps and suite audit requirements cite the chosen mechanism ids/refs (no “implicit normalization/aggregation inside score/compare/select”),
• gate separation is preserved: mechanisms and guards use tri-state GuardDecision := {pass|degrade|abstain} and MUST NOT publish GateDecision or DecisionLog; block remains gate-level only (OperationalGate(profile)),
• defaults remain single-sourced: portfolio mode, dominance regime, and unknown/failure behavior are either pinned in TaskSignature or one policy-assignment record, or not claimed; the suite does not define competing defaults,
• when the suite claims reusable outputs, publish/telemetry is explicit and terminates via existing publication forms/faces (e.g., G.10 and/or PTM), not as a hidden tail inside a selection step.

PCP‑P2W (Planned baseline & slot-fillings seam integrity) — Trigger: the reviewed pattern or subset introduces or revises planned-filling content in one exact U.WorkPlan against an exact governed declaration member, including a publication or view of that content. Checks include:

• SlotFillingsPlanItem remains declaration-local PlanItem content inside one exact U.WorkPlan ClaimGraph; it is not a U-kind, execution log, mechanism, independent record, relation occurrence, or second slot ontology,

• every relied-on row names the intended-performance designator, exact declaration edition, declaration-local member designator and family, the direct pattern that owns the member's reusable meaning and corresponding later actual-use predicate, the positive planned value or designation, the target declaration's effective designation rule and semantic cardinality, and the exact planning conditions; A.15.2/A.15.3, not the target owner, govern the intended-use claim,

• declaration families remain distinct: relation-participant rows target only SlotSpecs in exact RelationSignature editions, operation rows target exact A.6.1 ArgumentDeclarations or ResultDeclarations, and any other row targets an explicitly governed declaration member with a corresponding actual-use predicate; a method description, kit or suite description, schema field, card, checklist, interface form, database field, or generic slot-bearing description is not a target merely because it displays a field,

• target-declared cardinality remains operative: for a single-valued target, exact conditions and an exact resolution rule make at most one planned value effective for any one intended use; multivalued set, order, repetition, or multiplicity semantics are never inferred from row count or layout,

• a row is positive intended-use content; omission is open-world, while prohibition, exclusion, required absence, and completeness remain separately governed plan claims rather than empty fillers or negated references,

• planned filling stays plan content: a planned value, compatible ValueKind, matching token, WorkPlan, or PlanItem establishes no dated work, obtaining relation participant, operation application, argument or result binding, returned value, change, production, delivery, acceptance, or outcome,

• when later actual use is compared with the plan, the direct relation predicate or exact A.6.1 application-binding predicate must obtain independently; a missing-filler or negative comparison requires an applicable closure or negative criterion and exact case facts; the comparison preserves the cited WorkPlan edition and expresses substitution or variance as a neighboring governed claim rather than backfilling the plan,

• declaration-edition pins, planned-value-edition pins, concrete reference kinds, time, location, capability, readiness, gate, evidence, source-currentness, bridge, publication, baseline, or comparison conditions appear only when the named receiving use relies on them; every policy or reference has its concrete kind, owner, edition, applicability, and effective reference scheme when current, and the profile introduces no unconditional crossing, time-selector, scope, audit-pin, or context bundle,

• a card, table, view, index, or generated summary is read-only publication of selected WorkPlan claim content: it does not add planned fillings, defaults, declaration meanings, cardinality, conditions, baseline semantics, or a second row authority, and

• when no reusable declaration member is needed, lower to ordinary A.15.2 plan content; when the declaration member, reusable meaning, corresponding later actual-use predicate, or direct owner cannot be recovered, return the exact missing-governor blocker rather than manufacturing a SlotSpec, description wrapper, generic field declaration, or actual-use relation. PCP-TERM (Terminology & naming protocol) — Trigger: the pattern introduces new terms, new U-kind pressure, new governed value names, new “unified names”, redefines existing labels, leans on FPF-governed phrases whose head kind or qualifier claim kind or admissible-use boundary is not yet restored, or uses FPF-governed trigger wording as if the word itself carried the needed kind. Checks include:

• the “mint vs reuse” decision is explicit when a term is introduced or changed,

• naming follows the local-first naming protocol and avoids scope smuggling (roles, metrics, or stages baked into labels; overloaded words used as terms with a local sense). Remediation SHOULD use F.18,

• when PCP-TERM is selected, F.18 winner selection and A.6.P follow-through form one chain: inspect the candidate heads or phrases, kind conflicts, lexical conflicts, selected wording, and survival of the repaired phrase; repair a broken chain or return its exact defect rather than recording the successful chain as a pass account,

• classify FPF-governed trigger wording before acceptance by semantic area, not by a local forbidden-word list. Typical classes include admissibility/deontic terms, evidence and review-check terms, action-invitation terms, characteristic/scale and stratification source labels, state-family terms, lifecycle/process terms, pattern-application wording, publication-form terms, and local equivalents. The accepted sentence itself or its governing declaration must make the relevant object, value frame, relation, work, authority reference, pattern application, publication kind, companion function, or conformance claim recoverable; repair or report any case where it does not,

• generic heads and claim-bearing qualifiers are not accepted at face value in FPF-governed prose: restore the head kind first, and do not count a narrowing qualifier as that restoration; only then restore the qualifier claim kind or admissible-use boundary,

• if a sentence compares, escalates, downgrades, or otherwise puts pressure on a phrase after that restoration, check that the comparison criterion is ontologically homogeneous,

• when repaired wording still carries an architectural claim kind or admissible-use boundary, verify that the resulting primary EntityOfConcern, first useful move, outside work, and any role-word or package-form decision remain recoverable in the repaired text or the governing decision; repair or report a mismatch, and

• source-side old wording and continuity rules are respected. PCP‑DEONT (Deontic clause hygiene: RFC keywords) — Trigger: the pattern conflates admissibility/validity constraints with deontic obligations (e.g., uses RFC keywords where a non-deontic Invariant: predicate is required). Checks include:

• Deontic requirements are expressed with RFC-style keywords (see H-8);

• obligations are not smuggled into prose as informal imperatives. Admissibility/validity constraints are stated non‑deontically as Invariant: / Well‑formedness constraint: predicates and referenced from the Conformance Checklist when enforceable.

• Subject discipline for RFC keywords. If a sentence uses RFC keywords, its grammatical subject MUST be an agent or a specified published record/model whose required content is being constrained (author, reviewer, record, published model). RFC keywords MUST NOT modify modeled-world entities (e.g., “Earth”, “RoleAssignment”, “Role”, “holon”) — express those as Invariant: / Well‑formedness constraint: predicates instead, and (if needed) reference them from CC items.

PCP-ENTRY (Pattern-entry discoverability and entry-orientation changes) — Trigger: one change substantively affects how one reader recognizes, selects, rejects, or reclassifies one applicable governing pattern body, applicable projection function, first-entry pattern-comparison set, Problem-frame recognition signature, expanded entry-disambiguation case, or entry lexical-query cue.

Trigger classification:

PCP-ENTRY is an explicit profile identifier under the existing Pattern Check Profile family. It reuses the PCP profile kind; it is an editorial review profile, not a runtime gate, not GateProfile, not a workflow state, and not a new route registry. PCP-ENTRY is risk-triggered rather than universal. Use one lead review profile for the change, and import other profiles only for their specific failure mode.

Use this risk-trigger model:

• Trigger class 0 — micro-edit punctuation, formatting, typo repair, grammar, or meaning-preserving compression with unchanged pattern-selection effect. No PCP-ENTRY, no compact pattern-local note, no evidence mode, and no parity scan are required.

• Trigger class 1 — local recognition wording repair one improved Use this when, Not this pattern when, or one removed sequence-implying phrase with unchanged candidate-pattern set and unchanged governing-entry or applicable-projection-function boundary. Only the four-question core check is required.

• Trigger class 2 — substantive entry, companion, or projection change one new or changed README scenario, ToC query cue, E.11 entry-distribution locus, I.2 expanded entry-disambiguation case, pattern, or applicable projection function newly treated as entry-bearing, one changed wrong-pattern or governing-entry or applicable-projection-function boundary, one changed local first-entry selection effect, or one substantive lexical-query cue change. The author leaves one compact pattern-local note, runs the core check, and adds at most one selected risk check if needed.

• Trigger class 3 — multi-companion-function or high-risk public entry change one change affecting several selected projection or companion functions together, one public-entry rewrite, one often-misclassified entry-recognition function, or one newly introduced first-entry pattern-comparison set. The author runs the core check and adds only the relevant selected risk check, usually parity, wrong-pattern, public-entry, or expanded-entry-disambiguation-case adequacy.

• Trigger class 4 — retrieval-facing, observed-failure, or measured-improvement change one retrieval-facing companion or projection function changes, one observed misretrieval or repeated search failure is being repaired, or the patch itself claims measured discoverability improvement. One selected evidence mode may be required, but benchmark-style reporting is not the default.

• Trigger class 5 — normative authority, kind, or durable-name change one entry-selection split, stable-name settlement, label-family change, or other normative architectural rewrite is in scope. DRR, PCP-TERM, and PCP-MOD are the lead decision or review profiles as applicable; PCP-ENTRY reviews only the entry-facing effects.

Ordinary non-triggers include:

• punctuation, formatting, and typo fixes;

• meaning-preserving prose tightening;

• one bare mention of a pattern without changed entry-selection effect;

• local wording repair that preserves the current first honest entry-recognition function, candidate-pattern set, governing-entry or applicable-projection-function boundary, and first-entry pattern-comparison-set membership.

PCP-ENTRY stays one narrow additive review profile, not one super-profile that absorbs PCP-PRAG, PCP-MOD, PCP-TERM, PCP-NORM, and every other review/check scope. It composes with PCP-PRAG, PCP-TERM, and PCP-MOD; it does not replace them. Its distinctive object is changed pattern-selection effect, changed first-use entry-recognition function, changed first-entry pattern-comparison-set membership, changed tempting-wrong-pattern boundary, changed Problem-frame recognition function, changed expanded entry-disambiguation case effect, changed entry lexical-query cue, and changed semantic companion-or-projection function parity.

Its default review scope is one small core triggered check:

1. No workflow implication Entry text does not imply mandatory sequence, control transfer, handoff, or publication, carrier, or record sequence unless another governing entry or applicable projection function explicitly governs that semantics.

2. Governing-entry boundary preserved Entry, index, and lexical-query companion functions do not redefine the governing pattern body's Problem or Solution.

3. First honest entry-recognition function preserved The change does not make the first entry-recognition function or case signal misleading.

4. No duplicate high-detail companion or projection function The change does not create one new stale echo or one second high-detail companion or projection function outside the one applicable governing pattern body or applicable projection function already named for the claim.

A change pays only the review cost of the concern it actually changes. Learning-order edits do not trigger PCP-ENTRY unless they also change candidate-pattern set, governing-entry or applicable-projection-function boundary, first honest entry-recognition function, or first-entry pattern-comparison-set membership. Lexical-only edits do not trigger extra entry-review scope unless they change pattern-selection effect or entry recognition. Retrieval fixtures are not required unless retrieval-facing behavior is explicitly claimed, one machine-consumed projection is in scope, or one observed misretrieval is being repaired.

When the risk warrants more than that core check, the run may add only the relevant selected risk checks:

• one parity check when more than one pattern-entry discoverability-bearing projection changes;
• one wrong-pattern check when known misclassification is present;
• one lexical check when subject-language divergence is substantive;
• one expanded-entry-disambiguation-case check when I.2 changes or one high-risk first-entry pattern-comparison set still lacks depth;
• one public-entry check when coarse public entry wording substantively changes entry-selection effect or carries high public-entry risk;
• one retrieval check when the change is retrieval-facing or repairs one observed retrieval failure.

Substantial discoverability changes leave one compact pattern-local note only when the governing discoverability decision needs that rationale; use the current DRR, PCP result, patch note, or other governing decision result rather than an E.19 progress record. That pattern-local note may stop at one explicit rationale when the risk is already controlled by governing-entry or applicable-projection-function inspection, companion-or-projection function partition, or one local wording repair. It is not a separate review record unless the change is high-risk, disputed, public-facing with substantive entry risk, or retrieval-facing.

When one compact pattern-local note is needed, it names only the changed companion or projection function, the affected first-entry pattern-comparison set or pattern, the changed first-use entry-recognition function or recognition signature, the governing entry or applicable projection function for the claim or projection function, and the selected check if any.

One compact risk-triggered gate is enough here:

Empirical evidence is required only when the change is:

• high-risk;
• disputed;
• retrieval-facing;
• repeatedly misclassified;
• public-facing with substantive entry-selection change, repeated failure, or one measured-improvement claim;
• or itself claims measured discoverability improvement.

PCP-ENTRY-E4 is selected only when retrieval-facing behavior is explicitly claimed, one machine-consumed projection is in scope, or one observed misretrieval is being repaired. Public-facing changes with substantive entry-selection risk usually select PCP-ENTRY-E1. Lexical-hook changes usually select PCP-ENTRY-E3. Changes across multiple projections or companion functions usually select PCP-ENTRY-E5. Observed search or query failures usually select PCP-ENTRY-E6, optionally together with PCP-ENTRY-E3 or PCP-ENTRY-E4 when the failure is lexical or retrieval-facing.

The following evidence modes are selected high-risk tools, not one suite to exhaust on ordinary authoring passes. Selected evidence modes may include:

1. PCP-ENTRY-E1 — cold-reader recognition or pattern-selection task Given one real case signal, can one reader recover the intended applicable governing pattern body or one admissible candidate-pattern set? One tiny micro-task is enough:

   Given this entry-recognition phrase, name:
   1. the first candidate pattern,
   2. one tempting wrong pattern,
   3. the admissible entry stop,
   4. the governing entry or applicable projection function.

2. PCP-ENTRY-E2 — wrong-pattern and wrong-entry trap Does the companion or projection function actively prevent the most tempting wrong pattern or wrong family?

3. PCP-ENTRY-E3 — lexical query check Does subject-domain phrasing retrieve the governing entry or applicable projection function without uncontrolled aliases?

4. PCP-ENTRY-E4 — retrieval or RAG fixture Does retrieval recover the governing entry or applicable projection function under exact-ID or keyword phrasing, under semantic paraphrase phrasing, and under projection-vs-governing-entry ambiguity, while keeping retrieved companion material, source faithfulness, stale echoes, and post-rationalized citation-like material distinct from the applicable governing pattern body?

5. PCP-ENTRY-E5 — companion-or-projection function parity check Do the companion or projection functions, plus any explicit absence note, preserve the same first-use entry-recognition function, governing entry or applicable projection function, wrong-pattern boundary, projection-only status, and no-claim-beyond-Core claim without requiring identical wording, rows, or examples?

6. PCP-ENTRY-E6 — observed failure or query-log capture Does one observed misretrieval, wrong-pattern loop, or repeated query miss still survive after the repair, or has the failure actually been removed?

#Tiny golden case bank for regression and worked examples

One tiny golden case bank is enough here. It is a review-regression echo, not the canonical entry inventory: rows 1-4 mirror README scenarios, E.11 entry-distribution loci, and I.2 expanded entry-disambiguation cases that already carry entry companion or projection functions, while rows 5-6 add review-specific search and retrieval stress cases. E.11 and I.2 remain the governing entry companions; this bank only tests whether a change preserved them. It is not one benchmark suite and does not require universal empirical review for ordinary wording or companion-or-projection function edits. A run may cite one relevant golden case or state that none is relevant. It does not need to execute the whole bank. It keeps a stable set of recurring entry-recognition functions recoverable across hardening passes:

These six cases are enough to keep:

• entry-recognition consistency;
• wrong-pattern or wrong-entry rejection;
• admissible entry-stop honesty;
• lexical-query discipline;
• thin-echo retrieval hygiene;
• and governing-entry and projection separation recoverable as the amendment lands.

When one empirical or retrieval evidence run is actually selected, the run makes recoverable only the fields needed by that run, such as:

viewpoint_class
task_prompt_or_query
expected_governing_entry_or_admissible_candidate_set
near_miss_patterns_or_projection_functions_if_any
time_budget_if_relevant
success_criterion_if_relevant
success_or_failure_note
observed_failure_mode_if_any
rationale_or_repair_action

When retrieval evidence is selected, keep retrieval result, answer faithfulness, and stale-echo result distinct without forcing benchmark-style reporting on ordinary edits. One minimal retrieval fixture checks exact ID or keyword retrieval, semantic paraphrase retrieval, projection-vs-governing-entry disambiguation, and, when thin echoes are used, thin-echo governing-entry reference presence. Ordinary local guidance stays prose-only rather than minting one stable governing-entry reference by default.

#Common hardening questions are triggered by review need

Open a common hardening question when the concern has FPF-governed use, is disputed, or is explicitly invoked by the reviewed pattern or subset. Inspect the relevant source and the reviewed loci. In inspect-repair-verify, repair any defect and verify the affected use; in independent findings, record the defect and repair direction. When the question reveals no defect, make no durable absence or pass recital.

Use these questions only for the selected entry-recognition function:

1. Usability and working-reader fit. Open this when first-reading recognition text, assurance text, first-minute working-reader usability, practical payoff, worked slices, primary-reader fit, or E.8 / E.12 / E.13 / E.14 / E.17.* / F.16 checks can change the admission or refresh result. If a separate evaluation assigns a value, use that evaluation's result rather than copying it into E.19 findings.
2. Scenario, anti-case, and utility-fit source set. Open this when a scenario pack, anti-case corpus, pilot bank, utility tree, fitness catalog, or analogous source is actually relevant or substantively disputed. Record only a missing, misused, or failing source/case as an E.19 finding.
3. Packaging, governing-pattern relation, package relation, and shipping fit. Open this before a send-facing, landing-facing, monolith-facing, governing-pattern-relation, or package-relation claim. The changed sources and governing landing or release result carry successful alignment; E.19 repairs or reports a mismatch.
4. Domain-tightened profile depth. Open this when a domain-specific note actually tightens a selected profile. Apply its questions; do not add a second account of positive results.
5. Accepted-decision or accepted-source-material carry-through. Open this when the work claims to implement an accepted DRR, returned-finding set, intake, architecture source material, or other accepted source material named by value. Inspect each independently applicable decision against the reviewed loci or its named governing FPF pattern, companion document, result, or accepted source material. Repair or report partial, missing, wrongly rejected, or wrongly routed carry-through. The accepted source remains the decision source; E.19 does not duplicate decisions that are expressed sufficiently, inherited unchanged, correctly absent, or outside the reviewed subset. Do not rename an E.17.ID.CR comparative review unit, PublicationUnit, publication form or face, source-pinned interpretation case, source material, or project-side review relation as an E.19 reviewed pattern or subset.

For PCP-ENTRY, the ordinary compact pattern-local change note remains enough when the governed discoverability decision requires one; no separate E.19 account is created merely because the profile was checked.

#Pattern-Edition Use-Value Replay

Use this replay when an exact candidate pattern edition changes materially under E.8:4.1.2. Run it on the stable candidate before acceptance or landing, not after each edit. First verify the author-selected branch against the exact edition basis and changed locus. Treat a change as mechanical only when the smallest relevant comparison shows that every materiality value named in E.8:4.1.2 is preserved. A genuinely bounded local semantic edit opens only its affected use probe and changed wording group; physical rewrite size is not evidence.

Judge each selected use probe separately when its result can differ by branch, exact edition or candidate-only basis, working use or relying work, expected first useful result, boundary, necessity, or evidence mode. One review may contain probes from both branches. A grouped verdict such as uses preserved or added or usability preserved cannot substitute for those judgements. E.19 does not prescribe a per-probe progress store: inspect-repair-verify repairs and verifies failed probes, while independent findings records only regressions, insufficiencies, invalid transfers, unsupported decisions, and blockers. When E.8, E.21, or another governing evaluation requires reusable dispositions or values, keep them in that evaluation's result rather than copying them into E.19 findings.

Changed-wording check inside each affected prior-edition probe. Keep the selected use probe as the outer unit. When a predecessor-bearing candidate materially rewrites a normative sentence or inseparable sentence group that carries the governed extension, action discriminator, first useful result, stop, or neighboring-pattern exit, give that wording group its applicable differential disposition below before closing the outer probe. Keep sentences together only when they serve one reader task and must receive one disposition; split them when their extension, action, result, or route can differ.

For each changed wording group:

1. pin the old and candidate wording and the exact use it serves;
2. state in plain language the subject, concrete action or choice, visible result, and stop or exit;
3. compare the old head and modifiers, modal force, admitted referents/actions, excluded near-misses, and local interpretation burden;
4. probe the nearest alien case the candidate might newly admit and the nearest valid case it might newly exclude, naming any case that crosses the boundary; and
5. apply the differential disposition. preserved requires no unauthorized widening or narrowing and no greater decoding burden: a reader must not need campaign memory or an ontology-development memorandum to recover the action.

For a new action-guiding paragraph with no predecessor, do not invent history. Test one nearby alien case that must remain outside and verify that the local wording itself exposes a recognizable situation, concrete action or choice, visible first result, and non-use or neighboring-pattern exit.

Keep the cheap path cheap. Formatting, typo, link, citation, or exact-reference corrections remain mechanical when the smallest comparison proves that no E.8:4.1.2 materiality value changed. A bounded semantic edit checks only its affected wording group and use probe. Reuse an earlier hunk or lexical result only when the object and compared editions, changed scope, and assurance question match this extension, modal-force, near-miss, and interpretation-burden test; idea presence or broad-use preservation is not enough. This is one same-increment stable-candidate pass before acceptance or landing, not per-keystroke review, a new ledger, or a one-finding handoff.

Prior-edition differential. For one candidate pattern edition × one prior-edition use probe, distinguish the applicable disposition when the governing decision needs it:

A use classified as unsupported historical residue before replay receives no differential disposition and supports no compatibility claim. New evidence of a valid old use reopens that classification instead of restoring wording silently. A required regressed probe prevents a positive conclusion, but it does not stop inspection of the remaining independent probes.

Candidate-only adequacy. Review one candidate pattern edition × one new intended-use probe against its exact candidate-only basis, never against invented history. Distinguish these outcomes when the governing decision needs them:

A missing candidate-only decision or basis is absent or insufficient; it never licenses a fabricated prior edition. Absence for a required new use prevents a positive conclusion but does not stop the other independent probes. Absence for optional breadth is non-blocking by itself but cannot support breadth, transfer, or exceptional-expression claims. If no exact new intended use is selected, no candidate-only check opens.

Replay the positive Solution separately. Judge the following over the candidate edition when their answers can differ:

1. the governed subject;
2. the recurring problem and ordinary failure;
3. an executable proposed move;
4. a first useful result rather than completed review apparatus;
5. each prominent boundary or guard and the credible neighboring case whose action it changes;
6. guards that inspect an already present positive Solution instead of supplying its outline; and
7. for a method-bearing Solution that prescribes actual work or world-side change, the intended reader, method episteme, admitted performing U.System, current role assignment under which that system performs the work, dated work, and problem-facing result as separately recoverable positions. Treat the item as defective if the episteme, checklist, reader role, plan, or prose performs the work; leave it not applicable when the pattern only guides a judgement.

Refine item 5 by boundary whenever boundaries can pass, fail, or route independently. Follow the short first-use rendering's action and result logic against a concrete situation. Merely finding words such as situation, move, result, or stop is not evidence. Repair each failed item or record it as an exact finding with remediation direction; do not replace the replay with one prose-quality impression.

Replay each triggered enumeration. Verify the semantic resolution selected under E.8:4.1.2: a declared closed set has one explicit membership rule covering every member; named-kind or proposition examples remain subordinate and explicitly non-exhaustive; heterogeneous neighbors do not assert a false common kind; an implicit kind, relation, or structure reaches an existing direct governor or remains blocked; and a hidden action or claim is stated before its examples. Review a member separately when its membership can fail independently or require a different repair. A genuinely small closed set may be judged together only when one rule yields one truthful conclusion for every member and no member can differ. Nearby nouns that assert no common membership, and an unchanged declared set or example list still covered by its exact rule, need no durable positive recital. A blanket all lists are coherent conclusion cannot replace review of a triggered enumeration.

Desk replay is the ordinary evidence mode for use branches, changed wording groups, new action-guiding paragraphs, the positive Solution, and enumerations. Escalate to a cold reader, AI agent, or observed-work exercise when competing actions remain plausible, a near-miss boundary or result distinction is not recoverable by inspection, a transfer is uncertain, or a missed failure has high consequence. When a claim extends recurring applicability beyond the exact cases, or high consequence makes one observed slice insufficient, select a proportionate qualitative practitioner survey, action-research cycle, or case study. Evidence escalation is risk-selected; it is not a universal benchmark or an ordinary-rewrite requirement. E.19 returns repairs or findings while leaving ordinal coordinate values and PatternQualityStatus to the full E.21 evaluation.

#Decision outcomes

Complete the selected review scope before making an admission, refresh, or return-for-repair conclusion. A first defect or already-negative conclusion does not end the search for other independently obtainable findings. If a condition makes the remaining questions impossible to judge truthfully or safely, name the unexamined scope and the condition instead of presenting a partial result as complete.

Inspect, repair, and verify. Complete every in-scope review application, repair every defect through the relevant authoring work, and perform focused verification over the affected questions. The changed pattern edition and focused-verification claims are the substantive evidence and remain distinct from work; constitute one aggregate E.19 result episteme only when a receiving admission/refresh decision needs it. Record only an unresolved blocker, a decision outside current authority, or work that must transfer; do not create a parallel list retelling completed repairs.

Independent findings. Leave one compact C.2.1 findings-result episteme or semantic handoff containing all actionable in-scope defects and blockers, ordered by semantic impact, with repair direction precise enough that the author need not rediscover the diagnosis. If the selected questions reveal no defect, create neither an empty pass report nor positive checklist recital. The findings result is not the dated review work or an authority-bearing admission decision.

If a governing admission, refresh, E.21, DRR, landing, or release decision requires a durable conclusion or value, use its existing result. That result may cite E.19 findings or the repaired candidate; it does not turn per-question positive outcomes into a second review record.

Precision-remediation order. When a defect sentence combines a generic head, a claim-bearing qualifier, and mixed comparison-criterion pressure, remediation SHOULD repair them in that order: restore head kind, then qualifier claim kind or admissible-use boundary, then comparison-criterion homogeneity. A narrowing qualifier does not by itself repair the head-kind defect. Only after those repairs may the review keep or reintroduce a Plain, didactic, or coarsened restatement, and only if the more precise upstream interpretation remains recoverable.

Kind-restoration verification. A wording, naming, or F.19 phrase-level repair does not succeed merely because the old trigger word disappeared. Recheck the pre-repair and post-repair kind, relation or claim kind, admissible use, and scope. If the repair narrows, widens, splits, or changes them without an accepted decision, repair it or keep the defect unresolved. The repaired object, focused verification, or governing decision carries this evidence; E.19 does not require a per-repair pass account.

Ordering and effort. Put ontology, semantics, modularity, and SoTA defects in FPF-governed sections before compact low-signal formatting findings. If semantic defects are present, address them before mechanical edits; formatting and micro-typos must not dominate the work by volume.

#Archetypal Grounding — Tell–Show–Show: System / Episteme

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal (applies to all patterns and all clusters).

Bias risks and mitigations:

• Governance bias (Gov): reviewers may over-prioritize compliance signals and under-prioritize teaching value. Mitigation: PCP‑BASE includes didactic grounding and internal coherence checks and priority for ontology and semantics, not to form.
• Epistemic monoculture (Onto/Epist): SoTA‑Echoing can become single-tradition name-dropping. Mitigation: require explicit multi-tradition coverage and usage of F.18 for neutral naming.
• Pragmatic bias (Prag): a pattern can be “correct” yet unusable. Mitigation: consequences and anti-patterns remain mandatory sections, surfacing trade-offs and misuse paths.
• Didactic bias (Did): narrative quality can be mistaken for truth. Mitigation: conformance and SoTA‑Echoing sections bind claims to explicit requirements and lineage.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

Patterns are both teaching publications and normative guidance publications. A specification that grows without explicit quality gates becomes a patchwork: locally good, globally inconsistent. A profile-based gate is the smallest structure that keeps reviews repeatable while remaining sensitive to risk and pattern kind.

The baseline profile protects cross-pattern comparability and editorial sanity. Risk-selected profiles keep depth where it matters: norms, SoTA claims, cross-context reuse, terminology changes, staleness refresh, and reader fit. A pattern that is admissible in package terms but speaks to the wrong reader is still a review defect.

#SoTA-Echoing - post-2015 review and validation practice alignment

Evidence binding note. If a SoTA Synthesis Pack exists for review and validation discipline or refresh discipline in your Context, cite it and keep this section consistent with it. Otherwise, use the table below as the current source-use basis for this pattern revision; do not duplicate it elsewhere as a seed list or treat reference sources as automatic SoTA.

Action result from the pattern-review and validation practice grounding: a favorable, cautionary, or return-for-repair E.19 result episteme, clean checklist, or clean retrieval-entry check does not become project certification, project evidence, safety/compliance assurance, gate input, release justification, work authority, publication truth, or project refusal/approval. Its EntityOfConcern is the exact reviewed FPF pattern edition or subset; its ClaimGraph states the review scope, applicable profiles, findings or aggregate cleared boundary, conclusion, non-use, and reopen condition. Review/repair/verification work, witnesses and evidence use, F.10 status use, B.3 assurance, publication/currentness, and any authority-bearing admission or refresh decision remain separate. Reopen the result when the reviewed text, accepted-source-material decision, SoTA grounding, related governing pattern, selected companion/projection function, profile trigger, review boundary, or attempted project-side reuse changes.

#Relations

• Builds on:

  • E.8 (authoring conventions; canonical section order; SoTA-Echoing authoring requirements)
  • E.10 (lexical discipline, trigger detection, and applicability)
  • E.10.ARCH (distributed precision-restoration architecture and realization/governing-pattern split)
  • E.9 (design rationale records for changes that affect semantics)
  • E.9.DA (scoped DRR decision-adequacy evaluation specification before pattern drafting or host amendment; an E.19 finding may expose an upstream DRR defect, but dated E.9.DA assessment work and its result episteme remain separate. An E.19 pass, return, or absence is not E.9.DA coordinate evidence.)
  • E.22 (improvement-oriented quality-evaluation question framing; distinguishes floor blocker review, exceptional-improvement review, Pareto trade-off inspection, open-question discovery, and absorption impact before an E.19 review result is formed.)
  • E.23 (repeated quality-improvement method; an E.19 profile can supply questions and findings inside such a loop, but E.23 governs repeated absorption, object-under-improvement re-evaluation, method-family selection, and stop, continue, switch-method, open-new-frame, or hold decisions.)
  • E.15 (authoring/evolution protocol; harness mindset; refresh planning)
  • A.6.5 (slot discipline; SlotKind/ValueKind/refMode invariants)

• Coordinates with:

  • A.15.1, A.6.1, A.2, and A.2.1 (dated review/repair/verification work, exact check applications and bindings, reviewer role, and obtaining assignment)
  • C.2.1 (finding, focused-verification, aggregate review-result, and optional record epistemes)
  • A.10 and B.3 (evidence use/provenance and any assurance or reliance on an E.19 result)
  • F.10 and E.24.PUB (status use/interpretation and publication occurrence/form/carrier; neither is review work or admission authority)
  • F.8 (mint vs reuse decisions)
  • F.18 (local-first naming protocol)
  • F.9 (cross-context alignment discipline)
  • F.15 (conceptual harness and regression framing)
  • E.17 (MVPK publication and face discipline; an MVPK face, projected publication form, projection/construction, publication occurrence, rendering, and carrier remain distinct)
  • E.17.0 (independent conformance required before the selected episteme has U.View membership; E.19 profile checks and no-new-claim/no-shadow-default compliance create no membership)
  • E.11 (pattern-entry discoverability discipline, for PCP-ENTRY only as a review hook, not as a semantic prerequisite)
  • E.13 (pragmatic utility and proxy-to-value alignment when a pattern-quality pass, score, coordinate value, checklist result, benchmark, projection signal, or release posture is being used as value evidence)
  • E.21 (scoped pattern-quality characteristic space, coordinate evidence discipline, PatternQualityStatus, and stop condition; E.19 findings may become evidence only through the exact E.21 assessment application. Final coordinate values and PatternQualityStatus belong to a separate E.21 result episteme, not the E.19 profile or result.)
  • A.6.7 (MechSuiteDescription suite-level semantics)
  • A.15.3 (SlotFillingsPlanItem P2W planned-baseline seam)
  • G.11 (refresh/decay orchestration principles, where applicable)

#E.19:End

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