#Mechanism Introduction Protocol (MIP)

E.20 · 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: Draft Normativity: Normative

FPF is intentionally open-ended: new U.Mechanism definitions, suite compositions, and SoTA-driven wiring modules can be added over time. This flexibility creates a recurrent authoring problem: introducing a new mechanism (or revising an existing one) tends to touch multiple governing patterns, specification loci, and extension blocks across Parts A/E/F/G and can easily create drift:

#Keywords

• mechanism introduction
• authoring protocol
• governing-definition assignment
• MIP-run manifest
• canonical card-first
• no dangling …IntensionRef
• suite boundary hygiene
• P2W seam
• SlotKind lexicon discipline
• alias docking
• typed RSCR triggers
• regression envelope
• PQG profiles.

#Relations

#Content

#Problem frame

FPF is intentionally open-ended: new U.Mechanism definitions, suite compositions, and SoTA-driven wiring modules can be added over time. This flexibility creates a recurrent authoring problem: introducing a new mechanism (or revising an existing one) tends to touch multiple governing patterns, specification loci, and extension blocks across Parts A/E/F/G and can easily create drift:

• semantics appear in the wrong governing locus (e.g., Part G wiring starts carrying mechanism meaning),
• suites degrade into “meta‑mechanisms” or hidden gates,
• planned baselines (WorkPlanning) are conflated with execution witnesses (WorkEnactment),
• token drift breaks public references, or
• the corpus accumulates dangling references and non-normative drafting commitments without a governing definition.

This pattern provides a repeatable, governing-definition assignment protocol for introducing mechanisms. It preserves kernel coherence by keeping extension points and governing definitions explicit.

Use this when. Use E.20 when a proposed FPF change introduces or revises mechanism meaning, suite denotation, suite closure, suite obligations, suite pins, suite protocol semantics, planned-baseline pins, wiring semantics, governing-definition assignment, or what a citeable token denotes.

First useful move. Classify the edit with MIP trigger triage: MIP not triggered, local wording or alias-docking only, or MIP-run manifest required. If a manifest is required, name exactly one governing definition for each changed item before writing the pattern text.

Smallest sufficient governing-definition assignment guidance. Use the lightest governing-definition assignment guidance that preserves the next bounded reader move. Add MIP-run manifest fields, canonical mechanism card stubs, suite fields, planned-baseline pins, wiring refs, RSCR triggers, PQG coverage, or deprecation-continuity material only when the current mechanism-definition or citeable-token claim would otherwise become false, unsafe, non-replayable, or lack a named governing-definition locus.

Minimum sufficient next move. If the edit does not change citeable-token denotation, mechanism meaning, suite denotation, suite closure, suite obligations, suite pins, suite protocol semantics, planned-baseline pins, wiring semantics, or governing-definition assignment, a MIP-run manifest is not opened; name the current governing locus or alias-docking relation and stop.

Do not escalate when. Do not create a MIP-run manifest when alias docking or local wording repair preserves denotation. Do not treat a suite, plan, wiring module, or lexical cleanup as mechanism meaning unless the changed item needs a new or revised governing definition.

Same problem, different question under repair. For a mechanism-adjacent transformation-flow problem, use E.18 for transformation-flow structure, graph/path, valuation, or crossing claims, A.20 for internal step validity, A.21 for gate-decision publication, and E.20 for mechanism-meaning placement; do not open the other three until their own claim is present.

Semantic repair return. When E.20 blocks a misleading word, face, alias, or source label, the repair must return to the enabled authoring move: name the governing definition, canonical location, alias-docking relation, or non-trigger stop that remains available under E.20. Do not stop at a classification of vocabulary or publication faces.

Governed-object and relation separation. Keep the graph object and path or crossing relation (E.18), MVPK publication faces (E.17), internal CV status and witness (A.20), gate decision and DecisionLog (A.21), evidence or provenance relation (A.10/G.6), work plan or work occurrence (A.15), and mechanism-governing definition assignment (E.20) distinct. An MVPK face, DecisionLog, evidence value, provenance reference, MIP manifest, or work witness does not supply another pattern's project-side value unless that governing pattern consumes it for that relation.

Smallest affected locus. Localize the change to the smallest current locus: PathSlice or crossing in E.18, CV step in A.20, GateDecision equivalence class in A.21, or mechanism-governing definition in E.20. Do not widen to a whole flow or unrelated claim, locus, or EntityOfConcern when that locus is enough.

