E.19:4 - 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; the reviewer applies them and returns findings or repaired text. An unselected profile requires no result row or durable disposition.

Choose review depth from the harm if a defect survives, the novelty and complexity of the claim, how widely the pattern will be reused, and how likely its sources or neighbors are to change. Pattern length, official status, and the number of available checks do not justify deeper review by themselves. Use cheap automated or template checks for properties they can actually test, then spend reviewer attention on semantic, ontological, practitioner-use, and current-source questions they cannot close.

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 an ordinary bounded review, keep the reviewed edition or subset, question, selected profiles, checked loci, defects or repairs, and conclusion. When exact replay or a named later use needs a stronger account, also 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. the semantic review U.Method, when that identity matters; call an episteme its U.MethodDescription only after it passes A.3.2;
4. for each actual review, repair, or verification occurrence asserted as dated U.Work, recover every exact actual performer through A.13 and use A.15.1 to identify its time, Method, containing System, and Work independently. Add F.6 only when the review account expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. That attribution must be independently grounded rather than inferred from holder identity or timing, and a missing or failed F.6 link leaves the Work intact;
5. each exact PCP check application and A.6.1 binding only when the receiving use must replay those bindings;
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, A.10 evidence-use or provenance relations, and any B.3 assurance or reliance result when those claims are made; and
10. any F.10 status use, publication occurrence or form, carrier, and currentness relation used by the receiving claim.

Any local system-role kind and its independently evaluated classification are optional separate claims; neither supplies assignment or performance. Route unresolved source role through E.10.ROLE, and name intended-reader or representation positions directly. When a later claim relies on a dated occurrence, apply item 4 and CC-E19-0.

The phrase review run is Plain shorthand for that configuration, the reviewer’s actions, and their results. The §4 account keeps the declarations, applied Method, actual review work, findings, result, and any authority-bearing decision distinct when those identities are needed.

E.19:4.1 - Define the reviewed pattern or subset

Name the reviewed pattern or bounded subset, its edition or other stable version basis, the admission or refresh question, the selected profile questions, and the review boundary. That is enough for an ordinary bounded review. Add exact scope, window, and review-configuration identities only when a receiving result or named reliance needs them. Profile choice selects the questions and review depth; an ordinary bounded review requires no progress record.

When a reusable result or named reliance depends on how the review was enacted, apply the item 4 actual-Work account and CC-E19-0 to each asserted review, repair, or verification occurrence. If a durable aggregate result is needed, constitute a C.2.1 result episteme whose EntityOfConcern is the reviewed pattern edition or subset and whose ClaimGraph states the review scope, applicable profile questions, actionable findings or aggregate cleared boundary, conclusion, and reopen condition. Add a non-use boundary only when it changes a named receiving use under the F.19 plausible-intended-reader test. Witnesses, evidence use, the optional result publication, and any authority-bearing admission or refresh decision remain separate.

Choose inspect-repair-verify when the reviewer may edit and same-turn repair fits the declared use. Choose independent findings when the review needs separation from the author or an unchanged candidate. Independence changes who edits; it does not add a dossier or expand the selected questions.

Choose one review form. An E.19 review has two forms:

1. Inspect, repair, and verify. One bounded review may include inspection, repair, and focused verification. A reviewer performs those actions; distinguish their performer, Method, affected object, or occurrence only when the positions differ or a named later use needs them. Apply item 4 and CC-E19-0 if the account asserts dated Work. Apply every selected question, repair every in-scope defect, and reapply the affected checks. The changed edition and focused verification carry the substantive evidence; constitute an aggregate E.19 result episteme only when a receiving admission or refresh decision requires it. Make a separate findings record only for an unresolved blocker, a decision outside current authority, or transfer to another author.
2. Independent findings. A reviewer applies the selected questions without changing the reviewed pattern or subset. One C.2.1 findings-result episteme or handoff file records every actionable defect and blocker, with repair direction precise enough for the author to act without repeating the diagnosis. It is neither the reviewing action 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 pattern defines a reusable value or decision required by the declared use—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. E.19 specifies the substantive questions and outcomes independently of how a working environment keeps place during the review.

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 identify the exact FPF pattern-quality claim it states: admission, refresh, repair return, or selected pattern-quality boundary. Any project-side reuse then opens the concrete relation that governs that use: 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 the relevant project-side pattern. 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. A project refusal or approval requires a project-side governing relation that states the project claim and its admissible use.

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 pattern change needs a best-known Delta-Class (Δ-0…Δ-3) and initial impact radius, place them in the governing change, decision, or landing result using E.15’s actual-effect and actual-dependency tests. E.19 repairs or reports an omission that matters to the selected review; it does not copy a successful change account into a second review record.

