#SlotFillingsPlanItem — Planned Slot-Fillings Baseline (WorkPlanning PlanItem)

A.15.3 · Stable · Normative unless explicitly marked informative · Part A - Kernel Architecture Cluster

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

Tech-name: SlotFillingsPlanItem Plain-name: planned slot-fillings baseline item Short code: SFPI Pattern type: Definitional WorkPlanning pattern Status: Stable Normativity: Normative unless explicitly marked informative Placement: Part A -> A.15 work family Builds on: A.15.2 U.WorkPlan, A.15.1 U.Work, A.6.5 U.RelationSlotDiscipline, E.10.D2, E.17, E.18.1, and E.20 Used by: P2W work-planning slices, suite or kit planned baselines, Part G planned-baseline references, and performed-work variance records One-line purpose: name one planned baseline item that states which planned fillers are intended for which SlotKinds of one slot-bearing description before performed work occurs.

At a glance. Use SlotFillingsPlanItem when a U.WorkPlan needs more than a date, budget, or intended method: it needs a reproducible planned baseline saying which planned fillers are intended for one slot-bearing description's SlotKinds.

Use this when. Use this pattern when a P2W or work-planning slice needs planned references, policy pins, method-description refs, edition pins, evidence-reference pins, guard-preparation refs, or crossing-policy refs to stay fixed before performed U.Work.

First output. One SlotFillingsPlanItem naming exactly one target_slot_bearing_description_ref, one bounded_context_ref, the EntityOfConcern under planning, a time selector or time rule, authoritative planned-filling rows, and any guard-preparation, evidence-reference, edition, or crossing-policy refs needed before performed work.

Working use order.

1. Confirm that the current claim is a planned baseline inside a U.WorkPlan, not the slot-bearing description itself and not performed work.
2. Name the target slot-bearing description and use its SlotSpecs from the governing description pattern, with A.6.5 slot discipline.
3. Name the EntityOfConcern under planning and the bounded context; add a grounding holon only when the current claim needs one.
4. Write planned-filling rows from SlotKind to planned filler, with ByValue or concrete RefKind mode and edition pins when reproducibility depends on them.
5. Keep projections, views, evidence-reference pins, guard-preparation refs, and crossing-policy refs as secondary references. They do not add rows, create evidence, pass a gate, or finalize launch values.

Ordinary use. For a minimal baseline, use context, time selector, target slot-bearing description, EntityOfConcern ref, and planned-filling rows.

Reliance-bearing use. Use the fuller record when reproducibility, launch-guard preparation, crossing expectations, suite or kit reuse, Part G universalization, publication-view projection, or P2W carry-through depends on the baseline.

Stop condition. Stop once the planned rows are explicit enough for the work-planning move, or lower the claim to a plan cue, source-gap note, relation governed by another FPF pattern, or blocked kind-definition gap without claiming a conforming planned baseline.

What goes wrong if missed. Teams hide planned choices in mechanism prose, suite descriptions, generated cards, "latest" references, local checklists, or execution logs. Later nobody can tell what was planned, what was performed, which edition changed, or which variance belongs to performed work.

What this buys. A small planned-baseline record that lets later performed work cite the intended slot fillings and record variance without rewriting the plan after the fact.

Not this pattern when. Not this pattern when the current claim is the slot-bearing description itself (A.6.5 plus the governing description pattern), a mechanism definition (A.6.1 or E.20), a performed work occurrence (A.15.1), an ordinary work plan without slot-filling rows (A.15.2), evidence or assurance (A.10 or B.3), a gate or constraint decision (A.20 or A.21), publication-use behavior (E.17), or a declarative representation overread as work control (C.2.P.DR).

A.15.2 can already say that work is planned. Some plans also need to freeze a more specific relation: "for this planned work, this slot-bearing description will use these planned fillers in these SlotKinds under this bounded context and time rule."

#Keywords

• planned baseline
• slot-bearing description
• planned filler
• edition pins
• Γ_time selector
• guard pins
• WorkPlanning
• P2W seam
• variance trail.

#Relations

#Content

#Context

A.15.2 can already say that work is planned. Some plans also need to freeze a more specific relation: "for this planned work, this slot-bearing description will use these planned fillers in these SlotKinds under this bounded context and time rule."

That extra relation is not the target description, not the mechanism, not a publication view, and not the later performed work. It is a plan item inside work planning. SlotFillingsPlanItem gives that relation a stable place.

