#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 entry-bearing 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 one traceable chain from U.RoleAssignment through the governing method description to the actual U.Work occurrence or intended U.WorkPlan.

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 reroute.

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 taking action, 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), or only boundary/policy wording without a live role-method-work question (A.6 / A.6.B).

Typical next governing patterns/sources. A.15.1 for dated execution, A.15.2 for schedule/baseline planning, A.15.3 for slot-filling plan items, B.5.1 for the simple engineering-process reading, F.11 when method/work vocabulary itself must be aligned across contexts, and F.17 when the result should land on a human-facing work sheet.

Causal-use work boundary. Realized counterfactual-rung sampling, 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 owns the causal-use question, causality-ladder rung, causal estimand, support basis, counterfactual sampling realizability, and supported/unsupported use.

Common wrong escalations / reroutes. If the first honest artefact is still only a cue, reroute to A.16 / A.16.1; if the live question is boundary, promise, agreement-like service, or policy wording, reroute to A.6; if you only need one executed occurrence rather than the alignment frame, continue straight to A.15.1.

Authority-looking first-use split (subordinate work-reliance stress case). Use this compact entry only when an approval-, permission-, gate-, command-, credential-, delegation-, revocation-, status-, provenance-, dashboard-, copied-review-, generated-explanation-, schema/API-, or composed-chain case is about to guide work, action, release/reliance, execution evidence, approval use, role/status use, or another operational move. The trigger is the attempted use, not the displayed word. This subsection stays subordinate to the role/method/plan/work alignment frame; the detailed source-exit tables, role prompts, display guidance, lint cues, and stress cases live under A.15:4.4 after the core solution.

Here "authority-looking case" is only a recognition phrase for the encountered situation; it is not a U.* kind, not a profile, not a score, and not a new evidence source or governing source.

First stress-case output. Name the intended stronger use, actor/role, affected object/context/window, visible item, exact source exit or safe next move, and the stronger uses still unsupported. If exact support is incomplete, use the item only for orientation/source-finding, reopen or refresh the exact source, narrow the scope/window, run a bounded reversible probe under an explicit U.WorkPlan, route repair to the accountable source role, or block only the unsupported stronger reliance.

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 action cue, implementation checklist, work plan, work occurrence, approval, gate, or execution authority by convenience alone. If a weaker rendering needs return to a stronger source before work can proceed admissibly, keep that boundary explicit here and use A.6.3.CSC Controlled Semantic Coarsening for the weaker-source relation 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, Governed object, Governing move, and What this buys as the primary recognition block. Read the authority-looking first-use split as a specialized work-reliance stress case, and 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, 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 split
• U.WorkPlan vs U.Work
• contextual enactment
• coordinated-work evidence
• work-reliance stress case
• authority-looking briefing/source exit
• checkpoint return
• weakened briefing.

#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 intention becomes action:

• 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 actions are attributed to an external agent.