E.19:4.2 - 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 addresses the intended FPF user in the working role governed by that pattern. FPF developers, package architects, reviewers, and evaluators are appropriate readers when they occupy that role. FPF-governed sections explain admissible use, costs, boundaries, the concrete definitions, constraints, tests, or other contributions used from FPF 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 applications of the relevant patterns 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 Solution says how work should be done, first distinguish content that defines, constrains, tests, or guides a Method from an assertion that one dated Work occurrence or world-side change actually obtains. Method guidance alone does not trigger a fictive performer or Work. If an account asserts dated U.Work, verify the §4 actual-Work account; if it asserts a world-side change, identify the change relation, the pattern that defines it, and the things it relates. Keep the intended-reader position, any qualifying A.3.2 method-description episteme, actual performer, Work, and problem-facing result separate. For a literal dated U.Work claim, return a finding when an episteme, checklist, plan, prose, or intended-reader or representation position is made to perform Work, or when Work and result are collapsed. Judge ordinary or metonymic wording through the complete-claim test in F.19; a familiar instrumental expression alone does not require a formal Work account.

E.19:4.2.1 - 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.
• Give mechanical corrections a quick-pass when their scope is limited to the named mechanical property and their semantic and practical effects are unchanged, for example a micro-typo or heading-format correction. For live recoverability or contribution questions in stylistic or narrative rewriting, including RFC-form deontic cleanup, use the whole-span F.19 reading below. Automate a check only when the tool tests one clearly named property. A clean result closes only that property; it cannot establish semantics, ontology, practical usefulness, or source currentness.
• 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.
• Whole-span precise language. Reviewers SHOULD apply the complete connected Solution in F.19 to the selected FPF-governed span: recover meaning, test the contribution of each optional expression, and compare useful content before and after repair. Retain its precision-before-coarsening order, MG-DA cold-reader recovery with its evidence-selection and coverage conditions, and hypergeneric/specialization test.
• Precision-restoration distribution must be preserved. Apply CC-E19-21; keep only review-specific questions here and use the declared language or subject owner for the repair.
• Review-specific continuity questions. Apply these to the changed claim and affected uses:
  1. Is the pattern’s own EntityOfConcern, first useful move, practical delta, and any action-changing applicability boundary recoverable, with its action guidance before auxiliary wording, publication, architecture-placement, package, or quality apparatus?
  2. After wording or reference migration, does the claim still reach the same referent through the intended slot or reference position and alignment path? Record any deliberate retargeting in the governing change decision.
  3. When phrase apparatus, semio bias, architecture placement, package rationale, or quality apparatus changed, did the repair preserve the function that was actually needed and remove only the displaced apparatus? Name each outside definition, constraint, or test by its supplying pattern and use a formal identity only for a live distinction or named reliance.
  4. Do the affected current consumers still receive the intended meaning and use? Resolve semantic, mechanical, or compatibility changes in the affected sources; report unresolved conflicts rather than creating a disposition for every unaffected consumer.
