E.20:4.11 - Step 11: Apply PQG profiles (E.19) and close the run

Every MIP-run SHALL be reviewed using PQG (E.19) with:

• PCP‑BASE always, and
• the triggered profiles implied by the change class (at least):
  • PCP‑SUITE if any suite locus changed,
  • PCP‑P2W if any planned-baseline locus changed,
  • PCP‑TERM if any new terms/renames are introduced,
  • PCP‑SOTA if SoTA packs are introduced/modified,
  • PCP‑NORM if the run introduces/changes normative requirements or conformance items,
  • PCP‑DEONT if RFC keyword clauses are introduced/modified (or if invariant/predicate vs deontic form is ambiguous),
  • PCP‑BRIDGE if cross-context reuse, crossings, or bridges are introduced or changed,
  • PCP‑REFRESH if refresh-sensitive claims (SoTA lists, “current practice”, enumerations) are touched,
  • plus any applicable modularity / boundary / normativity profiles required by the delta.

MIP-run outcomes (normative set). A reviewed MIP-run SHALL be closed as one of:

1. Proceed (single change set).
2. Proceed via governing-definition split (mandatory when semantics were placed under the wrong governing definition; the change is split into governing-definition-correct edits).
3. Proceed via suite variant (preferred when kernel stability is threatened by adding new required stages).
4. Block with explicit missing condition (insufficient semantics; stub exists but completion condition is DRR-tracked).
5. Reject (violates invariants such as suite-as-gate, plan-as-enactment, or governing-definition ambiguity).