#U.Work: Dated Performed Work Occurrence

A.15.1 · 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.Work as the admitted kind when the current claim concerns one performed Work individual: a world-side dated occurrence performed by one or more admitted holder U.Systems under exact obtaining U.RoleAssignments. The systems perform the work; the assignments are the separately obtaining role-holding relations under which the attribution is valid. The occurrence has an actual temporal extent, enacts an exact method, and is executed within an exact containing system. State a binding, resource-use fact, or direct work-to-referent relation only when it actually obtains and the receiving use needs it; an assertion, description, log, or record about the occurrence is a separate U.Episteme and does not store fields in the occurrence. When the reader asks what the work returned, changed, produced, transferred, or caused someone to accept, use the concrete three-question route in §4.6 instead of adding an output or outcome field to Work.

Use this when. Use this pattern when a plan, method description, schedule, log, telemetry stream, dashboard, approval-looking cue, publication face, result statement, or evidence-provenance relation is being treated as if it were performed work. U.Work is the admitted kind; one Work individual is the world-side occurrence. A separate assertion or description episteme may designate that occurrence and its obtaining relations, while surrounding records may constrain, evidence, schedule, publish, or judge it; none becomes the occurrence by being published.

First useful object. One independently identified world-side dated Work occurrence admitted under U.Work. When the receiving use needs an assertion or description, keep that object as a separate U.Episteme: let it designate the occurrence and state the admitted holder U.System that actually performed it, the exact obtaining U.RoleAssignment under which that system performed it, and, when explicit attribution identity is consumed, the F.6 attribution relation linking the Work occurrence to that assignment. State actual enactsMethod -> U.Method, temporal extent, and executedWithin -> U.System. Add a direct work-to-referent relation, binding, or resource-use relation only when it actually obtains and the receiving claim uses it. If the next sentence reports a result, change, production, delivery, or judgment, use the matching §4.6 row; do not make it a Work field.

First-use checks.

1. Name the candidate occurrence and the work-facing claim that depends on it.
2. Recover every admitted U.System that actually performed the occurrence and the exact obtaining U.RoleAssignment under which each system performed it; then recover the enacted U.Method, temporal extent, and accountable or containing U.System. Add only the concrete bindings, performed resource-use facts, and direct work-to-referent relations that actually obtain and matter to the receiving use. Route any claimed result, change, production, delivery, evidence use, or judgment through the one matching §4.6 row.
3. Decide whether the encountered record, trace, item, or display designates a Work individual admitted under U.Work, only a plan (A.15.2), only a method (A.3.1), only a method description (A.3.2), only evidence for work (A.10), only a publication-use relation (E.17), only a declarative representation (C.2.P.DR or the direct representation pattern), or an A.15.4 appearance-based reliance repair case.
4. For composite, repeated, interrupted, or overlapping occurrences, declare each work-part relation and the naming threshold. Before using totals, recover the exact B.1.4 temporal aggregation or B.1.6 work-resource aggregation and its policy. Do not name a work part when a temporal relation, evidence slice, telemetry segment, or missing-source-relation note is the actual object needed.
5. If the required occurrence references cannot be recovered, lower the claim to a missing-source-relation note, work-evidence note, plan note, publication-use note, declarative-representation note, or A.15.4 repair request; do not backdate work.

Ordinary use. For a simple occurrence, one readable assertion naming the actual performer system, the covering assignment under which it performed, enacted method, temporal extent, and containing system is enough. Add a binding, used resource, or work-to-referent fact only when the assertion relies on that obtaining relation.

Work-versus-transformation probe. Use the coarsest branch that the current facts support.

• Change without Work: LunarTideRise-2026-07-27 may be identified under A.3.4 as a transformation of the exact water body over the stated interval. Without an independently admitted performer U.System, its covering U.RoleAssignment, an enacted U.Method, and F.6 work attribution, it is not a Work occurrence. A causal explanation of the tide supplies none of those agency facts.
• Self-directed Work: in the rehabilitation case, the current model admits MotorControlRightArmSystem-7 : U.System and Person-7 : U.System; A.14 ComponentOf(MotorControlRightArmSystem-7, Person-7) and ComponentOf(LeftArm-7, Person-7) obtain, so the mover and the affected limb are distinct parts of one person. MotorControlRightArmSystem-7 performs LeftArmStretchWork-7 from 2026-07-27T07:30:00+03:00 to 2026-07-27T07:35:00+03:00 under SelfCarePerformerAssignment-7; F.6 performedUnderAssignment obtains, the Work enacts AssistedLeftArmStretchMethod-E1, and executedWithin -> Person-7 obtains. Clinic relation specification ClinicRehabRelations@Clinic-E1 declares RehabWorkStretchesLimb@Clinic-E1(work, limb, interval), and the case facts make it obtain for that Work, LeftArm-7, and the five-minute interval. Separately, A.6.1 application AssistedStretchApplication-7 binds its declared AffectedLimbArgument to LeftArm-7. The first fact relates the Work to the limb; the second fills an operation argument. Neither is a primitive self-relation, and this case-specific decomposition is not a required anatomy for every self-directed action.

These branches test admitted facts, not human resemblance. A non-human or molecular-scale system can perform Work when its own system admission, covering assignment, enacted method, extent, containing system, and attribution obtain; unfamiliar agency is not a reason to reject it.

Reliance-bearing use. Add only the exact neighboring claims on which cost, quality, audit, evidence, conformance, gate, release, measurement, model use, or aggregation currently depends; do not turn them into fields of the work occurrence.

Stop condition. Stop once the occurrence is either recoverable as one Work individual admitted under U.Work at the needed granularity or lowered to a neighboring relation that no longer claims performed work.

What goes wrong if missed. Teams count plans, method descriptions, approval-looking cues, dashboards, telemetry, or evidence records as if work already happened, then attach cost, responsibility, quality, or result claims to the wrong EntityOfConcern.

What this buys. One dated occurrence identity whose actual performer systems, covering assignments, enacted method, temporal extent, and containing system remain inspectable, together with any actually obtaining work-to-referent, binding, and resource-use relations used by the claim. A practitioner can then report a result or consequence through the concrete §4.6 branch without turning it into Work identity.

Not this pattern when. Not this pattern when the current claim is only a method (A.3.1), only a method description (A.3.2), only a plan or schedule (A.15.2), only declaration-local SlotFillingsPlanItem content inside an A.15.3-governed WorkPlan, only work-entry readiness or full-kit preparation before work entry (A.15.5), only a visible cue that needs A.15.4 appearance-based reliance repair before reliance, only evidence or assurance (A.10 or B.3), only publication-use behavior (E.17), or only a declarative representation overread as a work-control or method claim (C.2.P.DR or the direct representation pattern).

After we have separated who is assigned (via U.RoleAssignment), what capability is being relied on (via U.Capability), how in principle the work is done (the exact U.Method), and which claim-bearing episteme, if one is selected, describes that method (U.MethodDescription), we still need a precise concept for what happened as performed work in real time and space.

#Aliases

• U.Work

#Keywords

• admitted U.Work kind
• world-side dated occurrence
• actual performer U.System
• covering U.RoleAssignment
• performedUnderAssignment
• enacted method
• temporal extent
• containing system
• optional direct bindings and resource use
• separate result or consequence.

#Relations

#Content

#Problem Frame

After we have separated who is assigned (via U.RoleAssignment), what capability is being relied on (via U.Capability), how in principle the work is done (the exact U.Method), and which claim-bearing episteme, if one is selected, describes that method (U.MethodDescription), we still need a precise concept for what happened as performed work in real time and space.

Every Work individual has actual performer-system, covering-assignment, enacted-method, temporal, and containing-system facts. It stands in a direct work-to-referent, binding, or resource-use relation only when that relation obtains world-side; none is a field stored in the occurrence. A separate assertion or description may designate that individual and state the relations, but the episteme neither creates the relations nor becomes the Work occurrence.

#Problem (what breaks without a clean notion of Work)

1. Plan and occurrence confusion. Schedules and diagrams get mistaken for performed work, so audits and KPIs attach to plans or representations instead of dated occurrences.
2. Method-description and work conflation. A method description, code artifact, or SOP is reported as if it were performed work; conversely, logs are treated as recipes.
3. Who and when leakage. People and calendars are baked into method descriptions; reuse and staffing agility collapse.
4. Resource dishonesty. Energy, money, and tool wear are represented as fields or booked to methods or roles instead of being stated through separately obtaining resource-use relations involving exact Work individuals; costing and sustainability measures drift.
5. Mereology muddle. Teams hand-wave over work parts, retries, overlaps, or long-running episodes; roll-ups double-count or miss work.

#Forces (what the definition must balance)

#Solution — admit accountable dated Work occurrences under U.Work

#Definition and occurrence identity

U.Work is the admitted U-kind for dated 4D occurrence holons. One Work individual is one independently identified world-side dated performed occurrence with its own governed temporal extent. The actual performer is an admitted U.System. For every performer, recover the exact obtaining U.RoleAssignment whose HolderSystemSlot resolves to that system, whose role interpretation is current, and whose occurrence covers the work or the exact attributed work part. The system acts; the assignment is the world-side relation under which the attribution holds, and it neither acts nor enacts a method.

The canonical F.6 relation performedUnderAssignment(W, RA) attributes one exact Work occurrence to one exact assignment occurrence. For an obtaining attribution, its actual-performer projection is S = RA.HolderSystemSlot; the relation obtains only when admitted system S actually performed W under RA and RA covers the attributed extent. In practitioner prose name both objects: S performed W under RA. The legacy spelling performedBy(W, RA) is a deprecated compatibility alias only; do not author new claims with it, and never say that RA performed W.

An exact enactsMethod relation connects the Work individual to an exact U.Method, and one exact executedWithin relation names its containing U.System. Direct work-to-referent, binding, and performed resource-use relations are recovered independently only when they obtain and the current claim needs them. An occurrence designator permits reference but does not identify work by label, ticket, trace, record, or storage convention; an assertion or description about the occurrence is a separate U.Episteme.