Ordinary success. For ordinary E.20 use, success is that the edit is classified, the current governing locus or alias-docking relation is named, and no MIP-run manifest is opened unless denotation, mechanism meaning, suite denotation, suite closure, suite obligations, suite pins, suite protocol semantics, planning pins, wiring semantics, or governing-definition assignment actually changes.

Locality asymmetry. E.18 is graph-local, A.20 is step-local, A.21 is gate-local, and E.20 is trigger-local. Do not normalize the four patterns into one assurance regime.

Do not merge these pairs. Keep CV.Status distinct from GateDecision, E.18 Check locus distinct from GateCheckKind, MIP manifest distinct from DecisionLog, ViewpointMap distinct from graph semantics, PathSlice distinct from a work run, and GateProfile=Lite distinct from PublishMode=Lite.

Field applicability. Always core for E.20: trigger triage and the current governing locus or alias-docking relation. Conditional fields: MIP-run manifest fields, canonical mechanism card stubs, suite fields, planned-baseline pins, wiring refs, RSCR triggers, PQG coverage, and deprecation continuity; open them only when the corresponding denotation, mechanism-meaning, suite, planning, wiring, lexical, refresh, review, or retirement claim is present.

Retrieval trap guard. When excerpted alone, E.20 manifest language must not be read as requiring a full MIP-run for every mechanism-adjacent edit. Pure currentness cleanup, alias docking, optional suite-member citation of an already-defined mechanism, and local wording repair stop at the current governing locus unless denotation, mechanism meaning, suite closure, suite obligations, suite pins, suite protocol semantics, planning pins, wiring semantics, or governing-definition assignment changes.

Anti-Goodhart guard. A complete MIP-run manifest is not a substitute for the governed mechanism result: the mechanism-governing definition must still carry the operation, law, admissibility, slot, transport, applicability, and audit meaning needed for the claim.

Generative side. E.20 preserves open-ended action by allowing new mechanism definitions, suite variants, wiring, and citeable tokens to enter FPF with a named governing definition; the discipline prevents semantic drift so new work can be added rather than merely blocked.

What goes wrong if missed. A suite can start defining mechanism meaning, a plan item can start carrying enactment witnesses or gate decisions, a wiring module can carry kernel semantics, or a token rename can break citations while looking like harmless cleanup.

What this buys. E.20 gives the reader one current authoring move: assign the change to the right governing definition and keep mechanism, suite, planning, wiring, and lexical continuity distinct.

Not this pattern when. If the edit is only pure currentness, typo, reference, or old-label cleanup and changes no semantics or citeable-token denotation, record the current governing locus and stop. If the question under repair is runtime gate passage, gate decision, approval, suite-as-mechanism, plan-as-enactment, or performed work, use the gate, suite, planning, or work loci that own that question. A MIP-run manifest is not a runtime gate, gate passage, approval packet, or binary pass/fail decision.

#Problem

When a new mechanism (or mechanism family) is introduced without an explicit authoring protocol:

1. Governing-definition ambiguity causes partial changes: a suite enumerates a new ...MechanismDefinitionRef, but the canonical U.Mechanism definition card is missing or inconsistent.
2. Boundary erosion occurs: suite descriptions start to define mechanism semantics; method wiring starts to redefine kernel meaning; publication/telemetry becomes a hidden tail.
3. Plan/enactment confusion appears: planned slot fillings start to carry launch values, witnesses, or gate decisions.
4. Terminology drift breaks citations: renames happen silently; tokens fragment across registers; downstream references become unstable.
5. Review becomes non‑local: every introduction is a bespoke scavenger hunt across patterns, making training, review, and refresh unreliable.

#Forces

#Solution — the Mechanism Introduction Protocol (MIP)

#Terminology note (disambiguation)

This protocol and any MIP-run manifest are authoring-side semantic-governing-definition assignment maps. A manifest is not an approval packet, gate, runtime decision, or pass/fail result. It names where mechanism meaning is governed and what must not be inferred from suites, plans, wiring, aliases, or gates.

MIP governs how changes are assigned to their governing definitions, not how systems execute.

MIP trigger triage. Not every reference cleanup is a MIP-run. Classify the proposed edit before requiring a manifest:

• MIP not triggered: pure currentness, reference, typo, or old-label cleanup that changes no mechanism, suite, planned-baseline, wiring, governing-definition, or citeable-token semantics.
• Local wording or alias-docking only: wording clarifies an already-governed mechanism relation, or F.18 alias docking preserves citeability of an old token without changing what the token denotes.
• MIP-run manifest required: the edit changes mechanism meaning, suite denotation, suite closure, suite obligations, suite pins, suite protocol semantics, planned-baseline pins, wiring semantics, governing-definition assignment, or what a citeable token denotes.

Only the third outcome uses the manifest in E.20:4.2. The first two still name the current governing locus or alias-docking relation when the text will be published. When the only current result is no denotation change, the published content should not carry MIP-run vocabulary except as a short non-trigger note.

#Mint vs reuse

Mints:

• MIP — Mechanism Introduction Protocol (this pattern).
• MIP-run — an authoring event that applies this protocol to a concrete change set, captured as a short manifest (recorded as a DRR-linked change record or an equivalent, explicitly citeable change record).

Reuses:

• U.Mechanism definition cards and MechanismDefinitionRef, suite descriptions (MechSuiteDescription and specializations), WorkPlanning plan items (SlotFillingsPlanItem and specializations), alias docking (F.18), RSCR triggers (G.Core), and PQG profiles (E.19).

#Step 1: Classify the introduction

A MIP-run SHALL first classify the change, because different classes have different governing definitions:

1. New mechanism family, species, or archetypal grounding (new U.Mechanism archetypal definition).
2. New mechanism definition within an existing A.6.1 mechanism kind (new MechanismDefinitionRef, new canonical card).
3. Mechanism revision (signature/laws/slots/transport/audit semantics change).
4. Suite change (membership, obligations, spec pins, suite protocols, suite audit obligations).
5. Planned-baseline change (new or revised SlotFillingsPlanItem specialization, or changes to its pins).
6. Wiring change (new or revised Part‑G extension modules, SoTA method packs, selectors).
7. Terminology migration (renames, token splits/merges, register changes).
8. Deprecation / supersession / retirement (marking mechanisms/suites/plan items as deprecated, declaring successors, and preserving citeability; apply E.20:4.9.1).

Mechanism kind boundary. A MIP-run may introduce a new MechanismDefinitionRef. It does not introduce a new E.18 transformation-flow locus kind or transformation-flow structure unless E.18 is explicitly updated, and it does not introduce a new C.3 U.Kind unless C.3 and A.6.5 discipline is the current governing question.

A.6.1 compatibility. MIP assigns mechanism meaning to A.6.1-governed mechanism definitions: operation algebra, law set, admissibility conditions, SlotIndex, per-operation SlotSpecs with required input and output SlotKinds, transport or bridge regime, applicability, audit, and monotone realization relation when declared. Suites, planned-baseline records, and Part-G wiring modules may cite or bind that meaning; they do not supply or redefine it.

New mechanism-family criterion. Treat a change as a new mechanism family, species, or archetypal grounding only when the existing mechanism-governing pattern cannot express the operation algebra, law set, admissibility conditions, SlotIndex, per-operation SlotSpecs, required input/output SlotKinds, transport boundary, audit semantics, or monotone realization relation when declared without changing its kind invariants. Otherwise classify the change as a new mechanism definition or MechanismDefinitionRef within an existing A.6.1 mechanism kind.

A single MIP-run MAY span multiple classes, but SHALL treat each class with its correct governing-definition assignment (below).

#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, or DRRId, 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 (MechanismDefinitionRef, SlotKind tokens, PatternScopeId, etc.) when token denotation or citeability changes,
• the best-known Delta-Class (Δ-0 to Δ-3) and impact radius estimate (E.15) when the run is plausibly Δ-2 or Δ-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):

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.

#Step 3: Card-first canonicalization (eliminate dangling refs)

If the introduction adds a new MechanismDefinitionRef anywhere (especially inside a suite):

1. The MIP-run SHALL first create a canonical mechanism card at the governing pattern location that publishes the MechanismDefinitionRef and the minimal identity fields (names, intent, and "this is a distinct mechanism").
2. The card MAY be a stub initially, but SHALL reserve:

• the stable MechanismDefinitionRef (and its lexical register entry per E.10/F.17),
• the intended mechanism family or species placement, and
• a DRR pointer for completing semantics (including any missing register/twin-label work).

Only after (1) is in place MAY suites or protocols enumerate the new MechanismDefinitionRef.

#Step 4: Mechanism semantics completion (what “done” means)

Definition-of-done note (delegated). MIP uses two completion checkpoints for mechanism cards:

• Stub done - a citeability stub for a MechanismDefinitionRef: a resolvable canonical target created only to prevent dangling references (E.20:4.3), not semantic completion.

A stub SHALL (i) exist at the mechanism-governing pattern's canonical location, (ii) reserve and publish the stable MechanismDefinitionRef (and its lexical/register entries), (iii) set MechanismDefinitionHeader.status = draft, and (iv) carry an explicit DRR pointer for completing semantics. A stub SHALL also list the A.6.1 conformance checklist item IDs it does not yet satisfy (without duplicating that checklist here). A stub may preserve citeability for suite or protocol enumeration, but it does not authorize suite closure, gate checks, planned baselines, wiring consumption, reuse, or import unless the fields required for that use are present and marked current.

• Introduced done - a mechanism card that can be relied upon as a U.Mechanism definition. "Introduced done" is defined by A.6.1 conformance: the card SHALL satisfy the applicable A.6.1:7 Conformance Checklist items (CC-UM.*), with the baseline items designated by A.6.1 (e.g., CC-UM.0 and CC-UM.1) being the minimum requirement.

The list below is informative only (semantic orientation); the normative structure and “done” criteria are delegated to A.6.1’s CC items to avoid drift between this protocol and the canonical mechanism definition.

For an “introduced” mechanism beyond a stub, the useful completion target is to make the following semantic fields explicit:

• Operation field: the named operations that the mechanism provides (signature-scoped intent).
• Law/invariant field: the invariants that govern the operations, including admissibility constraints when applicable.
• Admissibility field: preconditions or eligibility predicates for admissible operation (not a gate decision log, and not per-run outcomes).
• Slot discipline: SlotIndex, required input and output SlotKinds, per-operation SlotSpecs, stable ValueKinds, and explicit ref modes.
• Specialisation discipline (when ⊑/⊑⁺ is declared): explicit parent+morphism kind; SlotKind invariance; monotone ValueKind narrowing; no new mandatory inputs to inherited operations (per A.6.1:4.2.1 / CC‑UM.8).
• Transport and realization discipline: declarative transport semantics with no hidden crossings; when a realization relation is declared, it is monotone against the mechanism declaration and may tighten laws or guards but must not relax them.
• Audit obligations: which evidence references are required when the mechanism is used.

If the mechanism introduces new slot kinds shared across a family/suite, apply E.20:4.5.

#Step 5: Suite-scoped slot-token lexicon discipline (prevent slot drift)

If the mechanism belongs to a suite or family where multiple member mechanisms share slot vocabulary:

1. The suite-governing pattern SHALL provide a suite-scoped slot-token lexicon referencing A.6.5 SlotSpecs (or update it if already present) in the suite-governing pattern's canonical location (A.6.7 / A.6.7.<FamilyKey>), or as a dedicated lexicon card explicitly referenced from there. The lexicon cites and organizes SlotKind tokens; it does not create new SlotKind semantics.

2. Mechanism cards SHALL cite slot kinds from that lexicon (rather than minting local near-duplicates).

3. New slot kinds SHALL be introduced into the lexicon first, then referenced by member mechanisms. If any citeable SlotKind tokens are minted/renamed, apply E.20:4.9.

This step is specifically intended to prevent the “same idea, different slot token” drift that makes planned baselines and audits non‑portable.

#Step 6: Suite integration (if the mechanism is a suite member)

If the introduction changes a suite (MechSuiteDescription or specialization):

1. Membership set semantics (WF‑MS‑1). mechanisms is a set: duplicates are nonconformant and list order carries no semantics.
2. Ordering is only in protocols. If ordering matters, express it only in suite_protocols.
3. Protocol closure (WF‑MS‑2). If suite_protocols is present, then for every ProtocolStep in every SuiteProtocol, step.mechanism ∈ mechanisms.
4. No hidden tails. Required stages (e.g., normalization/aggregation/Γ‑fold) are explicit protocol steps; do not hide them inside other steps.
5. Guard/gate separation. Suites and mechanisms SHALL NOT publish GateDecision/DecisionLog. AdmissibilityConditions and tri‑state GuardDecision remain governed by the mechanism definition; OperationalGate(profile) acceptance thresholds and pass/fail criteria remain gate/acceptance concerns.
6. Suite is descriptive only (WF‑MS‑3/4). Any publish/telemetry continuation is outside the suite protocol and terminates via publication faces, packs, or modules; suites SHALL NOT define mechanism blocks (OperationAlgebra, LawSet, Transport, Audit, …).

