#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-memory 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 action-guiding 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 lives, 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/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 about a "process" without separating recipe, plan, capability, and executed work.

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

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

Working action path.

1. Name the role/holder/context distinction that is live.
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 current support, plan, run a bounded reversible probe, narrow scope, hand off to the project source that governs the live claim/effect, or stop.
5. If a visible item is being used as approval, permission, gate passage, evidence, engineering justification, role/status currentness, release support, or performed work by appearance, move to A.15.4 Work-Relevant Source Restoration and return here only for the role/method/plan/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 the neighboring A.15.4 cluster member.

Minimum sufficient next move. Choose the minimum sufficient next move, recover only the project source record needed for that move, and do not raise the claim beyond that recovered support.

Supported-source green path. If the required project source is present and its scope/window match the live role/method/plan/work move, proceed inside that bounded support. If not, narrow scope, run a bounded reversible probe, source-find or create only a prospective repair/request/decision/work-plan/source-gap record, or block only the unsupported claim/effect; do not treat the repair record as past evidence, approval, gate passage, performed U.Work, release permission, or assurance.

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.

Load-bearing use. Open the fuller alignment frame when the item is about to guide planned work, actual work, role/status attribution, release/reliance, disputed responsibility, or cross-context use. Use A.15.4 when the live issue is whether a visible item has the exact project source support needed for that work/reliance claim/effect.

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

Supported-use examples.

Governed object 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.

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

What goes wrong if missed. Teams collapse role, recipe, plan, capability, and actual run into one fuzzy "process" story, then mistake documentation for execution, capability for evidence, schedule for occurrence, or a weaker 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 / A.16.1), only boundary/policy wording without a live role-method-work question (A.6 / A.6.B), or work-relevant source restoration for a visible item (A.15.4).

Neighboring project records and governing patterns. A.15.1 governs dated execution records, A.15.2 schedule/baseline planning records, A.15.3 slot-filling plan items, A.15.4 work-relevant source restoration, B.5.1 the simple engineering-process reading, F.11 method/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, support basis, counterfactual sampling realizability, and supported/unsupported use.

Common wrong escalations / required project records. If the first honest encountered item is still only a cue, keep it under A.16 / A.16.1; if the live question is boundary, promise, agreement-like service, or policy wording, recover the A.6-governed claim record; if you only need one executed occurrence rather than the alignment frame, recover the A.15.1 dated work-occurrence record; if a visible item is being used for work/reliance support, use A.15.4.

Boundary to weakened renderings. A lighter briefing, summary, redacted note, or coarsened rendering may help orient work or cue attention, but it does not become a sufficient source for work execution, an implementation checklist, a work plan, a work occurrence, an approval, a gate decision, or execution evidence by convenience alone. If a weaker rendering needs return to the governing method, plan, approval, gate, or evidence source before work can proceed admissibly, keep that boundary explicit here and treat the weaker-source relation as A.6.3.CSC Controlled Semantic Coarsening governed rather than treating the weakened rendering as executable.

Recognition block vs assurance block. Read At a glance, Use this when, Start here when, First output, Working action path, Supported-use examples, Governed object, Governing move, What goes wrong if missed, What this buys, and Not this pattern when as the primary recognition block. Read the entity distinctions, canonical relations, checklist, and relations below as assurance blocks that tighten the same alignment-frame claim; they do not widen the pattern into one single work occurrence, one cue note, one wording pattern, one source-restoration pattern, or one undifferentiated "process" object.

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 about a "process" without clarifying if they mean the documented procedure, the team's ability to execute it, or a specific execution 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 about a "process" without clarifying if they mean the documented procedure, the team's ability to execute it, or a specific execution that happened last Tuesday.

This pattern provides the canonical alignment for modeling contextual enactment in FPF, serving as the ultimate implementation of the Strict Distinction Principle (A.7). It weaves together several foundational concepts into a single, coherent model of how intended work becomes planned and actual U.Work:

• A.2 (Contextual Role Assignment): Provides the Holder#Role:Context structure for assigning roles.
• A.4 (Temporal Duality): Provides the strict separation between design-time and run-time.
• A.12 (External Transformer): Ensures that all performed U.Work is attributed to an external agent.

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/calendars and A.15.1 U.Work for dated execution. Ambiguous terms like "process / workflow / schedule" are constrained by L-PROC / L-FUNC / L-SCHED (E-cluster): a workflow is a Method/MethodDescription, a schedule is a WorkPlan, and what happened is Work.

Terminology note (L-ACT). The words action/activity are not normative in the kernel. When a generic "doing" is needed, we use the didactic term enactment (not a type). Normative references must be to U.Method / U.MethodDescription / U.Work / U.WorkPlan. See lexical rules L-PROC / L-FUNC / L-SCHED / L-ACT.

#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 "Process/Activity": The overloaded term "process" is used indiscriminately to refer to all of the above, creating a fog of miscommunication that paralyzes decision-making. Generic doing/activity terms must be resolved via L-ACT to Method/MethodDescription (recipe), WorkPlan (schedule), or Work (run).

#Forces

#Solution

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 a function but is not the function itself.
• 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 (the SOP/algorithm/proof/recipe on a carrier).
• U.Capability: An attribute of a U.System that represents its ability to perform the work described in a MethodDescription. This is the "skill" or "know-how."
• 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 formal assertion Holder#Role:Context that links a specific U.Holon to a U.Role within a U.BoundedContext. This holder-to-role assignment link is what "activates" the requirements associated with a role.

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

