#SlotFillingsPlanItem — Declaration-Local Planned Designation

A.15.3 · Stable · WorkPlanning pattern · 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-filling plan item Short code: SFPI Type: WorkPlanning pattern Status: Stable Normativity: Normative unless explicitly marked informative Placement: Part A -> A.15 work family Builds on: C.2.1 episteme identity, A.15.2 U.WorkPlan, A.6.5 relation-declaration SlotSpec discipline, A.6.1 operation declarations, and the pattern that defines any other target member Used by: plans that must remember a chosen future relation participant, operation argument, expected result, or another value tied to an already declared member before work begins One-line purpose: record inside one U.WorkPlan which value is intended for one already declared member; the declaration defines how later actual use is judged, while A.15.3 records only the intention and makes nothing actual.

At a glance. Use SlotFillingsPlanItem when a plan must preserve a concrete choice before work begins—for example, Robot_8_Ref as the planned holder in a future role assignment or Pump_37_Ref as the planned candidate in a recognition operation. Point to the declaration member that already defines that position, record the planned value and conditions, and later compare them with what actually happened without rewriting the plan. A field name, compatible type, method phrase, form position, or plan label is not such a declaration.

Use this when. Use this pattern only when the choice points to a member already defined in a RelationSignature, an A.6.1 OperationDeclaration, or another declaration whose own pattern states both the member's meaning and the rule for its later actual use. If the plan merely says use this method, reserve this resource, or meet this threshold without reusing such a member, keep ordinary A.15.2 plan content. A planned row establishes no dated work, relation participant, operation application, returned value, change, delivery, or outcome.

First useful object. One PlanItem inside an identified U.WorkPlan with at least one row that names the intended future use, declaration edition, declaration-local member, planned value or designation, and the conditions under which that choice applies. The row follows the member's designation rule and semantic cardinality; it does not redefine either.

Working use order.

1. Identify the U.WorkPlan edition and the future performance being planned. Keep the WorkPlan's already identified present EntityOfConcern unchanged.
2. Open the declaration that will be used later and choose one member it actually defines. Verify that the declaration's own pattern states both what that member means and what must hold for actual use.
3. Record the declaration edition, its local member designator, and the planned value or designation. Do not substitute a description, record, form field, or matching label.
4. Apply the member's ValueKind, designation rule, and semantic cardinality. Add conditions and edition pins only when they can change which planned value is effective. State prohibitions, exclusions, and completeness as separate plan claims; omission is not prohibition.
5. When the later use occurs, identify the dated work and each actual participant or binding independently. Compare actual with planned under a stated comparison policy; preserve the cited plan instead of backfilling it.

Ordinary use. One row is enough: declaration edition, member designator, planned value or designation, and the condition under which it is intended. The declaration's own pattern must already define the member and its later actual-use rule.

Reliance-bearing use. Add concrete reference kinds, declaration or value edition pins, alternative-selection conditions, target-declared cardinality, and a later comparison policy only when coordination, replay, audit, or work-entry preparation would change without them.

Stop condition. Finish with one of three results. (1) The row resolves to an existing declaration member, and the planned value meets its ValueKind, designation, cardinality, and condition rules. (2) No reusable member is needed, so the choice stays ordinary A.15.2 plan content. (3) Typed reuse is needed but the member, its meaning, its actual-use rule, or the pattern that defines them is missing; return missing-governor for that planned use. Do not invent a SlotSpec, wrapper declaration, generic field, or actual-use relation here.

What goes wrong if missed. A plan silently turns method prose or a schema field into a slot, treats type compatibility as planned or actual participation, treats omission or an empty filler as a prohibition, or later edits the baseline to match what happened.

What this buys. The team can later say what it intended, what actually happened, and whether the two differ, while the declaration, plan, work, and actual participation remain separate objects.