The actual enactsMethod relation obtains between the Work occurrence and the exact U.Method; it is not a field of either participant. An exact U.MethodDescription may be cited when its claims identify, constrain, or justify that method for the receiving use; the description is not enacted and its fields do not become actual work bindings. A selected model-use structure likewise enters only through the exact receiving relation whose interpretation it changes.

Call a selected method description, continuity policy, or criterion an edition only when an exact C.2.1 EpistemeEditionRelation connects it to the earlier episteme and obtains. Otherwise name the selected episteme, or say that one episteme is a non-continuing replacement for another.

If the receiving sentence says that a referent changed, identify one exact U.Transformation independently under A.3.4. If a declared domain predicate relates exact Work W and transformation T, name that predicate, its participant order, and the facts that make it obtain. If no one direct predicate suffices but a one-case compound claim does, use A.6.RCD disposition 2 only when the substrate-admitted constructor, governed base predicates, actual participants, and case facts are recoverable; the result is C.2.1 claim content, not a relation kind or occurrence. Otherwise retain W and T separately and return missing-governor[work-to-change], or A.6.RCD's missing-substrate result when the proposed constructor itself has no current semantics. Shared time, referent, or wording connects neither object. A morphism, delta expression, state-plane trace, pre-state, or post-state may represent or support the neighboring change claim; none is a Work field or identity discriminator.

Memory aid: Work = “how it went this time” (dated, resourced, accountable).

#Core occurrence references and neighboring links

When a separate assertion or description episteme describes one Work occurrence, recover the following content at the granularity required by the current use. Each item names an occurrence designator, a world-side relation or temporal fact, or a reference to another episteme; the list is not a slot or field schema for the Work individual:

1. Occurrence and extent — one occurrence designator plus exact start and end, or an explicitly open end for in-flight work; add location only when the work claim depends on it.
2. Performer system and assignment — name each admitted holder U.System that actually performed the occurrence and the exact obtaining U.RoleAssignment under which it performed. Verify that the assignment's HolderSystemSlot resolves to that same system and recover its role value, role-taxonomy episteme, effective reference scheme, obtaining condition, and extent under A.2.1. When explicit F.6 attribution identity is used, performedUnderAssignment(W, RA) cites RA as the assignment ground; the actual performer remains its holder system.
3. Enacted method — actual enactsMethod -> U.Method. Cite methodDescriptionRef -> U.MethodDescription only when the receiving claim depends on that exact description episteme; the description is not enacted.
4. Containing system — executedWithin -> U.System; if ordinary speech says subsystem, name that U.System and its exact part relation to the larger holon.
5. Work-to-referent relation used by the claim — name the declared domain predicate, its participant order, and the actual Work and referent participants only when that predicate obtains and the receiving claim uses it. "Work on X", shared timing, a record mention, or a convenient affected field establishes no such relation. If the use needs the relation but no predicate governs it, keep the Work and referent and return missing-governor[work-to-referent]. An obtaining work-to-referent fact does not by itself assert change, production, delivery, or acceptance.
6. Actual participation and bindings — for an operation argument or result, name one identified A.6.1 application and its exact declaration-local binding. For another participant, parameter, supplied constituent, premise, or reference use, name the declared subject predicate, participant order, and actual values. If the required route is absent, name the missing relation or binding in the missing-governor result rather than asserting it. A MethodDescription field, plan row, type-compatible value, or log token establishes none of them.
7. Performed resource use — name the declared resource-use predicate and its actual Work, resource, amount, unit, and extent participants at the boundary needed by costing or sustainability use. If no predicate governs the needed use, return missing-governor[resource-use]; do not infer use from colocation, timing, or a plan estimate.
8. Continuity policy for an unresolved segmentation — when a named identity, episode, retry, resumption, or aggregation use has more than one defensible segmentation, cite workContinuityPolicyRef to the exact C.2.1 episteme whose claims state the branch criterion and tolerances for that use, and interpret those claims under its effective U.ReferenceScheme. If the criterion or its applicability cannot be recovered, leave that segmentation unresolved. The episteme is a U.MethodDescription only if it independently satisfies A.3.2's method-description criterion. A simple uninterrupted occurrence needs no continuity-policy reference; the policy supports a judgment about the occurrence and neither constitutes nor rewrites it.
9. Work mereology and temporal relations — exact parent, part, predecessor, successor, overlap, retry, or resumption relations only when their predicates obtain.
10. Actual change and production claims — identify each actual transformation independently under A.3.4; connect it to Work only through a declared domain predicate with its exact Work and transformation participants or a filled A.6.RCD disposition-2 claim with recoverable constructor, base predicates, participants, and case facts. Otherwise return missing-governor[work-to-change]. Keep the current A.15.PROD production-work, entity-identity-inception, and production-completion claims separate. None follows from work identity or parthood.
11. Evaluation and downstream claims — use the one matching §4.6 row for evaluation work and result, evidence use, delivery or transfer, and acceptance; omit every row that is not current.
12. Evidence, publication, and model use — cite only the exact evidence-use, publication-use, currentness, claim-scope, reference-plane, bridge, or selected model-use relation needed by the receiving claim.

#Clear distinctions (the four‑slot grammar in action)

#Publication-use boundary for U.Work

A publication about one Work occurrence projects an already declared assertion or description episteme; it does not create the world-side occurrence, add performed-occurrence facts, or make a plan, source reconstruction, dashboard, publication face, or carrier count as performed work.

Preparation is classifiable as one Work individual under U.Work only after it actually occurs and the actual performer U.System, its covering U.RoleAssignment and F.6 attribution when explicit, the exact enactsMethod, temporal extent, and executedWithin relation obtain independently. Add a work-to-referent, binding, or resource-use fact only through its own obtaining relation when the receiving preparation claim needs it. The readiness relation that asks whether intended work is ready enough to enter a work boundary is WorkEntryReadiness@Context under A.15.5; a readiness label, full-kit checklist, or launch-looking cue is not a performed occurrence.

#Crossing visibility for work publications

When a work publication relies on another selected method-description episteme, name that episteme and the relation the publication actually uses; do not infer an edition from a version label or later date. For a semantic crossing, name the two F.17 sense cells and test the F.9 Bridge predicate profile, then state the proposed action, direction, rule, and tolerated loss in a separate C.2.1 bounded-use claim. For a reference-scheme, claim-scope, model-use, reference-plane, unit, or publication change, cite the direct relation that the publication actually uses. A.10 or B.3 owns reliance on the bounded-use claim and any penalty; none of these facts changes the Work occurrence's identity.

A planned, gate-selected, or launch-labelled value becomes actual only when a named direct predicate with its actual participants obtains, or when an exact A.6.1 operation-application binding connects one identified application to that value. If neither the predicate nor the binding is present, keep the value planned and return missing-governor[actual-use]. Do not back-fill a plan or infer an actual binding from shared wording. Pre-state and post-state references remain with an independently governed transformation or comparison claim; bracketing the Work interval does not bind them to the occurrence.

#Route a result or consequence without folding it into Work

Start with the ordinary sentence the reader needs, then select exactly one row for each separate claim. An absent row stays absent; the table is not a result record to fill.

Three-question result check. (1) Did the work occur? Name W and its performer, assignment, method, time, and containing system. (2) What separate result or consequence is claimed? Name the exact returned value, entity, change, production claim, or transfer and use its row above. (3) Who judged or accepted what, by which criterion and evidence? Name the evaluation work, result, evidence relation, and acceptance relation separately. If the reader needs only the first or first two answers, stop there.

#Work mereology (how occurrences form holarchies)

Work identity is occurrence-grounded and 4D. Start from the actual performance history: work-entry and end events, occupied spatiotemporal extent, performer systems and assignments, enacted method, containing system, any direct work-to-referent relations, actual bindings, resource use, and exact work-part or temporal relations. A distinct actual work-entry after an established completion or termination identifies a later occurrence; a proper work part and its parent are distinct individuals; independently grounded concurrent performances are distinct. A record, trace, policy episteme, or later judgment creates none of them. A continuity policy is needed only when a named use must decide how to group that already existing history across an interruption, resumption, mode or method switch, performer replacement, referent or binding change, or composite boundary.

#Parts and wholes of Work (occurrence facts)

• Temporal-part (TemporalPartOf_work). A proper time-slice relation over one selected Work occurrence or work phase. The selected part is grounded by parent work identity plus interval and, when needed, a named aspect such as resource use, telemetry, SLA coverage, or interval-local evidence. A temporal part is useful for monitoring, utilization, lead time, and interval-local evidence. It has no independent method-switch identity by that fact.
• Episode-part (EpisodeOf_work). A named, event-bounded fragment selected inside one parent Work occurrence because a named use needs that fragment. Entry, resumption, mode switch, switch-to-method, interruption, switch-away, completion, or a declared pause may supply the candidate boundary. The direct episode predicate also cites an exact workContinuityPolicyRef only when the use needs that policy to decide whether the fragment remains under the parent; timestamps or an episode-looking label alone establish no episode relation.

workContinuityPolicyRef designates the exact C.2.1 episteme whose claims state the named use, boundary events, tolerated variation, and branch criterion. Interpret those claims under that episteme's effective U.ReferenceScheme. Add a U.ClaimScope, temporal qualification window, or model-use structure only when changing it changes the segmentation assertion; otherwise omit it. The policy episteme classifies the already existing history for that use. A later or competing policy episteme can support another identity or segmentation assertion. Call it an edition only when an exact C.2.1 EpistemeEditionRelation obtains between the exact earlier and later epistemes; without that relation it is a non-continuing replacement. Either way, the policy neither becomes a U.MethodDescription by policy form nor changes the occurrence, its parts, or their actual facts.