• U.Work: An occurrence or event. It is the concrete, dated, resource-consuming execution of a U.MethodDescription by a Holder acting under a U.RoleAssignment; capability checks are evaluated at run time against the holder. 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/organizational frame (e.g., commitments, authority states, 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 anyone in the ChefRole must have the Capability to follow the recipes in the cookbook.
• 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 a set of precise, normative relations that form an unbreakable causal chain. The following diagram illustrates this flow from the abstract context down to the concrete execution.

graph TD
    subgraph Design-Time Scope (Tᴰ)
        A[U.BoundedContext] -- defines --> B(U.Role)
        M[U.Method] -- isDescribedBy --> D[U.MethodDescription]
        Cap[U.Capability] -- supports --> 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

    RB -- performedBy --> W
    W  -- isExecutionOf --> D

    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 recipe on a carrier.
• isExecutionOf(Work, MethodDescription): A specific U.Work is a run-time realization of a design-time MethodDescription. Capability checks are evaluated against the holder at run time.
• performedBy(Work, RoleAssignment): A U.Work is always performed by a specific Agent (a U.RoleAssignment). This links the work occurrence to the actor-in-context.

At run time, capability thresholds declared by the context/spec 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.MethodDescription that governed it, the U.Method it describes, and the Agent (Holder + Role + Context) that was authorized and responsible for its execution.

#Bounded specialization scouting and CheckpointReturn

When one human-plus-AI pair faces a new task family or candidate solution corridor, the governed work system may temporarily compose four distinct local roles inside the same dyad: a human-side UtilityOwnerRole, an AIScoutRole, an AISpecialistProbeRole, and a human-side 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 should declare one utility target first, enumerate heterogeneous candidate approaches that may satisfy that target, spend a bounded scout or probe budget before any committed approach is chosen, and return 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/guard enforcement of E.16.

Every CheckpointReturn should carry:

• the declared utility target 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/reliance move: continue probing, commit to planned work, narrow the method or claim, hand off, or stop
• the exact commit trigger that would justify leaving the probe state

The return is candidate support, budget posture, observed result, and commit-trigger support. It is not the selected method, not a U.WorkPlan, not performed U.Work, not execution evidence, and not rollout authority until the project source that governs that stronger claim exists.

Low-human-overlap approaches remain admissible here only while they stay tied to the declared utility target, budget guard rails, and evidence basis by value.

#Boundary to A.15.4 Work-Relevant Source Restoration

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

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 asks which exact project source record must be recovered before the encountered item can support the live work/reliance claim/effect; that question belongs to A.15.4 or to the exact neighboring source pattern named there.

A principle scheme, functional diagram, scenario, screen, or explanation that makes a P2W chain readable may help the team plan work or find the needed source, but it does not become performed U.Work, work authority, evidence, gate passage, engineering justification, or release permission by publication alone.

#Archetypal Grounding

The Contextual Action Framework is universal. It applies identically to the modeling of physical engineering processes, knowledge work, and socio-technical systems.

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 exact same underlying causal structure. Both involve a Holder (a system) acting in a Role within a Context, using a Capability described by a MethodDescription to produce a specific, auditable instance of Work. This universality is what allows FPF to compare and align disparate domains without collapsing their local structure.

#Briefing is not execution authority

Source set. A release team has one governing deployment method description, one current work plan, one approval work item, and the evidence carriers / 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 path appears verified in the current source bundle. Deployment authority remains with the governing approval record and work plan.

This briefing may orient the team and cue attention, but it is not the governing execution authority by itself. Work can proceed admissibly only when the underlying method description, current work plan, required approval records, and evidence carriers / evidence paths stay explicit and reopenable. If the team wants to treat the briefing as sufficient to execute, the case leaves simple orientation and must reopen the governing method, plan, approval, or evidence source rather than treating the shortened note as the work-enactment authority.

#P2W principle-scheme publication supports planning, not occurrence

Source set. A team has a principle scheme that shows the P2W principles-to-work transduction chain for a fabrication task: signature or principle material, 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 support method inspection and work-planning preparation under A.15. It does not say that the work already occurred, that the batch may pass a gate, that evidence is sufficient, or that engineering justification is complete. A conforming use keeps the selected method, U.WorkPlan, actual U.Work, work-result record, and result measurement distinct. Evidence/provenance use requires a project evidence path governed by A.10; engineering-justification use requires an engineering-justification record governed by B.3; gate use requires the project gate/constraint decision governed by A.20 / A.21; carrier, screen, export, or OCR behavior requires the carrier/front-end record governed by A.7; publication/readability questions stay with E.17 and the relevant A.6.3.* relation.

#Scenario supports 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 in setup state S. The scenario is source material 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 support method-family selection and work-planning preparation. It is not the selected method by itself, not a U.WorkPlan, not performed U.Work, and not evidence that the work result was achieved. Once the team selects a method or prepares a plan, record that project choice or plan as the exact A.15 method/plan/work material; if the scenario is being used as evidence, gate passage, or engineering justification, first recover the existing project evidence path, gate/constraint decision, or engineering-justification record governed by A.10, A.20 / A.21, or B.3. If no existing project source carries the needed load-bearing claim, create only a prospective repair/request/decision/work-plan/source-gap record; do not backdate evidence, approval, gate passage, performed U.Work, release permission, engineering justification, or assurance for the earlier scenario-based claim.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/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 contextual-functional entities, not parts.
• Epistemic bias (Onto/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 "process" word because it feels faster. Mitigation: resolve "workflow / schedule / what happened" 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, a conforming model/use SHALL satisfy the following checks.

#Common Anti-Patterns and How to Avoid Them

• Role-as-part. Do not place U.Role or U.Capability inside structural partOf decomposition; keep them contextual and functional.
• Recipe-as-evidence. Do not treat a U.MethodDescription or SOP as proof that work occurred; record dated U.Work instead.
• 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 supports execution but is not execution.
• Approval collapse. Do not merge approval or authorization speech acts into the operational step they open; model them as distinct communicative U.Work when they change authority state.
• Process soup. Do not leave "process / workflow / activity" uninterpreted in load-bearing passages; resolve the word to method, plan, or work.
• Briefing-as-execution-cue. Do not treat a lighter review note, rollout summary, or redacted operations note as if it already authorized execution, approval, gate passage, or a work plan. Reopen the governing method, plan, approval, or evidence source before work proceeds.
• P2W publication as work occurrence. Do not treat a principle scheme, functional diagram, scenario, screen, or explanation as if it were performed U.Work, evidence, gate passage, or engineering justification. Use it only for the exact method or work-planning support it carries, then recover the project source record that actually supports any unsupported claim.
• Visible item as work source. Do not treat a dashboard tile, credential display, copied approval, generated explanation, provenance label, command-like cue, or composed source chain as approval, permission, gate passage, role/status currentness, work occurrence, evidence, or assurance by appearance. Use A.15.4 for the source-restoration question and keep A.15 for role/method/plan/work separation.

#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/processes like U.Work), and between intrinsic properties and relational roles. FPF makes these powerful distinctions accessible to practicing engineers.
• Process Theory: Formalisms like the Pi-calculus or Petri Nets model processes as dynamic interactions. The FPF Contextual Action Framework adds a more semantically rich enactment abstraction on top of such formalisms. The U.Work entity can be seen as an instance of a process, but FPF adds the crucial context of the Role, Capability, and MethodDescription that govern it.
• 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 all of its more advanced patterns, from resource management (Resrc-CAL) and decision theory (Decsn-CAL) to ethics (Norm-CAL).

#SoTA Alignment: Adopted/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 practice keeps recipe, plan, and execution separate.

Practice / source / alignment / adoption. Contemporary process modeling, service operations, and auditability practice after 2015 separates 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" object carries all three loads.

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 / alignment / adoption. Contemporary governance, service delivery, and incident practice distinguishes accountable assignee, governing procedure, and actual run record because post-hoc review depends on knowing who acted, under what role, and under which method. In the slices above, that is why the robot or reviewer 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 / alignment / adoption. 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 stance. The load-bearing 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/probe discipline rather than as a naked winner claim.

Practice / source / alignment / adoption. Contemporary agentic tool-use, adaptive workflow, and human-in-the-loop governance 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/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 exact project-source support before work/reliance, use A.15.4. A.15 receives only the returned role/method/plan/work part of the case.

The nearest recovery anchors 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 Implements: A.7 Strict Distinction.
• Builds Upon: A.2 (U.Role), A.2.1 (U.RoleAssignment), A.4 (Temporal Duality), A.12 (External Transformer).
• Is Used By / Provides Foundation For:
  • C.4 Method-CAL: Provides the formal definition of U.MethodDescription and the Gamma_method operator for composing them.
  • C.5 Resrc-CAL: Provides the U.Work entity to which resource consumption is attached.
  • B.1.6 Gamma_work: The aggregation operator for U.Work.
  • B.4 Canonical Evolution Loop: The entire loop is a sequence of U.Work instances that modify MethodDescriptions.
  • A.15.2 U.WorkPlan: plan-run split, baselines and variance against U.Work.
  • C.28 CausalUse-CAL: causal-use meaning and support for intervention, counterfactual sampling, target-trial emulation, and causal evidence work; A.15 keeps the role/method/work chain.
• Constrains: Any FPF pattern that models method, plan, work occurrence, or overloaded process language must use this framework to be conformant. It serves as the canonical alignment for contextual enactment in the FPF ecosystem.
• Coordinates with: L-PROC / L-FUNC / L-SCHED (E-cluster) for lexical disambiguation of process / workflow / schedule.
• Coordinates with: A.15.4 for work-relevant source restoration; A.6, A.6.B, and A.6.C for mixed boundary/policy/API/schema wording; A.10 for evidence/currentness/provenance; B.3 for assurance claims; A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef; A.20 for ConstraintValidity status/witness; A.15.1 for release/deployment work occurrence; and E.17.EFP for generated-explanation faithfulness/source-finding.

#Coordinated-work evidence and quantum-like reading 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.

Action path:

1. Name the role, method, and work result before naming any distributed state.
2. State which work traces, records, events, observations, reports, metrics, or role enactments 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 carrier, dashboard, or exported representation carries the inferred state faithfully enough for the supported state use, add a C.26.2 distributed-state reading.
5. State the weakest claim, time window, rival explanations, and export loss.
6. Carry evidence support through A.10 and assurance claims through B.3 when the claim supports work/reliance, audit, readiness, release, or compliance.

Add a C.26.2 distributed-state reading only when coordinated work is being used as evidence for a state that no participant statement, local component report, single carrier, dashboard, or exported representation carries faithfully enough for the supported state use. That evidence-bound claim states:

Useful outputs:

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

#A.15:End

Last Updated: 2026-05-12 — this section last modified in upstream FPF commit f73766dd (github.com/ailev/FPF)