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, including a worked comparison, 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:

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.
Governing-entry boundary preserved Entry, index, and lexical-query companion functions do not redefine the direct pattern body’s Problem or Solution.
First honest entry-recognition function preserved The change does not make the first entry-recognition function or case signal misleading.
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 a worked E.11 entry comparison 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:

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.
```
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.
PCP-ENTRY-E3 — lexical query check Does subject-domain phrasing retrieve the governing entry or applicable projection function without uncontrolled aliases?
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.
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.
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?