• Use preservation and guard selection are different decisions. Always compare the admissible uses of the old and repaired claims under their governing rules, including any expansion or narrowing. The F.19 plausible-reader test decides whether an explicit description, publication-use, or non-use guard deserves mention. A justified guard still undergoes the same before/after use comparison. Use F.19 and the direct owners for Method, Work, evidence, assurance, gate, status, decision, and unresolved role claims; dated Work uses CC-E19-0.

When E.21 is active, its PrecisionRestorationProfile carries the quality result; E.19 does not duplicate it.

• 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.

E.19:4.3 - 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 when several working-reader situations are being served; an explicit So what? adoption test; and, when the pattern claims universal or transdisciplinary reach, heterogeneous recognition-text situations adequate to the claimed breadth with F.16 preferred as the compact example-matrix template. When admission or refresh includes precise-language repair, apply CC-E19-7a. It preserves practical guidance and the Plain/Tech relation under E.2 P-2 and E.12, with formal identity and dated-Work checks only under the conditions stated there. F.19 governs the whole-span repair; E.10 supplies compact cues and FPF routing.

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, first useful move, and the definition, constraint, test, or other pattern contribution needed by the claim; in independent findings, record the exact harm and repair direction. A positive improved or preserved account is required only when another 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, concrete pattern-to-claim contribution, 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, the definition, constraint, test, or other pattern contribution actually used, and the package relation explicitly instead of leaving them implicit or varying them 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, for example an outdated SoTA claim, a renamed or superseded relation, terminology drift, or an explicit refresh window in a current source-use, change, or decision record. Checks include:

• refresh-sensitive claims are identified and either (a) updated from the best current problem-relevant source line with matching Solution changes, or (b) explicitly scope-limited and labeled as historical lineage; source date, count, official status, or novelty alone does not establish current-best use,
• select living refresh only for a high-priority claim or pattern subset likely to change when new evidence or a changed neighbor appears. Monitor and reopen the smallest affected unit at a named trigger; return it to ordinary periodic review when continued surveillance no longer buys enough currentness for its cost,
• 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 patterns, the concrete constraints or tests they supply, 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, the concrete pattern contribution or selected non-pattern FPF kind-reference pair it serves, 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 actual-effect Delta-Class, actual dependent reach, and any DRR, focused verification, source-refresh, or F.9 consequence that the changed use really requires under E.15, F.15, and 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.
• for a Δ-2/Δ-3 change, apply E.15’s actual-effect and material-decision test to the DRR requirement; a new normative pattern retains its DRR. When a DRR is required, it cites the applicable actionable PQG findings or the repaired candidate and focused verification, according to the selected review form; pointers suffice.

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, a source-supported applicability or reliance limit, which FPF pattern application must be named, or a claim’s eligibility for a named release, policy, assurance, gate, action-selection, or adjudication use. An explicit rejected reading follows F.19’s grounded-guard test,
• 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.

Apply the planned-filling rules in A.15.3 to the changed plan content and its affected consumers:

• A.15.3:4.0–4.4 govern declaration-local PlanItem content, declaration and member recovery, intended-performance and planned-value designation, target-declared cardinality, and positive intended-use meaning. Use the corresponding CC-A15.3-01 and CC-A15.3-03…09 questions.
• A.15.3:4.2, 4.5, and 4.6 govern conditional reference/policy pins, independently established actual use, baseline-preserving comparison, and read-only publication. Use CC-A15.3-11…14 for these uses.
• A.15.3:12a–12b supply the ordinary A.15.2 plan-content exit and the exact missing-source blocker when reusable typed use is needed but cannot be supported.