• Operational-part (OperationalPartOf_work). A work-part occurrence that may enact a factor of a recovered U.Method, for example, an incision occurrence within an appendectomy occurrence, possibly overlapping with others in time. If a method-description reference is used, it identifies, describes, constrains, or evidences that method factor; the referenced U.MethodDescription is not enacted. If no U.Method factor is recovered, keep the material as the work part, evidence segment, telemetry segment, mechanism material, system-component behavior, or missing-source-relation note that was actually identified; do not infer a method factor from its label.
• Concurrent work parts (derived use-side reading; no fourth parthood relation). First state each exact work-part relation to the same parent and then state the independently governed interval overlaps fact. If a claim also says that the parts were coordinated, name its declared coordination predicate and actual participants. Shared parentage and overlap do not by themselves establish coordination, and ConcurrentPartOf_work is not introduced as a primitive work-part relation.

Naming threshold. Do not mint a durable public U-kind, durable named work object, or separate work occurrence for every interval, telemetry segment, pause, or episode-looking wording. Use a derivative part relation unless the downstream use needs a named work part with its own resources, evidence, KPI, acceptance, repair, aggregation, cross-context reliance, or source-relation return use. Otherwise keep the temporal relation, evidence slice, telemetry segment, method-description constituent, missing-source-relation note, or other concrete neighboring object that the task actually needs.

Didactic rule: Method composition is not proof of Work decomposition, and Work decomposition is not proof of method composition. A temporal work part may enact the same whole method during a slice. An episode may continue one method or mode, span several operational parts, repeat the same method fragment, or be split by evidence policy without changing method identity. An operational part may correspond to a method factor only when that factor is recovered as U.Method.

Quick choice test.

• Ask "which interval or aspect of the parent work do I need?" If that is enough, use TemporalPartOf_work.
• Ask "does this named use need an event-bounded fragment of the parent?" If yes, recover the candidate boundary events. Cite workContinuityPolicyRef only when interruption, resumption, switch, replacement, or pause leaves the grouping ambiguous for that use; then use EpisodeOf_work only when its direct predicate is satisfied.
• Ask "which performed sub-occurrence has its own actual performer system, covering assignment, temporal extent, enacted method, affected referent, bindings, resource use, or aggregation role?" If that is current, use OperationalPartOf_work or another declared work-part relation. A neighboring evaluation or effect claim does not establish work parthood by itself.
• Ask "which way-of-doing part is being composed?" If the answer needs preconditions, effects, interface, and whole-method relation, recover a U.Method submethod under A.3.1 and B.1.5; do not make the work part itself carry the method identity.

#Key relations among Work

• precedes or happensBefore — strict partial order on Work windows.
• overlaps — intervals intersect but neither contains the other.
• contains or within — one Work's window contains another's.
• Causal-use relation reference — if one work occurrence is claimed to explain, trigger, or cause another, keep the work-occurrence link separate from the causal-use claim governed by C.28 or another causal-use pattern named by value.
• retryOf — a later Work occurrence that starts after the earlier occurrence ended and re-attempts the same named objective or enacted Method under the exact predicate of the retry relation. Similar wording or revised bindings alone do not establish the link.
• resumptionOf — an event-bounded episode or later Work occurrence that continues after interruption. Cite a continuity policy only when the named use must decide whether the later performance remains under the same parent or is a distinct occurrence linked to the earlier one.

These relations are occurrence facts, not method-design assumptions.

#Work-occurrence relations used by Part B roll-ups

A.15.1 supplies the identity of each independently identified Work occurrence or Work part and makes its exact temporal and performed resource-use relations recoverable. It does not itself return a temporal aggregate or resource ledger.

• Temporal coverage. When a receiving use needs utilization, elapsed time, phase coverage, or another roll-up over Work intervals, open B.1.4. Its recovered ContextTemporalAggregation@Context, coverage and non-overlap conditions, aggregation policy, and optional Gamma_time notation govern union, hull, or another admitted temporal aggregate. The work intervals remain A.15.1 facts.
• Resource aggregation. When a receiving use needs a total over materials, energy, time, money, tool wear, or another performed resource value, open B.1.6. Its recovered WorkResourceAggregation@Context, typed resource-accounting basis, evidence refs, overlap or deduplication policy, ledger, aggregation rule, and optional Gamma_work notation govern the aggregate. Each contributing performed resource-use relation obtains separately with its exact Work occurrence as a participant; any ledger or assertion about that relation is a separate episteme.

Manager's tip: cite the exact B.1.4 or B.1.6 aggregation result and policy beside the KPI. A Work-part list, shared parent, or operator spelling supplies neither the aggregate nor its policy.

#Identity and reidentification of Work

Two descriptions, assertions, records, or traces resolve to the same Work occurrence only when they designate the same actual world-side performance history, not merely the same name, policy label, similar policy content, or later date. First compare the direct facts at the selected grain:

• the same actual work-entry or start and compatible occupied spatiotemporal extent;
• the same performance history, with each performer system, covering assignment, enacted method, and containing system, plus every actually obtaining work-to-referent, binding, and resource-use fact used by the identity claim, placed at the interval where it obtains;
• compatible work-part and temporal relations; and
• no fact that already identifies distinct individuals: a proper part versus its parent, independently grounded concurrent performances, or a later work-entry after the first occurrence's established completion or termination.

A corrected or later description of the same actual start, open end, or completed end can refine the assertion without changing the occurrence. A change of performer, assignment, method, referent, binding, resource use, or containing system during an otherwise unended performance history is an actual change to state explicitly; that change alone neither splits nor preserves the Work occurrence.

When a named receiving use must decide whether an interruption, resumption, method or mode switch, performer replacement, retune, rework, referent or binding change, or composite boundary stays inside one parent, cite the exact continuity-policy episteme, its effective reference scheme, applicable scope and window, and the branch criterion it applies to those facts. The selected policy can support one identity or segmentation assertion for that use. A later or competing policy episteme may support another assertion; call it a later edition only when the exact C.2.1 EpistemeEditionRelation obtains, and otherwise treat it as a non-continuing replacement. Neither branch retroactively changes what occurred.

#Interruptions, retries, resumptions, and description changes

• Established end and later entry: identify a later Work occurrence when the first occurrence has actually completed or terminated and another work-entry occurs. A larger composite Work may contain both only through explicit work-part relations.
• Retry: identify the later Work occurrence independently and add retryOf only when that relation's own predicate connects it to the ended attempt.
• Ambiguous interruption or resumption: preserve the actual boundary events and facts. If a named use must decide same-parent versus separate-occurrence grouping, apply its exact workContinuityPolicyRef; without that criterion, return an unresolved segmentation rather than making the policy implicit.
• Performer, assignment, method, referent, binding, retune, or mode change: state the actual change where it occurs. Split or retain the parent only when the direct facts already decide the boundary or a policy current to the named identity, episode, retry, resumption, or aggregation use supplies the criterion.
• Method-description episteme change: record the newly selected description episteme separately. That selection neither splits nor preserves Work by itself; only an accompanying actual occurrence change enters the boundary judgment. Call the two descriptions editions only when their exact C.2.1 EpistemeEditionRelation obtains.
• Rework: identify the later performance independently. Relate it as another occurrence, episode, or operational part only after the applicable direct predicate and any genuinely needed boundary policy are satisfied. Keep causal attribution with the governing causal-use pattern.

Plans, costs, quality statistics, telemetry evidence, and method-reliance claims may depend on whether the selected history is a temporal part, event-bounded episode, operational part, or later occurrence. Name a continuity-policy episteme, effective reference scheme, scope, and qualification window only when that distinction is actually current. Otherwise retain the direct occurrence facts and stop; do not add policy apparatus to a simple uninterrupted case.

#Work mereology does not compose effects or transformations

A parent Work can have exact work parts without having one composite effect or composite transformation. Any temporal aggregate uses B.1.4; any performed-resource aggregate uses B.1.6; each names its own concern, policy, evidence, and result. Identify every actual transformation independently under A.3.4. Connect one to Work only through a named domain predicate and exact participants, or a C.2.1 local compound claim under A.6.RCD disposition 2 with its constructor, governed bases, participants, and case facts recoverable; otherwise return missing-governor[work-to-change].

Work parthood, method parthood, temporal inclusion, a common affected referent, a list of changed characteristics, or adjacent plan items establishes neither transformation parthood nor a composite transformation. If a production or effect claim needs transformation composition, name the declared composition predicate, its participants, and the facts that make it obtain. If none is available, retain the exact Work and independently identified transformations and return missing-governor[transformation-composition]. A.15.PROD may still recover any independent production-work, entity-inception, or completion claim that does not depend on that missing composition.

#Archetypal grounding (parallel domains)

Each case below is presented as readable content of a separate assertion or description episteme. Arrow notation abbreviates independently obtaining world-side relations involving the named Work individual; methodDescriptionRef and continuity-policy references cite separate epistemes. The bullet layout declares no slots or fields on the Work individual.

#Surgical case (overlap and episodes)

