#U.WorkPlan: The Schedule of Intent

A.15.2 · Stable · Architectural (A) · Normative unless 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.

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

At a glance. Use U.WorkPlan when one exact episteme carries substantive claims for coordinating possible future performed work over a horizon through PlanItem content: intended method, planned window, performer and role conditions, capability-fit requirements, resource budgets, dependencies, commitments, acceptance targets, and a baseline for later comparison. C.2.1 keeps the episteme identity through one already identified present EntityOfConcern. A designator for merely possible future performance remains claim content; it neither designates a dated Work occurrence admitted under U.Work nor becomes another entity merely because it is planned.

Use this when. Use this pattern when a schedule, calendar, rota, Kanban ticket, Gantt bar, shift plan, rollout plan, reservation, planning cue, or P2W preparation note may be an episteme about intended work but is being treated as a method, method description, performed work, evidence, approval, gate result, publication cue, query-plan representation, or database query-optimizer representation. A system may use U.WorkPlan only when it can state the plan's substantive claims, the existing thing those claims concern, the scheme used to interpret them, and the possible future performance named in the plan content. The episteme itself neither acts nor makes work happen.

First useful object. One exact U.WorkPlan episteme with one present EntityOfConcern, one effective reference scheme, one horizon, and at least one PlanItem content component. For ordinary coordination, that component names the possible future performance or repeated-work subject, target U.Method, planned window, intended performer or role condition, and the resource, dependency, commitment, target, or baseline the current coordination needs. A later fulfilment or variance question is not required for membership or first use; open it only when a receiver asks about one independently identified Work occurrence.

First-use checks.

1. Ask what already existing thing the plan coordinates work for, then identify that one present U.Entity as C.2.1's EntityOfConcern. It may be an exact system, asset, or promise-content episteme. Use the plan episteme itself only when its claims are expressly about its own coordination commitments. Keep a possible future performance, repeated-work family, or proposed group as a plan-content designator. If several existing things have no independently identified joint subject, split the claims or lower the cue; do not use a merely possible Work occurrence as if it already existed.
2. State the coordination facts the team will act on now: target method, any method-description episteme the plan actually cites, horizon and window, intended performer or role condition, capability threshold, resources, dependencies, commitments, acceptance target, baseline, and effective reference scheme. Call the cited description an edition only when the C.2.1 EpistemeEditionRelation predicate obtains. If the team plans one particular future participant or operation value and will later compare that choice with actual participation, use A.15.3 only after an exact declaration member defines both its reusable meaning and its later actual-use predicate. Otherwise keep the choice as ordinary plan content; if typed reuse is required but that member or predicate is absent, return missing-governor. For an expected effect, name the intended subject and target under the pattern that defines them rather than adding a generic result field.
3. Ask what claim the schedule-like source actually carries. Intended-work coordination opens U.WorkPlan; a way of doing or its instructions opens A.3.1 or A.3.2; a dated performance opens A.15.1; a reusable planned declaration member opens A.15.3. Readiness, evidence, a gate result, appearance-based reliance repair, publication use, a forecast or dynamics model, and a declarative representation stay with their named patterns. A ticket, diagram, row, or file is only a cue or representation until one of those claims is stated.
4. For ordinary coordination, declare only the PlanItem organization, constraints, resources, dependencies, commitments, targets, and baseline needed to coordinate the intended work now. Stop this route once the plan is usable at that granularity. Do not choose a future fulfilment or variance policy, A.6.RCD disposition, or relation kind merely to make the plan coordinate work.
5. Only when a receiver later asks whether one exact Work occurrence fulfilled, deviated from, or remained outside one exact plan item, identify that Work independently under A.15.1 and open section 4.5. Select the smallest A.6.RCD disposition: a one-case local compound assertion for one case; a reusable predicate-definition episteme for repeated semantics that need no occurrence identity; relation-kind admission only for a receiver that genuinely consumes distinct relation occurrences. Unavailable case facts return missing-information; absent predicate, policy, or relation authority returns missing-governor. Neither stop creates a negative claim or universal fulfilment/variance relation.

Ordinary use. For simple coordination, one PlanItem inside one exact U.WorkPlan is enough. For example, a plan about existing Lathe-7, interpreted under FabMaintenanceScheme-E2, can set horizon 2026-07-27, item inspect-spindle, method SpindleInspectionMethod-E2, window 08:00–09:00, intended MaintenanceTechnician role, a one-hour machine reservation, dependency lockout complete, and baseline normal vibration. The team can coordinate tomorrow's rota and reservation from that content and stop. No future Work occurrence, fulfilment policy, variance rule, or relation kind is needed until a receiver asks the later comparison question in step 5.

Reliance-bearing use. Use fuller WorkPlan claim content when cross-role coordination, budget reservation, delivery commitment, gate preparation, audit expectation, cross-context acceptance, release preparation, evidence-reference notes, source-currentness requests, or P2W carry-through depends on the plan.