Typical situations:

• a CHR or CG-frame plan chooses comparator specs, normalization methods, indicator policies, or guard refs before work;
• a mechanism-suite plan chooses which suite description, method-description edition, or policy ref will be used later;
• a QD or archive plan fixes descriptor and distance-definition editions before selection work;
• a refresh or parity plan cites planned refs so later performed work can record variance rather than silently changing the plan.

#Problem

Without an explicit SlotFillingsPlanItem, six failures recur:

1. Plan and performed-work blur. Planned fillers get treated as launch values or run-time actuals.
2. Slot drift. A SlotKind's meaning changes because the target description edition changed, but the plan still reads as if it meant the old description.
3. Implicit latest. Source text says "use latest" or "current best" without a time selector or pinned edition.
4. View becomes authority. A card, dashboard, or generated view becomes the de facto place where planned rows live.
5. Mechanism prose hides planning. Suite or mechanism text quietly carries chosen fillers even though those choices vary by plan instance.
6. Variance disappears. After work happens, the plan is edited to match the performed work, erasing the gap that audit or improvement needs.

#Forces

#Solution

#Definition

SlotFillingsPlanItem is a kind of U.WorkPlan.PlanItem whose content is one planned slot-filling baseline for one slot-bearing description in one bounded context.

It is:

• produced inside work planning;
• tied to one target description episteme that supplies SlotSpecs;
• pinned enough to replay what was planned;
• cited later by performed U.Work when variance, substitutions, launch values, telemetry, or result records are written.

It is not:

• the target slot-bearing description;
• a MechanismDefinitionRef;
• a gate decision, evidence item, assurance result, publication truth, or performed-work occurrence;
• a second slot ontology beside A.6.5.

#Core fields

A conforming SlotFillingsPlanItem states these fields when the corresponding claim is current:

1. Plan identity

   • plan_item_id
   • kind = SlotFillingsPlanItem
   • work_plan_ref
   • optional plan_item_edition

2. Target slot-bearing description

   • target_slot_bearing_description_ref
   • The target is a Description episteme that declares SlotSpecs, such as a suite description, kit description, method-description family, or other description governed by its own pattern.
   • Do not target MechanismDefinitionRef directly. If a mechanism-level baseline is needed, introduce or cite a description that exposes the slots being planned.
   • When the target description's SlotSpecs are edition-sensitive, the target ref is edition-pinned.

3. EntityOfConcern and context

   • entity_of_concern_ref
   • bounded_context_ref
   • optional grounding_holon_ref when the EntityOfConcern is not itself a holon and the current comparison or reference-plane claim needs grounding;
   • optional reference_plane_ref only when the governing measurement, CHR, or comparison pattern defines that field.

4. Time selector or time rule

   • time_selector_ref or time_rule_ref
   • Use this when "current", "latest", reproducibility, comparability, launch preparation, or source-currentness matters.
   • When time is required, use exactly one of the two forms; both-present and both-absent baselines are nonconforming.

5. Planning scope refs

   • optional cg_frame_ref, p2w_carry_through_ref, publication_scope_ref, suite_ref, or kit_ref when those relations are current;
   • these refs locate the planned baseline, but they do not add planned rows by themselves.

6. Guard-preparation refs

   • optional expected guard or policy refs, such as compare-guard or launch-guard preparation refs;
   • these refs name what later work or gate checks should be prepared to use;
   • the PlanItem records preparation, not the guard result.

7. Evidence-reference pins

   • optional concrete pin refs naming where evidence is expected to be placed or cited later;
   • a pin ref is not evidence and does not create evidence sufficiency.

8. Crossing-preparation refs

   • optional refs for expected cross-context or cross-plane support, such as BridgeCard refs, policy-id refs, reference-plane refs, or already-published CrossingBundle baseline refs;
   • these refs state expected crossing support only;
   • they are not crossing witnesses, do not embed CL/Phi/Psi tables, and do not claim that a crossing occurred.

9. Authoritative planned-filling rows

   • planned_fillings[], each row with:
     • row_id;
     • slot_kind, taken from the target description's SlotSpecs;
     • planned_filler, written ByValue or ByRef with a concrete RefKind;
     • optional edition_pin;
     • optional planning_note.
   • If the target SlotSpec is single-valued, there is at most one row for that SlotKind.
   • If both a row and its referenced filler carry edition pins, they agree or the baseline is nonconforming.