• Top work occurrence: Appendectomy_Case_2025-08-10T0905_1142.
• Actual method and containing system: enactsMethod -> Appendectomy@Hospital-2025; executedWithin -> SurgicalService_A.
• Patient and administered dose: project relation specification MED-ADM-2026, owned by ClinicalAdministrationRelations@Hospital-8472, declares ClinicalWorkAdministersDoseToPatient(dose, patient, clinicalWork, interval). The stipulated administration facts make it obtain for MedicineDose_8472, Patient_8472, Appendectomy_Case_2025-08-10T0905_1142, and the surgery interval. This relation establishes only that administration claim. The case names no admitted predicates for theatre, consumables, or staff-time resource use, so those optional claims return missing-governor[SURGERY-RESOURCE-USE] and do not enter Work identity.
• methodDescriptionRef: Appendectomy_v5.
• Performer system and assignment: admitted system OR_Team_A performs this occurrence under exact OR_Team_A_SurgicalTeamAssignment_2025-08-10 : U.RoleAssignment, whose role value is SurgicalTeamRole, role-taxonomy episteme is HospitalRoles-2025, effective reference scheme is Hospital-Operating-Scheme-2025, and obtaining extent covers the surgery interval. The team system acts; the assignment does not.
• Operational parts: Incision (09:15–09:22), Exploration (overlaps with monitoring), Closure (11:10–11:35).
• Episode: a brief power dip occurs from 10:02 to 10:07. The named surgery-continuity use applies HospitalWorkContinuityPolicy_2025, a C.2.1 policy episteme interpreted under Hospital-Operating-Scheme-2025; its stated pause-and-resumption criterion keeps both event-bounded fragments under the same parent Work. The power dip alone would not decide that grouping.
• B.1.4 temporal roll-up: SurgeryORUtilizationAggregation-8472 uses union under ORUtilizationUnionPolicy-2025; SurgeryPatientLeadTimeAggregation-8472 uses hull under PatientLeadTimeHullPolicy-2025. Both consume the named surgery and part intervals; neither supplies a resource-use or acceptance relation.
• B.1.6 resource roll-up: no positive aggregate is asserted in this fixture because the direct theatre-, consumables-, and staff-time resource-use predicates are absent. Preserve the Work and the administration relation and return missing-governor[SURGERY-RESOURCE-USE]; open B.1.6 only after the project declares those predicates and supplies their actual participants and facts.

#ETL pipeline (parallelism and retries)

• Top work occurrence: ETL_Nightly_2025-08-11T01:00-01:47.
• Actual method and containing system: enactsMethod -> Nightly_ETL_Load@DataOps-2025; executedWithin -> DataPlatform_Prod.
• Dataset participation; resource stop: relation specification ETL-DATA-REL-2025, owned by ETLDataUseRelations@WarehousePlatform, declares SourceDatasetParticipatesInETLWork(dataset, work, extent) and DestinationDatasetParticipatesInETLWork(dataset, work, extent). The stipulated job facts make the first obtain for RawOrders_2025-08-11, ETL_Nightly_2025-08-11T01:00-01:47, and its extent, and the second for WarehouseOrders_2025-08-11 with the same Work and extent. Neither predicate means later analytics use or dataset transformation. The case names no direct cluster-time or storage-use predicate, so those optional claims return missing-governor[ETL-RESOURCE-USE].
• Actual change, no connection yet: A.3.4 identifies WarehouseOrders_LoadTransformation_2025-08-11 as the bounded change of the exact dated warehouse partition across 01:00–01:47 under the declared source-snapshot and partition-write conditions. Before that boundary the partition lacks AcceptedOrdersRowSet_2025-08-11; after it, the project data-state relation to that row set obtains. This fixture declares neither a direct W-to-T predicate nor a complete A.6.RCD disposition-2 claim with a constructor, governed base predicates, participants, and case facts, so it returns missing-governor[ETL-WORK-TO-CHANGE]. Keep the Work, transformation, and dataset-participation facts; shared time, destination label, and post-state do not connect W to T.
• Performer system and assignment: admitted system ETL_Runtime performs this occurrence under exact ETL_Runtime_TransformerAssignment_2025-08-11 : U.RoleAssignment, whose role value is TransformerRole, role-taxonomy episteme is DataOpsRoles-2025, effective reference scheme is DataOps-Execution-Scheme-2025, and obtaining extent covers the ETL interval. The runtime system acts; the assignment does not.
• Parallel parts: Extract_A ‖ Extract_B; Transform starts when either completes (overlap).
• Retry: WarehouseWrite failed at 01:36; retried with batch size ↓ — new Work linked via retryOf.
• B.1.4 temporal roll-up: ETLSLACoverageAggregation-2025 uses hull under ETLSLAHullPolicy-2025; ETLClusterUtilizationAggregation-2025 uses union under ETLClusterUnionPolicy-2025. They consume the named Work-part intervals and do not establish dataset participation, resource use, or change.
• B.1.6 resource roll-up: no compute or storage aggregate is asserted until the ETL project declares cluster-time and storage-use predicates and supplies the exact Work, resource, value, unit, and extent participants. Until then return missing-governor[ETL-RESOURCE-USE]; the two dataset-participation relations remain valid.

#Thermodynamic cycle (work through a state-plane trace)

• Run: Carnot_Cycle_Run_2025-08-09T1300_1306.
• Actual method and containing system: enactsMethod -> Carnot_Cycle_Operation@ThermoLab; executedWithin -> LabRig_7.
• Referent and energy-use stop: this fixture supplies no admitted predicate relating the run to WorkingFluidCharge_7 and no direct predicate for electrical-energy use through HeaterBank_7 or Chiller_7. Keep the grounded Work occurrence and return missing-governor[THERMO-REFERENT-AND-ENERGY-USE] for those optional claims. A state-plane trace, shared interval, or equipment label cannot fill the missing predicates.
• methodDescriptionRef: Carnot_Cycle_Spec with Dynamics model.
• Performer system and assignment: admitted system LabRig_7 performs this occurrence under exact LabRig_7_TransformerAssignment_2025-08-09 : U.RoleAssignment, whose role value is TransformerRole, role-taxonomy episteme is ThermoLabRoles-v2, effective reference scheme is ThermoLab-Experiment-Scheme, and obtaining extent covers the laboratory-work interval. The rig system acts; the assignment does not.
• Work identity: this uninterrupted six-minute run is identified from its actual entry, extent, performer system, covering assignment and F.6 attribution when explicit, enacted method, and containing system. No continuity-policy reference is needed because no interruption or competing segmentation is current. The optional referent and energy-use claims remain at missing-governor[THERMO-REFERENT-AND-ENERGY-USE]. The thermodynamic state-plane trace separately describes or evidences actual change; it is not a Work field, control relation, or instruction sequence.
• Part B roll-ups: no B.1.4 temporal aggregate is asserted in this fixture. A later roll-up must name this Work ref, the aggregation concern, window, coverage and non-overlap conditions, and the exact policy selecting union, hull, or another admitted result; the run interval alone is insufficient. B.1.6 cannot aggregate energy use until the missing direct energy-use predicate and participants are supplied. Any thermodynamic transformation remains independently grounded under A.3.4 and needs its own named W-to-T route before connection to this Work.

#Claim handling (episodes versus monitoring slices)

• Top work occurrence: ClaimHandling_Case_8142_2026-06-03.
• Actual method and containing system: enactsMethod -> ClaimHandling@InsuranceOps-2026; executedWithin -> ClaimsOperations_A.
• Claim and resource stop: this fixture names Claim_8142, handler-time intervals, and ClaimsPlatform_A, but supplies no admitted Work-to-claim, handler-time-use, or case-system-time-use predicate. Keep the grounded claim-handling Work and return missing-governor[CLAIM-REFERENT-AND-RESOURCE-USE] for those optional relations. Callback and monitoring records remain neighboring evidence or telemetry, not occurrence constituents.
• methodDescriptionRef: Claims_Method_v7.
• Performer system and assignment: admitted system ClaimsTeam_A performs this occurrence under exact ClaimsTeam_A_HandlerAssignment_2026-06-03 : U.RoleAssignment, whose role value is ClaimsHandlerRole, role-taxonomy episteme is InsuranceOpsRoles-2026, effective reference scheme is Claims-Handling-Scheme-2026, and obtaining extent covers the claims-work interval. The team system acts; the assignment does not.
• Episode policy: the named claims-handling continuity use applies ClaimsWorkContinuityPolicy_v7, a C.2.1 policy episteme interpreted under Claims-Handling-Scheme-2026. Its stated under-one-hour callback criterion supports assertion ClaimsSegmentation-v7-8142: InitialReview_09:00-09:42 and ResumedResolution_10:11-10:38 are two EpisodeOf_work fragments under the same parent.
• Nearest non-continuing replacement: competing episteme ClaimsWorkContinuityPolicy_15min-Alt, interpreted under the same reference scheme, states a fifteen-minute callback threshold. Applied to the same 29-minute gap, it supports assertion ClaimsSegmentation-15min-8142 that the resumed performance is a later Work occurrence rather than an episode under the first parent. No EpistemeEditionRelation between the exact v7 and 15-minute policy epistemes is established, so the second is a non-continuing replacement, not an edition. Either assertion may govern its named receiving use; switching the selected policy changes the use-local segmentation judgment, not either interval's actual history. Only if C.2.1's historical-continuation predicate is separately satisfied may the later policy be called an edition.
• Temporal monitoring slice: MonitoringSlice_09:15-09:20 is TemporalPartOf_work for queue-latency evidence. It is not a new work occurrence and not an episode unless downstream reliance needs a named part with its own evidence, KPI, acceptance, repair, or aggregation role.
• Method relation: under ClaimsSegmentation-v7-8142, both episodes enact the same claim-handling method; under ClaimsSegmentation-15min-8142, each of the two Work occurrences enacts that method. The segmentation choice changes neither enactment fact. The five-minute slice does not prove a submethod.

#Internal-combustion engine (cycle parts without human-only boundary language)

• Top work occurrence: EngineRun_Cell7_2026-06-03T1300_1330.
• Actual method and containing system: enactsMethod -> FourStrokeEngineOperation@TestBench-2026; executedWithin -> Engine_Cell7.
• Engine and resource stop: this fixture supplies no admitted Work-to-engine, fuel-use, or ignition-energy-use predicate for EngineUnderTest_7, FuelBatch_F7, and the 13:00–13:30 run. Keep the grounded engine-cell Work and return missing-governor[ENGINE-REFERENT-AND-RESOURCE-USE]; a test-bench label or shared interval establishes none of those optional relations.
• methodDescriptionRef: FourStrokeOperationSpec_v4.
• Performer system and assignment: admitted system Engine_Cell7 performs this occurrence under exact Engine_Cell7_OperationAssignment_2026-06-03 : U.RoleAssignment, whose role value is EngineOperationRole, role-taxonomy episteme is EngineCellRoles-2026, effective reference scheme is TestBench-Operating-Scheme-2026, and obtaining extent covers the engine-run interval. The engine-cell system acts; the assignment does not.
• Episodes: when diagnosis or utilization needs event-bounded fragments, EngineRunEpisodePolicy_2026, a C.2.1 policy episteme under TestBench-Operating-Scheme-2026, states which start, stop, mode-change, fuel, ignition, or diagnostic events bound an EpisodeOf_work. Without that named use and branch criterion, the events remain direct history and do not mint episode objects.
• Temporal parts: crank-angle intervals or one-second telemetry windows are TemporalPartOf_work unless an exact receiving use requires a named work part for resource, evidence, KPI, acceptance, repair, or aggregation.
• Method factors: intake, compression, combustion-expansion, and exhaust are method factors only if recovered as U.Method submethods with method-level preconditions, effects, interfaces, and whole-method relation. Actual strokes are work parts or temporal parts of engine work, not submethods by label.