Stop condition. Stop once a system can coordinate the intended work at the needed granularity. If step 3 identifies another claim, use that pattern and make no WorkPlan claim. If no pattern states the predicate needed for a later fulfilment, variance, or occurrence-facing relation, stop only that stronger use; the plan and any local comparison whose predicate and supporting facts can be stated remain usable.

What goes wrong if missed. Teams treat calendars, tickets, reservations, or rollout notes as if work already happened; identify a possible future performance as an existing Work occurrence; let the plan episteme act; or treat a plan as method, evidence, gate result, approval, or publication authority.

What this buys. One identifiable intended-work episteme whose present subject, horizon, windows, intended performer and role conditions, capability-fit requirements, constraints, budgets, dependencies, commitments, acceptance targets, baseline, and later comparisons with independently identified Work occurrences remain inspectable.

Not this pattern when. Not this pattern when the current claim is a dated performed work occurrence (A.15.1), A.15.3 declaration-local planned-filling content, work-entry readiness or full-kit condition (A.15.5), a reliance appearance being used before the governing pattern or relation is recovered (A.15.4), a method (A.3.1), a method description (A.3.2), evidence or assurance (A.10 or B.3), a gate or constraint decision (A.20 or A.21), publication-use behavior (E.17), a non-agentive forecast or dynamics model (A.3.3), or a declarative representation overread as a work-control or method claim (C.2.P.DR).

Intended operations are coordinated in time. Even with suitable roles, abilities, and methods, no intended performance begins merely because it is forecast or described: a system must decide when and by whom possible future work is intended, under what constraints and budgets. Teams need a first-class concept for plans and schedules that does not get confused with:

#Aliases

• U.WorkPlan

#Keywords

• intended-work episteme
• present EntityOfConcern
• possible future performance
• PlanItem content
• horizon
• performer and capability conditions
• positive or governed-negative local fulfilment assertion
• reusable predicate semantics
• variance
• no actuality by plan.

#Relations

#Content

#Context (plain‑language motivation)

Intended operations are coordinated in time. Even with suitable roles, abilities, and methods, no intended performance begins merely because it is forecast or described: a system must decide when and by whom possible future work is intended, under what constraints and budgets. Teams need a first-class concept for plans and schedules that does not get confused with:

• the semantic “way of doing” (that is U.Method),
• the written recipe (that is U.MethodDescription),
• the performed work occurrence (an individual admitted under U.Work), or
• the state-change model (that is U.Dynamics).

U.WorkPlan is that missing intended-work episteme.

#Problem (what breaks without WorkPlan)

1. “Workflow = schedule” conflation. Flowcharts or code are used as calendars; resource clashes and SLA misses follow.
2. Plan and occurrence blur. Gantt bars or Kanban tickets are reported as if the work already happened; audits and costing degrade.
3. Specification and time leakage. People and calendars creep into MethodDescriptions; reuse and staffing agility collapse.
4. No variance model. Without planned baselines, deviations in time, cost, and quality cannot be explained or improved.
5. Structure entanglement. BoM and org charts get baked into “process” views; plans become brittle and unmaintainable.

#Forces (what the definition balances)

#Solution - U.WorkPlan as the time-bound intention for U.Work

#Definition, membership, and identity

U.WorkPlan is a same-individual dependent kind under U.Episteme. C.2.1 first identifies exact episteme P by:

<exact ClaimGraph, one already identified present EntityOfConcern, effective U.ReferenceScheme>

A.15.2 recognizes that same P as U.WorkPlan when its ClaimGraph substantively declares coordination of possible future performed work over one exact horizon through at least one PlanItem and, when it contains several items, their plan-content organization. The intended-performance designator may denote one proposed future performance, a named repeated-work family, or one bounded proposed group. It remains claim content: planning it neither asserts the existence of a dated Work occurrence nor makes a merely possible performance into C.2.1's already identified EntityOfConcern.

The present EntityOfConcern is the already identified existing entity that the plan's claims are about: for example, a system, asset, or promise-content episteme for which work is being coordinated. When the plan claims are expressly about their own coordination commitments, C.2.1's reflexive option permits P itself. When the claims concern several entities jointly, C.2.1 still requires one independently identified joint EntityOfConcern; otherwise split the claim content rather than filling the position with a list of unrelated or merely possible referents.

The stable positive membership condition is substantive intended-work content. At least one PlanItem must name its intended-performance designator, intended method or method family, planned window or entry condition, intended performer or role condition, and enough constraints, resources, dependencies, commitments, targets, or baseline to make one coordination decision—for example, reserve a machine, order two items, staff a window, or set the target to be checked later. A calendar picture, ticket title, publication, approval cue, method description, forecast, or list of dates that supplies no such intended-work claims does not gain U.WorkPlan membership by format.