Kernel stability rule (recommended). If the suite is a kernel suite, and the change adds a new required stage, prefer creating a suite variant rather than mutating the kernel membership. If mutation is unavoidable, pair it with terminology continuity (E.20:4.9) and RSCR triggers (E.20:4.10).

#Step 7: Planned baseline & P2W planning-to-work boundary (if planning changes)

If the mechanism introduction changes what a WorkPlanning baseline pins (e.g., selected comparator specs, method descriptions, time selector, guard pins):

1. Introduce or revise a SlotFillingsPlanItem specialization under the WorkPlanning governing pattern.
2. The plan item SHALL remain planning-only:
   • pins/refs only (ByValue or <RefKind>),
   • no launch values,
   • no FinalizeLaunchValues witnesses,
   • no gate decisions or decision logs.
   • time is explicit: include Γ_time_selector or Γ_time_rule_ref (XOR); implicit “latest/current” is nonconformant.
3. The plan item SHALL target exactly one Description-scoped, edition-addressable slot-bearing description via target_slot_bearing_description_ref (typically a kit or suite) and SHALL NOT target a MechanismDefinitionRef. If a "standalone mechanism baseline" is needed, introduce an explicit Description-scoped slot-bearing description wrapper (e.g., a mech kit or a suite-of-one) and target that.

This step exists to keep the P2W planning-to-work boundary crisp: planning defines planned fillers, enactment witnesses actual runs.

#Step 8: Wiring & SoTA updates (keep method evolution out of kernel)

If the introduction involves methods, comparators, selectors, or other SoTA-sensitive choices:

1. Put method/comparator family semantics in SoTA packs (G.2) and reference them by edition-pinned refs.
2. Pin the chosen SoTA refs for a baseline in WorkPlanning plan items (E.20:4.7); wiring consumes pins rather than silently overriding them.
3. Put flow/task binding logic in wiring modules (GPatternExtension), with an explicit PatternScopeId and declared governing pattern.
4. Wiring may bind, select, dispatch, or cite SoTA method packs; it may not redefine the operation, law, admissibility, transport, slot, or audit meaning of the mechanism it wires.
5. If a SoTA update changes a mechanism's signature/laws, that semantic change SHALL be performed in the mechanism-governing pattern, under the A.6.1 mechanism-definition template; the change SHALL emit RSCR triggers (E.20:4.10).

#Step 9: Terminology continuity (alias docking)

If the introduction renames any public token or changes canonical naming:

1. Use lexical alias docking (F.18) so old tokens remain citeable.
2. Update registers and twin labels per lexical discipline.
3. Avoid silent rewrites: the MIP-run SHALL make the alias relation and successor relation explicit.

#Deprecation / supersession / retirement (preserve citeability)