#Detector radio receiver (component behavior, method factor, work part)

• Top work occurrence: ReceiverReception_Rx42_2026-06-03T2115_2120.
• Actual method and containing system: enactsMethod -> EnvelopeDetection@RadioLab-2026; executedWithin -> Receiver_Rx42.
• Signal and resource stop: this fixture supplies no admitted Work-to-signal, receiver-channel-time-use, or electrical-energy-use predicate for RF_TestSignal_42_2115, Rx42_Channel_1, and the 21:15–21:20 reception. Keep the grounded receiver Work and return missing-governor[RECEIVER-REFERENT-AND-RESOURCE-USE]; waveform and telemetry traces remain representations or evidence.
• methodDescriptionRef: EnvelopeDetectionMethod_v2.
• Performer system and assignment: admitted system Receiver_Rx42 performs this occurrence under exact Receiver_Rx42_DetectorAssignment_2026-06-03 : U.RoleAssignment, whose role value is DetectorReceiverRole, role-taxonomy episteme is RadioLabRoles-2026, effective reference scheme is RadioLab-Reception-Scheme-2026, and obtaining extent covers the reception interval. The receiver system acts; the assignment does not.
• Episodes: when signal-quality or diagnostic use needs event-bounded fragments, ReceiverReceptionEpisodePolicy_2026, a C.2.1 policy episteme under RadioLab-Reception-Scheme-2026, states whether retune, on/off, interruption, or diagnostic-mode events bound an EpisodeOf_work. A trace timestamp or retune label without that current branch criterion remains history, not an episode relation.
• Temporal parts: a one-second reception slice is TemporalPartOf_work for signal-quality evidence or telemetry aggregation. It is not a new occurrence merely because it appears in a trace.
• Method and mechanism split: tuning, rectification, smoothing, and acoustic output may be recovered as method factors, system-component behaviors, mechanism material, evidence traces, or operational work parts depending on the current claim. A detector component or waveform segment does not become a submethod or a work part by label.

#Classification work without result collapse

Pump37_RecognitionWork_2026-07-20T1015_1022 is one Work individual admitted under U.Work, with temporal extent 10:15–10:22. Admitted system RecognitionEvaluator_A performs it under Pump37_EvaluatorAssignment_2026-07-20 : U.RoleAssignment; exact F.6 performedUnderAssignment, enactsMethod(Pump37_RecognitionWork_2026-07-20T1015_1022, HolonRecognitionEvaluation@FPF), and executedWithin(Pump37_RecognitionWork_2026-07-20T1015_1022, FPF_Recognition_Service_A) obtain. A.6.1 application Pump37_RecognitionApplication_2026-07-20T1017 has obtaining candidateArgument -> Pump_37 and judgmentResult -> unknown bindings, so the candidate participation and returned value need no generic affected-referent or Work-result relation. This fixture supplies no admitted evaluator-time or runner-compute resource-use predicate; return missing-governor[PUMP37-RESOURCE-USE] for those optional claims without lowering the Work or application bindings.

The returned unknown value remains the A.6.1 result binding. No U.Transformation of Pump_37 or of a classification record is asserted. This evaluation Work remains admitted from its performer system, covering assignment, enacted method, extent, and containing system; the application binding is a separate obtaining fact, and the absent optional resource-use predicates do not lower the Work. No pre-state, post-state, or delta is needed. Candidate-side criterion satisfaction remains under A.1; evidence and assurance remain neighboring relations; and any materialized classification assertion or evaluation-result episteme remains under C.2.1. None is the Work occurrence or an intrinsic Work result field.

#Filled result route: build, verify, transfer, accept

ReleaseBinary12_BuildWork_2026-07-21T0900_0912 : U.Work is performed by BuildRunner_A : U.System under BuildRunnerAssignment_2026-07-21 : U.RoleAssignment, enacts ReproducibleBuild@BuildOps-v12, runs from 09:00 to 09:12, and is executed within BuildService_A. Those facts establish the Work occurrence. The rows below add only the result and consequence claims that are current in this case.

The readable report is therefore: the build Work occurred; a different entity was returned and produced; BuildWorkPopulatedStore-12 states the positive local W-to-T claim; separate verification Work returned a verdict supported by evidence; and ArtifactTransferToStaging_12 transferred the entity. Acceptance remains at missing-governor[STAGING-ACCEPTANCE]. Removing any non-current row does not alter the identity of the build Work.

#Bias-Annotation

#Scope Declaration and Rationale

• Applicability: Use the same occurrence test for pragmatic costing, architectural accountability, teaching examples, and source or evidence questions; when the current claim is only about a description, publication, source, or evidence relation, apply the governing pattern for that claim.
• Scope declaration: The occurrence head is universal. Temporal semantics use the declared temporal reference. A simple uninterrupted occurrence needs no continuity-policy episteme; identity, episode, retry, resumption, or aggregation claims cite workContinuityPolicyRef and its effective U.ReferenceScheme only when the named use must resolve an ambiguous boundary. Add claim scope, a qualification window, model-use structure, evidence use, or source-currentness assessment only when changing that neighboring fact would change the receiving assertion or reliance; otherwise omit it.
• Rationale: Gives FPF a clean, actionable notion of occurrence with admitted performer U.Systems acting under exact obtaining U.RoleAssignments and with actual enactsMethod relations, so that costing, quality, and audit rest on independently identified work occurrences rather than plans, recipes, assignments made to act, or a generic role-enactment fact.

#Conformance Checklist (admission checks)

CC-A15.1-1 (Strict distinction). U.Work is the admitted kind for dated performed Work occurrences. Each Work individual is world-side; it is not a U.Method (semantic way), U.MethodDescription (description), U.Role or U.RoleAssignment (assignment), U.WorkPlan (plan or schedule), or assertion, record, log, or publication about work.

CC-A15.1-2 (Required occurrence basis). A conforming assertion or description about a Work individual designates one world-side occurrence admitted under U.Work and makes each actual performer U.System, the exact obtaining U.RoleAssignment under which that system performed, any explicit F.6 performedUnderAssignment(W, RA) attribution, actual enactsMethod -> U.Method, temporal extent, and executedWithin -> U.System recoverable. It also names every declared work-to-referent, subject-participation, or resource-use predicate used by the receiving claim, together with its participant order and actual participant values, or gives the exact A.6.1 binding for an identified operation application. When a needed predicate or binding is absent, it returns the corresponding missing-governor result instead of inventing a positive relation. Cite methodDescriptionRef -> U.MethodDescription only when the receiving claim depends on that exact description episteme. The episteme designates these independently obtaining objects and relations; it does not turn them into occurrence fields or make the assignment act. CC-A15.1-3 (Time window). A conforming assertion or description about one Work occurrence designates a world-side individual with a closed temporal extent [t_start, t_end], or an explicitly open end while the occurrence is in flight. The episteme states or designates that extent and, where relevant, location or asset; neither an interval field nor the presence of the record creates the occurrence.

CC-A15.1-4 (Interpretation and policy basis). A load-bearing work claim names direct occurrence facts first. It cites workContinuityPolicyRef, its effective U.ReferenceScheme, and applicable scope or qualification window only when a named identity, episode, retry, resumption, or aggregation use must resolve an ambiguous segmentation. Any selected method-description episteme, aggregation-policy episteme, selected model-use structure, acceptance criterion, evaluation work, result episteme, and evidence use remains a neighboring claim rather than a work-identity field.

If two local senses must be related, F.9 receives two exact SchemeSenseCell endpoints and one BridgePredicateProfile; a Bridge is positive only when that profile's predicate obtains. State the proposed comparison, substitution, translation, or publication separately in a C.2.1 bounded-use claim, with its action, direction, correspondence rule, and tolerated loss. A.10 or B.3 owns reliance on that claim. A different reference scheme, role assignment, selected description episteme, or model-use structure alone establishes none of these facts. CC-A15.1-4b (No mandatory state-plane or delta). A Work claim needs no StatePlaneRef, pre-state, post-state, or delta merely to establish occurrence identity. If the receiving claim says that a referent changed, A.3.4 identifies the transformation and its state or boundary facts. Connect it to Work only through a declared domain predicate with exact W and T participants, or one C.2.1 local compound claim under A.6.RCD disposition 2 with a recoverable constructor, governed base predicates, actual participants, and case facts; otherwise return missing-governor[work-to-change]. CC-A15.1-5 (RoleAssignment interval coverage). Every U.RoleAssignment cited by an obtaining F.6 performedUnderAssignment(W, RA) attribution has as its holder the exact admitted U.System stated to perform the work and covers the work interval or exact performed part attributed to that system. If the holder differs or the assignment does not cover the extent, keep the Work occurrence, performer claim, and assignment claim separate: repair or reject the attribution, or establish a retroactive assignment only under the exact A.2.1 rule that admits it.

