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

Pattern A.15.3 · Stable · Architectural (A) · Normative (unless explicitly marked informative) Part A - Kernel Architecture Cluster

Tech-name: SlotFillingsPlanItem Plain-name: planned slot-fillings baseline item (planned baseline) Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.15 (Work & WorkPlanning) Builds on: pattern template (E.8), U.WorkPlan (A.15.2), Work enactment discipline (A.15.1 / TGA), Context discipline (E.10.D1), MechSuiteDescription (A.6.7), conformance discipline (E.19), publication/view discipline (E.17; views are projections, not places of meaning) Used by: planned-baseline requirements from suites/kits; P2W (selection → WorkPlanning → WorkEnactment); Part G universalization Purpose (one line): provide a universal, context-explicit planned baseline that maps a slot-owner’s SlotKinds to planned fillers, to be consumed by Work enactment where launch values are finalized.

Minting notes (informative)

• Mint vs reuse: This pattern mints the kind name SlotFillingsPlanItem. It reuses existing Core terms and disciplines (e.g., U.WorkPlan.PlanItem, SlotKind/ValueKind/RefKind/refMode discipline, edition pinning, U.BoundedContext, and the P2W split between WorkPlanning and WorkEnactment).
• SlotFillingsPlanItem (kind name): keep the suffix PlanItem to preserve the WorkPlanning locus. Do not mint aliases like SlotBinding… (conflicts with the A.6.5 binding discipline) or SlotValue… (ambiguous owner/context).
• Anchor names: if any anchors in §4.2 are later materialized as formal field names, keep …_ref only for fields whose values are concrete RefKind handles, and keep …_id only for identifiers. Avoid introducing generic placeholders like SpecRef/PolicyRef/GateRef inside this pattern; prefer existing concrete ref kinds (or a dedicated DRR+LEX step).
• Row vocabulary: treat SlotFillingRow and PlannedFiller as internal names of this pattern unless/until a separate DRR+LEX step promotes them to shared tokens.

FPF frequently needs to make reproducible, reviewable choices about what fills which conceptual slot (spec refs, policy refs, mechanism-instance refs, time selectors, evidence hooks, etc.) before any Work is enacted. These choices must be visible as a planned baseline for a concrete P2W slice (CG-frame / path slice / publication scope), and must remain distinct from run-time “actuals” and gate decisions.

#Keywords

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

#Relations

#Content

#Problem frame

FPF frequently needs to make reproducible, reviewable choices about what fills which conceptual slot (spec refs, policy refs, mechanism-instance refs, time selectors, evidence hooks, etc.) before any Work is enacted. These choices must be visible as a planned baseline for a concrete P2W slice (CG-frame / path slice / publication scope), and must remain distinct from run-time “actuals” and gate decisions.

However, absent a universal WorkPlanning artifact for “architecture-by-planned-slot-filling”, authors tend to hide these choices inside mechanism prose, CG/CN specs, ad-hoc cards, or informal checklists—making Part G patterns difficult to universalize and making Work audit trails ambiguous.

SlotFillingsPlanItem addresses this by defining a WorkPlan PlanItem kind whose job is to state, in one place and with explicit context, a mapping:

(Target slot owner, slot kind) → planned filler (ByValue | ByRef(), with edition pins when needed)

and to do so in a form that can be cited by Work enactment and by suite/kit contract pins, without collapsing into “execution” or “decision logging”.

#Problem (what breaks without it)

Without an explicit SlotFillingsPlanItem baseline, at least six failure modes recur:

1. Hidden slot ownership and meaning drift: a planned filler is stated without making explicit whose slot set is being filled, allowing silent reinterpretation of SlotKinds across kits/suites.

2. Plan/execution collapse: plan documents get “backfilled” with run-time values, so there is no stable planned baseline and no clean variance trail. WorkPlan explicitly warns against this.

3. Implicit time (“latest”) and implicit recency: planned claims about comparability or launch readiness omit an explicit Γ_time, which violates the time discipline (“no implicit recency”).

4. Edition ambiguity: references to methods/policies/specs are not edition-pinned where reproducibility requires it, or the plan mutates the edition vector instead of citing pinned editions (edition changes are crossings, not “plan edits”). A particularly harmful subtype is edition-key backfill: retroactively editing a previously used baseline so that an edition-key change looks like an innocent PlanItem edit (hiding the required GateCrossing witness and breaking audit traceability).

