#Mechanism Introduction Protocol (MIP)

E.20 · Draft · 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-memory 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.* intensions, 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.* intensions, 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 supports 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-intension 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 admissible 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 live mechanism-intension 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-intension 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 live question. For a TGA-looking problem, use E.18 for graph/flow/crossing, 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 live.

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 admissible. 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 carrier, MIP manifest, or work witness does not carry another pattern's project-side value unless that exact governing pattern consumes it for that relation.

Smallest affected locus. Localize the change to the smallest live 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 governed object 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, TGA Check 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 liveness. Always core for E.20: trigger triage and the current governing locus or alias-docking relation. Conditional-live: 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 live.

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 intensions, 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 live question 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 …IntensionRef, but the canonical U.Mechanism.Intension 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 lives 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-intension 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 live 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.Intension / U.Mechanism.IntensionRef, 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.Intension archetype).
2. New mechanism intension within an existing A.6.1 mechanism kind (new …IntensionRef, 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 U.Mechanism.IntensionRef. It does not introduce a new U.Transduction(kind=...) 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 explicitly live.

A.6.1 compatibility. MIP assigns mechanism meaning to A.6.1-governed mechanism definitions: operation algebra, law set, admissibility conditions, slot interface, transport or bridge regime, applicability, and audit. 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, slot interface, transport boundary, or audit semantics without changing its kind invariants. Otherwise classify the change as a new mechanism intension or …IntensionRef 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 support fields appear only when live:

• the change class(es) from E.20:4.1 when needed to disambiguate the assignment,
• new or changed citeable tokens (…IntensionRef, 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 refresh or regression wiring is live, 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 carrier until assigned to its governing definition.

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

If the introduction adds a new U.Mechanism.IntensionRef anywhere (especially inside a suite):

1. The MIP-run SHALL first create a canonical mechanism card at the governing pattern location that publishes the …IntensionRef 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 …IntensionRef (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 …IntensionRef.

#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 U.Mechanism.IntensionRef: 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 …IntensionRef (and its lexical/register entries), (iii) set IntensionHeader.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.Intension. “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 interface: required input and output slot kinds, with stable kinds 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: declarative transport semantics (no hidden crossings; crossings are published via Bridges where required).
• Audit obligations: which evidence anchors 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 seam (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 U.Mechanism.IntensionRef. 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 seam 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-intension 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 (…IntensionRef, 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 …IntensionRef enumerations,
• suite membership set semantics + protocol closure,
• guard/gate separation preservation,
• P2W seam 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 U.Mechanism.IntensionRef as an optional member and changes no operation, law set, admissibility condition, slot interface, transport boundary, audit semantics, 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.

| Governing-definition assignment | Each change item has one governing definition; changes are assigned there, not smeared. | 1) Add the new mechanism card under the mechanism-governing pattern. 2) Add a suite variant under the suite-governing pattern. 3) Pin the variant via a planned-baseline specialization. 4) Wire the variant via a GPatternExtension. | 1) Add a new archetypal grounding under the governing pattern. 2) Add A.6.7.<FamilyKey> describing the suite. 3) Add a suite-specific SlotFillingsPlanItem specialization. 4) Add SoTA packs and wiring modules. | | Card-first | No suite enumerates a missing …IntensionRef. | Create the new …IntensionRef card stub first; then update the suite variant membership. | Create the new mechanism-governing card(s) first; then publish suite membership by …IntensionRef. | | Suite discipline | Suites are descriptive: membership, obligations, pins, protocols; not mechanisms and not gates. | The variant’s suite_protocols explicitly names the new stage; publish/telemetry remains outside the suite. | The new suite defines shared obligations and allowed pipelines without embedding mechanism semantics. | | P2W seam | Planning pins refs; enactment witnesses runs. | The plan item pins the chosen suite variant and any method/spec refs; no launch values or decision logs. | The plan item specialization defines the planned fillers/pins that downstream flows cite. | | SoTA updates | Methods change faster than kernel meaning; wiring is where choices live. | A GPatternExtension selects a post-2015 scoring method by edition‑pinned ref; no kernel mutation required. | The family ships method packs and wiring modules; kernel cards remain the semantic source of mechanism meaning. |

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

