E.20:4.7 - Step 7: Planned baseline & P2W planning-to-work boundary (if planning changes)

If the mechanism introduction changes what one exact U.WorkPlan pins, such as selected comparator specifications, method descriptions, a time selector, or guard pins, the WorkPlan edition is the identifiable planning object.

1. Introduce or revise the SlotFillingsPlanItem rows as declaration-local ClaimGraph content inside that exact WorkPlan. Each row points to a declaration member whose own pattern defines its meaning and later actual-use rule.
2. Give no row an independent kind, record identity, edition, specialization lineage, canonical target, or successor relation. Changing identity-bearing row content changes the WorkPlan’s claim content and is handled as a WorkPlan-edition change under C.2.1 and A.15.2.
3. Keep the declaration-local planned-filling content planning-only:
   • pins and references only, whether ByValue or through the declared reference kind;
   • no launch values;
   • no FinalizeLaunchValues witnesses;
   • no gate decisions or decision logs; and
   • explicit time through Γ_time_selector or Γ_time_rule_ref (XOR); implicit “latest” or “current” wording is nonconformant.
4. In this mechanism-baseline branch, the WorkPlan’s planned-filling content SHALL target exactly one Description-scoped, edition-addressable slot-bearing description through target_slot_bearing_description_ref, typically a kit or suite. It SHALL NOT target a MechanismDefinitionRef. If a standalone mechanism baseline is needed, introduce an explicit Description-scoped slot-bearing description wrapper, such as a mechanism kit or suite-of-one, and target that.
5. When a receiver needs one row, cite it only through the exact WorkPlan edition and a stable local-content locator. The locator does not make the row independently resolvable.

This step keeps the P2W planning-to-work boundary crisp: the WorkPlan states planned fillers; enactment witnesses actual runs.