The dependent kind supplies no second identity rule. Changing exact ClaimGraph content, the present EntityOfConcern, or the effective U.ReferenceScheme identifies another episteme under C.2.1. An explicit EpistemeEditionRelation may preserve historical continuity only when its own predicate obtains. Changing only a file path, carrier, layout, publication occurrence, ticket key, or version label leaves identity unchanged when the three C.2.1 discriminators are preserved.

Planned methods, possible-performance designators, performer designations, role conditions, windows, desired fillings, capability-fit requirements, resource budgets, dependencies, commitments, acceptance targets, and expected effects are claim content or separately governed planned claims. They establish no dated work occurrence, obtaining U.RoleAssignment, capability-fit result, actual participant, resource use, transformation, result value, result episteme, produced entity, delivery, acceptance verdict, or downstream outcome.

Strict distinction (memory aid): Method = how in principle. MethodDescription = how it is written. WorkPlan = when, by whom in intent, under which constraints. Work = how it went this time.

#PlanItem content

A PlanItem is a declaration-local content component in one exact U.WorkPlan, not a U-kind, future or performed work occurrence, method part, assignment, relation occurrence, or result record. Its designator is interpreted inside that exact plan episteme. A receiving episteme may refer to the content component, but the designator or reference does not make its intended claims actual.

Choose only the claims the team will use to coordinate the intended work. The list is an open recognition palette, not a record schema or a kind defined by enumeration. When one row mentions a neighboring relation, state its own participants and predicate rather than treating the row or reference as proof that it obtains:

1. Target method and description use — the U.Method intended for enactment and, only when one plan claim relies on a particular U.MethodDescription episteme, that episteme and the relying instruction, constraint, or justification claim. Call the description an edition only when the C.2.1 EpistemeEditionRelation predicate obtains. The description neither identifies the method, constrains or justifies it by itself, nor becomes the enacted object.
2. Planned window or entry condition — earliest start, latest finish, timebox, recurrence, blackout period, or another exact intended temporal condition.
3. Intended performer and role conditions — intended holder designation, U.Role value, role-admission conditions, and, when already obtaining, an exact U.RoleAssignment intended to cover later work. A proposed holder-role tuple is not an obtaining assignment.
4. Capability requirement — an exact A.2.2 threshold or CapabilityFitCondition needed for work admission. Cite an existing capability claim only when the plan relies on it. The plan neither creates U.Capability nor evaluates fit for the later work interval.
5. Resource budgets and reservations — intended energy, materials, machine windows, money, and exact reservation claims. A planned budget is neither a performed resource-use fact nor a B.1.6 aggregate ledger result.
6. Dependencies and commitments — state the source item or commitment, the affected target item, and the condition that blocks, orders, overlaps, or excludes the planned work. A cited gate, approval, source-currentness, or promise claim keeps its own predicate; the citation establishes neither gate passage, approval, promise fulfilment, nor world-side ordering.
7. Acceptance targets — name the criterion and target value or window that a later evaluation will test. The target is not the evaluation or acceptance verdict.
8. Location, affected-subject, and asset constraints — where a proposed performance is intended to occur and which existing referent it is intended to concern, without asserting actual participation or change.
9. Desired planned bindings — use A.15.3 only when the plan intentionally fills one exact participant, argument, or result member already declared by A.6.5, A.6.1, or another pattern that states both the member meaning and its later actual-use predicate. A.15.2/A.15.3 state the intended choice; the declaration states what later counts as actual use. Without that member, keep an ordinary plan choice when typed reuse is unnecessary, or return missing-governor when it is necessary.
10. Expected effect, result, or delivery target — write the planned sentence with its intended subject and target: for example, the machine state sought, measurement window to be met, entity to be produced, or publication or delivery to be completed. Use the pattern that defines that effect. The broad words output, result, outcome, deliverable, or handoff do not name one plan field or universal kind.

A method description may describe generic participant meanings and intended effects, but it supplies no planned filling by itself. A desired filling remains planned; an expected result or effect remains expected. Neither establishes a dated Work occurrence admitted under U.Work, actual participant, operation application, actual change, returned value, result episteme, produced entity, acceptance verdict, delivery occurrence, or downstream outcome.

Didactic guardrail: No log, telemetry value, performed-work fact, actual participant, or actual result belongs in WorkPlan identity-bearing claims merely because the plan later receives a comparison. Step logic and solver internals remain with the exact Method, MethodDescription, Mechanism, or representation pattern.

#Clear distinctions for schedule, process, and workflow wording

Schedule-word guard. Schedule-like words do not determine the kind by themselves. Use U.WorkPlan only when the text actually states intended work, a horizon or window, performer or role conditions, and enough constraints, resources, dependencies, targets, or baseline to coordinate it. Otherwise use the pattern for the method, instructions, dated Work, evidence, gate, publication use, or representation actually claimed.

#Plan mereology (composition of plans ≠ composition of methods or work occurrences)

Keep three separations crystal-clear:

• Method composition admits a composite U.Method only when A.3.1/B.1.5 supplies the submethods, whole-forming relations, and whole-level commitments.
• Work organization starts with exact A.15.1 work-part relations. Temporal overlap is an independently governed interval fact under B.1.4, and coordination is a separate direct claim when it obtains. Shared parentage or overlap creates neither a ConcurrentPartOf_work primitive nor coordination.
• Plan-content organization arranges declaration-local PlanItem components inside the exact ClaimGraph for coordination. It is epistemic organization, not world-side work or method mereology.

Common plan-content claim families include:

• precedence or dependency constraints naming exact source and target item designators, start or finish conditions, and any prerequisite or gate condition;
• overlap or exclusivity constraints naming the exact scheduling policy and the windows it permits or excludes;
• refinement claims stating which intended-performance designator is preserved and exactly which window, constraint, target, or budget is tightened; and
• alternative claims stating the alternatives and the independently governed condition used to choose among them.

Start with the readable plan constraint—for example, “item B starts only after clearance claim C for item A is current.” Keep that claim inside the WorkPlan ClaimGraph and name the two item designators, the condition, scope, and qualification. A graph edge, row order, or repeated spelling creates no world-side ordering, assignment, resource use, work parthood, or relation kind. If several plans reuse the same parameterized rule, A.6.RCD may supply a predicate-definition episteme. Open relation-kind admission only when a named receiver must distinguish occurrences of that relation; then E.24/E.24.UK and the standalone direct pattern must supply obtaining and identity before A.6.REL is used. If the rule, its source predicates, or occurrence identity cannot be stated, return the corresponding A.6.RCD blocker rather than minting Precedes_pl, MutuallyExclusive_pl, Refines_pl, or another pseudo-kind here.

Didactic rule: A PlanItem does not force an identical work shape. A later one-case comparison with an independently identified Work occurrence remains a separate local plan-use assertion unless an admitted direct relation has actually been supplied.

#How WorkPlan meets Work

Ask one concrete question first: “Did Work W satisfy plan item I under policy F?” Identify W under A.15.1, then name exact WorkPlan episteme P, declaration-local item I, and policy episteme F. Check only the independently obtaining facts that F requires—for example, enacted Method, required assignments, and Work extent in the hospital case below. Put the answer in a separate C.2.1 assertion whose EntityOfConcern is P. The assertion neither changes P nor admits a WorkPlanFulfilmentRelation kind.

A positive answer requires every fact in F's positive criterion. State a negative answer only when F contains an applicable failure or closure criterion and the case facts satisfy it. Missing occurrence facts return missing-information; an absent predicate or policy authority returns missing-governor. Neither stop is a negative claim. The assertion keeps W, P, I, F, polarity, and the supporting facts explicit; a matching label, window, ticket, record link, or policy name closes nothing. Several Work occurrences may satisfy different parts of I, or one consolidated Work may satisfy several items, only when F states that mapping. Unplanned Work remains valid Work; a separate assertion may classify it as unplanned for one named variance or improvement use.

If a receiving practice repeatedly needs the same parameterized fulfilment rule but consumes no relation-occurrence identity, use A.6.RCD disposition 3 to publish one predicate-definition episteme with one truthful exact EntityOfConcern, participant meanings, derivation, applicability, polarity, dependencies, and currentness; it is not a RelationSignature or relation kind. Only when a named receiver also needs distinguishable fulfilment occurrences may A.6.RCD return a relation-kind candidate for E.24/E.24.UK admission, a standalone direct subject settlement, and later A.6.REL discipline. Until those requirements are met, return the exact blocker only for the stronger use; do not infer partlessness, deny the local assertion or reusable predicate semantics, or add a universal fulfils edge.

A variance question is handled in the same economy. Use a separate local comparison assertion unless the measurement, evaluation, acceptance, resource, or temporal pattern already states the exact comparison. Name one planned value in exact P and I, one independently established actual value, the comparison method, scale, qualification window, and result. Do not make variance an intrinsic field of a Work occurrence, enter it into P's identity-bearing claim content, or rewrite the plan. Common comparison questions include:

• schedule variance: actual Work extent against the planned window, using the exact temporal comparison and any B.1.4 aggregate needed by the receiving KPI;
• resource or cost variance: exact A.15.1 performed resource-use facts or a B.1.6 aggregate result against the planned budget;
• method variance: actual enactsMethod against the intended method, including an exact substitution claim when the comparison asserts substitution;
• description-selection variance: the method-description episteme cited by a named assertion about a Work occurrence or by a separately governed instruction-use claim, compared with the description reference planned earlier; call either object an edition only when the C.2.1 EpistemeEditionRelation predicate obtains, and do not treat that episteme as enacted;
• acceptance-target variance: a separately governed measurement, evaluation, or acceptance verdict against the planned target; and
• assignment variance: every exact performed-work U.RoleAssignment against the intended holder and role claims.