CC-A15.1-6 (Actual participant and operation binding). For an operation argument or result, name one identified A.6.1 application and its exact declaration-local binding. For any other actual parameter, participant, premise, constituent, reference use, resource, or work-to-referent claim, name the declared subject predicate, participant order, and actual participant values. If the required route is absent, name the missing relation or binding in the missing-governor result and do not assert it. A MethodDescription declaration, default, A.15.3 planned filling, gate selection, compatible ValueKind, or stored token establishes no actual binding. CC-A15.1-7 (Capability check). Any capability threshold relied on for a Work occurrence is the declared bound in the selected method-side claim and is tested by a named A.2.2 capability-fit predicate against each performer system's capability instance for the work interval or declared checkpoints. Name that predicate, the capability instance, threshold, work need, and result. If the fit predicate is absent, return missing-governor[capability-fit] and assert neither fit nor failed fit. A U.Method or U.MethodDescription may cite or describe the threshold but creates neither capability nor fit. State a failed fit in its evaluation-result episteme or direct characteristic/evaluation relation, never as an intrinsic work outcome.

CC-A15.1-8 (Acceptance criteria). An acceptance claim names the selected criterion episteme or comparator specification, its applicable scope and window, the evaluation or acceptance work that applied it, its returned value or result episteme, and the declared acceptance predicate with all actual participants. If the claim relies on historical continuity with an earlier criterion episteme, name the exact C.2.1 EpistemeEditionRelation; a version label alone is not enough. If no acceptance predicate governs the claim, return missing-governor[acceptance]. Success class, quality measurement, comparison result, and acceptance verdict remain distinct; no verdict is an intrinsic field of the Work occurrence or a condition of U.Work membership. CC-A15.1-9 (Resource honesty). Performed resource-use facts (energy, materials, machine-time, money, tool wear) are attributed through declared predicates that name the particular Work, resource, amount, unit, and extent participants, not to U.Method, U.MethodDescription, U.Role, or U.Capability. If no predicate governs the needed use, return missing-governor[resource-use]; estimates remain in method descriptions or plans. Any aggregate ledger, unit conversion, allocation, or overlap and deduplication result belongs to B.1.6 and cites the contributing Work occurrences and resource-use facts.

CC-A15.1-10 (Mereology declared). When exact work-part relations obtain among Work individuals, declare each relation: temporal-part, episode-part, operational-part, or another relation with its own predicate. Ambiguous mixtures lower aggregation and identity claims. A TemporalPartOf_work claim names parent work identity plus interval or aspect; an EpisodeOf_work claim names the parent, candidate boundary events, and named use, adding workContinuityPolicyRef only when those facts leave the grouping ambiguous for that use; an OperationalPartOf_work claim names the occurrence-side part and any recovered method factor separately. Concurrency adds a separate interval overlaps fact. If the reader also claims coordination, name its declared predicate and actual participants; overlap alone does not establish it.

CC-A15.1-11 (Temporal coverage selection). For a temporal roll-up, B.1.4 names the exact Work refs, aggregation concern, time window, coverage and non-overlap conditions, and policy selecting union, convex hull, or another admitted result. A.15.1 supplies the occurrence intervals but does not own the aggregate.

CC-A15.1-12 (Resource aggregation). For a resource roll-up, B.1.6 names the exact Work refs, typed resource basis, units, evidence, delimitation and time window, overlap or deduplication policy, ledger, and aggregation rule. A.15.1 supplies performed resource-use facts but does not own the aggregate ledger.

CC-A15.1-13 (Identity and retries). A distinct actual work-entry after an established completion or termination identifies a later Work occurrence; a proper work part and its parent and independently grounded concurrent performances are also distinct individuals. Add retryOf, resumptionOf, or EpisodeOf_work only when its own predicate holds. An interruption, performer or assignment replacement, method or mode switch, retune, rework, affected-referent change, or binding change is stated as direct history and neither splits nor preserves the parent by itself. Cite workContinuityPolicyRef only when a named use needs a branch criterion for that ambiguity. A changed MethodDescription or another policy episteme alone revises at most the dependent description or segmentation judgment. Call the policy an edition only when an exact C.2.1 EpistemeEditionRelation obtains; a non-continuing replacement can support a different judgment without rewriting the occurrence. CC-A15.1-14 (Concurrency and ordering). Overlaps and precedences among work occurrences use interval relations (overlaps, precedes, contains, or within). Implicit "step order" claims are not admitted as performed-work evidence.

CC-A15.1-15 (Cross-locality evaluation). A work occurrence keeps one identity when several receiving uses evaluate it. Each use names its own effective reference scheme, claim scope, criterion, qualification window, evaluation work, and result episteme. When two local senses must be related, test the exact F.9 Bridge, then state the proposed comparison or substitution, direction, rule, and tolerated loss in a separate bounded-use claim and check reliance under A.10 or B.3. A shared work name, record, or Bridge carries no acceptance across uses. CC-A15.1-16 (Method-description changes do not decide Work identity). If the selected MethodDescription episteme changes during the occurrence, state the description-selection or override claim separately. That selection change alone neither splits nor preserves Work. When an accompanying actual performer-system, covering-assignment, enacted-method, binding, affected-referent, mode, or extent change creates a boundary question for a named use, apply that use's exact continuity-policy criterion. A later or competing policy episteme may support another judgment; it is a later edition only when its exact C.2.1 EpistemeEditionRelation to the earlier policy obtains. Otherwise it is a non-continuing replacement. Neither changes the occurrence. CC-A15.1-17 (Distributed performers). If multiple admitted U.Systems jointly perform the same top-level work occurrence, name every system, its exact obtaining covering U.RoleAssignment, and every explicit F.6 attribution; verify that each assignment's holder is that system and that its obtaining extent covers the attributed work. If the use instead needs a parent work with child occurrences, give every child its actual performer system, covering assignment, and work-part relation. A lead, accountability, or coordination claim remains separate and cannot substitute one designated assignment for the actual performer set.

CC-A15.1-18 (Logs are evidence, not work by themselves). Logs and telemetry support a claim about work only through an exact evidence-use relation that identifies the Work occurrence, actual performer system and covering assignment, enacted method, temporal extent, and containing system, plus any selected method-description episteme, work-to-referent relation, binding, resource-use fact, policy, or qualification value on which the receiving claim relies.

CC-A15.1-19 (Affected referent and work scope). Each assertion or description about a Work occurrence designates the exact Work individual and states a direct work-to-referent relation only when the receiving use needs one. That relation must obtain independently; naming the referent in the episteme establishes neither actual change, production, delivery, acceptance, nor a universal affected relation. When the receiving use needs no such relation, omit it without lowering the Work occurrence. CC-A15.1-20 (Actual change stays neighboring). When the receiving claim needs actual change, identify an exact U.Transformation under A.3.4. Connect it to Work only through a declared domain predicate with exact W and T participants, or one C.2.1 local compound claim under A.6.RCD disposition 2 with a recoverable constructor, governed base predicates, actual participants, and case facts; otherwise retain both objects and return missing-governor[work-to-change]. Work can occur without a current transformation claim, and a no-op, evaluation, inspection, communication, or record-handling occurrence is not forced into a delta schema. The inverse also holds: a transformation does not become Work unless an admitted performer system, covering assignment, enacted method, temporal extent, containing system, and F.6 attribution obtain independently. Apply the paired first-use probe to natural change and self-directed action; do not invent an assignment for a causal participant, reject a non-human performer by resemblance, or collapse internal performer and affected positions into a primitive self-relation. CC-A15.1-21 (Record handling remains Work without automatic transformation). Copying, formatting, evaluating, or publishing records can be performed by Work individuals admitted under U.Work when the actual performer system, covering assignment, actual enacted method, extent, and containing system are grounded. State an affected referent, binding, or resource-use fact only through its independently obtaining relation when the receiving claim uses it. Identify any actual record or dataset transformation separately under A.3.4; a label, output record, or post-state picture does not establish it. CC-A15.1-22 (Executed-within declaration). Each Work occurrence stands in one exact executedWithin -> U.System relation, which an assertion or description about the occurrence may state. When the accountable system is a subsystem in ordinary speech, name the system and its exact part relation to the larger holon. When that system differs from the affected referent, keep both identities separate. If the receiving claim relates the Work to the referent or to a transformation, name that declared predicate, its participants, and the facts that make it obtain; otherwise assert no connection merely from containment or shared timing.

CC-A15.1-23 (No transformation composition from Work mereology). Exact Work parts support only their declared work-part facts and provide inputs to separately recovered B.1.4 or B.1.6 aggregation claims. They establish neither component transformations, transformation parthood, a composite transformation, nor a parent effect. Recover each actual transformation independently; when a production or effect claim needs unavailable transformation composition, return missing-governor[transformation-composition]. CC-A15.1-24 (No new claims on publication views). MVPK views about Work project the declared assertion or description of the Work occurrence; they do not add properties or claims. Numeric or comparable content names unit, scale, reference-plane, and EditionId pins; work-publication views do not use "signature" for these publication pins.

CC-A15.1-25 (No Gamma leakage). Publication views cite exact B.1.4 temporal-aggregation or B.1.6 work-resource-aggregation results and policies when showing aggregates. They do not encode aggregation semantics in prose or imply defaults. Optional Gamma notation lives with its recovered Part B aggregation claim; the view carries only pinned references needed by the publication use.

CC-A15.1-26 (No input-output re-listing). Publication views do not restate method-description input and output lists; they publish presence pins and source references only under the publication-use pattern governing that view.

CC-A15.1-27 (Comparator ordering and return sets). Across-occurrence comparison presented on a publication view about Work uses a declared ComparatorSet (map-then-compare), returns sets when order is partial, and lowers hidden scalarization or ordinal-mean claims.

CC-A15.1-28 (Comparator and transport pins). Numeric or comparable acceptance or KPI claims on a publication view about Work pin ComparatorSet.edition, comparator-spec edition, and, where conversions occur, TransportRegistry.edition with the selected transport policy ids. When two local senses must be related, cite the exact obtaining F.9 Bridge only as the correspondence premise, state the proposed bounded reuse in a separate C.2.1 claim, and check reliance under A.10 or B.3. A selected reference-plane change remains with CHR and its direct relation; the Bridge transfers neither reuse nor a plane value. Penalties affect the reliability relation only.

