#U.Method: The Abstract Way of Doing

Pattern A.3.1 · Stable Part A - Kernel Architecture Cluster

Teams must talk about how something is done without entangling:

#Aliases

• U.Method

#Keywords

• recipe
• how-to
• procedure
• abstract process.

#Relations

#Content

#Context (plain‑language motivation)

Teams must talk about how something is done without entangling:

• Who is assigned (that is Role/RoleAssigning),
• Whether the holder can do it (that is Capability), and
• What actually happened (that is Work).

U.Method supplies the how—the abstract way of performing a transformation, independent of a specific run, a specific assignee, or a specific notation. It works across paradigms:

• Imperative (step‑graphs, SOPs, BPMN),
• Functional (pure mappings and compositions, no “steps”),
• Logical/constraint/optimization (goals, rules, admissible solutions).

In FPF, a system bearing a TransformerRole enacts a U.Method (producing Work) by following a MethodDescription—an episteme that describes the method in some representation.

#Problem (what goes wrong without a clean notion of “method”)

1. Process soup. “Process” gets used for recipe, execution, schedule, or org area. Planning, staffing, and audit blur together.
2. Spec = run fallacy. A flowchart (or code) is taken as if execution already happened; conversely, logs get mistaken for the recipe.
3. Role leakage. People encode assignments inside the recipe (“this step is the surgeon”), tying who to how and making reuse impossible.
4. Notation lock‑in. When “method” is defined as “a set of steps,” functional or logical styles become second‑class citizens and cannot be modeled cleanly.

#Forces (what the definition must balance)

#Solution — the method as an abstract, paradigm‑agnostic “way of doing”

#Definition

U.Method is a context‑defined abstract transformation type—the semantic “way of doing” a kind of work.
It is: Described (never identical) by one or more U.MethodDescription epistemes (code/SOP/diagram/rules),
Enacted by a U.System bearing an appropriate Role (usually a TransformerRole) to produce U.Work, and
Independent of who is assigned, what instance ran, or which notation was used.

Strict Distinction (didactic):

• Method = how in principle (semantic Standard).
• MethodDescription = how it is written (artifact on a carrier).
• Work = how it actually went this time (dated execution).

#Representation‑agnostic stance (specs may be imperative/functional/logical)

A U.Method does not require an imperative step structure. Representations live in U.MethodDescription, not in the Method itself.
Typical MethodDescription forms include:

• Imperative MethodDescription: step‑graph/flow (serial/parallel/branch).
• Functional MethodDescription: a composition f ∘ g ∘ h with typed interfaces/constraints, no “steps”.
• Logical/constraint MethodDescription: a goal/constraint set with admissible solutions and search/optimization semantics.
• Hybrid MethodDescription: imperative scaffolding with functional kernels and/or solver calls.

Semantic identity criterion (context‑local). Two MethodDescriptions describe the same U.Method in a given U.BoundedContext iff, for all admissible inputs and conditions recognized by that context, they entail the same preconditions, guarantee the same postconditions/effects, and satisfy the same non‑functional bounds (allowing permitted non‑determinism). Internal control‑flow/search details may differ.

#Method vs MethodDescription vs Work (quick litmus)

Didactic rule: when referencing the idea of “how”, say Method; when referencing the document or code, say MethodDescription; when referencing the run, say Work.

#Interface and effect (conceptual descriptors)

When presenting a U.Method in a review, anchor it with these paradigm‑neutral elements (not a data schema):

1. Interface — what is required/provided in general (inputs/outputs/types or resources/roles/ports).
2. Preconditions — what must already hold (guards, invariants, Standard “requires”).
3. Postconditions / Effects — what is guaranteed after successful enactment (Standard “ensures”).
4. Non‑functional constraints — latency, accuracy, cost, safety envelope (ties to Capability thresholds).
5. Failure modes — known failure classes and recoverability hints.
6. Compositional hooks — whether this method composes serially/parallel/choice/iteration (see §4.5).

#Method mereology (composition without confusing it with runtime)

Methods compose into bigger methods; executions compose into bigger executions—do not conflate the two.

Method composition (design‑time): serial (-), parallel (‖), choice (|), iteration (*), refinement/substitution—yield new U.Methods. Work composition (run‑time): the corresponding Work may split/merge/overlap differently due to scheduling, failures, or environment, yet it is still execution of the same Method. Mapping advice: avoid naming run‑time artifacts inside the method definition (no “this thread”, “this person”); keep those in Role/Work.

#Constructor‑theoretic reading (why Method ≠ algorithm ≠ spec)

Constructor Theory views a constructor as a physical entity that effects transformations. In FPF:

• A U.System with TransformerRole is the constructor (the performer).
• A U.Method is the abstract transformation type it enacts (semantic Standard).
• An algorithm artifact is a U.MethodDescription for an information‑transformation Method.
• A universal transformer generalizes the Turing machine by executing any U.Method described by a physically admissible U.MethodDescription (not only informational ones).