5. Crossing invisibility: cross-context/plane expectations (Bridge + policy ids) are not stated at plan time, so later gate crossings appear as “magic” rather than traceable expected constraints.

6. G-pattern fragmentation: each Part G pattern invents its own place to stash planned refs (method pick, comparator pick, QD archive config, etc.), blocking a clean “G.Core” universal layer and making modular reuse brittle.

#Forces (what we must balance)

• Strict distinction: planned baseline is not a run-time witness; launch values are finalized only in Work enactment.
• Context must be explicit: every normative claim/rule is context-bound; the PlanItem must carry its context rather than relying on file location or prose.
• Time must be explicit: no implicit “latest”; any plan that will be cited by comparability/launch checks needs an explicit Γ_time selector/rule.
• SlotKind meaning is stable: the plan may choose fillers, but must not reinterpret SlotKinds or smuggle new semantics into indices.
• Derived indices must not become “places of meaning”: projections like “planned spec refs” are useful, but must remain derivable from the authoritative rows.
• Conceptual, not procedural: no solver steps, no lints, no “data governance”; this is an epistemic object used by humans in review.
• Supports universalization: one PlanItem pattern must be usable across the whole of Part G, not just G.5.
• Integrates with suites/kits: suites may require a planned-baseline ref and may act as slot owners.

#Solution

#A.15.3:4.1 Definition

A SlotFillingsPlanItem is a kind of U.WorkPlan.PlanItem whose content is a planned slot-fillings ledger for a single slot owner, within an explicit P2W context.

It is a WorkPlanning baseline, intended to be:

• produced/approved in WorkPlanning,
• cited by downstream Work enactment (as planned baseline),
• compared against actual fillings (variance recorded in Work, not by rewriting the plan).

Normative note (I/D/Spec vs views): A SlotFillingsPlanItem is a Description-level planning episteme (a PlanItem). It MAY be projected into U.View (e.g., TechCard(SlotFillingsPlanItemRef)), but any view is strictly a projection and MUST NOT introduce additional claims or “shadow defaults”.

#A.15.3:4.2 Core conceptual descriptors (not a data schema)

A conformant SlotFillingsPlanItem SHALL provide the following description (names are indicative; the semantics are normative):

1. PlanItem core (from A.15.2) The PlanItem MUST remain a planning artifact: it may include assumptions, dependencies, constraints, expected artifacts, and notes; it MUST NOT contain run-time logs/actuals.

2. Target slot owner

   • target_slot_owner_ref : <concrete …DescriptionRef> (required) Identifies the owner of the SlotKind set being filled (e.g., a kit description or a suite description). The slot owner MUST be referenced as an edition-addressable Description episteme (a concrete …DescriptionRef such as MechSuiteDescriptionRef, …KitDescriptionRef, etc.), and MUST NOT be a mechanism U.Mechanism.IntensionRef (or any other intensional ref). A MechSuiteDescription MAY serve as a slot owner for this purpose. If the slot owner’s SlotKind interface is edition-sensitive (or expected to evolve), the reference MUST be edition-pinned (e.g., target_slot_owner_ref.edition) whenever the PlanItem is used as a reproducibility baseline.

3. Described entity and grounding (for “whose measurements/choices?”)

   • described_entity_ref : <concrete RefKind> (required) The referent is the described entity (C.2.3 role): the thing the planned baseline is about. It MUST NOT be silently conflated with a holon. (Example: a baseline can be about a width/measure while the grounding holon is a stool with that width.) Use a concrete RefKind of the described entity (e.g., U.HolonRef, U.MeasureRef, …). Do not mint a new generic EntityRef token inside this pattern.
   • grounding_holon_ref? : U.HolonRef (optional; required when the described entity is not itself a holon and a grounding holon is needed for plane/frame anchoring)
   • reference_plane? : ReferencePlane (optional; required when not unambiguously derivable from cited context artifacts such as CG-frame/spec pins)

4. Explicit planning context (no hidden context)

   • bounded_context_ref : U.BoundedContextRef (required)
   • cg_frame_ref? : CGFrameRef (recommended when the fillings feed CG legality/selection)
   • path_slice_id? : PathSliceId (recommended for P2W reproducibility)
   • publication_scope_id? : PublicationScopeId (recommended if the plan will be surfaced in publication-facing views) These anchors exist because context is mandatory for claims/rules in FPF-style authoring.