The intent of this pattern is to establish a normative, unambiguous vocabulary and set of relations for describing the entire evolution of an action, from the specification of a capability to its concrete, resource-consuming execution.

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 bill-of-materials (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. Activity/action 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 action. 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 actions 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 action 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 route is chosen, and return one CheckpointReturn that compares the tested approaches rather than silently treating one successful probe as a committed rollout. A.15 owns this dyadic move and local role split only; it does not re-own 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 action: continue probing, commit, narrow, hand off, or stop
• the exact commit trigger that would justify leaving the probe state

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.

#Authority-looking work-reliance stress case

Authority-looking first-use split (subordinate work-reliance stress case). Use this subsection when an approval-, permission-, gate-, command-, credential-, delegation-, revocation-, status-, provenance-, dashboard-, copied-review-, generated-explanation-, schema/API-, or composed-chain case is about to be used as a work cue, action basis, release/reliance basis, execution basis, approval-use basis, role/status-use basis, or next operational move. The trigger is the attempted use, not the wording. This subsection does not change the governed object of A.15: it uses the role/method/plan/work separation to decide whether the encountered case has exact work-relevant support here or must exit to another FPF pattern before stronger reliance.

Here "authority-looking case" is only a recognition phrase for the encountered situation; it is not a U.* kind, not a profile, not a score, and not a new evidence source or governing source.

The central behaviour is: name the intended stronger use, choose the minimum sufficient next move, recover only the source needed for that move, and do not raise claim strength beyond that recovered support. If the exact governing source is already available, cite that source directly rather than routing through wording analysis.

Positive repaired path. A visible item becomes usable for action or reliance when the team can pair it with the exact governing source, affected actor/action/object/context/window, and source-supported use. The repaired outcome is the smallest admissible action/reliance statement plus the unsupported stronger uses that remain blocked.

Load posture by intended stronger use:

A small A.15 note is enough for the first posture:

When exact source support is incomplete, choose one admissible degraded-operation move after naming the intended stronger use; pick the lightest move that preserves practical action and source recoverability:

1. Use the item only for orientation or source-finding.
2. Reopen the exact source or refresh status/currentness.
3. Narrow actor/action/object/context/window until the recovered source really covers the move.
4. Run a bounded reversible probe under an explicit U.WorkPlan when no external-impact reliance is being made.
5. Ask the accountable issuer, gate source, evidence source, role/status source, or boundary source to expose or repair the missing source.
6. Repair the U.WorkPlan, U.MethodDescription, dashboard label, source link, or boundary wording that made the overread plausible.
7. Proceed only inside the recovered scope/window.
8. Block only the stronger reliance that lacks source support.

Broken-source repair route. If the exact source is required but unavailable to the acting user, route the repair to the accountable issuer/source role, gate source role, evidence source role, role/status source role, or boundary source role. The acting user records the blocked stronger use and the source to expose or repair, then proceeds only with the safe narrowed move available under recovered support.

Visible items are carriers, renderings, or cues unless another FPF source gives them stronger typed status for the live use. Do not treat a file, display, dashboard tile, model card, credential view, or generated text as the object, work occurrence, gate decision, role/status, evidence relation, or assurance claim by presentation alone.

Adversarial misuse guard. Do not let release pressure, delegated pressure, compliance pressure, green-dashboard pressure, or copied/generated wording convert a cue into action support. Pressure may trigger source recovery or scope narrowing; it does not replace the exact governing source.

Source exits for stronger use:

• cue-only orientation: use only for attention or source-finding; stay with A.16 / A.16.1 for pre-articulation cues or A.6.A for action invitation. Cue-only orientation is not action guidance, work plan, gate passage, approval, work occurrence evidence, or assurance.

• issuing, approval, authorization, delegation, or revocation act: cite A.2.9 U.SpeechAct / SpeechActRef, including act type, actor/role, affected object, judgement context, window, carrier/evidence refs when currentness matters, and instituted effects if claimed; because U.SpeechAct <: U.Work, the same act can satisfy dated work-occurrence evidence only when it is used as that communicative work occurrence;

• role or status reliance: cite A.2.1 / U.RoleAssignment, a status-changing U.SpeechAct, a governing context-state record, a credential proof/status result under A.10, or an A.21 GateDecision when the status is gate-owned; do not infer a status kind from a label;

• deontic permission, obligation, prohibition, or recommendation-as-duty: cite U.Commitment / A.2.8 and the instituting SpeechActRef when provenance matters; if "permission" means admissibility predicate, gate passage, authorization act, role/status effect, credential status, cue, or advice, route to A.6.B, A.21, A.2.9, A.2.1, A.10, A.16, or A.6.A instead;

• boundary, policy, API, schema, "allowed", "authorized", "approved", "recommended", or "guaranteed" wording: split the statement through A.6 / A.6.B; route agreement-like guarantee, SLA, promise, or contract-bearing wording through A.6.C, A.2.3, A.2.8, and A.2.9 before action reliance;

• gate decision or gate passage: cite A.21 OperationalGate(profile), GateDecision, GateDecisionRationale, DecisionLogRef, gate profile/version, check set, scope/window, and replay/freshness pins;

• constraint or flow-validity witness: cite A.20 ConstraintValidity status/witness, GateCheckRef.aspect = ConstraintValidity, path/window/sentinel/pins as applicable; this is not the same thing as a gate decision;

• release/deployment/rollback work occurred: cite A.15.1 dated U.Work occurrence and the A.10 evidence carrier path; a gate decision or command-like cue is not execution evidence;

• evidence, provenance, authenticity, currentness, copied-source, or generated-source support: exit to A.10; evidence support does not approve, permit, execute, pass a gate, or raise assurance by itself;

• assurance, readiness, safety, compliance, trust, release confidence, R, F, G, or CL increase: exit to B.3;

• generated explanation: use E.17.EFP for explanation faithfulness or source-finding relation, then require A.10 claim-level source support for every operative claim that will be relied on.

• approval-use split: if approval means someone approved something, cite A.2.9 U.SpeechAct / SpeechActRef; if the approval institutes a deontic binding, cite A.2.8 U.Commitment and the instituting act; if it means a gate passed, cite A.21 GateDecision / DecisionLogRef; if it is being used as evidence that release or other work occurred, cite A.15.1 dated U.Work plus A.10; if it is only approval wording in boundary, API, policy, or schema prose, split through A.6 / A.6.B; if it is evidence of approval, exit to A.10; if it is confidence because something was approved, use B.3 only when a typed assurance claim is live.

• permission-use split: if permission is a deontic relation, cite A.2.8 U.Commitment and the instituting source; if it is an admissibility predicate, cite the A.6.B A-* claim; if it means gate passage, cite A.21; if it means an authorization act, cite A.2.9; if it changes or depends on role/status, cite A.2.1 or status-changing support; if it means credential status, use A.10; if it is only a UI label, badge, dashboard display, or permission-looking wording, treat it as orientation/source-finding until the exact source is recovered.

• authorization-use split: if authorization means a speech act authorizing, cite A.2.9; if it means a policy/admissibility predicate over subject, action, object, context, and policy version, split through A.6.B; if it means gate decision or gate passage, cite A.21; if it means access proof, credential proof, status proof, or currentness, use A.10; if it means role assignment or role/status effect, cite A.2.1 or status-changing support; if it is being used to say execution happened, do not use authorization as evidence of execution, cite A.15.1 dated U.Work plus A.10 instead.

Return products for loop closure:

Stronger action or reliance - especially external-impact, irreversible, release-bearing, role/status-bearing, gate-bearing, compliance/safety-bearing, delegated, contested, or assurance-bearing use - is admissible only for the actor, action, affected object, audience, scope, environment, version, policy context, operational mode, and time/window for which exact governing FPF support is recoverable. Cue-only, source-finding, learning, and bounded reversible probes stay lightweight and do not require a full source dossier.

Quick dispositions:

| Rollback command-like cue | Treat as cue or action invitation unless exact command/authorization, work occurrence, execution result, or gate support is recoverable. | | Generated explanation says "authorized" | Explanation may help find sources; it does not issue, approve, revoke, commit, authorize, pass a gate, evidence execution, or raise assurance. A citation or source mention inside the explanation supports stronger reliance only when the cited carrier supports that exact relied-on claim in the relying context under A.10. |

| Extracted-source -> rewrite -> representation shift -> explanation -> gate/release use | Reopen the strongest exact source at the first lossy or non-commutative transform step; stronger use waits for exact transform, evidence, explanation, gate, or assurance support. | | Repeated green-tile/no-source failures | Treat recurrence as upstream source-system repair work: expose decision refs, fix dashboard semantics, add source links/currentness, revise boundary wording, or add review/lint cues so the acting user is not repeatedly forced to reconstruct missing source support. |

Worked dashboard/approval slice:

A release dashboard shows a green approval-looking tile for Release-2026.05.08-prod. Treat the tile as orientation and source-finding only until the team can name the intended stronger use and the exact governing source.

Role prompts:

First-entry map for authority-looking cases:

Display guidance for bounded status: a visible status meant to guide work should expose source type, exact ref or link, freshness/window, scope, and unsupported stronger uses. For example, prefer Gate check passed / GateDecisionRef / release target / environment / window / not compliance proof, rollback success, or assurance increase over a bare approval-looking label.

Incident-learning fields for authority-looking overread: visible item, intended stronger use, affected actor/action/object/context/window, missing or stale source, exact governing source or source role, plausible overread, safe disposition used now, and upstream repair item for the source, dashboard, explanation, credential view, boundary wording, or publication face.

Contestability/redress route: when an authority-looking case affects person or team status, access, assignment, responsibility, release blockage, compliance posture, or safety-impacting work, name the review route before stronger reliance hardens. The route should name the disputed source or claim, the source role that can refresh or correct it, the evidence/status path to reopen, the safe interim disposition, and the time/window for review.

Lintable overread cues:

Stress cases for practice:

#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-bearing materials 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, and any required approval records or evidence-bearing materials 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 stronger governing materials rather than treating the shortened note as the work-enactment authority.

#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 ensure the integrity of action modeling, all FPF-compliant models must adhere to the following normative 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 stronger governing method or evidence-bearing material before work proceeds.
• Authority-looking case as source / work/role-status overread. 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. First name the intended stronger use, then exit to the exact governing source or block reliance.

#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-Echoing

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 route choice. 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.

The nearest recovery anchors are the manufacturing, peer-review, rollout briefing, and authority-looking case slices above, plus CC-A15-7, CC-A15-10, CC-A15-12, and CC-A15-13. 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 actions or processes 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.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 strength; 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 route note

Use A.15 first when the claim is about who acts, by which method, under which role, 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, artifacts, 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 intended use, add a C.26.2 distributed-state reading.
5. State the weakest claim, time window, rival explanations, and export loss.
6. Route evidence strength through A.10 and assurance strength through B.3 when the claim supports action, 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 intended 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 route when the reading will support stronger use;
• no distributed-state claim when carriers, rivals, or time window cannot be named.

#A.15:End