Thus, welding, milling, reagent mixing, and proof construction are all Methods; textbooks/code/derivations are their MethodDescriptions; Work are the concrete runs.

#Context anchoring

U.Method is local to a U.BoundedContext: terminology, admissible pre/postconditions, and non‑functional constraints are interpreted inside that context. If two teams or theories use the same name for different “ways of doing,” they are different Methods in different contexts unless bridged explicitly.

#Archetypal grounding (cross-paradigm examples: imperative / functional / logical)

#Industrial transformation (imperative flavor)

• Method: Etch_Al2O3.
• MethodDescription: SOP document; a PLC program that controls gas mix and timing.
• Enactment: Tool_42#TransformerRole:FabLine_A produces Work runs W‑101, W‑102….
• Notes: Step diagram exists, but a later functional spec may also exist (composition of gas‑flow functions). Both specs describe the same Method.

#Operational planning (functional/optimization flavor)

• Method: JS_Schedule_v4 (job‑shop scheduling).
• MethodDescription: a MILP model + solver configuration; documentation of constraints/objective.
• Enactment: PlannerService_v4#TransformerRole:PlantScheduling_2025 produces Work Run_2025‑W32‑P1.
• Notes: No “steps” are visible at the method level; the solver’s search is internal. Still a U.Method.

#Scientific proof (logical flavor)

• Method: Gauss_Elimination.
• MethodDescription: formal rules in a proof assistant; textbook chapter as a second spec.
• Enactment: CAS_Alpha#TransformerRole:MathLab_2025 generates a Work proof instance for a concrete matrix.
• Notes: The Episteme (spec) is not the ability (that belongs to the CAS system) and not the execution (the proof run).

#Didactic quick grammar (for managers)

• Who? Holder#Role:Context (Role assignment)
• Can? Capability(holder) within envelope/measures
• How (in principle)? Method, described by MethodDescription
• Did? Work (execution), linked by performedBy → RoleAssigning and isExecutionOf → MethodDescription

Keep the four words apart and plans become dependable.

#Bias‑Annotation (as in cluster‑E patterns)

• Lenses tested: Arch, Prag, Did, Epist.
• Scope declaration: Universal; semantics are context‑local via U.BoundedContext.
• Rationale: Gives FPF a paradigm‑neutral “how” that bridges MethodDescription (knowledge on a carrier) and Work (execution), while staying independent of Role (assignment) and Capability (ability).

#Conformance Checklist (normative)

CC‑A3.1‑1 (Strict Distinction). U.Method is the semantic “way of doing”. It is not a U.MethodDescription (artifact on a carrier), not a U.Work (dated execution), not a U.Role/assignment, and not a U.PromiseContent/promise.

CC‑A3.1‑2 (Context anchoring). Every U.Method MUST be defined within a U.BoundedContext. Identity, admissible pre/postconditions, and non‑functional bounds are interpreted in that context.

CC‑A3.1‑3 (Specification linkage). A U.Method SHOULD be described by ≥1 U.MethodDescription. For operational gating, at least one MethodDescription MUST be present and named. Multiple specs may coexist (imperative/functional/logic), see CC‑A3.1‑7.

CC‑A3.1‑4 (assignment‑free). A U.Method SHALL NOT hard‑code holders or assignments. If a step “needs a surgeon”, express that as a role requirement (to be satisfied via U.RoleAssignment at run time), not as a named person/unit inside the method.

CC‑A3.1‑5 (Runtime‑free). A U.Method SHALL NOT contain schedule, calendar slots, or run IDs; those belong to U.WorkPlan (plans) and U.Work (executions). Methods are timeless.

CC‑A3.1‑6 (Interface & effects). A U.Method MUST admit a context‑local statement of interface (inputs/outputs or ports/resources), preconditions, postconditions/effects, and (when relevant) non‑functional bounds. These anchor semantic identity beyond a particular notation.

CC‑A3.1‑7 (Multi‑spec semantic identity). Two or more U.MethodDescription describe the same U.Method in a given context iff they entail the same admissible preconditions, guarantee the same effects, and satisfy the same non‑functional bounds for all inputs/conditions recognized by that context (allowing permitted non‑determinism). Internal control‑flow/search differences are irrelevant.

CC‑A3.1‑8 (Composition vs execution). Composition of Methods (design‑time) and composition of Work (run‑time) MUST be kept distinct. Method composition yields new Methods; Work composition yields composed executions. They may correspond but are not identical.

CC‑A3.1‑9 (Parameterization). If a Method is parameterized, parameters are declared at the Method/MethodDescription level; concrete values are bound at U.Work creation. Avoid freezing parameter values inside the Method definition.

CC‑A3.1‑10 (Dynamics ≠ Method). Laws/trajectories (U.Dynamics) are models of state evolution and SHALL NOT be labeled as Methods. A Method may rely on a Dynamics model (e.g., for control), but they remain distinct artifacts/concepts.