5. Explicit time selector (no implicit recency)

   • exactly one of:

     • Γ_time_selector : Γ_timeSelector (ByValue), or
     • Γ_time_rule_ref : Γ_timeRuleRef (RefKind) This MUST be present whenever the plan is intended to support comparability/launch-related downstream checks.

6. Expected guard pins (refs/expectations only; no gate decisions)

   • expected_usm_guard_pins : [USM.CompareGuard | USM.LaunchGuard] (ByValue; subset of {USM.CompareGuard, USM.LaunchGuard}) These lexemes are reserved for USM.Guards pins (gate-level surfaces), not for mechanism operator names. If USM.LaunchGuard is expected, the plan MUST include enough pins/refs to make that guard executable downstream (explicit Γ_time_*, pinned editions where needed, and evidence hook anchors). The PlanItem MUST NOT include outcomes for these guards and MUST NOT emulate gate decisions; it only records expectations and required anchors.

   • guard_owner_gate_ref? : <concrete OperationalGateRefKind> (refs only; required when expected_usm_guard_pins is non-empty unless unambiguously derivable) Identifies the gate that owns/aggregates GuardFail outcomes (via the GuardOwnerGateSlot discipline). This remains an expectation pin, not a decision log. (Use the concrete RefKind that addresses OperationalGate(profile) in A.21. If such a RefKind does not yet exist, treat this as a DRR+LEX item.)

7. Planned evidence anchors (pin refs only)

   • planned_evidence_pin_refs? : [<concrete …PinRef>…] These are anchors to where evidence will be placed or cited (typically SCR/RSCR pins; optionally other pin kinds explicitly allowed by the downstream guard regime), not the evidence itself.

8. The planned slot-fillings ledger (authoritative rows)

   • planned_fillings : [SlotFillingRow+] where:

     SlotFillingRow := ⟨ slot_kind, planned_filler, edition_pin? ⟩

     • slot_kind : SlotKind A SlotKind provided by the target_slot_owner_ref (the PlanItem MUST NOT reinterpret SlotKind meaning). Unless the slot owner explicitly declares the slot as multi-valued, each slot_kind SHALL appear at most once in planned_fillings.
     • planned_filler : PlannedFiller where: PlannedFiller := ByValue(value) | ByRef(ref : <concrete RefKind>) In ByRef(…), the ref MUST be of a concrete RefKind (e.g., …SpecRef, …PolicyRef, …MethodDescriptionRef); the PlanItem MUST NOT use an untyped/generic “Ref” / “RefKind” placeholder. The chosen filler MUST conform to the SlotSpec discipline of the slot owner (A.6.5-style: refMode ∈ {ByValue | <concrete RefKind>}). Changes to planned fillers are described using the A.6.5 verb discipline: ByValue content change (fill/assign/update) vs ref retargeting (retarget) vs ref resolution (resolve), never by “renaming the slot”.
     • edition_pin? : EditionId Required only when reproducibility depends on an edition and the planned filler cannot carry an edition pin directly (preferred: …DescriptionRef.edition on the ref itself). If both the planned filler ref and the row provide edition pinning, they MUST agree (mismatch ⇒ nonconformant). ByValue rows SHOULD NOT carry edition pins unless the pinned edition is explicitly tied to a cited external artifact (e.g., a referenced rule/policy/method description).

9. Derived indices (optional; never a second source of truth)

   • planned_spec_ref_index? : [<concrete …SpecRef>…]
   • planned_policy_ref_index? : [<concrete …PolicyRef>…]
   • planned_mechanism_instance_ref_index? : [<concrete …MechanismInstanceRef>…] If any of these are present, they MUST be derivable projections of planned_fillings; any mismatch is nonconformant. (These are categories of refs extracted from the authoritative rows, not an invitation to introduce new generic SpecRef/PolicyRef token-kinds.)

10. Expected crossing policy pins (refs only; no crossing witnesses)

• expected_crossing_policy_refs? : [⟨bridge_card_ref, phi_policy_id, psi_policy_id?, phi_plane_policy_id?, reference_plane(src,tgt)⟩ …] These communicate what the plan expects will be needed for crossings, without claiming that a crossing has occurred. bridge_card_ref is expected to pin a Bridge identity/channel (BridgeId + channel) and to be auditable via downstream CrossingBundle/UTS rows. This section states Bridge-only expectations; it MUST NOT introduce non-Bridge crossing mechanisms, and it MUST NOT embed CL/Φ/Ψ/Φ_plane tables (refs/policy-ids/pins only).