10. Derived projections

• optional cards, views, indices, or summaries;
• each projection is derivable from planned_fillings;
• any projection that adds rows, defaults, or semantics is a publication-use or view-use error under E.17.

11. Variance policy

• how later performed U.Work cites this baseline;
• how substitutions, missing fillers, extra fillers, launch values, or edition changes are recorded in the performed-work or gate relation.

#Compact record form

SlotFillingsPlanItem:
  plan_item_id:
  kind: SlotFillingsPlanItem
  work_plan_ref:
  target_slot_bearing_description_ref:
  entity_of_concern_ref:
  bounded_context_ref:
  time_selector_ref or time_rule_ref:
  planning_scope_refs:
  guard_preparation_refs:
  evidence_reference_pins:
  crossing_preparation_refs:
  planned_fillings:
    - row_id:
      slot_kind:
      planned_filler:
      filler_mode: ByValue | ByRef(<ConcreteRefKind>)
      edition_pin:
      planning_note:
  derived_projection_refs:
  variance_policy:

#Relation to performed work

A SlotFillingsPlanItem is not a launch-value finalization witness and not a record that work occurred.

When a performed U.Work occurrence uses the baseline, the work record cites the PlanItem edition and records launch values, performed values, substitutions, missing planned fillers, extra fillers, telemetry, outcomes, and variance under A.15.1 or the governing gate, evidence, result, or archive pattern.

Do not backfill the plan to match what happened. If the plan changed before the work, create a new PlanItem edition or new PlanItem as appropriate. If the work differed from the plan, record variance in the performed-work relation.

#Relation to suites, kits, and mechanism introduction

A suite, kit, or mechanism-introduction pattern may require a planned-baseline ref. That requirement does not make the suite or mechanism text the baseline.

Use:

• the suite or kit pattern for the meaning of the suite or kit;
• A.6.5 for SlotSpec discipline inside the target description;
• A.15.3 for the plan instance that chooses planned fillers;
• A.15.1 for performed work and variance;
• A.20 and A.21, A.10 and B.3, or E.17 when gate, evidence, assurance, or publication-use claims become current.

#Variants

Specialized PlanItem kinds are allowed only when the target governing pattern needs extra planned fields.

Example:

CHRMechanismSuiteSlotFillingsPlanItem <: SlotFillingsPlanItem
  target_slot_bearing_description_ref = CHRMechanismSuiteDescriptionRef
  required_slots = {NormalizationMethodSlot, IndicatorPolicySlot, ComparatorSpecSlot}

The specialization may add fields needed by that suite, but it still inherits the WorkPlanning-only boundary: no performed-work actuals, no launch-value witnesses, no gate decisions, and no publication-view semantics.

#Local boundaries

#Archetypal Grounding

#CHR suite planned baseline

Tell. A team plans characterization work over a CG-frame using a CHR mechanism suite. The suite description declares SlotKinds for normalization method, indicator policy, comparator spec, and selector policy.

Show without A.15.3. The plan says "use the latest CG-Spec and current best comparator." Later the comparator set changes. Later audit readers cannot tell whether the work used the intended comparator or a later one.

Show with A.15.3. The SlotFillingsPlanItem targets the CHR suite description edition, names the bounded context and time selector, and writes rows:

planned_fillings:
  - slot_kind: NormalizationMethodSlot
    planned_filler: ByRef(UNMDescriptionRef:2026-06)
    edition_pin: 2026-06
  - slot_kind: ComparatorSpecSlot
    planned_filler: ByRef(ComparatorSpecRef:CG42-v3)
    edition_pin: v3
  - slot_kind: SelectorPolicySlot
    planned_filler: ByValue(SetReturningSelectionPolicy)

If the later work uses ComparatorSpecRef:CG42-v4, the work record states variance or crossing witness. The PlanItem remains the planned baseline.

#Archive and QD selection

Tell. A project plans to return an archive rather than one winner. Descriptor definitions and distance functions are edition-sensitive.

Show without A.15.3. The published archive card lists descriptors and distances, but the original planned descriptor edition is gone. The card becomes a mutable publication face rather than a planned-baseline relation.

Show with A.15.3. The PlanItem rows pin descriptor description refs, distance-definition refs, and time rule. The published card is a projection of those rows. If the archive generation later changes descriptors, performed work and result records cite the baseline and state the variance.

#Hardware acceptance fixture

