#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 semantic owners across Parts A/E/F/G and can easily create drift:

#Keywords

• mechanism introduction
• authoring protocol
• owner routing
• 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 semantic owners across Parts A/E/F/G and can easily create drift:

• semantics leak into the wrong plane (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 “workpad commitments” without ownership.

This pattern defines a repeatable, owner‑routed protocol for introducing mechanisms that keeps the kernel coherent while remaining extensible.

#Problem

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

1. Ownership 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 is an authoring-plane route map. It is not a suite protocol (SuiteProtocol in MechSuiteDescription) and is not a runtime gating mechanism (OperationalGate(profile) or any gate-level decision log).
MIP governs how changes are routed to their semantic owners, not how systems execute.

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

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 owners:

1. New mechanism kind / new archetypal grounding (new U.Mechanism.Intension archetype).
2. New mechanism intension within an existing kind (new …IntensionRef, new canonical card).
3. Mechanism revision (signature/laws/slots/transport/audit semantics change).
4. Suite change (membership, obligations, contract 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).

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

#Step 2: Declare the semantic owner route map (mandatory)

For every new or modified artifact, the MIP-run SHALL declare exactly one semantic owner and route the change there. In FPF, an “owner” is a citeable container that can be patched: a PatternId (or PatternId:SectionPath) for text, a PatternScopeId = G.x:Ext.* for wiring modules, or a DRRId (E.9) for a decision/rationale record. The declaration SHALL be captured as a MIP-run manifest in a citeable change record (typically DRR-linked) listing, at minimum:

• the change class(es) from E.20:4.1,
• each touched artifact → owner → canonical location (expressed as PatternId:SectionPath / PatternScopeId / DRRId, not as prose),
• any new/changed citeable tokens (…IntensionRef, SlotKind tokens, PatternScopeId, etc.),
• the best-known Delta-Class (Δ‑0…Δ‑3) and an impact radius estimate (E.15) when the run is plausibly Δ‑2/Δ‑3,
• intended RSCR trigger types, and
• the PQG (E.19) profile set used to review the run.

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 SemanticOwnerPatternId (wiring is binding-only; meaning remains owner-routed).

Canonical owner route map (normative):

Guard (normative). Any proposed change that cannot name a semantic owner from the table above SHALL be treated as non-normative workpad content and SHALL NOT be relied upon as an architectural commitment. Such content MAY exist only as explicitly-marked workpad material until routed.

#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 owning pattern location that publishes the …IntensionRef and the minimal identity surface (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 kind/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 resolvable canonical target created to eliminate dangling references (E.20:4.3). A stub SHALL (i) exist at the mechanism-card owner’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 is sufficient to unblock suite/protocol enumeration, but MUST NOT be treated as an “introduced” mechanism for reuse/import decisions.
• 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.

To be considered “introduced” (beyond a stub), a mechanism card SHOULD make the following semantic surfaces explicit:

• Operation surface: the named operations that the mechanism provides (signature-level intent).
• Law / invariant surface: the invariants that govern the operations (incl. legality constraints when applicable).
• Admissibility surface: preconditions/eligibility predicates for valid operation (not a gate decision log, and not per-run outcomes).
• Slot contract: required inputs/outputs as 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 surfaced via Bridges where required).
• Audit obligations: which evidence anchors must exist when the mechanism is used.

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

#Step 5: SlotKind lexicon discipline (prevent slot drift)

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

1. The suite owner SHALL provide a suite-level SlotKind lexicon (or update it if already present) in the suite owner’s canonical location (A.6.7 / A.6.7.<FamilyKey>), or as a dedicated lexicon card explicitly referenced from there.
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 affects 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 mechanism-owned; OperationalGate(profile) acceptance thresholds and pass/fail criteria remain gate/acceptance-level concerns.
6. Suite is descriptive only (WF‑MS‑3/4). Any publish/telemetry continuation is outside the suite protocol and terminates via publication surfaces (packs/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 is affected)

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

1. Introduce or revise a SlotFillingsPlanItem specialization under the WorkPlanning owner.
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-level, edition-addressable slot owner via target_slot_owner_ref (typically a kit or suite) and SHALL NOT target a U.Mechanism.IntensionRef. If a “standalone mechanism baseline” is required, introduce an explicit Description-level slot-owner 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 semantic owner.
4. If a SoTA update requires changing a mechanism’s signature/laws, that semantic change SHALL be performed in the mechanism card owner (A.6.1) and 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 migration 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 artifact (mechanism card / suite description / plan item / 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 artifact SHALL declare a successor pointer (or explicitly declare that there is none) using the project’s established deprecation/supersession fields.
4. Route downstream updates by owner. Any required suite membership/protocol changes, WorkPlanning pins, or wiring changes SHALL be performed via their respective semantic owners (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 affecting citeable tokens,
• or other reference surfaces

SHALL emit typed RSCR triggers via the RSCR owner 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 owned in 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 surface changed,
  • PCP‑P2W if any planned-baseline surface 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 / 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 split routing (mandatory when semantics were placed in the wrong owner; the change is split into owner-correct patches).
3. Proceed via suite variant (preferred when kernel stability is threatened by adding new required stages).
4. Defer (insufficient semantics; stub exists but completion is DRR-tracked).
5. Reject (violates invariants such as suite-as-gate, plan-as-enactment, or semantic owner ambiguity).

#Archetypal Grounding (Tell–Show–Show)

#Bias-Annotation

Lenses tested: Governance (semantic ownership, continuity), Architecture (boundary hygiene and modularity), Onto/Epist (meaning placement and type discipline), Pragmatic authoring (reviewability, split routing), Didactic (Tell–Show–Show training affordance).

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

• Mechanism introductions become trainable and reviewable (a repeatable route map).
• Reduces drift by enforcing single semantic ownership and preventing semantic leakage.
• Keeps suites descriptive and the P2W seam crisp, improving auditability.
• Supports SoTA evolution without destabilizing kernel meaning.

Costs

• Introductions require more explicit routing artifacts (owner map, PQG coverage).
• Some changes will be split into multiple patches (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 affect suites, planned baselines, wiring modules, and audits. Without a protocol, the corpus tends toward semantic smearing (meaning duplicated across planes) and non-local correctness (you can’t know what changed without reading everything).

Owner‑routed authoring is a pragmatic compromise: it does not require tooling, yet it produces a stable “map of truth” that makes future review and refresh feasible.

#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 ownership)
• 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 affects citeable surfaces.

#E.20:End