Manager's view: A plan that cannot support one exact later local fulfilment or variance question is only a calendar picture for that use, not yet a reliance-bearing WorkPlan.

#What a good WorkPlan states (review checklist)

Use this as a human-facing recognition palette, not a rigid schema or a definition by enumeration:

1. Present EntityOfConcern, horizon, and cadence (for example, the current service system and “W36 surgeries” or “daily ETL”), with possible future performances kept as plan-content designators.
2. PlanItem content components with intended-performance designator, target Method, the selected method-description episteme when one plan claim relies on it, planned windows, and dependencies.
3. Intended holder and role conditions, any already obtaining assignment reference, and exact A.2.2 capability threshold or fit condition; a proposed tuple or threshold is not an assignment or fit result.
4. Safety envelopes, constraints, and other admissibility conditions for planned work.
5. Resource budgets and exact reservation claims on assets.
6. Acceptance targets with their direct criteria and intended qualification windows.
7. Cross-context interpretation boundary: before copying a planned value, target, or verdict into another context, pin both effective reference schemes and resolve the two F.17 SchemeSenseCell values. F.9 says only whether their Bridge obtains. A separate C.2.1 claim says whether this exact reuse is acceptable in this direction, under this correspondence rule and tolerated loss; A.10 governs ordinary evidence reliance and B.3 governs assurance-bearing reliance. A negative use claim leaves the Bridge true but stops the reuse; a non-passing reliance result stops or narrows it. Establish any value conversion, target comparison, commitment, acceptance, verdict reuse, plan coordination, or Work claim separately under the pattern that defines it.
8. Baseline when the receiving comparison needs one. If this plan is being related to another exact plan episteme and EpistemeEditionRelation actually obtains, name both epistemes and add the change note that makes their attributed difference inspectable. A first plan and a non-continuing replacement carry no such relation; a revision label or change note alone does not create it.
9. Policy pointers to A.15.1 work continuity, B.1.4 temporal aggregation, B.1.6 resource aggregation, and any exact local comparison policy needed by the receiving KPI.
10. Exception question stating how ad hoc or emergency Work will be handled by a local plan-use assertion; use one reusable predicate-definition episteme only for repeated semantics, and require an admitted direct relation kind before claiming fulfilment or exception occurrences.

#Archetypal grounding (parallel domains)

#Hospital OR day plan (shift rota + cases)

• WorkPlan: OR_DayPlan_2025-08-12-E3 : U.WorkPlan is one C.2.1 episteme. Its present EntityOfConcern is exact existing system OR-Service-System-12 : U.System; its effective reference scheme is HospitalORPlanningScheme-E4; its horizon is 2025-08-12T00:00:00+03:00/2025-08-13T00:00:00+03:00. Proposed case performances remain ClaimGraph designators and are not dated Work occurrences.
• One PlanItem: Case_1_Appendectomy coordinates proposed performance PlannedAppendectomy-Case1 through the following exact content.

• Later Work: A.15.1 independently identifies AppendectomyWork-2025-08-12-Case1 : U.Work with workContinuityPolicyRef = SingleProcedureFromAnesthesiaStartToHandover-E1 and temporal extent 2025-08-12T09:04:00+03:00/2025-08-12T10:21:00+03:00. F.6 performedUnderAssignment obtains for RA-Surgeon-DrK-2025-08-12 and RA-Anesthetist-DrM-2025-08-12; A.15.1 enactsMethod obtains for LaparoscopicAppendectomyMethod-E2; B.1.4 supplies the exact within-window comparison. The plan created none of those facts.
• Named one-case policy: ORCase1FulfilmentPolicy-E2 is one exact C.2.1 episteme about exact plan episteme OR_DayPlan_2025-08-12-E3, interpreted under HospitalORPlanningScheme-E4. Its ClaimGraph is limited to item Case_1_Appendectomy and states positive polarity only when the identified Work enacts the target Method, both required performedUnderAssignment relations obtain, and its extent lies inside the planned window. It uses only those four facts for this local conclusion, does not travel to another plan episteme, and admits no fulfilment relation kind.
• Visible result: C.2.1 assertion episteme OR-DayPlan-Case1-Fulfilment-Assertion-E1 has OR_DayPlan_2025-08-12-E3 as its exact EntityOfConcern; its ClaimGraph names AppendectomyWork-2025-08-12-Case1, item Case_1_Appendectomy, policy ORCase1FulfilmentPolicy-E2, the four supporting facts, and positive polarity. The result says that this Work satisfies this plan item under that policy. It does not rewrite the plan and does not assert a universal relation.
• Nearest false shortcut: a theatre log row carrying key Case_1_Appendectomy and start time 09:04 establishes neither performedUnderAssignment nor enactsMethod. Without those independently obtaining facts the local conclusion returns missing-information; matching labels and times produce neither negative polarity nor fulfilment.
• Edition boundary: OR_DayPlan_2025-08-12-E3 is the first plan episteme used for this day, so this case has no EpistemeEditionRelation and needs no change note. If planners later change its ClaimGraph but establish no edition predicate, C.2.1 identifies a new, non-continuing plan episteme. Reusing the day-plan label or adding a Rev-4 note cannot turn that replacement into a continuation; a later policy must name whichever exact plan it judges.

