E.20:4.2 - Step 2: Declare the governing-definition assignment map (mandatory)
For every new or modified change item, the MIP-run SHALL name exactly one governing definition and assign the change there. In FPF, that governing definition is a citeable, patchable PatternId, PatternId:SectionPath, PatternScopeId = G.x:Ext.*, or DRRId (E.9). The core MIP-run manifest in a citeable change record is limited to:
- each changed item,
- its governing definition,
- its canonical location (expressed as
PatternId:SectionPath,PatternScopeId, orDRRId, not as prose), and - the forbidden overread or forbidden move blocked by that assignment.
Conditional manifest fields appear only when the corresponding claim is present:
- the change class(es) from E.20:4.1 when needed to disambiguate the assignment,
- new or changed citeable tokens, including a
MechanismDefinitionRefor a public operation, argument, or result designator, when token denotation or citeability changes, - the actual-effect Delta-Class (
Δ-0toΔ-3) and affected-reach estimate from E.15 when the run is plausiblyΔ-2orΔ-3, - intended RSCR trigger types when a refresh or regression-wiring claim is present, and
- the PQG (E.19) profile set when the run crosses an E.19-governed review boundary.
Note (normative). If the canonical location is a Part‑G wiring module, it SHALL be cited as a PatternScopeId (G.x:Ext.*) and the module SHALL declare GoverningPatternId (wiring is binding-only; meaning remains governed by its cited pattern).
Canonical governing-definition map (normative):
| Change kind | Governing definition | Canonical location | Forbidden move |
|---|---|---|---|
U.Mechanism identity and content: exact EntityOfConcernRef, effective reference scheme, direct subject and range fields, operation algebra, laws, admissibility, Applicability, and optional dependency manifest | Mechanism-subject pattern under A.6.1 | Designated mechanism-subject pattern | A suite, plan, wiring module, card layout, or MIP manifest does not supply mechanism semantics; neighboring relations stay with their direct patterns. |
| Suite membership, obligations, spec pins, and suite protocols | Suite-subject pattern | A.6.7 or A.6.7.<FamilyKey> | SHALL NOT carry mechanism semantics, acceptance thresholds, gate criteria, DecisionLogs, or publication tails into the suite. |
| Planned baseline pins (planned slot fillings, edition-pinned refs, explicit time selector) | One U.WorkPlan and the planned-filling rows kept inside it | A.15.2 plus A.15.3 rows that point to declaration members defined by their own patterns | SHALL NOT embed launch values, witnesses, or gate decisions in planning, or give a row independent identity. |
| SoTA method, comparator, or generator definitions, including provenance and evaluation semantics | SoTA-pack subject pattern | G.2 (SoTA synthesis packs) | SHALL NOT rephrase SoTA evolution as kernel semantics. |
| Wiring that binds SoTA packs into flows or tasks | Extension module governing definition | G.x:Ext.* (GPatternExtension with explicit PatternScopeId) | SHALL NOT mint new semantics; SHALL bind only. |
| Token renames and drift management | Lexical subject pattern | F.18 (alias docking) plus registers per E.10/F.17 | SHALL NOT silently rewrite tokens or break citations. |
| Change-cause taxonomy and regression triggers | RSCR subject pattern | G.Core | SHALL NOT invent ad hoc “reason kinds” scattered in patterns. |
| Project specializations of a mechanism | Project specialization pattern | P.* patterns (using ⊑/⊑⁺) | SHALL NOT mutate kernel membership to express project variants. |
Guard (normative). Any proposed change that cannot name a governing definition from the table above SHALL be treated as a non-normative drafting note or candidate intake and SHALL NOT be relied upon as an FPF architectural commitment. Such material may exist only in an explicitly marked non-normative source note until assigned to its governing definition.