#Role-Method-Work Alignment (Contextual Enactment)

A.15 · 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. This pattern is the enactment-alignment pattern for engineer-managers when the real confusion is not "what component is this" but who is responsible, how the work is supposed to happen, when the plan applies, and what actually happened.

Use this when. Use this pattern when the real job is to separate role, method, plan, capability, and actual work before a team treats one cue, one schedule, one display, one copied or generated statement, or one document as if it already counted as the role assignment, the method, the work plan, execution evidence, or the work itself.

Start here when. The dominant ambiguity is role vs method vs schedule vs actual run, and the team keeps arguing over a source-side "process" cue without separating recipe, plan, capability, and executed work.

First output. One explicit separation of U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work, plus the shortest traceable chain that already exists from U.RoleAssignment through the governing U.Method and its method-description source to the intended U.WorkPlan or actual U.Work occurrence, or an explicit source gap that blocks admission of the claim.

Working enactment-alignment spine. Role, method, plan, and work confusion -> separate role, holder, bounded context, method description, intended U.WorkPlan, and actual U.Work -> choose proceed, plan, bounded probe, narrow, apply the direct governing pattern for any non-A.15 claim, or stop -> output the smallest alignment frame needed for the next project move -> use A.15.4 only when an encountered episteme publication, display, credential view, explanation, copied statement, provenance mark, dashboard tile, schema wording, API wording, or composed source chain begins to carry or justify a work claim or reliance claim.

Working application moves.

1. Name the role, holder, and context distinction under repair.
2. Name the method or method description that is meant to govern the work.
3. Name the intended U.WorkPlan or actual U.Work occurrence being claimed.
4. Choose the next move: proceed inside the recovered relation, plan, run a bounded reversible probe, narrow scope, apply the governing FPF pattern and project-side FPF kind and reference named by value for the claim or effect being made, or stop.
5. If an encountered source candidate or display is being used by appearance for a work claim, reliance claim, or source-restoration claim, apply A.15.4 Work-Relevant Source Restoration to that source-restoration claim; keep A.15 only for the U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work separation.

Action-pattern protection. This pattern is not about classifying encountered publications, displays, or cues. It keeps role, method, plan, capability, and actual work distinct so the acting engineer-manager can choose the next admissible project move. Work-relevant source restoration is handled by the related A.15.4 cluster member.

Minimum sufficient next move. Choose the minimum sufficient next move, recover only the project-side FPF kind and reference named by value needed for that move, and do not raise the claim beyond that recovered relation, source, or admissible-use boundary.

Recovered-source ready condition. If the required project-side FPF kind and reference named by value is present and its scope and window match the role, method, plan, or work move under repair, proceed inside that recovered scope and window. If not, narrow scope, run a bounded reversible probe, source-find, or create only the smallest source-restoration request, decision-request record, prospective work-plan entry, source-gap note, or missing-source admission block needed for the next move.

Ordinary use. If the team only needs to separate role, method, plan, capability, and actual work for orientation or planning, one separation sentence or small working card is enough.

Reliance-bearing use. Use the fuller alignment frame when an encountered source candidate or display is about to guide planned work, actual work, role attribution, status attribution, release reliance, disputed responsibility, or cross-context use. Use A.15.4 when the issue under repair is whether that source candidate exposes the project-side FPF kind and reference named by value needed for that work claim or reliance claim.

Stop condition. Stop once the separation changes no next admissible work move or reliance move and blocks no concrete overclaim about role, method, plan, work, status, approval, evidence, or release.

Admissible-use examples.

Alignment frame in plain terms. One alignment frame linking U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work through U.RoleAssignment; not a single work occurrence, not a checklist, not a language-style repair pattern, and not a mere cue note.

First admissible project move in plain terms. Keep design-time role, method, and work plan distinct from run-time work while making the chain between them inspectable enough for enactment, audit, and source restoration.

What goes wrong if missed. Teams collapse role, recipe, plan, capability, and actual run into one fuzzy source-side "process" label, then mistake documentation for execution, capability for evidence, schedule for occurrence, or a narrower briefing for the source that makes work admissible.

What this buys. One inspectable enactment frame that lets a team ask who held what role, which method governed, what plan existed, and what work actually occurred before treating follow-on work, blame, or approval as if those distinctions were the same.

Not this pattern when. Not this pattern when the honest need is only one dated work occurrence (A.15.1), only planning or schedule baseline (A.15.2), only a cue note that has not yet become an enactment-alignment question (A.16 or A.16.1), only boundary wording or policy wording without a role-method-work question under repair (A.6 or A.6.B), or work-relevant source restoration for an encountered source candidate or display (A.15.4).