Not this pattern when. Use the declaration's own pattern (A.6.5, A.6.1, or another declared-member owner) when defining the member; use A.15.2 for ordinary intended work without a planned filling; use A.15.1 for dated work; and use the applicable pattern for actual relation participation, operation bindings, methods, evidence, assurance, gates, acceptance, results, publication, or representation.

A work plan may need more precision than use this method or perform this task. An inspection plan may need to remember that Robot_8_Ref is intended for HolderSystemSlot in a cited RoleAssignmentRelationSignature edition. A recognition plan may need to remember that Pump_37_Ref is intended for the declaration-local candidate argument.

#Keywords

• WorkPlan claim content
• intended-performance designator
• exact declaration member
• direct owner
• participant/argument/result meaning
• actual-use predicate
• positive planned designation
• semantic cardinality
• concrete RefKind and policy
• edition pin
• open-world omission
• baseline replay
• no actuality by plan.

#Relations

#Content

#Context

A work plan may need more precision than use this method or perform this task. An inspection plan may need to remember that Robot_8_Ref is intended for HolderSystemSlot in a cited RoleAssignmentRelationSignature edition. A recognition plan may need to remember that Pump_37_Ref is intended for the declaration-local candidate argument.

The declaration already owns the participant, argument, or result meaning. The WorkPlan owns the intention. A.15.3 joins them only as plan content. It neither changes the declaration nor makes the planned value participate.

#Problem

Without this boundary, five failures recur:

1. Generic slot creation. Any description field named input, output, role, result, or parameter is treated as a SlotSpec.
2. Declaration-family collapse. RelationSignature SlotSpecs and operation arguments or results are placed in one undifferentiated slot schema.
3. Plan-as-actual inference. A planned value is treated as an obtaining relation participant or actual operation binding.
4. Description-as-declaration inference. A U.MethodDescription that mentions an input or effect is treated as if it declared a reusable participant locus.
5. Baseline rewrite. Performed values are copied back into the plan, erasing substitution and variance.

#Forces

#Solution

#What the plan item is—and is not

SlotFillingsPlanItem is a content form inside one U.WorkPlan ClaimGraph. It is not a U-kind, dependent durable kind, U.Relation occurrence, ontic SlotRelation, independent record, or second slot ontology. Its item and row designators have meaning only within that WorkPlan episteme.

C.2.1 and A.15.2 identify the WorkPlan episteme. Changing an identity-bearing row creates different WorkPlan claim content and therefore another WorkPlan episteme. The two are historical editions only if an EpistemeEditionRelation predicate obtains between them; a shared file, label, carrier, or revision order does not supply that continuity. A reference may point to the WorkPlan and this content component, but it gives the PlanItem no separate identity or edition rule.

A planned-filling claim says: for this intended future performance and under these conditions, use this value or designation for this declared member. A.15.2 and A.15.3 state that intention. The member's own pattern still defines what the participant, argument, or result means and what must hold for its later actual use.

The phrase planned filling does not mean that a declaration is filled, a relation obtains, an application occurs, or a value is actually bound. The row is plan content and needs no relation kind of its own. A later claim that the plan was fulfilled, missed, or changed belongs to A.15.2, A.6.RCD, or the applicable comparison pattern.

A planned-filling row states a positive intention. To prohibit or exclude a value, require its absence, or claim the list is complete, write a separate constraint or negative plan claim with its own applicability and polarity rule. Omission, an empty filler, and a negated reference do not express those claims.

#Use only members that a declaration already defines

Each row points to one member in one declaration edition selected for the intended future use. First choose what is being planned; then open the pattern that defines that member and the rule for its actual use:

A U.MethodDescription is not a target merely because it mentions inputs, effects, parameters, bounds, or acceptance conditions. Nor does a suite description, kit description, table, schema, card, checklist, interface form, or database field expose an A.6.5 SlotSpec unless a cited RelationSignature actually contains that SlotSpec. Operation arguments and results stay in A.6.1 declarations; planning them does not turn them into A.6.5 SlotSpecs.