CC-A15.1-29 (Telemetry-reference pins, when applicable). If a work occurrence feeds G.11 or QD and OEE portfolios, the evidence relation cites the telemetry, archive, and policy references declared by the governing comparison, archive, evidence, or refresh pattern. Illumination remains report-only telemetry unless a governing comparison, archive, or selection pattern promotes that use.

CC-A15.1-30 (Part naming parsimony). Do not create a durable named work part for every interval, telemetry segment, pause, event-log row, engine stroke label, detector component, or encountered wording. Name a work part only when downstream use needs its own resources, evidence, KPI, acceptance, repair, aggregation, cross-context reliance, or source-relation return use. Otherwise lower to a temporal relation, evidence slice, telemetry segment, method-description constituent, missing-source-relation note, or another direct neighboring object.

CC-A15.1-31 (Method and work granularity are coupled but not isomorphic). A work part may enact a recovered submethod, but the correspondence is not automatic. A temporal work part usually enacts the same whole method during a slice. An episode records continuity under one method or mode and may span several operational parts, repeat the same method fragment, or be split by evidence policy without changing method identity. An operational work part corresponds to a method factor only when that factor is recovered as U.Method under A.3.1 and B.1.5; otherwise keep it as the work part, method-description node, evidence segment, mechanism material, or system-component behavior actually identified.

#Work-to-aggregation interface

A.15.1 makes the occurrence-side inputs recoverable without storing them in the occurrence: a separate assertion or description episteme designates exact Work individuals or work parts and states their temporal extents and the separately obtaining resource-use relations selected for aggregation. B.1.4 identifies the temporal-aggregation claim and result; B.1.6 identifies the resource-aggregation claim, ledger, and result. Neither becomes a Work field.

#Temporal aggregation return

For utilization, lead time, cycle time, phase coverage, or another temporal roll-up, use B.1.4. Name the exact work refs, carrier or aggregation concern, time window, coverage and non-overlap conditions, aggregation policy, and admissible use there. Union, convex hull, and optional Gamma_time notation are properties of that recovered temporal aggregation, not fields or identity invariants of a Work occurrence.

When the exact B.1.4 result selects the Work-interval profile, retain these use-specific choices:

• Union of intervals for utilization or availability: preserve every covered instant and do not count overlap twice.
• Convex hull [min t_start, max t_end] for lead time or cycle time: preserve elapsed span from first start to last end, including gaps.
• Declared algebraic behavior: for either exact set-based policy, duplicate input is idempotent, input order is irrelevant, and adding intervals cannot shrink the union or hull. If another policy lacks those properties, name it rather than borrowing the union/hull result.

Never switch union and hull silently between KPIs. The formulas above profile a recovered B.1.4 aggregation over Work intervals; the selected B.1.4 claim, not A.15.1, states the temporal result.

#Resource aggregation return

For a total or ledger over performed resource-use facts, use B.1.6. Name the exact work refs, typed resource-accounting basis, units, measurement or evidence refs, holon delimitation, time window, overlap or deduplication policy, aggregation rule, and admissible use there. Additivity, allocation, traceability, the aggregate ledger, and optional Gamma_work notation belong to that recovered resource-aggregation claim, not to Work-occurrence identity.

Filled heterogeneous BuildOps route. Published case-local specification BuildOpsResourceUseRelations-v12 declares BuildWorkUsesResource@BuildOps-v12(work, resource, amount, unit, extent) with participant order <work, resource, amount, unit, extent>. Its test requires the named Work actually to occupy or consume the named resource during that extent, with the amount measured in the named unit. Separate case facts state that ReleaseBinary12_BuildWork_2026-07-21T0900_0912 occupied BuildPoolCPU_A for 24 runner-core-minute during 09:00-09:12, and consumed 0.84 kWh of GridElectricity_BuildZone3 within BuildService_A_Delimitation-v12 during the same extent. Those facts make relation occurrences BuildRunUsedCPU_12 and BuildRunUsedElectricity_12 obtain with those exact participant tuples. BuildRunnerAllocationEvidence_12 and BuildZone3EnergyMeasurement_12 support the facts; neither record is the resource use, and neither relation is a field of the Work.

B.1.6 result BuildResourceAggregation_12 : WorkResourceAggregation@Context names concern Build12MeasuredResourceUse, bounded context BuildOps-v12, that exact Work, and the two relation occurrences. It uses typed basis BuildComputeAndElectricityBasis-v12, measures BuildRunnerCoreMinuteMeasure_12 and BuildZone3KWhMeasure_12, evidence refs BuildRunnerAllocationEvidence_12 and BuildZone3EnergyMeasurement_12, holon delimitation BuildService_A_Delimitation-v12, and window 09:00-09:12. Policy BuildResourceRelationDedup-v12 counts each exact relation occurrence once across repeated evidence or a parent/child view. Rule BuildTypedResourceVectorSum-v12 adds only entries of the same resource type and unit. Ledger BuildResourceLedger_12 contributes <BuildRunUsedCPU_12, 24 runner-core-minute> and <BuildRunUsedElectricity_12, 0.84 kWh> and returns Build12MeasuredResourceVector = <24 runner-core-minute, 0.84 kWh> without summing or converting its unlike components. Its admissible use is the measured resource-disclosure input for Build 12; it proves no Work identity, production result, efficiency, cost, sustainability verdict, or acceptance.

When an exact B.1.6 aggregation must allocate shared or overlapping resource use, retain these non-default policy examples:

• Parent attribution: book a declared shared fixed value once at the parent and independently measured variable values at children.
• Pro rata by wall time: divide a declared shared value by relative durations only when that driver is admissible for the resource basis.
• Driver based: allocate by a measured driver such as CPU share, weight, or priority and state the exact allocation rule that uses it.

Whichever policy is selected, add only disjoint or explicitly deduplicated values and keep every aggregate figure traceable to its contributing Work refs and evidence. A policy label alone establishes neither allocation nor ledger value.

A Work publication or KPI may cite either result through the exact E.17 publication-use relation that projects it. It may not recreate an unselected operator, infer an aggregate from parthood, or turn an aggregation record into a Work occurrence.

#Work-claim interpretation checks

When another decision relies on a work occurrence, perform three quick checks:

1. Method-description interpretation. Does methodDescriptionRef resolve to the selected U.MethodDescription episteme under the effective U.ReferenceScheme used by the receiving claim? If the claim also says this is an edition of an earlier description, does the exact C.2.1 EpistemeEditionRelation obtain? If two local senses must be related, test an F.9 Bridge and state the bounded use separately rather than treating the reference change as a Bridge.
2. Performer and assignment coverage. Is the exact admitted U.System named as performer the holder of every U.RoleAssignment cited by an obtaining F.6 performedUnderAssignment(W, RA) attribution, and does each assignment's obtaining extent cover the occurrence or exact performed part attributed to that system? If not, keep the Work occurrence, performer claim, and defective assignment or attribution claim separate until A.2.1 and F.6 admit or repair them.
3. Evaluation boundary. Has separately performed evaluation or acceptance work applied the selected criterion episteme to the independently obtaining relations involving the Work occurrence, changed subject, measurement results, or delivered entity that the criterion actually requires? If not, no acceptance verdict follows. If yes, keep the evaluation work, result episteme, verdict content, evidence, and acceptance relation separate. Claim edition continuity only when the exact C.2.1 relation obtains.

These checks tell the reader which description, assignment, criterion, evaluation, and relation to cite. They neither create one judgment-context object nor make acceptance part of work identity.

#Common Anti-Patterns and How to Avoid Them

• "The log is the performed occurrence." Dumping telemetry without occurrence references (actual performer system, covering assignment, enacted method, time window, and containing system, plus any selected method-description episteme, work-to-referent relation, binding, resource-use fact, or evidence-use relation on which the claim relies) -> Not Work. Recover the Work occurrence and relate the log as evidence.
• Record-handling-as-transformation. ETL, copying, formatting, evaluation, or publication work is treated as proof that a record or dataset changed -> Keep the grounded Work occurrence, but assert actual change only after A.3.4 identifies the transformation and a declared domain predicate with the exact Work and transformation participants obtains; otherwise return missing-governor[work-to-change].
• Silent cross-locality acceptance. "Ops accepted it, so audit accepts it." -> Name each receiving criterion, evaluation work, and result episteme. Assert acceptance only through that use's declared predicate and actual participants; otherwise return missing-governor[acceptance]. If the criteria use different local senses, test the F.9 Bridge, state the proposed cross-local comparison or substitution in a separate bounded-use claim, and check reliance; the Bridge itself transfers no acceptance.
• Description-change-as-occurrence-change. Selecting another MethodDescription episteme is treated as automatically splitting or preserving Work -> State the description-selection change separately. Only when an accompanying actual history change creates an identity question for a named use should its continuity-policy criterion be applied; the policy revises the judgment, not the occurrence. Call the descriptions editions only when their exact C.2.1 relation obtains.
• Budget on the method. Charging costs to Method or Role -> Attribute performed resource use only through exact relations involving Work individuals; keep estimates in method descriptions or plans.
• Part ambiguity. Mixing retries, episodes, and operational parts with no declared relation → Choose and declare the part relation.
• Slice-as-episode. A monitoring interval, telemetry window, crank-angle segment, or one-second reception trace is called an episode only because it has timestamps -> Use TemporalPartOf_work, an evidence relation, or a telemetry relation unless actual boundary events and the direct episode predicate establish an event-bounded fragment for a named use; add a continuity policy only if those facts leave its grouping ambiguous.
• Episode-as-new-work by habit. A pause, retune, or interruption is always recorded as either a new occurrence or the same one -> Preserve the boundary events first. Apply exact workContinuityPolicyRef only when a named use must decide the grouping; otherwise return unresolved segmentation rather than forcing either answer.
• Method-factor-as-work-part by label. A step, stroke, receiver component, graph node, or method-description section is treated as a work part or submethod by name -> Recover the current object: U.Method factor, U.MethodDescription constituent, TemporalPartOf_work, OperationalPartOf_work, evidence segment, mechanism material, system-component behavior, or missing-source-relation note.
• Granularity inflation. Every interval or trace row receives a durable work-part name -> Name the work part only when a current resource, evidence, KPI, acceptance, repair, aggregation, cross-context reliance, or source-relation return use hangs on it.
• Union-hull confusion. Changing KPI coverage silently between reports -> recover the exact B.1.4 temporal aggregation and cite its policy per KPI.
• Double-count in overlaps. Summing child and parent resource facts as one ledger -> recover the B.1.6 aggregation claim and apply its exact overlap or deduplication policy.