Related project records and governing patterns. A.15.1 governs dated execution records, A.15.2 schedule or baseline planning records, A.15.3 slot-filling plan items, A.15.4 work-relevant source restoration, B.5.1 Explore -> Shape -> Evidence -> Operate for project progression, F.11 method and work vocabulary alignment across contexts, and F.17 the human-facing work sheet.

Causal-use work boundary. Realized counterfactual-sampling work, counterfactual randomization, intervention assignment, target-trial emulation work, and causal evidence collection remain U.MethodDescription, U.WorkPlan, and U.Work structures here. A.15 can say who performs which sampling or intervention work under which method and role; it does not make the resulting causal use admissible. C.28 governs the causal-use question, CausalityLadderRung, causal estimand, CausalEvidenceSupportBasis, counterfactual sampling realizability, and supported use and unsupported use.

Related-record mistakes. If the first honest encountered source cue is still only a cue, keep it under A.16 or A.16.1; if the question under repair is boundary wording, promise, agreement-like service, or policy wording, recover the corresponding A.6 boundary-claim record; if you only need one executed occurrence rather than the alignment frame, recover the A.15.1 dated work-occurrence record; if an encountered source candidate or display is being used for a work relation or reliance relation, use A.15.4.

Boundary to coarsened renderings. A lighter briefing, summary, redacted note, or coarsened rendering may orient work or cue attention. It becomes sufficient for work execution, plan use, approval, gate decision, or execution evidence only when the required method, plan, approval, gate, or evidence source remains explicit and reopenable. Treat the coarsened-rendering relation through A.6.3.CSC Controlled Semantic Coarsening when the rendering itself changes what can be relied on.

Use boundary. Use A.15 when the current project question needs role-method-work alignment. If the current claim is one single work occurrence, source-restoration note, wording repair, assurance claim, or source-side "process" label, use the governing pattern for that claim and keep only the A.15 separation that remains needed.

In any complex system, from a software project to a biological cell, there is a fundamental distinction between what something is (its structure), what it is supposed to do (its role and specified capability), and what it actually does (its work). Confusing these distinctions is a primary source of design flaws, budget overruns, and failed projects. Teams argue over a source-side "process" cue without clarifying whether the FPF object under repair is a U.Method, a U.MethodDescription, a U.Capability, a U.WorkPlan, or a specific U.Work occurrence that happened last Tuesday.

#Keywords

• role-method-work distinction
• U.Role
• U.Method
• U.MethodDescription
• U.WorkPlan
• actual U.Work
• contextual enactment
• coordinated-work evidence
• work admission display
• source-restoration boundary.

#Relations

#Content

#Problem frame

In any complex system, from a software project to a biological cell, there is a fundamental distinction between what something is (its structure), what it is supposed to do (its role and specified capability), and what it actually does (its work). Confusing these distinctions is a primary source of design flaws, budget overruns, and failed projects. Teams argue over a source-side "process" cue without clarifying whether the FPF object under repair is a U.Method, a U.MethodDescription, a U.Capability, a U.WorkPlan, or a specific U.Work occurrence that happened last Tuesday.

This pattern provides the canonical alignment for modeling contextual enactment in FPF. It applies the Strict Distinction Principle (A.7) to the passage from intended work to planned and actual U.Work, without making A.15 the whole strict-distinction ontology. It weaves together current governing relations into a single, coherent model:

• A.2 and A.2.1: Provide U.Role values and U.RoleAssignment as the typed work-facing assignment relation with holder, role, bounded-context, window, and justification slots governed through A.6.5-style slot discipline.
• A.15.2 and A.15.1: Separate U.WorkPlan intent windows from dated U.Work occurrences.
• A.3.1 and A.3.2: Separate U.Method from U.MethodDescription, so recipes, algorithms, procedures, and source-side "process" cues do not become performed work by word choice.
• A.3.4: Provides U.Transformation for bounded change under conditions when the actual change, affected entity, pre/post state, mechanism, method, or work relation is current.
• A.10, C.2.1, and E.17: Keep evidence, source, publication, and carrier relations outside the work-facing role assignment unless a system or acting holon is actually assigned a role for performed work.

The intent of this pattern is to establish a normative, unambiguous vocabulary and set of relations for describing the passage from role and method capability to planned and actual, resource-consuming U.Work.

To keep plan-run separation explicit, this pattern references A.15.2 U.WorkPlan for schedules and calendars and A.15.1 U.Work for dated execution. Ambiguous source terms like "process", "workflow", "activity", and "schedule" are handled by E.10 and E.10.ARCH: recover the project concern first, then assign the source cue to U.Method, U.MethodDescription, U.WorkPlan, U.Work, or another direct governing pattern.