One item may contain several rows when they serve the same intended performance, baseline policy, and rule for revising the plan. Each row still resolves to its own declared member. Split the item when those three controls differ. The WorkPlan's present EntityOfConcern remains its C.2.1 identity discriminator; a merely possible future performance does not replace it.

#State one planned-filling row

A conforming item contains or resolves these values:

SlotFillingsPlanItem:
  planItemDesignator
  workPlanRef
  intendedPerformanceDesignator
  plannedFillingRows:
    - rowDesignator
      targetDeclarationRef
      targetOperationDesignator?
      targetMemberDesignator
      targetMemberFamily:
        RelationSignatureSlotSpec |
        OperationArgumentDeclaration |
        OperationResultDeclaration |
        OtherDeclaredMember
      memberDefinitionPattern
      plannedValueOrDesignation
      planningConditions?
      declarationEditionPin?
      plannedValueEditionPin?
  baselinePolicyRef?
  laterComparisonPolicyRef?

This block represents WorkPlan claim content; it is not an ontic record schema or a second authority for rows. targetMemberFamily is an open local dispatch vocabulary, not a public kind or closed inventory. For an operation argument or result, targetOperationDesignator is required so the member resolves inside the cited mechanism edition; it stays absent for relation SlotSpecs. The memberDefinitionPattern field points to the pattern that defines the member and its actual-use predicate. A.15.3 still states only the plan's intention.

Read the designation rule from the selected member instead of copying it into the plan. An A.6.5 member uses its refMode; an A.6.1 member uses its bindingDesignationRule. A ByRef value must use the concrete reference kind required there and resolve to the declared ValueKind. A generic Ref, SpecRef, stored token, or merely compatible value does not pass.

Use the selected member's semantic cardinality. For a single-valued member, conditions and a resolution rule must make at most one planned value effective for one intended use. Alternatives need conditions and a rule that selects among them; row order supplies neither priority nor exclusivity. A multivalued member keeps the declaration's set, sequence, multiset, repetition, and ordering semantics. If the declaration and cited policy do not decide the needed cardinality, return missing-governor for the member cardinality or selection policy.

Omitting a row says only that this WorkPlan does not rely on that filling. It does not say the value or later participant is absent. Prohibition, exclusion, required absence, and closed-world completeness remain separate plan claims with their own applicability and polarity rules.

intendedPerformanceDesignator names the future use being planned; it does not make a future Work occurrence or entity exist. The enclosing WorkPlan keeps its already identified present EntityOfConcern under C.2.1 and A.15.2.

Add time, location, capability, readiness, gate, evidence, source-currentness, bridge, or publication conditions only when changing one would change whether the planned value applies or which value is selected. Cite the separate claims that establish those conditions. planningConditions points to them; it creates none of them and is not a generic condition bundle.

When a baseline or comparison policy selects a planned value or judges a later match, identify its concrete kind, defining pattern, edition, applicability, and reference scheme. A generic PolicyRef or shared label supplies no policy. Pin a declaration or edition-bearing value only when another resolution would change the planned meaning, and make the target reference and pin agree.

#Plan a future relation participant

For a RelationSignature row:

1. open the relation pattern and its obtaining predicate;
2. choose the RelationSignature edition the plan will use;
3. choose its declaration-local SlotSpec and SlotKind;
4. check the planned designation against the SlotSpec's ValueKind and refMode;
5. apply the declaration's semantic cardinality and participant constraints; and
6. record the row as a positive intended designation.

The row does not fill the SlotSpec. The SlotSpec remains reusable declaration content. The planned designation does not become the actual participant, and the direct relation does not obtain until its direct predicate is satisfied for independently identified participants.

#Plan a future operation argument or result

Open the cited A.6.1 mechanism edition, choose its operationDesignator, then choose the argumentDesignator or resultDesignator. Apply that declaration's ValueKind, bindingDesignationRule, binding predicate, semantic cardinality, and the plan's stated conditions.