If the change class includes deprecation/supersession/retirement (E.20:4.1 #8), the MIP-run SHALL preserve reference continuity while making the status change explicit:

1. Preserve the canonical target. The deprecated mechanism card, suite description, plan item, or wiring module SHALL remain resolvable at its canonical location; deprecation MUST NOT be implemented by removal that would break citations.
2. Keep the public token citeable. The deprecated token (MechanismDefinitionRef, suite token, plan-item token, etc.) SHALL remain citeable. If a successor token/name is introduced, the old token SHALL be alias-docked per F.18 (E.20:4.9).
3. Declare successor (or “no successor”). The deprecated mechanism card, suite description, plan item, or wiring module SHALL declare a successor pointer (or explicitly declare that there is none) using the project’s established deprecation/supersession fields.
4. Assign downstream updates to governing definitions. Any needed suite denotation, closure, obligation, pin, protocol-semantic, WorkPlanning-pin, or wiring-semantic change SHALL be performed in its respective governing definition (E.20:4.2), preferably by introducing a suite variant rather than silently swapping kernel membership.
5. Emit RSCR triggers. Deprecation/supersession SHALL emit typed RSCR triggers and extend the regression envelope (E.20:4.10), including checks for dangling refs and alias coverage.

#Step 10: RSCR triggers + regression envelope

A MIP-run that changes any of:

• mechanism signatures,
• suite membership/protocols,
• planned baseline pins,
• slot vocabulary / SlotKind lexicon,
• terminology/alias docking that changes citeable tokens,
• or other reference loci

SHALL emit typed RSCR triggers via the RSCR governing pattern and SHALL extend the regression envelope to include, at minimum:

• no dangling MechanismDefinitionRef enumerations,
• suite membership set semantics + protocol closure,
• guard/gate separation preservation,
• P2W planning-to-work boundary preservation (planning vs enactment).

Guard (normative). Trigger kind identifiers (e.g., RSCRTriggerKindId) SHALL be selected from the RSCR trigger catalogue governed by G.Core. A MIP-run SHALL NOT mint ad hoc trigger kinds (“reason kinds”) scattered in arbitrary patterns/modules.

Manifest hook (recommended). The MIP-run manifest SHOULD list emitted trigger types and the regression envelope deltas as checkable items.

#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).

#Archetypal Grounding (Tell–Show–Show)

Show 0 (suite member, no new mechanism meaning). A suite adds an already-defined MechanismDefinitionRef as an optional member and changes no operation, law set, admissibility condition, SlotIndex, required input/output SlotKinds, per-operation SlotSpecs, transport boundary, audit semantics, monotone realization relation when declared, planned-baseline pins, or wiring semantics. E.20 records the suite-governing locus and stops; no new mechanism-governing card and no MIP-run manifest are opened.

#Bias-Annotation

Lenses tested: Governance (governing-definition assignment, continuity), Architecture (boundary hygiene and modularity), Onto/Epist (meaning placement and type discipline), Pragmatic authoring (reviewability, governing-definition split handling), Didactic (Tell-Show-Show training scaffold).

#Conformance Checklist (normative)

Conformance use. This checklist is evidence for the governing-definition assignment guidance already stated in the Solution. It is not the first entry text for ordinary use and not a full audit regime by default; an item is applied only when its corresponding trigger triage, manifest, card, suite, planning, wiring, lexical, RSCR, PQG, or deprecation move is present. Before applying any item, name the Solution move it tests; if no such reader move is present, treat the item as orientation-only or not applicable rather than expanding the applied assurance or conformance material.

Conformance groups. Ordinary E.20 use starts with trigger triage and stops at the current governing locus when no denotation or mechanism-meaning change is present. Manifest-core items apply only when a MIP-run is actually triggered. Publication/assurance items apply only when citeability, card stubs, alias docking, RSCR, PQG, or deprecation continuity is part of the current claim. Crossing, launch, and work-enactment checks are not governed by E.20; if those claims become present, use the gate, planning, or work loci and keep E.20 to governing-definition assignment.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

• Mechanism introductions become trainable and reviewable (a repeatable governing-definition map).
• Reduces drift by requiring one governing pattern for each mechanism meaning and keeping semantics in their governing pattern.
• Keeps suites descriptive and the P2W planning-to-work boundary crisp, improving auditability.
• Supports SoTA evolution without destabilizing kernel meaning.

Costs

• Introductions use more explicit assignment records (governing-definition map, PQG coverage).
• Some changes will be split into multiple governed edits (by design), which increases authoring overhead.
• Kernel stability discipline can feel “slow” when a team wants a quick mutation.

#Rationale

Mechanisms are high-leverage semantic units: a small change can touch suites, planned baselines, wiring modules, and audits. Without a protocol, the corpus tends toward semantic duplication across governing loci and non-local correctness (you can’t know what changed without reading everything).

Governing-definition-directed authoring is a pragmatic compromise: it does not depend on tooling, yet it gives a stable governing-definition map that enables subsequent review and refresh.

#SoTA-Echoing

#Relations

Builds on:

• E.8 (pattern structure and normative authoring discipline)
• E.10 / F.17–F.18 (lexical registers, twin labels, alias docking)
• E.19 (PQG/PCP profile-based review)
• E.15 (evolution discipline; DRR/edition thinking)

Coordinates with:

• A.6.1 (U.Mechanism definition template governance)
• A.6.7 (MechSuiteDescription integrity)
• A.15.3 (SlotFillingsPlanItem and planned baseline seam)
• E.18 (TransformationFlowStructure values that cite planned baselines)
• G.Core (RSCR trigger catalogue)
• G.2 (SoTA synthesis packs)
• G.x:Ext.* (wiring modules via GPatternExtension)

Constrains:

• Any change set that introduces or revises mechanisms, suites, planned baselines, or wiring in a way that changes citeable loci.

#E.20:End

---

Last Updated: 2026-05-15 — this section last modified in upstream FPF commit 37a19061 (github.com/ailev/FPF)