Terminology note. The words action and activity are not normative kernel names by themselves. When a generic "doing" cue appears, recover the FPF kind being claimed: U.Method, U.MethodDescription, U.Work, U.WorkPlan, or a neighboring governed value such as U.Transformation, U.Dynamics, evidence, gate, source, or publication use.

#Problem

Without this formal framework, models suffer from a cascade of category errors:

1. Role-as-Part: A Role (e.g., AuditorRole) is incorrectly placed inside a structural parts list (ComponentOf), making the system's architecture brittle and nonsensical.
2. Specification-as-Execution: A MethodDescription (the "recipe") is treated as evidence that the work was done. This leads to "paper compliance," where a system is considered complete simply because its documentation exists.
3. Capability-as-Work: A team's ability to perform a task (Capability) is conflated with the actual performance of that task (Work). This obscures the reality of resource consumption and actual outcomes.
4. Work-without-Context: An instance of work is logged without a clear link back to the role, capability, and specification that governed it, making the work unauditable and its results impossible to reproduce.
5. Ambiguous source-side "process" or "activity" cue: The overloaded term "process" is used indiscriminately to refer to all of the above, creating a fog of miscommunication. Repair generic doing or activity terms through E.10 and E.10.ARCH to U.Method, U.MethodDescription (recipe), U.WorkPlan (schedule), U.Work (run), or another direct governing pattern.

#Forces

#Solution

Method and work governing-pattern cue. When a source-side "process", "algorithm", "solver", "workflow", "procedure", or similar label points to changing, producing, selecting, deriving, controlling, or maintaining an EntityOfConcern, use E.10.ARCH:3.1 to recover the project concern first and then assign separately governed typed values. A.15 carries only the alignment among role, method, method-description, work-plan, and performed-work references. Formal substrate, mathematical-lens use, mechanism declaration or realization, evidence, gate, source, result, publication, and temporal claims are governed by their own patterns.

When methods are related to one another, A.15 keeps only the alignment use of that relation. The method-side object is MethodRelationStructure@BoundedContext under A.3.1, A.3.2, G.5, or a direct method-composition pattern when current. A method algebra, workflow graph, process calculus, matrix, category, embedding, or neural representation is a lens or method description over that structure, not a role relation, work plan, dated work occurrence, or assignment relation. The solution is a stratified alignment that cleanly separates the design-time and run-time for contextual enactment. The bridge between these worlds is the U.RoleAssignment.

#The Core Entities: A Strict Distinction

FPF mandates the use of the following distinct, non-overlapping entities to model method, plan, and work enactment. Using them interchangeably is a conformance violation.

A) Design-Time Entities (The World of Potential):

• U.Role: A contextual "mask" or "job title" (e.g., TesterRole). It specifies expected contribution or responsibility in a bounded context; it is not the holder, method, capability, work plan, or work occurrence.
• U.Method: The abstract way-of-doing inside a context (paradigm-agnostic; may be imperative, functional, logical, or hybrid).
• U.MethodDescription: A U.Episteme describing a U.Method; it may be expressed in an SOP, algorithm, proof, recipe, or other method-description publication.
• U.Capability: An attribute of a U.System that represents its ability to enact the declared U.Method under stated conditions. A MethodDescription may describe that method; the capability is not the description and not the work occurrence.
• U.WorkPlan: An U.Episteme declaring intended U.Work occurrences (windows, dependencies, intended performers as role kinds, budgets) - see A.15.2.

B) The Bridge Entity:

• U.RoleAssignment: The typed work-facing assignment relation that links a holder system or acting holon, a U.Role, a U.BoundedContext, any current window, and justification or source references when they matter.

C) Run-Time Entity (The World of Actuality):

• U.Work: An occurrence or event. It is the concrete, dated, resource-consuming enactment or execution of a U.Method by a Holder acting under a U.RoleAssignment; capability checks are evaluated at run time against the holder, and methodDescriptionRef names the source episteme used to identify or constrain the method when that source is being used for the work claim. This is the only entity that has a start and end time and consumes resources.

Kinds of Work and the primary target

Well-formedness constraint A15-WF-1 (work target and kind). A U.Work occurrence has primaryTarget: U.Holon with cardinality 1..1 (total) and kind with cardinality 1..1 (total).

Local kind values used here:

• Operational - transforms a U.System or its environment.
• Communicative (SpeechAct) - transforms a deontic or organizational frame (e.g., commitments, authority effects, approvals).
• Epistemic - transforms a U.Episteme (e.g., curating a dataset). The primaryTarget disambiguates enactment: what is being acted upon. Example: an approval is kind=Communicative, primaryTarget = Commitment(change=4711). A deployment is kind=Operational, primaryTarget = ServiceInstance(prod-us-eu-1).

Didactic Note for Managers: The "Chef" Analogy