The row plans a value; it is not an application or binding. An actual argument binding needs an identified application whose argument-binding predicate holds. An actual result binding additionally needs that application to return the value under the declared result meaning. Type compatibility, an expected result, a method phrase, a ticket value, or a matching token establishes neither binding.

#Compare later use without changing the plan

When work actually occurs, identify W : U.Work under A.15.1. Independently establish each relation participant through its obtaining predicate and each operation argument or result through the A.6.1 application-binding predicate. A matching plan row, label, type, or value establishes none of those facts.

If the team must state whether actual use matched the plan, name the comparison policy and the independently established actual facts. A one-off comparison may use A.6.RCD disposition 2 for a local compound assertion. Repeated parameterized comparisons may use disposition 3 for a predicate-definition episteme. Do not admit a comparison relation kind unless a later calculation or decision must refer to repeated comparison occurrences as such; then name that use and follow relation-kind admission. None of these comparisons changes the WorkPlan or creates a universal planned-to-actual relation.

An unplanned participant is still actual when its own predicate holds. To say that a planned value was missing, excluded, or substituted, apply the comparison policy's closure or negative criterion to the case facts. An absent log, unresolved reference, or unavailable fact yields missing-information, not a negative use or variance result; absent authority yields missing-governor.

#Preserve revisions and replay

Pin a declaration edition or edition-bearing planned value only when choosing another one could change the planned meaning. Latest, a mutable alias, a publication face, or an untyped policy label is not a reproducible reference.

If the selected declaration member changes before use, revise the WorkPlan claim content. An identity-bearing change creates another WorkPlan episteme; assert historical continuity only when EpistemeEditionRelation obtains. Preserve the earlier WorkPlan reference already cited by work or another actual use, and state substitution or variance separately. A carrier or representation change alone does not reidentify the plan while the C.2.1 discriminators stay fixed.

A card, table, view, index, or generated summary may show selected WorkPlan content under its publication-use pattern. It is read-only: it may not add planned rows, defaults, declaration meanings, cardinality, conditions, or baseline rules.

#Archetypal Grounding

#Planned holder designation against the admitted role-assignment declaration

An inspection team plans a later role assignment and chooses Robot_8_Ref as the holder system. Plan result: one row points to the cited RoleAssignmentRelationSignature edition and its HolderSystemSlot; Robot_8_Ref : U.EntityRef resolves to admitted Robot_8 : U.System. A.2.1 defines the assignment predicate and occurrence identity, while A.6.5 defines the declaration-local SlotKind, ValueKind, and reference mode.

The row establishes neither a U.RoleAssignment nor actual participation. Later, an affirmative assignment assertion is available only when all four participants are designated and the A.2.1 predicate holds continuously for them. A type-compatible planned holder can therefore remain the baseline while that predicate either fails under a stated negative criterion or cannot yet be resolved.

Blocked near-miss: Bearing_C isPartOf Pump_P cannot supply a relation row. A.6.5:5.2 keeps PartHolonSlot and WholeHolonSlot hypothetical until a part-relation pattern defines their meanings, predicate, applicability, and occurrence identity. Return missing-governor: planned part-relation participant designation for <Bearing_C, Pump_P> or keep the choice as ordinary A.15.2 plan content; do not present the sketch as an admitted RelationSignature.

#Planned argument and expected result against A.6.1

A team plans one Pump #37 recognition evaluation. It expects the application to use Pump #37 as candidate and return true if the cited criterion, construction facts, reidentification rule, interpretation basis, and required fastening-relation fact are available and determine satisfaction. The condition reference records that expectation; it makes none of those claims true. Pump37-Classification-Plan-E1_Ref identifies the WorkPlan, HolonRecognitionMechanism-E1_Ref identifies the cited A.6.1:5.7 mechanism edition, and Pump37-ExpectedTrue-Conditions-E1_Ref identifies the separate condition claims.