The declaration’s own pattern defines member meaning and actual-use predicates; A.15.2/A.15.3 define the planned intention. Review the use actually changed under those rules, retaining the exact declaration and WorkPlan editions on which that use relies. 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 (role-word meanings, metrics, or stages baked into labels; overloaded words used as terms with a local sense). Remediation SHOULD use F.18 when its durable-name use condition applies,
• when F.18 winner selection and A.6.P follow-through are both needed under their respective use conditions, treat them as 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,
• use the semantic-area cues in E.10:0.2 with F.19’s whole-span reading. 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,
• for unresolved generic heads or claim-bearing qualifiers, and for a subsequent comparison, escalation, downgrade, or other use that puts pressure on that interpretation, apply F.19:4’s precision-before-coarsening rule,
• 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 E.10.ROLE disposition or package-form decision remain recoverable in the repaired text or the decision that set the boundary; 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 published record or model whose required content is being constrained. State modeled-world admissibility or validity requirements as Invariant: or Well-formedness constraint: predicates and reference them from CC items when needed, under E.8 H-8 and CC-SG.4.

PCP-ENTRY (Pattern-entry discoverability and entry-orientation changes) — Trigger: one change substantively affects how one reader recognizes, selects, rejects, or reclassifies one applicable direct 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 editorial review profile under the existing PCP family. 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 runs the core check and adds at most one selected risk check if needed. A compact pattern-local note is conditional on the rationale need stated below.

• 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 reviews entry-facing effects alongside the independently applicable PCP-PRAG, PCP-MOD, PCP-TERM, PCP-NORM, or other profile. 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 direct 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 direct 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 misclassification is observed or independently plausible for the intended reader under F.19’s grounded-guard test;
• 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.

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.

Select only evidence modes needed for the changed entry risk. An unselected mode requires no result row or durable disposition. 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 direct pattern body or one admissible candidate-pattern set? One tiny micro-task is enough. Ask for the alternative in item 2 only when an observed choice or independent local cues make it plausible for the intended reader and the distinction changes selection or use; otherwise omit that item.

   Given this entry-recognition phrase, name:
   1. the first candidate pattern,
   2. when grounded, 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 For an observed or independently plausible misclassification, can the reader distinguish the intended pattern, entry, or family from that alternative? Use direct problem and subject cues; add an explicit rejected alternative only when F.19’s grounded-guard test warrants it.

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 direct pattern body? Retrieval returns the governing entry or intended projection cue before one stale echo, and answer-to-governing-entry faithfulness remains intact. When thin echoes are used, check that they carry a governing-entry reference.

5. PCP-ENTRY-E5 — companion-or-projection function parity check Check that one governing entry or applicable projection function stays unique and the changed companion or projection functions agree on first-use entry-recognition function, wrong-pattern boundary, projection-only status, and no claim beyond the Core pattern body’s admitted use; they need not share identical wording or examples. Include any explicit absence note in that comparison; identical rows are not required either.

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?

E.19:4.3.1 - Tiny golden case bank for regression and worked examples

Select a case that exercises the changed entry risk. Cases 1–4 specialize I.2.4, I.2.2, I.2.6, and I.2.3 respectively; E.11 governs the entry-distribution use, and the direct subject patterns govern the recovered claims. Cases 5–6 add search and retrieval stress under PCP-ENTRY-E1 and PCP-ENTRY-E4. Another relevant E.11/I.2 case may be used. Select empirical evidence under PCP-ENTRY; unselected cases need no run or absence note.

The tempting_wrong_pattern_or_wrong_relation column is conditional on an observed or independently plausible reader mistake that changes selection or use. Leave it unused when that condition is absent; keep the case’s positive recognition and admissible stop.

In case 3, evaluate episteme identity separately under C.2.1: its discriminators are claim content, EntityOfConcern, and effective reference scheme. Changed wording or audience alone leaves that identity unchanged; a changed discriminator identifies another episteme. A.6.3.CR permits claim-preserving or explicitly loss-declared same-EntityOfConcern re-expression under its own use conditions.

Selected cases test:

• 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 in the changed entry text.

When one empirical or retrieval evidence run is selected, keep recoverable the facts needed to understand its question and result. A structured result may use the following field names, including only those needed by that run:

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. Use the retrieval questions in PCP-ENTRY-E4, including its conditional thin-echo reference check. Ordinary local guidance stays prose-only rather than minting one stable governing-entry reference by default.

E.19:4.3.2 - 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.