• expected_crossing_bundle_refs? : [CrossingBundleRef…] (optional) Permitted only when the plan is explicitly citing already-published CrossingBundle baselines (e.g., “fixed context constants”); otherwise, the PlanItem SHALL state only expected policy pins and allow the crossing witness to appear at the gate/work level.

11. Notes (didactic, non-normative)

• planned_filling_notes? Helpful narrative for reviewers; must not embed new claims that contradict the rows.

#A.15.3:4.2.1 Canonical skeleton (Show)

The following compact pseudo-record illustrates the intended canonical minimum: explicit context + explicit time + a few authoritative rows.

SlotFillingsPlanItem := ⟨
  kind = SlotFillingsPlanItem,
  target_slot_owner_ref = CHRMechanismSuiteDescriptionRef@edition(E_suite),
  described_entity_ref = U.HolonRef(H:described-entity), // or another concrete RefKind per C.2.3
  grounding_holon_ref = U.HolonRef(H:grounding-holon)?,  // when the described entity is not itself a holon
  bounded_context_ref = U.BoundedContextRef(BC:context),
  cg_frame_ref = CGFrameRef(CG:frame),              // optional but typical for G.* legality/selection
  path_slice_id = PathSliceId(P2W:slice),           // optional but typical for reproducibility
  Γ_time_selector = point(t0),                      // no implicit “latest”
  expected_usm_guard_pins = {USM.CompareGuard, USM.LaunchGuard},
  planned_evidence_pin_refs = [RSCR.PinRef(RSCR:evidence-anchor)],
  planned_fillings = [
    ⟨ slot_kind = CNSpecSlot, planned_filler = ByRef(CNSpecRef(CN:…@edition(E_cn))) ⟩,
    ⟨ slot_kind = CGSpecSlot, planned_filler = ByRef(CGSpecRef(CG:…@edition(E_cg))) ⟩,
    ⟨ slot_kind = ScoringMethodDescriptionSlot,
      planned_filler = ByRef(ScoringMethodDescriptionRef(M:…@edition(E_m))) ⟩
  ]
⟩

#A.15.3:4.3 Relation to Work enactment (planned baseline vs actuals)

• A SlotFillingsPlanItem is not a witness of FinalizeLaunchValues. Launch values (actuals) occur only in Work enactment, and their witness belongs in Work/audit surfaces, not in this PlanItem.

• Deviation at execution time is allowed, but it must be recorded as variance in Work, and the plan must not be rewritten to match the execution. When a Work enactment claims to follow a planned baseline, the Work MUST cite the SlotFillingsPlanItem in its Audit as the planned baseline reference, and MUST record any variance against it (rather than “backfilling” the plan). The baseline citation SHOULD be edition-addressable (i.e., the Work cites a stable PlanItem edition), so that later PlanItem revisions cannot erase what was actually planned. If the baseline needs to change (including any edition-pinned ref changes), author a new PlanItem edition (or a new PlanItem) and treat the difference as a planning change—not as a retroactive edit of the previously cited baseline.

#A.15.3:4.4 Relation to suites/kits

• Any suite/kit that requires a “planned baseline” may require and cite a reference to a SlotFillingsPlanItem via its contract pins; MechSuiteDescription explicitly provides a place for such a requirement.

#Variants

1. Suite-specialized PlanItem (Refinement) A suite may define XSuiteSlotFillingsPlanItem ⊑ SlotFillingsPlanItem with:

   • fixed target_slot_owner_ref = XSuiteDescriptionRef,
   • additional required rows (e.g., mandatory pinned CGSpecRef, CNSpecRef, suite-required mechanism instance refs),
   • additional required expected pins (guards, crossing policies).

2. Minimal vs crossing-aware variants

   • Minimal: includes only context + planned rows + time selector.
   • Crossing-aware: adds expected_crossing_policy_ref[] and explicit reference_plane.

3. Evidence-gated variant For workflows where USM.LaunchGuard is expected, require planned_evidence_pin_refs[] and explicitly pin the relevant edition set needed for the later guard.

#Non-goals