CC‑A3.1‑11 (Capability checks are orthogonal). A step may impose capability thresholds; those thresholds are checked against the holder’s U.Capability independently of assignment and independently of the Method’s description.

CC‑A3.1‑12 (Constructor‑theoretic alignment). Algorithm artifacts are U.MethodDescription for information‑transforming Methods. Physical Methods are equally valid (matter/energy transformations). A “universal transformer” is a system that can enact any physically admissible MethodDescription; this does not collapse Method into “algorithm.”

#Method mereology (composition) — design‑time only

Operators (conceptual, context‑scoped):

• Serial composition (-) — do A then B → A - B is a new Method.
• Parallel composition (‖) — do A and B concurrently (with declared independence/joins).
• Choice (|) — do one of {A, B} under guard/selector.
• Iteration (*) — repeat A under a loop invariant/termination condition.
• Refinement (≤ₘ) — Method M' preserves M’s interface/effects and strengthens preconditions or tightens non‑functional bounds (context‑defined lattice).
• Substitution — replace a Method factor with a semantically equivalent one (M ≡ N in context) without changing the whole’s Standard.

Design‑time laws (intuitive, not mechanized here):

• Associativity for - and, where admissible, for ‖.
• Distributivity over guarded choice under context rules.
• Identity elements (e.g., Skip that preserves state and satisfies neutral bounds).
• Monotonicity: refinement of a factor should not break the whole’s postconditions.

Run‑time mapping (do not conflate): U.Work instances of A - B may interleave differently due to scheduling or failure‑handling and still be executions of A - B. The mapping is “execution semantics,” not part of Method mereology.

#How Methods interact with Roles, Capability, Work, Dynamics (manager’s view)

• Roles (assignment). Steps stipulate role kinds (e.g., IncisionOperatorRole), not people. At run time, U.Work references a U.RoleAssignment that satisfies the role kind.
• Capability (ability). Steps may require thresholds (e.g., “precision ≤ 0.2 mm”). They are checked against the holder’s U.Capability in the context/envelope.
• Work (execution). Each run records isExecutionOf → MethodDescription (the spec used) and performedBy → RoleAssigning. Logs, resources, and timestamps live here.
• Dynamics (laws/models). Methods may cite or assume a Dynamics model; runs may attach traces that are explained by that model. Do not label the model itself as the Method.

#Anti‑patterns (and the right move)

• Spec = Method. “The BPMN is the Method.” → The BPMN is a MethodDescription; the Method is the semantic way it denotes.
• Run = Method. “Yesterday’s process is our Method.” → Yesterday’s run is Work.
• Role leakage. “Step 3 is done by Alice.” → Step 3 requires SurgeonRole; Alice may be assigned via RoleAssigning.
• Schedule leakage. “Run at 02:00 daily” inside the Method. → This belongs to WorkPlan; Methods are timeless.
• BoM entanglement. Putting parts/assemblies inside Method definition. → Structure stays in PBS/SBS; Method references interfaces/resources, not a BoM.
• Algorithm‑only bias. Declaring that only code counts as a Method. → Physical transformations (welding, mixing) are Methods too; their SOPs/parameters are MethodDescriptions.
• Hard‑coding capability. Baking “≤ 0.2 mm” into a role name or Method name. → Keep thresholds on steps; capability lives on the holder.

#Migration notes (quick wins)

1. Rename wisely. Where texts say “process/method” but mean a diagram or code repo, label it MethodDescription; where they mean the abstract “how,” label it Method.
2. Extract assignments. Replace named people/units in specs with role kinds; enforce assignments via RoleAssigning at run time.
3. Pull time out. Move calendars/schedules from specs into WorkPlan.
4. Parameter hygiene. Declare parameters at Method/MethodDescription; bind values in Work.
5. Equivalence notes. When two specs are intended as the same Method, write an equivalence note in the context (pre/post/bounds parity).

#Consequences

#Relations

• Builds on: A.1 Holonic Foundation; A.1.1 U.BoundedContext; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability.
• Coordinates with: A.3 (role masks for transformers/constructors/observers); A.15 (Role–Method–Work Alignment); B.1 Γ (aggregation) for method families vs assembly of systems.
• Informs: U.WorkPlan definitional pattern (plans reference Methods they schedule); U.PromiseContent definitional pattern (promises cite Methods as delivery means); U.Dynamics definitional pattern (models that Methods may assume).

#Didactic quick cards (reuse in specs and onboarding)

• Method / MethodDescription / Work = how in principle / how it is written / how it went this time.
• Four‑slot grammar: Who? → RoleAssigning. Can? → Capability. How? → Method (via MethodDescription). Did? → Work.
• Design‑time vs run‑time: Composition of Methods ≠ composition of Work.
• No steps required: Functional, logical, and hybrid MethodDescriptions are first‑class.
• Keep time and people out: Schedules → WorkPlan; assignees → RoleAssigning.

#A.3.1:End