#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 live. Before applying any item, name the Solution move it tests; if no such reader move is live, treat the item as support-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 live. 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 are live. Crossing, launch, and work-enactment checks are not governed by E.20; if they become live, use the gate, planning, or work loci and keep E.20 to governing-definition assignment.

| CC-E20-1 (Governing-definition assignment declared). | Every MIP-run SHALL provide a MIP-run manifest that lists each changed item, exactly one governing definition, and the canonical location; each changed item SHALL be written in that canonical location. | Prevents “floating commitments” and semantic placement errors. | | CC‑E20‑2 (Card-first canonicalization). | Any new U.Mechanism.IntensionRef enumerated anywhere SHALL resolve to a canonical mechanism card (stub allowed) before suite/protocol enumeration. | Eliminates dangling refs. | | CC‑E20‑3 (Suite discipline preserved). | If a suite is edited, it SHALL preserve: membership set semantics, protocol closure, no hidden tails, no gate decisions/logs, no publication records. | Prevents suite-as-gate and suite-as-mechanism drift. | | CC‑E20‑4 (SlotKind lexicon used when shared). | If mechanisms share slot vocabulary in a family/suite, a suite-scoped lexicon SHALL exist and member mechanisms SHALL cite it. | Stops slot token drift. | | CC‑E20‑5 (P2W seam preserved). | If planned baselines are edited, plan items SHALL remain WorkPlanning-only (pins/refs only), SHALL target exactly one Description-scoped slot-bearing description via target_slot_bearing_description_ref (and SHALL NOT target a U.Mechanism.IntensionRef), and SHALL NOT contain enactment witnesses, launch values, or gate decisions. | Keeps planning and enactment separable and auditable. | | CC‑E20‑6 (Kernel stability handled). | If a kernel suite would gain a new required stage, the change SHOULD be expressed as a suite variant; if mutation occurs, it SHALL include continuity measures (alias docking and explicit delta). | Minimizes E.15 impact radius of kernel edits. |

| CC‑E20‑7 (SoTA wiring, not kernel semantics). | Method/comparator choices SHALL be represented via SoTA packs and wiring modules; if a SoTA update changes mechanism semantics, that change SHALL be made in the mechanism-governing pattern and not by wiring. | Prevents silent semantic shifts. | | CC‑E20‑8 (Terminology continuity). | Any rename changing citeable tokens SHALL use alias docking and register updates; silent rewrites are non‑conformant. | Preserves reference stability. | | CC‑E20‑9 (RSCR triggers + regressions). | Any semantic or reference-change SHALL emit RSCR triggers and extend the regression envelope to cover dangling refs + suite closure + guard/gate separation + P2W seam. | Makes changed loci and regression obligations explicit and testable. |

| CC‑E20‑10 (PQG coverage). | Every MIP-run SHALL be reviewed under PQG (E.19) with PCP‑BASE and the triggered profiles implied by the change. | Normalizes review and refresh. | | CC‑E20‑11 (Deprecation preserves citeability). | Any deprecation/supersession/retirement action SHALL preserve citeability of the deprecated token (alias docking if renamed), keep the canonical mechanism card, suite description, plan item, or wiring module resolvable, and declare a successor pointer or “no successor” explicitly (E.20:4.9.1). | Prevents broken citations and orphaned semantics during evolution. |

#Common Anti-Patterns and How to Avoid Them

| Token drift by silent rename | “Just rename UNM to ...” without aliasing. | Breaks citations and downstream reasoning. | Use F.18 alias docking; update registers explicitly. | | MIP as gate surrogate | A MIP-run manifest is treated as a runtime pass/fail result or gate passage. | Governing-definition assignment is being mistaken for project execution or gate decision. | Keep MIP as authoring-side governing-definition assignment; use A.21 for gate decisions and A.15 for work or enactment claims. | | Governing-definition ambiguity | “We’ll put it somewhere later.” | Leaves incompleteness and drift invisible. | Name the governing definition up front; otherwise treat as non-normative. |

#Consequences

Benefits

• Mechanism introductions become trainable and reviewable (a repeatable governing-definition map).
• Reduces drift by requiring one governing pattern for each mechanism-intension meaning and keeping semantics in their governing pattern.
• Keeps suites descriptive and the P2W seam 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 supports 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.Intension template governance)
• A.6.7 (MechSuiteDescription integrity)
• A.15.3 (SlotFillingsPlanItem and planned baseline seam)
• E.18 (E.TGA flows 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)