The WorkPlan carries this copyable planning content:

SlotFillingsPlanItem:
  planItemDesignator: pump37-recognition-baseline
  workPlanRef: Pump37-Classification-Plan-E1_Ref

  intendedPerformanceDesignator: planned-pump37-recognition-use-01
  plannedFillingRows:
    - rowDesignator: candidate-pump37
      targetDeclarationRef: HolonRecognitionMechanism-E1_Ref
      targetOperationDesignator: recognizeAdmittedHolonCandidate
      targetMemberDesignator: candidate
      targetMemberFamily: OperationArgumentDeclaration
      memberDefinitionPattern: A.6.1
      plannedValueOrDesignation: Pump_37_Ref
      planningConditions: Pump37-ExpectedTrue-Conditions-E1_Ref
      declarationEditionPin: HolonRecognitionMechanism-E1
    - rowDesignator: expected-recognition-true
      targetDeclarationRef: HolonRecognitionMechanism-E1_Ref
      targetOperationDesignator: recognizeAdmittedHolonCandidate
      targetMemberDesignator: recognitionJudgment
      targetMemberFamily: OperationResultDeclaration
      memberDefinitionPattern: A.6.1
      plannedValueOrDesignation: true
      planningConditions: Pump37-ExpectedTrue-Conditions-E1_Ref
      declarationEditionPin: HolonRecognitionMechanism-E1

In that operation declaration, candidate accepts exactly one U.Entity through a U.EntityRef; recognitionJudgment returns exactly one carried-by-value member of RecognitionJudgmentValue = {true, false, unknown}. The rows cite those rules instead of redeclaring them.

Later, A.6.1 identifies Pump37RecognitionApplication-2026-07-21T100000Z. The application binds Pump #37 as candidate, but a required fastening-relation fact is unavailable, so it returns unknown. Comparison result: the plan expected true under its cited conditions; the actual application returned unknown because one availability condition failed. An A.6.RCD disposition-2 local compound assertion may state that comparison from the preserved plan edition, application, result binding, and failed condition. It neither rewrites a row nor admits a universal planned-to-actual relation.

The plan rows themselves identify no application, bind no candidate, return no result, prove no A.1 criterion, create no result episteme, and warrant no claim. Those later facts remain with A.6.1, A.1, C.2.1, and the applicable evidence or assurance patterns.

#Hardware-acceptance pseudo-slots rejected

A hardware acceptance method says to use a calibrated instrument, selected reference plane, calibration record or certificate, and threshold. That sentence describes a method; it declares no A.6.5 SlotSpecs. Keep those choices as ordinary A.15.2 plan content, each under the pattern that defines the plane, calibration or evidence reference, and threshold.

Open A.15.3 only when an A.6.1 declaration, a RelationSignature SlotSpec, or another declared member already defines both the position and its actual-use rule. Otherwise return missing-governor for typed reuse; do not wrap the method description or fixture card in a fictitious slot-bearing declaration. Measurement, evidence sufficiency, readiness, acceptance, and actual instrument use remain separate.

#Edition-sensitive selector or archive planning

A selector or archive plan may need to preserve a comparator, descriptor definition, distance definition, evidence policy, or another edition-sensitive choice. A suite description, archive card, or generated view does not make those labels declaration members.

If a cited declaration exposes an A.6.1 argument or result, a RelationSignature SlotSpec, or another member whose defining pattern supplies its meaning, actual-use predicate, and cardinality, record one A.15.3 row per chosen member and pin only editions that affect the plan. Otherwise keep the choice as ordinary A.15.2 content or return missing-governor for typed reuse. The later application, dated work, archive or selection result, evidence path, publication, and variance remain separate; the card is a read-only view.

#Scope Declaration and Rationale