This model can be easily understood using the analogy of a chef in a restaurant.

• ChefRole is the Role. It's a job title with certain expectations.
• A Cookbook (U.MethodDescription) contains the recipe for a Souffle. It's a piece of knowledge.
• The chef's skill in making souffles is their U.Capability. They have this skill even when they are not cooking.
• The restaurant's rulebook (U.BoundedContext) states that a holder assigned to ChefRole needs the capability to follow the recipes in the cookbook before the relevant cooking work is admitted.
• The actual act of making a souffle on Tuesday evening - using eggs and butter, taking 25 minutes, and consuming gas - is the U.Work.

Confusing these is like mistaking the cookbook for the souffle. FPF's framework simply makes these common-sense distinctions formal and mandatory.

#The Canonical Relations: Connecting the Layers

The entities are connected by precise, normative relations that form a traceable alignment chain. The following diagram illustrates the relation chain from bounded context and method description to dated work occurrence.

graph TD
    subgraph Design-Time Scope (Tᴰ)
        A[U.BoundedContext] -- defines --> B(U.Role)
        M[U.Method] -- isDescribedBy --> D[U.MethodDescription]
        Cap[U.Capability] -- is capability for --> M
        H(U.System as Holder) --> RB(U.RoleAssignment)
        B -- is the role in --> RB
        A -- is the context for --> RB
        A -- bindsCapability(Role,Capability) --> Cap
    end

    subgraph Run-Time Scope (Tᴿ)
        W[U.Work]
    end

    W -- performedBy --> RB
    W  -- enactsMethod --> M

    style A fill:#e6f3ff,stroke:#36c,stroke-width:2px
    style B fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style Cap fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style M fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style D fill:#f8cecc,stroke:#b85450,stroke-width:2px
    style H fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style RB fill:#dae8fc,stroke:#6c8ebf,stroke-width:3px,stroke-dasharray: 5 5
    style W fill:#ffe6cc,stroke:#d79b00,stroke-width:2px,font-weight:bold

• bindsCapability(Role, Capability): A U.BoundedContext asserts that a given Role requires a specific Capability. This is a design-time rule.
• isDescribedBy(Method, MethodDescription): A U.Method is formally described by one or more MethodDescriptions. This links the abstract way-of-doing to the method-description episteme and to the publication used when that source is being used for the method claim.
• enactsMethod(Work, Method): A specific U.Work is a run-time enactment of a U.Method under a U.RoleAssignment. Capability checks are evaluated against the holder at run time; the MethodDescription remains the source episteme or method-description reference used to identify, constrain, or justify the method when that source is being used for the work claim.
• performedBy(Work, RoleAssignment): A U.Work is performed by the holder named through a specific U.RoleAssignment. This links the work occurrence to the holder-in-role-in-context.

At run time, capability thresholds declared by the context or specification are checked against the holder; U.Work outcomes provide evidence for capability conformance.

This chain provides complete traceability: a specific instance of U.Work can be traced back to the U.Method it enacts, the MethodDescription or source publication used to identify or constrain that method, and the U.RoleAssignment relation whose holder, role, bounded-context, and current-window slots make the work-facing assignment explicit.

#Bounded specialization scouting and CheckpointReturn

When one human-plus-AI pair faces a new task family or candidate solution family, the governed work system may temporarily compose four distinct local roles inside the same dyad: a human-held OutcomeCriterionHolderRole, an AIScoutRole, an AISpecialistProbeRole, and a human-held CommitAuthorityRole. The payoff of the dyad is faster admissible specialization of the next move, not disappearance of the human decision step.

For this bounded dyadic work question, the pair declares one outcome criterion first, enumerates heterogeneous candidate approaches that may satisfy that target, spends a bounded scouting budget or probing budget before any committed approach is chosen, and returns one CheckpointReturn that compares the tested approaches rather than silently treating one successful probe as a committed rollout. A.15 governs this dyadic move and local role split only; it does not restate the checkpoint-record semantics of C.24 or the budget and guard enforcement of E.16.

Every CheckpointReturn carries:

• the declared outcome criterion and current TaskFamily
• the candidate approaches actually tested
• the evidence observed on each tested approach, including progress toward the named work-measure threshold and important failure signals
• the budget already burned and the residual budget still available
• the recommended next work move or reliance move: continue probing, commit to planned work, narrow the method or claim, apply the direct governing pattern for a non-A.15 claim, or stop
• the commit trigger named by value that would justify leaving the bounded probe

The return is candidate-approach evidence, burned and residual budget amounts, observed result, and commit-trigger condition. It is not the selected method, U.WorkPlan, performed U.Work, execution evidence/provenance relation, or rollout decision. Those claims need the project-side FPF kind and reference named by value before committed rollout.