#Existing work-log repair applications

1. Recover occurrence assertions. For existing logs, identify the independently grounded Work occurrence and write an assertion or description that cites its designator, each actual performer system, the covering assignment and any explicit F.6 attribution, actual enactsMethod, extent, and containing system. Add optional methodDescriptionRef and only those independently obtaining work-to-referent, binding, and resource-use relations on which the receiving claim relies. Do not create Work by creating a record.
2. Recover the work-judgment basis. Name the direct occurrence facts first. Add exact workContinuityPolicyRef, effective reference scheme, scope, or qualification window only when the identity, episode, retry, resumption, or aggregation judgment has more than one defensible branch. Keep any selected MethodDescription episteme, aggregation policy, criterion, and evidence-use relation outside the Work.
3. Record a continuity policy only for an actual ambiguity. Cite exact workContinuityPolicyRef and its named use when an interruption, resumption, replacement, switch, or composite boundary could support more than one segmentation. If direct facts already close a simple uninterrupted case, omit the policy.
4. Separate slice, episode, and operational part. Use interval/aspect for TemporalPartOf_work, event-bounded continuity for EpisodeOf_work, and recovered occurrence-side part plus any separately recovered method factor for OperationalPartOf_work.
5. Name only useful work parts. If no named resource, evidence, KPI, acceptance, repair, aggregation, cross-context reliance, or source-relation return claim depends on the candidate part, keep it as a relation, evidence slice, or telemetry slice.
6. Return temporal roll-up to B.1.4. Cite the exact temporal aggregation and its union, hull, coverage, and non-overlap policy in the KPI rather than recreating it on Work.
7. Return resource roll-up to B.1.6. Recover the typed resource ledger, evidence basis, allocation, and overlap or deduplication policy there; each contributing performed resource-use relation remains independently obtaining with an exact Work occurrence as a participant.
8. Pull plans out. Keep calendars and planned fillings in exact U.WorkPlan content; establish performed values only through direct relations in which the Work occurrence participates and through exact A.6.1 bindings.
9. Bind actual values directly. For an operation argument or result, name the identified A.6.1 application and its exact binding. For any other participant or parameter, name the declared subject predicate, participant order, and actual values; return the matching missing-governor result when that predicate is absent. Retain MethodDescription defaults and WorkPlan choices as non-actual neighbors.

#Consequences

#Rationale

U.Work is retained as the admitted kind for dated Work occurrences because performer system, role assignment, method, method description, work plan, affected entity, actual change, evaluation-result episteme, delivered entity, and downstream effect are different FPF objects. One Work individual is the world-side occurrence; each actual performer is an admitted U.System acting under an exact obtaining U.RoleAssignment, and an assertion or description about the work is a separate episteme. The same wording in a source episteme, publication occurrence, method description, or work plan can point to several of these objects, but performed-work claims need occurrence grounding, temporal bounds, actual performer system, covering assignment, enacted method, and containing system rather than a convenient method, assignment, plan, affected-object, or delta label. Add direct work-to-referent, binding, resource-use, or change facts only when their own relations obtain. This keeps work mereology, resource aggregation, and P2W carry-through grounded in what happened.

#SoTA-Echoing

SoTA alignment rule. A source tradition counts here only when it preserves the local separations: U.Work is the admitted kind; one Work individual is a world-side dated occurrence; each actual performer is an admitted U.System; the exact obtaining U.RoleAssignment states the role under which that system performs; and an assertion or description about the occurrence is a separate U.Episteme. The occurrence has exact method, temporal, and containing-system relations; work-to-referent, binding, and resource-use relations are added only when they independently obtain. Neighboring change, evaluation, evidence, production, delivery, and acceptance claims remain separate. Historical occurrence modeling is used as lineage only when a current practice still needs those distinctions.

#Relations

• Builds on: A.1 Holonic Foundation; U.System; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; A.3.1 U.Method; A.3.2 U.MethodDescription; C.2.1 for episteme edition and effective U.ReferenceScheme; A.2.6 for claim scope; and C.27.TA for temporal qualification. A.1.1 enters only when a separately identified BoundedModelUseStructure changes the receiving work claim.
• Coordinates with: A.15 for Role-Method-Work alignment; A.6.1 and the exact direct relation patterns for actual bindings and participants; A.3.4 for independently identified actual transformations; A.15.PROD for local production-work, entity-identity-inception, and production-completion claims; B.1.4 for temporal aggregation and optional Gamma_time; B.1.6 for work-resource aggregation, ledger discipline, and optional Gamma_work; E.10 and E.10.ARCH for work-wording recovery; A.10, B.3, E.17, and A.15.4 for evidence, assurance, publication-use, or appearance-based reliance repair; A.15.5 for readiness before performed work; and C.32.P2S for carry-through. A permission, gate, result, production, delivery, or acceptance claim remains independent of Work identity.
• Informs: reporting and KPI patterns; assurance and evidence patterns that use Work as the reference occurrence; and scheduling patterns that compare exact U.WorkPlan claims with independently identified Work occurrences admitted under U.Work.

#Didactic quick cards

• What is Work? How it went this time → dated, resourced, accountable.
• Separation aid: Who performs? System. Under which held role? RoleAssignment. Can? Capability. How? Method. Which account of the method? MethodDescription. Did it happen? Work.
• Three-question result check: Did the work occur? What separate result or consequence is claimed? Who judged or accepted what, by which criterion and evidence? Use §4.6 and stop after the last question the receiving use actually asks.
• Roll-ups: A.15.1 supplies exact Work refs, intervals, parts, and performed resource-use facts; cite B.1.4 for temporal aggregates and B.1.6 for resource ledgers, each with its declared policy.
• Episodes vs retries: record end, interruption, resumption, and later work-entry facts first; add a continuity policy only when a named use still has more than one defensible grouping.
• Resource honesty: relate performed resource use to exact Work individuals through separately obtaining resource-use relations; route any result or consequence through the one matching §4.6 row.

#P2W Performed-Work Use Relation

When E.18.1 reaches performed work, identify one Work individual admitted under U.Work, then recover each actual performer U.System, the exact obtaining U.RoleAssignment under which it performed and any explicit F.6 attribution, plus the separately obtaining enacted-method, temporal, and containing-system relations. Add only the actual operation binding, resource use, or work-to-referent relation on which the receiving sentence relies. When P2W continues into a result or consequence claim, select the matching §4.6 row, name the object and facts that row requires, and stop at its stated non-inference or missing-governor result.

A Work occurrence may be designated by an episteme that also cites a U.WorkPlan, exact A.15.3 planned-filling claim, or prior readiness claim as a baseline. For an operation argument or result, cite one identified A.6.1 application and its exact binding. For another participant, premise, resource use, or work-to-referent claim, name the declared predicate, participant order, and actual values; if that predicate is absent, return the corresponding missing-governor result. Do not copy a result or consequence into Work; follow the concrete §4.6 route.

#Lowering, Repair, and Refresh Conditions

Lower a candidate assertion that an individual is Work admitted under U.Work when the occurrence designator, actual performer system, covering assignment and any explicit F.6 attribution, actual enacted method, temporal extent, or executedWithin relation cannot be recovered. If the receiving claim additionally relies on a work-to-referent or resource-use relation, lower that dependent claim when its declared predicate, participants, or obtaining facts cannot be recovered. If it relies on an operation argument or result, lower that dependent claim when the identified A.6.1 application or exact binding is absent. Do not lower the Work occurrence merely because an unneeded affected referent or delta is absent. Require a continuity-policy basis only when an identity, episode, retry, resumption, or aggregation claim actually depends on ambiguous segmentation. Lower a candidate work-part claim when the downstream use does not need a named work part or when the candidate is only an interval, event-log row, telemetry segment, method-description constituent, component behavior, mechanism material, or wording cue. The acceptable lowered object is the exact temporal relation, plan episteme, readiness-gap claim, evidence episteme, telemetry slice, method-description reference, unresolved-segmentation note, missing-relation blocker, A.15.4 repair request, or direct neighboring object, not a backdated Work occurrence or gratuitous work part.

Repair the work assertion or description when a subsequent source changes the resolved temporal extent, actual performer system, covering assignment or F.6 attribution, actual enacted method, selected method-description reference, direct binding, resource-use claim, work-to-referent relation, containing system, or work-part relation. Reidentify only when the direct A.15.1 boundary rules decide the change or the selected policy's branch criterion applies to a named ambiguous use. When the selected continuity-policy episteme changes, repair the dependent identity, episode, retry, resumption, or aggregation judgment and cite the newly selected exact episteme. Call it a changed edition only when the exact C.2.1 EpistemeEditionRelation obtains; otherwise record a non-continuing replacement. Neither route rewrites the Work occurrence or its actual history. Repair a result or consequence through the matching §4.6 row rather than editing Work.

Refresh before cross-context model use, aggregation, comparison, measurement, acceptance, release reliance, gate use, evidence use, assurance use, QD or OEE archive use, or P2W carry-through use. If the claim being made after refresh is no longer about performed work, use the direct pattern for that object or relation and retain a Work-occurrence reference only when the receiving claim actually depends on that occurrence.

#A.15.1:End

---

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