Scope. A.15.3 records only positive planned designations against declared members inside one WorkPlan. It does not define declarations, prohibitions, negative constraints, work identity, actual participation, applications, comparison results, evidence, readiness, gates, production, delivery, acceptance, publication, or downstream effects.

Rationale. The practitioner gets a reusable planned baseline without another U-kind or universal slot relation. Each declaration family keeps its own member meanings and actual-use rules; A.15.3 adds only the planned choice.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

Planning needs a way to preserve intended values without turning every planning field into ontology. Existing RelationSignature SlotSpecs, A.6.1 operation declarations, and other declarations already define reusable member meanings and actual-use predicates. A.15.3 records only the intended use of those members inside one WorkPlan.

The split is concrete: the declaration pattern defines the member and actual-use rule; A.6.5 or A.6.1 defines its declaration form; the WorkPlan remains one C.2.1 episteme whose A.15.2/A.15.3 content records the intention; and later Work, applications, relation occurrences, results, and comparisons are identified separately. A row cites these objects for planning but constitutes none of them.

#SoTA-Echoing

#Relations

• Builds upon: C.2.1 and A.15.2 for WorkPlan identity, present EntityOfConcern, intended-performance designators, and intended-work content; A.6.5 for SlotSpecs inside RelationSignature editions; A.6.1 for operation argument and result declarations; and the pattern that defines any other admissible declaration member.
• Coordinates with: A.15.1 for dated Work; relation patterns for actual participants; A.6.1 for applications and bindings; A.6.RCD for local fulfilment or variance claims when no comparison relation is already defined; A.15.5 for work-entry readiness; and the evidence, gate, evaluation, result, production, delivery, acceptance, publication, and currentness patterns when those claims are made.
• Does not replace: a declaration, method or method description, WorkPlan, dated Work, actual participant or binding, constraint or negative plan claim, comparison result, result episteme, evidence, gate, production, or publication object.

#P2W planned-filling use

When P2W reaches intended work and a planned value reuses a declaration member admitted by 4.1, carry the WorkPlan, intended-performance designator, declaration edition, member designator, defining pattern, planned value, and each condition or pin whose change would alter the effective planned value or later comparison. The declaration pattern defines the member and actual-use rule; A.15.2 and A.15.3 state the intention. P2W creates neither the declaration, plan claim, participant, nor application binding.

If no reusable member is needed, carry ordinary A.15.2 plan content. If typed planned use is needed but the member, its meaning, its actual-use predicate, or its defining pattern is absent, carry missing-governor for that intended use. A planned-filling row does not carry performed work, readiness, evidence, gate, result, measurement, publication, delivery, acceptance, exclusion, or completeness claims. Preserve each separately—for example, A.15.1 identifies performed Work and A.15.5 decides work-entry readiness.

#Lowering, repair, and refresh conditions

Use ordinary A.15.2 plan content when no reusable declaration member is needed. When typed use is needed, return missing-governor if the intended-performance designator, declaration edition, member designator, designation rule, cardinality, actual-use predicate, or defining pattern is missing; an operation argument or result also requires its operation designator. Do not replace that blocker with a generic slot-bearing description.

State prohibitions, exclusions, required absence, and completeness under their plan-constraint or negative-claim patterns instead of using omission or an empty filler. A later missing-filler, substitution, or variance result needs a comparison policy whose closure or negative criterion applies to the case facts.

Revise the WorkPlan ClaimGraph when the target member, planned value, intended-performance designator, condition, or relied-on declaration edition changes. If a C.2.1 identity discriminator changes, identify another WorkPlan episteme and relate it to the earlier one only when EpistemeEditionRelation obtains. Preserve the earlier WorkPlan reference already cited by work or another actual use. Refresh only a declaration, reference resolution, policy, or WorkPlan episteme whose changed resolution would alter the later decision; re-evaluate an actual-use change under its relation predicate or A.6.1 application predicate.

#A.15.3:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)