Low-human-overlap approaches remain admissible here only while they stay tied to the declared outcome criterion, budget limits, and evidence/provenance relation by value.

#Boundary to A.15.4 Work-Relevant Source Restoration

Use A.15.4 when an encountered episteme, episteme publication, display, credential view, generated explanation, copied statement, provenance mark, dashboard tile, schema wording, API wording, or composed source chain is being used by appearance for a work claim, reliance claim, role-assignment currentness claim, status currentness claim, approval, permission, gate passage, evidence, engineering justification, release reliance, or performed U.Work.

A.15 itself keeps the kernel separation: U.Role, holder, context, U.Method, U.MethodDescription, U.WorkPlan, actual U.Work, and the U.RoleAssignment chain between them. The source-restoration question recovers the project-side FPF kind and reference named by value before the encountered source candidate or display can carry the work claim, reliance claim, or effect claim being made; that question belongs to A.15.4 or to the source-restoration pattern governing that reliance named there.

A principle scheme, functional diagram, scenario, screen, or explanation that makes an E.18.1 P2W carry-through structure recoverable may help the team plan work or find the needed source.

#Archetypal Grounding

The role-method-work alignment applies whenever the question under repair is holder-in-role, method description, intended plan, or performed work. Physical engineering, knowledge work, and socio-technical cases can all use the same distinction without turning A.15 into a universal process ontology.

Key takeaway from grounding: This side-by-side comparison reveals the power of the framework. A seemingly different activity like welding a car chassis and reviewing a scientific paper are shown to have the same underlying enactment structure. Both involve a Holder (a system) acting in a Role within a Context, using a Capability to enact a U.Method, citing a MethodDescription when a recipe or source is used to identify or constrain the method, and producing a specific, auditable instance of Work. This universality is what allows FPF to compare and align disparate domains without collapsing their local structure.

#Briefing guides orientation, not execution

Source set. A release team has one deployment method description, one current work plan, one approval or decision record when required, and the evidence records and evidence paths used to decide whether the rollout may proceed. A short rollout briefing is prepared for the daily stand-up.

Briefing slice. Status briefing only: rollback procedure appears verified in the current source bundle. Execution remains tied to the deployment method, work plan, required approval or decision record, and evidence path.

This briefing may orient the team and cue attention. If the team wants to execute from the briefing alone, use A.15.4 or the evidence, gate, decision, or assurance pattern governing the claim to recover the missing project-side kind and reference. Inside A.15, keep only the role, method, plan, and work-occurrence separation.

#P2W principle-scheme publication guides planning, not occurrence

Source set. A team has a principle scheme that shows an E.18.1 P2W carry-through structure for a fabrication task: signature or principle episteme, method-family selection, selected method, U.WorkPlan, performed U.Work, work-result record, and result measurement.

Published slice. For this batch family, method M-2 is selected from the declared method family; prepare work plan WP-17 before any run is recorded.

This publication may guide method inspection and work-planning preparation under A.15. A conforming use keeps selected method, U.WorkPlan, actual U.Work, work-result record, and result measurement distinct. If the publication is used for evidence, provenance, engineering justification, gate or constraint decision, material carrier, screen, export, OCR behavior, or publication-use, apply the governing pattern for that claim being made. If no project-side kind and reference named by value exists, create only a source-restoration request, decision-request record for the next decision, prospective work-plan entry, or explicit source-gap note.

#Scenario guides method selection, not performed work

Source set. A method-selection scenario says that material X is below threshold T, resource window W is available, and the fabrication cell is under setup condition S. The scenario is the source episteme or source publication for choosing between method families.

Published slice. Under scenario S, method family MF-2 is admissible for planning; choose the selected method and prepare the work plan before execution.

The scenario can guide method-family selection and work-planning preparation. Once the team selects a method or prepares a plan, record that project choice or plan as the selected A.15 selected-method, work-plan, or work-occurrence record named by value. If the scenario is used for evidence, gate, or engineering-justification reliance, first recover the project evidence path, gate or constraint decision, or engineering-justification record named by value under A.10, A.20, A.21, or B.3; otherwise record only a source-restoration request, decision-request record, prospective work-plan entry, or source-gap note.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto and Epist, Prag, Did. Scope: Universal for contextual enactment across engineering, operational, and knowledge-work settings.

Bias risks and mitigations:

• Governance bias (Gov): teams may over-treat role labels or approval displays as enough evidence that work happened. Mitigation: keep U.RoleAssignment, U.MethodDescription, U.WorkPlan, and U.Work distinct, and let only U.Work carry actuals and resource use.
• Architectural bias (Arch): modelers may pull roles or capabilities into structural part hierarchies because those diagrams are already present. Mitigation: preserve role and capability as context-bound assignment and ability values, not parts.
• Epistemic bias (Onto and Epist): a documented recipe or schedule can be mistaken for proof of execution. Mitigation: require the traceability chain from U.RoleAssignment and U.MethodDescription to dated U.Work.
• Pragmatic bias (Prag): teams may keep using one overloaded source-side "process" word because it feels faster. Mitigation: resolve "workflow", "schedule", and "what happened" source cues through U.Method, U.MethodDescription, U.WorkPlan, and U.Work.
• Didactic bias (Did): the chef analogy can make the pattern seem intuitive while hiding the need for explicit model links. Mitigation: pair the analogy with the canonical relations and checklist.

#Conformance Checklist

To preserve role-method-work modeling, check the following predicates.

#Common Anti-Patterns and How to Avoid Them

• Role-as-part. Do not place U.Role or U.Capability inside structural partOf decomposition; keep role as contextual assignment value and capability as ability value under stated conditions.
• Recipe-as-evidence. A U.MethodDescription or SOP may identify or constrain a method; dated U.Work records carry the occurrence claim.
• Plan-as-actual. Do not let schedules, calendars, or intended assignments stand in for actual execution; use U.WorkPlan for intent and U.Work for actuals.
• Capability-as-work. Do not treat possession of a capability as if the task has already been performed; capability enables execution under conditions but is not execution.
• Approval collapse. Keep approval or authorization speech acts distinct from the operational step they permit; model them as communicative U.Work when they institute a role, gate, or commitment effect.
• Process soup. Do not leave "process", "workflow", or "activity" uninterpreted in FPF-governed passages; resolve the source cue to U.Method, U.MethodDescription, U.WorkPlan, or U.Work.
• Briefing-as-execution-cue. A lighter review note, rollout summary, or redacted operations note may orient work; use A.15.4 or the source-restoration pattern governing that reliance before relying on it for execution, approval, gate, evidence, or plan claims.
• P2W publication as work occurrence. A principle scheme, functional diagram, scenario, screen, or explanation may guide selected method or work-planning moves named by value; recover the project-side FPF kind and reference named by value for any selected-method, work-plan, work-occurrence, result, evidence, gate, or engineering-justification claim, and keep the E.18.1 carry-through structure separate from those typed values.
• Source candidate or display as work source. A dashboard tile, credential display, copied approval, generated explanation, provenance label, command-like cue, or composed source chain is only a source candidate until A.15.4 recovers the project-side kind and reference named by value needed for the work or reliance claim under repair.

#Consequences

#Rationale

This pattern solves a problem that has plagued systems modeling for decades: the conflation of what a system is with what it does. Its rigor is not arbitrary but is grounded in several key intellectual traditions.

• Ontology Engineering: The pattern is a direct application of best practices from foundational ontologies (like UFO), which have long insisted on the distinction between endurants (objects like a U.System) and perdurants (events and performed occurrences such as U.Work), and between intrinsic properties and relational roles. FPF makes these powerful distinctions accessible to practicing engineers.
• Process-theory source tradition: Formalisms like the Pi-calculus or Petri Nets model dynamic interactions under terms often translated as processes. A.15 does not import process as a new FPF object; it maps the useful local use to U.Method, U.MethodDescription, U.WorkPlan, and dated U.Work. The U.Work entity can be seen as an occurrence recognized by such a source tradition, but FPF adds the crucial context of the Role, Capability, enacted U.Method, and MethodDescription source that make the occurrence inspectable.
• Pragmatism and Practice: The framework is deeply pragmatic. The distinctions it makes (e.g., between a MethodDescription and U.Work) are precisely the ones that matter in the real world of project management, compliance, and debugging. When a failure occurs, a manager needs to know: was the recipe wrong (MethodDescription), did the chef lack the skill (Capability), or did they just make a mistake this one time (U.Work)? This framework provides the vocabulary to ask and answer that question precisely.

By creating this clean, stratified alignment for enactment, FPF provides a stable and scalable foundation for downstream resource accounting, decision, constraint, gate, evidence, assurance, ethics, and transformation patterns without letting any one of those neighboring claims collapse into A.15.

#SoTA Alignment: Adopted and Adapted Invariants and Rejected Shortcuts

SoTA alignment rule. Read each row here as source idea -> local FPF invariant -> practical local test -> popular shortcut rejected. A source citation governs nothing by reputation; it counts only when the cited idea is translated into the Solution, conformance checks, boundary rules, worked slices, and Relations of this pattern.

Claim 1. Best-known current workflow, digital-thread, and service-operations source traditions keep recipe, plan, and execution separate.