#Fab maintenance weekend (asset reservations)

• WorkPlan: Fab_Maintenance_W36 is interpreted under FabMaintenancePlanningScheme-E3, has horizon [2025-09-06T00:00Z, 2025-09-08T00:00Z), and concerns already identified Fab-Production-System-4 : U.System. Tool_42 and Tool_13 remain exact assets named by the PlanItems; they are not an unproved joint EntityOfConcern.
• PlanItem content: Tool_42 chamber clean under ChamberCleanMethod-E2; Tool_13 calibration under ToolCalibrationMethod-E1; the ClaimGraph carries an exact exclusivity constraint with production windows under the named scheduling policy, not a reusable MutuallyExclusive_pl relation kind.
• Reservations: nitrogen, DI water, metrology window.
• Later local assertion: The exact chamber-cleaning Work occurrence is identified independently as an individual admitted under U.Work. FabChamberCleanPlanUsePolicy-E1 asks whether that Work enacted ChamberCleanMethod-E2, stayed inside the planned window, and kept nitrogen use within the reserved amount. A.15.1, B.1.4, and B.1.6 establish those three facts. In this transfer probe they all obtain, so a separate C.2.1 assertion about the plan states positive fulfilment, early completion, and nitrogen underrun. A shared item label or reservation row supplies none of those facts.

#Data-center rollout (multi-context plan)

• WorkPlan: DC_Rollout_Phase-2 is interpreted under DCOperationsPlanningScheme-E5, has horizon [2025-09-01T00:00Z, 2025-09-15T00:00Z), and concerns already identified Service-A-Operations-System : U.System. The Security Audit scheme remains a separate interpretation source used only through the branch below.
• Interpretation boundary: Operations uses DCOperationsPlanningScheme-E5; Security Audit uses SecurityAuditScheme-E4. Their acceptance criteria remain separate; apply the branch in checklist item 7 before proposing any cross-context reuse.
• Bridge premise: exact F.17 cells OperationsReadyCell-E3 and SecurityAuditPassedCell-E2 participate in F.9 Bridge OpsAuditReadinessOverlapBridge-E1 under OpsAuditPartialOverlapProfile-E1. The Bridge obtains as partial-overlap: both senses exclude a known blocking security defect, while Operations readiness also requires rollback rehearsal and live monitoring and the audit sense applies its own security criteria.
• Rejected verdict transfer: C.2.1 claim AuditPassAsOperationsReadyUse-E1 proposes copying GateDecision=pass from A.21 gate SecurityAuditGate-E2 into an A.15.5 work-entry readiness result, from the audit cell to the Operations cell, by identity transfer and with zero tolerance for omitted readiness conditions. The claim is negative because the two senses do not align on rollback rehearsal or monitoring readiness. A.10 evidence-provenance path OpsAuditTransferEvidencePath-E1 has RelianceDisposition=pass for that negative claim, so the team retains the A.21 audit decision and evaluates Operations readiness separately under A.15.5. The obtaining Bridge remains true. A narrower plan use may cite the audit decision as one readiness input; it still cannot transfer the verdict.
• PlanItem content: Deploy Service A, Pen-test A; exact dependency and window claims name their predicates and conditions inside the plan ClaimGraph.
• Later local assertions: Exact deployment and audit Work occurrences are identified independently as individuals admitted under U.Work. Separate operations and audit evaluations apply their own targets and produce separately governed verdicts; plan-use assertions state exact local fulfilment and per-context comparison without adding those actual facts to the plan content or creating one cross-context fulfilment relation.

#Scope Declaration and Rationale

• Applicability: Use the same intended-work test for coordination, budgeting, architecture planning, teaching examples, and source or evidence questions. When the current claim is performed work, a non-agentive forecast, dynamics, evidence, assurance, publication use, appearance-based reliance repair, or declarative representation, apply the direct pattern for that claim.
• Scope declaration: Domain-general where a system is actually coordinating possible future performed work. A tide table, weather forecast, simulation schedule, or predicted natural trajectory is not a WorkPlan unless its claim content also coordinates a system's intended Work. Interpret the plan through its effective U.ReferenceScheme and, when the use needs a bounded claim set or model-applicability question, the exact U.ClaimScope and ModelApplicabilityRelation governed by A.2.6 and A.1.1. An already identified BoundedModelUseStructure enters only when a separate receiving claim or use relation states how that structure changes this plan use and its direct predicate obtains; otherwise omit the structure rather than inventing a context field. Ordinary project, domain, or context wording stays Plain and creates no container or identity field. For cross-context sense reuse, apply checklist item 7.
• Rationale: Planning and scheduling become a first-class episteme that systems can use to coordinate intended methods, performer and role conditions, and possible future work without turning the episteme into an actor or the proposal into an occurrence.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