Tell. A hardware team plans acceptance work for a fixture. The slot-bearing description is an acceptance-method description with slots for reference plane, measurement method, calibration source, and acceptance threshold.

Show with A.15.3. The planned baseline pins the reference-plane description, calibration source ref, and threshold edition. The performed acceptance work later records actual measurements and substitutions. The PlanItem does not become the measurement evidence.

#Scope Declaration and Rationale

SlotFillingsPlanItem has a deliberate explicitness bias. It asks for target description, context, time, and planned rows because those are the smallest fields that keep planned slot filling separate from performed work and publication views.

The pattern does not try to make every work plan heavy. Ordinary plans stay in A.15.2. A.15.3 opens only when slot-filling choices themselves are the planned baseline that later work, gates, evidence, or publication projections will rely on.

The anti-bias guard is locality: if the current issue is mechanism meaning, evidence sufficiency, gate passage, source restoration, publication use, or performed work, use that governing pattern and bring only the returned planned-baseline relation back here.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

The pattern exists because planned slot fillings are neither generic plan text nor performed work. They are relation-bearing plan items: one target description supplies SlotKinds, the plan chooses fillers, and later work records what happened.

A.6.5 prevents a common type explosion. slot_kind, planned_filler, and RefKind fields are not new U-kinds. They are positions and fillers inside one relation-bearing PlanItem. E.17 prevents a second row source by keeping views and cards as projections. A.15.1 prevents plan backfilling by keeping performed-work actuals and variance outside the plan.

This split is especially useful in P2W and Part G work because many downstream records need the same planned baseline without copying suite semantics, mechanism definitions, gate decisions, evidence claims, or publication views into the plan.

#SoTA-Echoing

#Relations

• Builds upon: A.15.2 for U.WorkPlan and PlanItem discipline; A.15.1 for performed U.Work; A.6.5 for SlotKind, ValueKind, RefKind, and SlotSpec discipline; E.10.D2 for EntityOfConcern vs Description episteme vs specification-use; E.17 for publication-use and view-use projection; E.18.1 for P2W carry-through; E.20 for mechanism-introduction boundaries.
• Coordinates with: A.20 and A.21 for gates and constraint decisions; A.10, B.3, and G.6 for evidence, assurance, and provenance; C.27.TA and G.11 for currentness and refresh; Part G patterns when planned baselines are used by kits, packs, or refresh plans.
• Does not replace: target description patterns, mechanism definitions, suite definitions, gate records, evidence relations, publication views, performed work, or source restoration.

#P2W planned-baseline use relation

When E.18.1 reaches a planned-baseline question, SlotFillingsPlanItem records the planned relation between one slot-bearing description's SlotKinds and the fillers intended for a future work-planning move.

If the same source phrase also carries launch-value, performed-work, evidence, gate, result, measurement, publication-use, source-restoration, or refresh meaning, name that separate current relation before using the PlanItem downstream.

#Planned-baseline to performed-work boundary

A performed U.Work occurrence may cite a SlotFillingsPlanItem as the planned baseline for slot fillers. The performed-work record states launch values, actual fillers, substitutions, variance, telemetry, and result-related records under A.15.1 and the current gate or evidence relation.

The work-planning record preserves what was intended. The performed-work record preserves what happened.

#Lowering, repair, and refresh conditions

Lower a SlotFillingsPlanItem claim when the item cannot name exactly one target slot-bearing description, concrete SlotKinds from that description, EntityOfConcern, bounded context, time selector or time rule, authoritative planned-filling rows, concrete RefKinds for ByRef fillers, or required edition pins. The lowered result is a plan cue, source-gap note, relation governed by another FPF pattern, or blocked kind-definition gap.

Repair the PlanItem when a source-currentness change alters the target description edition, exposed SlotKind set, planned filler, concrete RefKind, edition pin, context, time rule, evidence-reference pin, guard-preparation ref, crossing-policy ref, or expected gate relation. If performed U.Work already cited the PlanItem as a baseline, preserve the cited baseline and record variance or crossing witness in the work-governed relation.

Refresh before the PlanItem is used for performed-work preparation, launch-guard preparation, cross-context comparison, suite or kit reuse, Part G universalization, publication-view projection, evidence-reference use, or P2W carry-through. Stop the refresh at the smallest changed relation: the PlanItem, target slot-bearing description, concrete RefKind, cited source edition, performed-work variance record, or related gate, evidence, bridge, or publication relation.

#A.15.3:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)