Practice source, local alignment, and adoption decision. Contemporary process-modeling source traditions, service operations, and auditability practice after 2015 separate procedure, schedule, and executed occurrence because otherwise paper compliance becomes indistinguishable from completed work. In the manufacturing and peer-review slices above, this means a procedure or calendar never counts as the weld or the review itself. This pattern adopts that separation, adapts it through U.Method, U.MethodDescription, U.WorkPlan, and U.Work, and rejects the shortcut where one undifferentiated "process" label carries all three meanings.

Claim 2. Best-known current accountability practice keeps actor-in-context explicit rather than attributing work to a role label or a document.

Practice source, local alignment, and adoption decision. Contemporary service delivery, incident practice, and role-accountability practice distinguish accountable assignee, governing procedure, and actual run record because after-the-fact review depends on knowing who acted, under what role, and under which method. In the slices above, that is why the welding robot or peer-review assignee acts under U.RoleAssignment rather than the role or guideline acting on its own. This pattern adopts explicit actor-in-context attribution through U.RoleAssignment, adapts it to bounded-context semantics, and rejects anonymous work logs and role-as-part modeling.

Claim 3. Best-known current approval and execution practice treats communicative gate acts and operational acts as distinct kinds of work.

Practice source, local alignment, and adoption decision. Contemporary release, compliance, and safety-critical practice separates approval, authorization, and review acts from the operational steps they permit because authority change and world change are not the same event. In the examples above, that means an approval is not the same work as a deployment or a weld. This pattern adopts that split, adapts it through communicative versus operational U.Work kinds, and rejects the collapse of approval into the thing being approved.

Local claim. The FPF-governed SoTA claim for this pattern is practical and narrow: contextual enactment remains reviewable only when role, method, plan, and work stay distinct enough that audits can tell whether the problem was in the assignment, the recipe, the schedule, the capability, or the run itself.

Claim 4. Best-known current agentic work practice treats fast bounded specialization as a checkpointed scout and probe discipline rather than as a naked winner claim.

Practice source, local alignment, and adoption decision. Contemporary agentic tool-use, adaptive method-selection, and human-in-the-loop work-control practice separates bounded exploration from committed rollout because a successful probe is not yet an admissible committed approach. In the working moment above, that is why the pair returns one CheckpointReturn with candidate approaches, evidence, burned and residual budget, and a commit trigger rather than only a winner label. This pattern adopts checkpointed scout and probe discipline, adapts it through the dyad-local roles and CheckpointReturn, and rejects the shortcut where an early probe silently becomes a committed rollout.

For visible credential, provenance, dashboard, explanation, or composed-source cases that need project-side FPF kind and reference named by value before work or reliance, use A.15.4. The A.15 family carries only the role, method, plan, and work portion of the case.

The nearest recovery loci are the manufacturing, peer-review, rollout briefing, CC-A15-7, CC-A15-10, CC-A15-12, and the boundary to A.15.4. If a SoTA row cannot be recovered through those local checks, do not let the source citation stand in for the local A.15 rule.

#Relations

• Directly applies: A.7 Strict Distinction for the role, method, method-description, plan, and work split.
• Builds upon: A.2 for U.Role, A.2.1 for U.RoleAssignment, A.2.2 for U.Capability, A.2.5 for role-state admission, A.2.7 for role relation structure, A.6.5 for slot-relation discipline used by assignment and relation declarations, A.3.1 for U.Method, A.3.2 for U.MethodDescription, A.3.3 for U.Dynamics, A.3.4 for U.Transformation, A.15.1 for U.Work, A.15.2 for U.WorkPlan, and A.15.3 for slot-filling plan items.
• Coordinates with: A.15.4 for work-relevant source restoration; E.10 and E.10.ARCH for source cue recovery around process, workflow, activity, schedule, algorithm, solver, and procedure wording; A.6, A.6.B, and A.6.C for mixed boundary, policy, API, schema, agreement-like, or promise wording; A.10 for evidence, currentness, and provenance; B.3 for assurance claims; A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef; A.20 for ConstraintValidity status or witness; C.28 for causal-use admissibility; C.29 for mathematical-lens use; E.18.1 for P2W carry-through; and E.17.EFP for generated-explanation faithfulness or source-finding.
• Used by: patterns that need to keep systems or acting holons with role assignments, method descriptions, work plans, work occurrences, result records, and source-restoration claims distinct. A.15 is not a generic process ontology, workflow engine, evidence graph, gate pattern, or publication pattern.

#Coordinated-work evidence and distributed-state relation note

Use A.15 first when the claim is about who acts, by which method, under which role, under which work plan, producing which work result. Coordinated work, routine skill, team alignment, tacit knowledge, and role-method fit are not quantum-like by default.

Application moves:

1. Name the role, method, and work result before naming any distributed state.
2. State which work traces, records, events, observations, reports, metrics, U.Work occurrences, or RoleEnactmentFact records make the coordination visible.
3. Ask whether role-method-work alignment alone explains the case. If yes, stay in A.15.
4. If no participant statement, local component report, single evidence record, dashboard, or exported representation carries the inferred state faithfully enough for the intended state use, add a C.26.2 low-recoverability distributed-state reading.
5. State the weakest evidence-bound state-reading claim, time window, rival explanations, and export loss.
6. Carry evidence use through A.10 and assurance claims through B.3 when the reading will guide work, reliance, audit, readiness, release, or compliance.

Add a C.26.2 low-recoverability distributed-state reading only when coordinated work is being used as evidence for a state that no participant statement, local component report, single evidence record, dashboard, or exported representation carries faithfully enough for the intended state use. In C.26.2 terms, the reading is a minimal evidence-bound U.Episteme claim under carriers, window, rivals, and export limits; it is not a group mind, not performed work, not evidence sufficiency, and not assurance by itself. That evidence-bound reading states:

Useful outputs:

• an A.15 work-alignment claim when work roles explain the case;
• a C.26.2 low-recoverability distributed-state reading when coordination evidence survives ordinary rivals;
• an A.10 evidence path or B.3 assurance claim path when the distributed-state reading will be used as evidence or assurance for a work claim or reliance claim;
• no distributed-state reading when evidence sources, rivals, or time window cannot be named.

#C.29 mathematical-lens use relation

If a mathematical lens helps select a method, compare method families, shape a work plan, or diagnose work, use C.29 only for the fit of that mathematical diagnostic or method-selection reason. The next concrete object remains under the A.15 family: ChoiceResult or local choice record when a choice is made, selected method or method-family selection when the method-governance claim is being made, U.WorkPlan for a plan, performed U.Work and work-result record for execution, and an A.15.4 source-restoration reference when the issue is work-relevant source restoration. A mathematical lens may explain why a diagnostic distinction is useful; it does not make a plan into performed work or a method explanation into execution evidence.

#P2W Work-Family Split

When a P2W use under E.18.1 produces a WorkPlanning relation, this family carries the split among selected method, U.WorkPlan, SlotFillingsPlanItem, performed U.Work, and result-related records. A P2W principle scheme, functional diagram, or scenario may guide method inspection and work-planning preparation only after the current work-family object is named.

WorkPlanning may place evidence-reference hooks and source-currentness requests for the governing pattern that carries the relation under repair. If the relation under repair is evidence, gate passage, launch-value finalization, performed work, result measurement, assurance, or refresh, name that relation before relying on the work-planning record.

#P2W Performed-Work Relation

When E.18.1 reaches performed work, this family keeps the current kind as U.Work. WorkEnactment wording is explanatory only: it points to dated performed work, not to a second work kind.

A performed-work record may cite a U.WorkPlan and planned baseline, while recording launch values, actuals, substitutions, variance, telemetry, outputs, outcome, and result-related records in the performed-work occurrence. Comparator, transport, PrincipleFrame, U.Signature(profile=FormalSubstrate), evidence, assurance, and gate relations are named separately when those claims are being made.

#P2W Integration As Role Enactability

When E.18.1 uses integration wording to mean role enactability under interface constraints, this family carries the role, method, plan, and performed-work part of the claim. Name the selected role, U.RoleAssignment when the role-assignment claim is being made, method or method description, relevant U.WorkPlan or performed U.Work, and the interface constraints governed by the architecture or module-interface pattern.

If the same phrase also raises connected artifacts, telemetry, acceptance records, diagrams, module-interface claims, selected-structure claims, checks, gates, evidence, or provenance, split those relations before relying on the integration wording.

#Lowering, Repair, and Refresh Conditions

Lower an A.15 claim when the role, holder, bounded context, method, method description, work plan, performed work occurrence, or capability check cannot be named at the granularity required by the next work move. A weaker but admissible result is a separation note, source-gap note, source-restoration request, decision-request record for the next decision, or prospective work-plan entry.

Repair the local alignment frame when a subsequent source shows that the role assignment, method description, work-plan baseline, performed-work occurrence, capability threshold, status-currentness record, or source-currentness window was wrong for the claimed move. Repair only the changed relation: do not rewrite the method when only the work plan changed, do not rewrite the work occurrence when only the evidence path changed, and do not treat a source-restoration request as carrying a non-A.15 claim.

Refresh the A.15 use before relying on it across a new context, new role assignment, new method family, new work plan, new execution window, new result measurement, or new evidence, assurance, gate, source-restoration, or mathematical-lens relation. If the issue under repair after refresh is no longer role-method-work alignment, use the governing pattern for that relation and keep only the remaining A.15 separation here.

#A.15:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)