• Future-work-as-entity. Do not use a possible future performance or PlanItem designator as C.2.1's already identified EntityOfConcern or as a dated Work occurrence; keep it in plan claim content until an exact direct entity or occurrence exists.
• Plan-as-actual. Do not treat a Gantt bar, Kanban ticket, shift rota, or calendar booking as performed work; create or cite an exact Work occurrence admitted under U.Work only when A.15.1's occurrence basis is present.
• Workflow-as-schedule. Do not treat a method description or flowchart as a plan; make a U.WorkPlan only when the claims state a present subject, intended-performance designator, horizon, window, constraints, performer or role conditions, and baseline.
• Assignment-or-capability-by-plan. Do not treat an intended holder, role, threshold, or capability reference as an obtaining U.RoleAssignment, capability instance, or fit result for later Work; apply A.2.1/A.2.2 at the exact interval and use.
• Budget-as-cost. Do not book planned budgets as performed resource use; establish performed facts on exact A.15.1 Work and any aggregate ledger or allocation under B.1.6.
• Plan-shape overreach. Do not force performed Work to match plan decomposition, infer non-fulfilment from a missing link or unavailable facts, or mint a fulfilment relation from a local comparison. Stop at a positive or governed-negative local compound assertion when it suffices; use a predicate-definition episteme for repeated semantics without occurrence identity; open relation-kind admission only for a named occurrence-facing need.
• Context-bridge overreach. Do not bridge contexts as wholes or use F.9 to convert planned values, commitments, criteria, or verdicts. F.9 relates exact SchemeSenseCell values; apply checklist item 7 for the separate use claim and reliance result before any cross-context plan use.
• Evidence-note-as-claim. Do not treat evidence-reference notes, gate-preparation notes, or source-currentness requests as evidence, gate passage, assurance, or release authorization.
• Readiness-or-gate-as-permission. A ready result reports entry conditions and an A.21 gate decision governs its declared crossing; neither institutes permission or performed Work. Recover an exact current A.2.8.PER grant when permission is required.
• Description-as-planned-filling. Do not turn a method-description word such as input or output into a planned slot. Use A.15.3 only when one exact declaration member already states what the value means and what later counts as actual use. Otherwise keep the choice as ordinary plan content or return missing-governor when typed reuse is required.
• Expected-as-actual. Do not treat a desired filling, expected effect, output, result, outcome, deliverable, or handoff as an actual participant, change, returned value, produced entity, delivery, acceptance, or downstream effect.

#Consequences

#SoTA Alignment

#Relations

• Builds on: C.2.1 for episteme identity and local assertion identity; A.15 for Role-Method-Work alignment; A.15.1 for independently identified performed Work occurrences admitted under U.Work; A.2.1 for U.RoleAssignment; A.2.2 for capability instances, thresholds, and fit conditions; A.3.1 for U.Method; and A.3.2 for U.MethodDescription.
• Coordinates with: A.15.3 for planned filling against exact governed declarations; A.6.1 for operation argument and result declarations; A.6.5 for RelationSignature participant declarations; A.6.RCD for the existing-direct/local-compound/reusable-predicate/relation-kind economy; E.24/E.24.UK for any later kind admission; A.6.REL only after an admitted direct or derived relation needs occurrence discipline; A.15.4 for work-relevant appearance-based reliance repair; A.15.5 for work-entry readiness; B.1.4 for temporal aggregation; B.1.6 for performed-resource aggregation; A.10 for evidence-provenance relations; B.3 for assurance; A.20 and A.21 for gates and constraint decisions; C.32.P2S for architecturing-flow references to intended work; E.17 for publication-use questions; and F.9 only for exact cross-context SchemeSenseCell correspondence, with any proposed use and reliance routed through checklist item 7.
• Used by: P2W carry-through when principle-to-work reasoning reaches WorkPlanning, and P2S carry-through when architecture-selected structures require intended-work epistemes. Both uses keep present plan subject, possible future performance, readiness, performed Work, actual use, evidence, gate, comparison, result, and downstream effect separately governed.

#P2W WorkPlanning use

When E.18.1 reaches WorkPlanning, one exact U.WorkPlan retains its present EntityOfConcern and states possible future performed work over an exact horizon through PlanItem content: intended-performance designators, windows, methods, performer and role conditions, capability requirements, constraints, budgets, dependencies, commitments, targets, evidence-reference notes, and source-currentness requests. If the plan chooses a value for a reusable declaration member, use A.15.3; if it states an expected effect, name the intended subject and target under the pattern that defines that effect.