• Not a mechanism; it performs no operations and publishes no operator signatures.
• Not a …Spec; it is not an acceptance harness and does not replace CN-Spec or CG-Spec.
• Not a hiding place for acceptance thresholds: any threshold-like semantics MUST live in explicit Acceptance/Policy artifacts (and be referenced/pinned), not smuggled in as anonymous ByValue numbers.
• Not a gate log: it MUST NOT contain GateDecision / DecisionLog, and MUST NOT claim that a crossing occurred.
• Not a run-time witness: it MUST NOT contain FinalizeLaunchValues actuals.
• Not a publication surface: it may be projected to views, but it is not “the card” itself. Any view MUST be an explicit projection (e.g., TechCard(PlanItemRef)), and unchecked presentation drift is a known failure mode.

#When to use

Use SlotFillingsPlanItem whenever:

• a workflow will be enacted through P2W and you need a planned baseline for what fills a suite/kit’s slots;
• you must pin editions/time policies explicitly (e.g., legality gates, comparator sets, transport registries);
• you are refactoring/authoring Part G patterns and want a uniform place to record selected refs/policies/mechanism instances;
• you expect a LaunchGate or any guard-based eligibility check to be meaningful and traceable.

#Implementation notes

Informative authoring guidance (conceptual):

1. Choose one target_slot_owner_ref per PlanItem. If multiple slot owners are involved, author multiple SlotFillingsPlanItems (one per owner) to keep slot meaning unambiguous.
2. Fill rows by SlotKind, not by positional arguments or “index numbers”.
3. If any downstream reasoning may hinge on “now vs then”, supply Γ_time_selector or Γ_time_rule_ref explicitly.
4. Prefer edition-pinned references when the downstream step is intended to be reproducible across review cycles.
5. Use derived indices only as projections for reader convenience; never maintain them independently.
6. If a PlanItem has been cited as a baseline by a Work, do not “edit it in place” to match reality. Create a new PlanItem edition and let Work record variance and/or the required crossing witnesses.

#Archetypal Grounding (Tell–Show–Show; System / Episteme)

#Archetype 1: CHR suite planned baseline for lawful characterization

Tell. A team plans a characterization workflow over a CG-frame that uses a CHR mechanism suite. The suite requires an explicit planned baseline reference.

Show (failure without SlotFillingsPlanItem). The “plan” is implicit: it says “use the latest CG-Spec and the current best comparator; compute scores and launch” without an explicit Γ_time, without edition pins, and without a stable mapping from SlotKinds to chosen fillers. Review later cannot distinguish: (i) what was planned, (ii) what was executed, and (iii) what changed via a crossing / edition-key shift.

Show (repair with SlotFillingsPlanItem). A conformant SlotFillingsPlanItem:

• targets CHRMechanismSuiteDescriptionRef as the slot owner (and pins its edition if used as a reproducibility baseline),
• pins CNSpecRef and CGSpecRef (editions pinned where reproducibility requires),
• pins a ScoringMethodDescriptionRef.edition (e.g., a monotone scoring family) and/or a set-valued method family (e.g., conformal-style set predictions),
• declares Γ_time_selector = point(t0) (no implicit “latest”),
• declares expected_usm_guard_pins = {USM.CompareGuard, USM.LaunchGuard},
• includes evidence pin refs that will later be populated/used in Work enactment.

The resulting Work enactment cites this PlanItem as the planned baseline; any substitution (e.g., retargeting a method description ref) appears as Work variance (and, when relevant, as a crossing witness), not as a retroactive plan rewrite.

#Archetype 2: Archive/QD selection with edition-sensitive descriptors

Tell. A workflow plans to return an archive (quality-diversity style) rather than a single winner. The selection pipeline depends on descriptor maps and distance definitions that are edition-sensitive.

Show (failure without SlotFillingsPlanItem). Descriptor-map and distance-definition drift is discovered only after the fact: an “archive” is produced, but reviewers cannot reconstruct which descriptor edition and distance definition were assumed at planning time, and the published view/card becomes the de facto (and mutable) “source of truth”.

Show (repair with SlotFillingsPlanItem). A conformant SlotFillingsPlanItem:

• targets an archive-selection kit/suite as target_slot_owner_ref,
• pins DescriptorMapDescriptionRef.edition and DistanceDefDescriptionRef.edition (or their kit equivalents),
• states expected_usm_guard_pins = {USM.CompareGuard} (if no LaunchGate is expected yet),
• records expected crossing policy pins if descriptors are reused cross-context.

