A.15.2:4.2 - 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 system-role-kind conditions — an intended performer U.System designator, the local system-role kind under which that performer is expected to qualify, its admission conditions, and, only when it already obtains, an assignment occurrence whose species is declared under U.SystemRoleAssignment and that is expected to cover later Work. A proposed holder-and-kind pair is not an actual assignment.
4. Capability requirement — an exact A.2.2 threshold or CapabilityFitCondition needed for planned work entry. Cite an existing capability claim only when the plan relies on it. The plan establishes neither the holder’s actual ability nor 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.