When the P2W use also needs a readiness question, the WorkPlan may supply target PlanItems, planned preparation tasks, reservations, and planned baselines. A.15.5 supplies the exact readiness criterion and local result about that plan content; the criterion may consume current commitment, resource, work-in-progress or load, flow-policy, and launch-gate claims only through their separately governed values, boundaries, counting or threshold rules, and qualification windows.

If the same P2W source material also claims performed work, an actual launch value or participant, evidence, gate passage, result, measurement, publication use, appearance-based reliance repair, or refresh, state that claim outside the WorkPlan under the pattern that defines it. The WorkPlan establishes none of them.

#Launch-value and actual-use boundary for P2W

For P2W use, U.WorkPlan may state intended holder and role claims, planned values, exact A.15.3 fillings, constraints, reservations, commitments, and evidence-reference notes. A.15.5 may later publish one C.2.1 work-entry readiness result about this exact plan and PlanItem. An A.21 GateDecision separately selects, narrows, blocks, or passes its declared crossing under one current GateProfile. Neither result institutes permission.

When the entry criterion consumes permission material, keep the current A.2.8.PER values distinct. A GrantedPermissionRelation@Context occurrence is strong permission only for its exact beneficiary, action specification, U.ClaimScope, and validityWindow. A NonProhibitionFinding@Context reports only its frame-relative result for its evaluationWindow; it is not a grant. A PermissionNormConflictFinding@Context exposes overlap for its overlapWindow, and only its direct owner can supply a current resolution result with an effectiveWindow; an unresolved conflict stops or degrades the proposed use. PermissionExerciseRelation@Context and NonViolationFinding@Context require already dated actual Work and therefore cannot be prospective proof that the intended performance may start. When the governing entry policy requires a grant, absence or unavailability of that exact current grant permits no authorization claim; readiness, gate passage, or non-prohibition cannot stand in for it. The WorkPlan, readiness result, gate decision, permission values, and their windows make no planned value actual and create no Work occurrence.

At performed-work entry, identify one exact Work occurrence as an individual admitted under U.Work by A.15.1. For an actual relation participant or another world-side value, name the direct relation and its obtaining predicate. For an operation argument or returned result, use A.6.1 only after the exact application and its declaration-local binding predicate obtain. Keep the gate decision, plan claim, readiness result, permission facts, Work occurrence, actual-use relation, provenance, change, result episteme, production, delivery, acceptance, and downstream effect separate.

#Lowering, repair, and refresh conditions

Lower a candidate U.WorkPlan claim when the reader cannot identify one present EntityOfConcern, the effective U.ReferenceScheme, the horizon, one substantive PlanItem, or its intended-performance designator well enough to coordinate the intended work. Split the claim content when several existing subjects have no one jointly identified EntityOfConcern. The acceptable lowered object is a planning cue, schedule or forecast representation, method-description note, missing-source-relation note, A.15.4 repair request, publication-use cue, readiness-gap note for A.15.5, or evidence-reference note, not a conforming WorkPlan.

When intended method, window, performer or role condition, capability requirement, resource budget, dependency, commitment, acceptance target, baseline, plan-content claim, local comparison policy, or exception policy changes, repair the exact ClaimGraph. If claim content, present EntityOfConcern, or effective reference scheme changes, C.2.1 identifies another episteme. Then ask separately whether EpistemeEditionRelation obtains between the two exact epistemes and name it only when it does. With no earlier plan episteme in scope, the result is a first plan. When another plan episteme is present but the edition predicate does not obtain, the result is a non-continuing replacement. A changed file, carrier, layout, publication, ticket key, revision label, or change note alone establishes neither reidentification nor continuity.

Do not rewrite an independently identified Work occurrence when only the plan changes, and do not make a revised plan evidence that Work occurred. Repair an actual participant, resource use, change, result, production, delivery, acceptance, evidence, or downstream effect under the pattern that defines that claim. When a one-case local fulfilment or variance assertion is no longer enough, use A.6.RCD disposition 3 if repeated predicate semantics are sufficient. Only when a named receiver needs distinguishable relation occurrences does kind admission open; if no truthful occurrence settlement or governing pattern is available, preserve the plan, local assertions, and reusable definition and return missing-governor for that stronger use.

Refresh the selected plan episteme before relying on it for cross-context coordination, budget reservation, release or gate preparation, work-entry readiness, evidence-reference use, performed-work entry, result measurement, or P2W carry-through. If the proposed reuse crosses the two named reference schemes, resolve both SchemeSenseCell values and test whether their exact F.9 Bridge obtains. Then apply checklist item 7 to the proposed use and its reliance result, and re-establish each value, criterion, commitment, or verdict mapping under the pattern that defines that claim. If the refreshed use claims readiness, performed work, actual participation, evidence, assurance, gate passage, result, publication use, representation, or appearance-based reliance repair, use that claim's governing pattern and retain only the intended-work claims here.

#A.15.2:End

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