This prevents “silent” descriptor drift across iterations and makes Part G’s archive-related extensions composable rather than embedded in selector prose.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal.

#Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#Plan-as-execution

A plan document says: “Use the latest CG-Spec and the current best comparator; compute scores and launch.” This is nonconformant because it omits explicit Γ_time, omits edition pins, collapses planning into execution, and provides no stable baseline for variance/audit.

#Anti-example: Edition-key change disguised as a plan edit (backfill)

A team executes Work while actually using CGSpecRef@edition(E2) (and/or ComparatorSetRef@edition(E2)), but the previously approved baseline PlanItem had pinned @edition(E1). Later, instead of recording variance and the required GateCrossing witness for the edition-key change, someone edits the baseline PlanItem “in place” to replace E1 → E2, and then claims “no variance; we followed the plan”.

This is nonconformant because it:

• collapses planning into execution (retroactive baseline editing),
• hides an edition-key change that is crossing-relevant,
• destroys reproducibility and breaks Work/Audit traceability.

Correct handling: keep the old baseline intact; record variance in Work and, where applicable, require the gate/work-level crossing witness (UTS/CrossingBundle + policy-id pins), or produce a new PlanItem edition as the new planned baseline for subsequent enactments.

#Consequences

#Rationale

This pattern exists to give WorkPlanning an explicit, citeable place to commit to “which artifacts will fill which slots” without collapsing into run-time state.

Keeping the baseline bound to exactly one slot owner makes SlotKind semantics checkable and prevents accidental cross-owner slot drift.

Treating indices as derived projections preserves a single source of truth (the rows) while still enabling human-friendly navigation or tooling acceleration.

Finally, by disallowing run-time witnesses (launch values, observed values, concrete Γ_time) the pattern enforces the plan/run split and keeps audit variance attributable to an explicit baseline rather than to shifting defaults.

#SoTA‑Echoing (informative)

This pattern aligns with post‑2015 practice in multiple traditions while deliberately staying notationally/tool independent.

• ISO/IEC/IEEE 12207:2017 — Adopt the separation between planning artifacts and execution artifacts plus baseline/change-control concepts; Adapt them into a lightweight, citeable PlanItem kind; Reject prescribing any specific process tooling as normative inside FPF.
• ISO 26262:2018 — Adopt the emphasis on traceability, change impact visibility, and preventing retroactive “paper compliance”; Adapt it into baseline immutability + variance reporting; Reject treating safety certification structure as a required envelope for all contexts.
• NIST SP 800-128 Rev.1 (2020) — Adopt baseline management and deviation recording as an audit primitive; Adapt by expressing baselines as epistemic, context-bound references rather than machine configuration states; Reject security-tooling prescriptions as a dependency of the conceptual model.
• Forsgren, Humble, Kim (2018), Accelerate — Adopt the empirical lesson that explicit change tracking and small, attributable deltas improve reliability; Adapt by making the baseline the anchor for fulfilment/variance; Reject any “one true pipeline” or vendor-specific operational recipe.
• Morris (2021), Infrastructure as Code (2nd ed.) — Adopt the desired-state vs observed-state distinction and the discipline of explicit declarations; Adapt by keeping declarations as plan-level epistemes rather than deployment manifests; Reject binding the model to any specific IaC syntax or platform.

#Relations

• Builds on / governed by:
  • A.15.2 U.WorkPlan — container + PlanItem discipline; baseline citeability.
  • A.6.5 slot discipline — SlotKind/RefKind hygiene and binding-time separation.
  • E.10.D1 Context discipline — explicit context/edition; no implicit “latest”.
  • E.18 / TGA — keeps FinalizeLaunchValues strictly in WorkEnactment; pin/guard discipline.
• E.17 / Publication discipline — views are projections; no new semantics on cards.
• Interacts with / complements:
  • A.6.7 MechSuiteDescription — suites may require the presence of a planned baseline ref/pin without embedding planned fillers or launch values.
  • A.15.1 Work / WorkEnactment discipline — fulfilment and variance are recorded downstream against this baseline.
  • C3.2-S-02 Time discipline — time selection policy may be pinned by ref; run-time Γ_time stays in Work evidence.

#A.15.3:End