#U.Method: The Abstract Way of Doing

A.3.1 · Stable · Definitional pattern · Normative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Definitional pattern Status: Stable Normativity: Normative

Use this pattern when a project needs to say how something is done in principle without prematurely treating that method claim as a document, program, workflow diagram, plan, run log, role assignment, capability statement, mechanism claim, or mathematical-model claim before those positions are recovered.

#Aliases

• U.Method

#Keywords

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

#Relations

#Content

#Problem frame

Use this pattern when a project needs to say how something is done in principle without prematurely treating that method claim as a document, program, workflow diagram, plan, run log, role assignment, capability statement, mechanism claim, or mathematical-model claim before those positions are recovered.

Typical moments:

• a team says "the method is the code", "the process is the BPMN", "the workflow is the evidence", or "the solver model is the operation";
• a procedure, protocol, proof script, optimization model, control strategy, or recipe must be reused across many runs;
• two descriptions look different but may describe the same way of doing;
• a graph, query, table, dashboard, checklist predicate, or mathematical representation is being interpreted as if it were an instruction sequence;
• work planning, dated work, method description, formal substrate, mechanism, and evidence are starting to collapse into one vague "method" word.

Primary EntityOfConcern. The EntityOfConcern is the U.Method: the context-local semantic way of doing a kind of transformation or enactment.

First useful move. Name the context-local way of doing, the transformation or enactment it is about, and the EntityOfConcern whose state, result, selection, derivation, control relation, or maintained condition changes or is preserved.

What goes wrong if missed. A diagram starts authorizing work, a query plan starts looking like performed work, a program starts looking like proof of operational success, or a graph path starts looking like a route that something followed.

What this buys. The project can reuse, compare, describe, plan, enact, and audit a way of doing without confusing the method with its descriptions, runs, mechanisms, mathematical substrates, evidence relations, gates, or authority claims.

Not this pattern when. If the current claim is a method description, work plan, dated work occurrence, evidence relation, source relation, mechanism declaration, mathematical-lens use, gate decision, authority claim, or publication-use relation, use the pattern that governs that claim and link it back to the U.Method only when the relation is current.

#Problem

Without a current U.Method distinction, FPF cannot repair method-like wording cleanly. Texts then slide among several different claims:

1. Description as method. A SOP, code repository, proof script, BPMN diagram, SQL query, solver model, or protocol is treated as the method itself.
2. Plan or run as method. A calendar plan, access plan, run log, telemetry trace, or work-result record is called the method.
3. Mechanism or formal substrate as method. A mathematical object, formal substrate, mechanism declaration, causal model, or control structure is used as if it already selected the way of doing work.
4. Role or capability leakage. Named people, organizations, teams, permissions, or capability thresholds are baked into the method instead of being kept in role assignment, authorization, capability, or gate patterns.
5. Programming-paradigm overread. Imperative, functional, logical, constraint, object-centric event, or effect-handler wording is taken as a direct ontology of work rather than one possible description or representation of a way of doing.

The practical harm is fragile reliance. Changing a publication looks like changing the method; a run error looks like method invalidation; a mechanism declaration starts authorizing work; and a dashboard cue starts acting like evidence or permission.

#Forces

• A method must be stable enough to compare, reuse, teach, improve, and audit across many runs.
• Work still happens in dated situations with named systems, resources, holders, conditions, and outcomes; a method statement must not pretend that the dated work has already occurred.
• Method descriptions can be executable, formal, graphical, procedural, declarative, or hybrid; their publication form must not decide the method ontology by itself.
• Mechanisms and mathematical substrates often make a method explainable or constrained enough to rely on, but the mechanism claim and the method claim still answer different project questions.
• A useful method statement must stay broad enough for welding, clinical triage, proof construction, optimization, agent orchestration, lab protocols, software execution, and organizational work without making software notation the default model of method.

#Solution

U.Method is the context-defined semantic way of doing a kind of transformation or enactment.

It is not the text, code, diagram, model, plan, run, role, capability, or evidence relation that may be associated with that way of doing. A U.Method is:

• context-defined: its identity, admissible inputs, conditions, effects, and bounds are interpreted inside a U.BoundedContext;
• semantic: it is the way of doing that descriptions denote and work may enact;
• transformation-facing: it concerns a possible or intended transformation, enactment, or produced result, including physical, informational, organizational, mathematical, or hybrid transformations;
• description-independent: one method may be described by several U.MethodDescription epistemes;
• run-independent: one method may be enacted by many U.Work occurrences;
• assignment-independent: method requirements may name role kinds or capability requirements, but named holders and dated assignments belong elsewhere.

The primary repair move is not to replace the word "method" with one better word. Recover the current slot first:

#Thin first-use record

For ordinary first use, write only the fields needed to keep the method claim from collapsing into a description, plan, run, mechanism, or evidence relation:

Method statement:
  MethodRef:
  BoundedContext:
  TransformationOrEnactmentKind:
  EntityOfConcern:
  Preconditions:
  IntendedEffectsOrPreservedConditions:
  CurrentMethodDescriptionRef:
  WorkRelation:
  ClaimBoundary:

ClaimBoundary names the nearest stronger claim that is not carried by this method statement, such as work authorization, performed work, evidence for success, mechanism declaration, or formal-substrate adequacy. It is a boundary field, not a place to repeat every neighboring pattern.

#Method and mechanism settlement

Do not decide the method and mechanism question by vocabulary. When a source expression or project concern appears to name changing, producing, selecting, deriving, controlling, or maintaining an EntityOfConcern, use E.10.ARCH:3.1 to recover the project concern first and then assign separately governed typed FPF values.

For this host, keep the local question thin: does the current claim state a U.Method, the context-local way of doing a transformation or enactment? If the source label also raises mechanism, formal-substrate, work-plan, dated-work, evidence, source, gate, result, publication, or temporal claims, keep those values linked only by explicit relation positions and apply their own governing patterns.

• In method position, the current claim is the context-local way of doing a transformation or enactment.
• In mechanism position, the current claim is a law-governed declaration or revision of operations, laws, admissibility predicates, transport, audit relation set, and monotone realizations under A.6.1 and E.20.

Do not assign the same typed value as both U.Method and U.Mechanism unless a governing pattern explicitly admits such dual typing. Slot-position labels do not create alternate ontology.

This gives the working distinction:

A method may cite a mechanism, be selected by a mechanism, be constrained by a mechanism, or be one value in a mechanism's slot. A mechanism may govern an operation algebra whose operations include applying, selecting, composing, or normalizing methods. Those links do not collapse the typed values or their governing claims. If both claims are current, write both: the U.Method statement for the way of doing, and the U.Mechanism statement for the law-governed declaration or realization relation.

Fail closed when neither position can be recovered. Do not repair algorithm, program, workflow, process, solver, proof, recipe, or control strategy to method or mechanism merely because the replacement sounds more technical.

#Method, MethodDescription, WorkPlan, Work

Keep the four positions separate.

The same solver model, repository, protocol, diagram, or run packet may participate in several claims, but each claim has its own slot. A solver model can be a U.MethodDescription; its mathematical formulation can also expose a formal substrate for C.29; a solver run can be U.Work; a run result can be evidence for a separate claim. Those claims are not interchangeable.

#Method statement fields

A useful U.Method statement can usually recover these fields in ordinary project language:

This is not a data schema. It is the minimum recognition field set needed before method-like wording can guide work, evidence, assurance, gates, or planning.

#Representation and programming-paradigm discipline

A U.Method does not require an imperative step structure.

Imperative procedures, functional compositions, logical rule sets, constraint models, object-centric event models, effect-handler programs, process diagrams, SQL queries, equality-saturation graphs, proof scripts, and optimization models may all help describe, represent, or analyze a way of doing. Their representation style does not by itself decide whether the current claim position is a method, a method description, a formal substrate, a mechanism, a work plan, work, evidence, or a declarative representation under C.2.P.DR.

Use this discipline:

• If the text states the semantic way of doing, use A.3.1.
• If the text states the representation that describes that way, use A.3.2.
• If the text states a formal object or mathematical representation used to reason, use A.6.0, C.29, or the direct mathematical pattern.
• If the text states a law-governed operation structure, admissibility predicate set, transport clause, or realization relation, use A.6.1 or E.20.
• If the text states planned work, use A.15.2.
• If the text states dated performed work, use A.15.1.
• If the text states an evidence relation or provenance relation, use A.10.
• If the text turns a graph, path, query, table, dashboard, predicate, publication face, or pattern relation into a route, call sequence, dispatch, or work procedure by metaphor, use C.2.P.DR before choosing the direct governing pattern.

This is why "algorithm" is not repaired to "method" automatically. An algorithm-looking expression may indicate a method description, formal substrate, mechanism, control strategy, work plan, work occurrence, evidence relation, or quoted source wording. The repair must recover the slot.

#Constructor and process-theory settlement

FPF interprets method claims through transformation first, not software notation first.

In the constructor-theory and process-theory source line adopted here, claims about computation, information, dynamics, and procedure are kept close to possible or impossible transformations and their compositional realization. That gives FPF the following settlement:

• a system in a transformer-like role can enact a method;
• the method is the context-local way of doing the transformation;
• a method description is an episteme that describes that way;
• a formal substrate or mathematical lens may make the method analyzable, but does not become the method by itself;
• a mechanism may declare law-governed operation structure, admissibility predicates, transport, and realization relations for a method-facing transformation, but that mechanism claim is not the same claim as selecting, describing, planning, or enacting a method;
• a work plan prepares or schedules dated work;
• dated work is the occurrence that happened.

This settlement covers welding, milling, reagent mixing, clinical triage, proof construction, optimization, scheduling, training, inference, and software execution without making "code" the privileged form of method.

#Semantic identity and variants

Two U.MethodDescription epistemes may describe the same U.Method in a bounded context when, for the recognized inputs and conditions of that context, they preserve the same method identity:

• compatible preconditions;
• compatible effects or postconditions;
• compatible non-functional bounds;
• accepted nondeterminism or search behavior;
• the same work-facing acceptance relation.

Different internal control flow, search strategy, proof notation, programming paradigm, diagram notation, or textual format does not by itself make a different method. Conversely, the same name, diagram family, repository, supplier label, or workflow label does not by itself prove identity.

When variants differ only by parameter ranges, equipment envelope, or local representation, keep one method with declared variation when the context accepts that identity. When variants change effects, bounds, accepted inputs, safety envelope, or work-facing acceptance criteria, declare a refinement, substitution, or distinct method.

#Method relation structure, composition, and work enactment

Methods may compose into larger methods. Work occurrences may compose into larger work histories. These are related but different claims.

When the current question is one semantic way of doing, the governed object is U.Method. When the current question is a relation among methods, method families, local method expressions, method-description links, or work-facing method-use relations, the governed object is MethodRelationStructure@BoundedContext: a context-local structure over method-side values.

A method relation structure may include:

• serial composition;
• parallel composition;
• guarded choice;
• iteration;
• refinement;
• substitution;
• decomposition;
• parameterization;
• method-family membership, selection, fallback, or dispatch relation;
• a relation from method requirement to accepted role assignment when work admission depends on it.

Those relations are design-side or definition-side claims about ways of doing. They are not dated work merely because an implementation, graph, process model, or workflow-looking diagram can be executed or followed.

Work composition is occurrence-side: dated work may interleave, split, merge, retry, fail, recover, or be recorded in traces differently from the method description or method relation structure.

Algebraic, graph, categorical, process-calculus, effect-calculus, matrix, embedding, distributed, or neural notation may describe or analyze a selected MethodRelationStructure@BoundedContext. That notation is a mathematical or representation lens under C.29 or a U.MethodDescription representation when the description itself is current. Do not name it U.MethodAlgebra or treat the lens as the method, method family, work plan, performed work, mechanism, role relation structure, or selector registry.

Do not infer method composition from document modules, graph layout, table order, method-family registry rows, or source-file structure alone. A two-module description is not automatically a two-step method. A path in a graph is not automatically an execution sequence. A pipeline-looking diagram is not automatically dated work. A method-family registry may select among or compose families, but the registry entry is not the method relation structure unless the governing selector or method pattern states that relation by value.

#Archetypal Grounding

Across the slices below, a U.Method is not recognized by source wording, notation, or publication form. It is recognized by a stable project answer to this question:

In this bounded context, what way of doing changes, produces, derives, selects, controls, or preserves the EntityOfConcern under these conditions?

Manufacturing, optimization, proof, graph or query overread, and clinical triage differ in material, representation, and assurance needs, but they share the same method slot. The archetypal failure is also shared: a nearby description, plan, run, mechanism, formalism, or evidence relation takes the method name and silently changes what the project can rely on.

#Manufacturing recipe

Etch_Al2O3 is the method when the bounded context uses that name for the way of transforming a wafer surface under specified conditions.

The SOP, PLC program, calibration recipe, and supplier note are method descriptions when they describe that method. A planned maintenance-window run is a U.WorkPlan. Tool run W-143 with timestamps and logs is U.Work. Gas-flow equations may be a formal substrate or mathematical lens input. Evidence for whether the run met a safety or quality claim is governed separately by A.10, B.3, C.27, or a gate pattern.

#Optimization model

JS_Schedule_v4 may be the method when it names the project-accepted way of producing a job-shop schedule.

The MILP formulation, solver configuration, and acceptance tests are method descriptions or formal-substrate declarations depending on the current claim. The solver's internal search is not automatically the project work sequence. A scheduled production plan is U.WorkPlan; the actual scheduling run and resulting dated decision record may be U.Work and evidence for separate claims.

#Proof or derivation

Gauss_Elimination can be a method for deriving a result under a mathematical context.

A textbook explanation, proof-assistant script, and formal rule set are method descriptions. A proof run in a concrete assistant session is work. The algebraic structure may be a formal substrate. The claim that this proof is used as evidence for a project decision is an evidence or assurance claim, not part of the method merely because the method produced a derivation.

#Graph or query overread

A graph path, SQL-like query, checklist predicate, or dashboard table may represent a relation, state, evidence structure, provenance structure, or publication face. It becomes a method claim only if the text recovers a semantic way of doing and its work-facing relation.

If the wording says the graph "routes" a project to a pattern, the query "calls" a work sequence, or the table "authorizes" action without a recovered method kind, work kind, gate claim, or authority claim, apply C.2.P.DR first.

#Clinical triage protocol

SepsisTriage_v3 may be the method when the hospital context uses that name for the way of classifying a patient state and selecting the next clinical response.

The protocol PDF, order-set screen, and decision-support rule are method descriptions or publication faces. The clinician's dated assessment is U.Work. The physiological model or score formula may be a formal substrate or mathematical lens. An admission policy, a treatment-release gate, and evidence that the triage reduced harm are neighboring claims. Keeping those claims separate prevents a document from becoming authorization, proof, and performed work merely because it describes the method.

#Bias-Annotation

This pattern mainly blocks six recurring biases:

• description-as-method bias: a publication, program, diagram, or protocol is treated as the method instead of a method description;
• run-as-method bias: a trace, log, run, or result record is treated as the reusable way of doing;
• software-notation bias: code, algorithm, workflow, or programming-paradigm language becomes the default ontology for every method;
• mechanism-overread bias: law-governed mechanism or formal-substrate material is treated as if it already selected the project method;
• holder-as-method bias: a team, system, supplier, or capability holder becomes the method name;
• semio-bias: the discussion shifts from the way of doing to the description, publication, evidence face, or wording repair before the method slot is recovered.

The repair is the same in each case: recover the U.Method slot when the semantic way of doing is current, and then link neighboring values through their own slots or relations.

#Conformance Checklist

CC-A3.1-1 (Method slot). U.Method is the context-defined semantic way of doing a kind of transformation or enactment. A method claim is not closed by naming a method description, work plan, dated work occurrence, evidence relation, role assignment, capability, mechanism declaration, formal-substrate declaration, publication face, or pattern relation. If one of those claims is also current, state it in its governing pattern and link the positions explicitly.

CC-A3.1-2 (Context anchoring). Every method identity is interpreted inside a U.BoundedContext. Same name across contexts does not prove same method.

CC-A3.1-3 (Description relation). A method should have at least one named U.MethodDescription when work, assurance, gate, or audit reliance depends on it. Several descriptions may describe the same method only under a stated method-identity relation or criterion.

CC-A3.1-4 (Assignment-free method). A method may state role-kind requirements or capability requirements. It does not bind named people, teams, organizations, or calendar slots.

CC-A3.1-5 (Runtime-free method). Dated runs, timestamps, telemetry, logs, and work-result records belong to U.Work and associated evidence patterns or source patterns, not to the method identity.

CC-A3.1-6 (Plan-free method). Work preparation, schedule, go or no-go date, work authorization, and planned work relation belong to U.WorkPlan, gate, authority, or commitment patterns.

CC-A3.1-7 (Mechanism and formal-substrate separation). A formal substrate, mathematical-lens use, mechanism declaration, mechanism realization, or control model may provide constraints, invariants, or realization facts used when judging a method claim, or may be linked by typed relation-position claims under E.10.ARCH:3.1. It still does not close the method claim unless the current claim states the context-local semantic way of doing and its work-facing identity.

CC-A3.1-8 (Programming-paradigm neutrality). Imperative, functional, logical, constraint, object-centric event, effect-handler, and hybrid descriptions are representation choices or description forms until the method slot is recovered.

CC-A3.1-9 (Graph and representation guard). A graph path, path slice, query, predicate, table, dashboard, publication face, or pattern relation is not a method or work sequence by layout. Use C.2.P.DR when representation wording is overread as imperative action.

CC-A3.1-10 (Method relation structure and work composition distinction). Method composition, method-family selection, fallback, refinement, substitution, iteration, decomposition, and work-occurrence composition must stay separate even when they correspond. When method-side relations are current, recover MethodRelationStructure@BoundedContext; algebraic, graph, categorical, process-calculus, effect-calculus, matrix, embedding, distributed, or neural notation is a lens or representation over that structure unless a governing pattern states a different object by value.

CC-A3.1-11 (Parameter and variant discipline). Parameters may be declared at method or method-description level; concrete values are bound in work planning or work occurrence. Variant identity must be justified by effects, bounds, accepted inputs, and context.

CC-A3.1-12 (Evidence and assurance boundary). A method or method description does not by itself prove that work happened, that a result is warranted for the claimed use, that a gate is passed, or that action is authorized. Those claims use the relevant evidence, assurance, gate, temporal, authority, work-plan, or work patterns.

#Common Anti-Patterns and How to Avoid Them

#Consequences

• Method-like language becomes reusable across physical, informational, organizational, and mathematical work without privileging software code or ordered instructions.
• Teams can compare descriptions, variants, and implementations without confusing them with dated work.
• Work planning and evidence become more reliable because a method no longer smuggles in authority, proof, schedule, or performed-work claims.
• The cost is explicit slot recovery: when wording says "method", "algorithm", "workflow", "process", "procedure", "program", "recipe", "proof", or "solver", the user must recover which FPF object or claim position is current before relying on it.

#Lowering and refresh conditions

Lower confidence in a U.Method use when:

• the text cannot state transformation or enactment kind, EntityOfConcern, preconditions, and intended effects;
• the method name is only a document, repository, diagram, model, run log, team name, supplier label, or authorization claim;
• the same typed value is assigned as both U.Method and U.Mechanism without a governing pattern admitting the dual typing;
• the first usable move requires a long related-pattern catalogue before the method slot is visible;
• graph, path, query, table, or predicate wording is treated as ordered execution without C.2.P.DR recovery;
• a later U.MethodDescription, U.WorkPlan, U.Work, U.Mechanism, C.29, E.18, or evidence pattern changes the slot relation on which the method statement relied.

The smallest useful repair is usually local: rewrite the method statement, split the neighboring value into its governing pattern, or add one ClaimBoundary line. Reopen the wider method family only when repeated project material shows that U.Method, U.MethodDescription, U.WorkPlan, U.Work, U.Mechanism, formal substrate, or mathematical-lens use can no longer be separated by the current slot rules.

#Rationale

FPF needs U.Method because practical work often depends on a way of doing before there is one dated work occurrence, one accepted description, one final implementation, or one verified result. Treating the method as the document, code, mechanism, plan, or run makes reuse brittle: changing the publication looks like changing the method, a run error looks like method invalidation, and a mechanism claim starts authorizing work.

The distinction between method and mechanism is especially important because the same source expression or project concern can need both linked values. The method says what way of doing is intended or enacted in context. The mechanism says what law-governed operation structure, admissibility predicate set, transport, audit relation set, or realization relation is being declared. These values may be linked, but they should not be made two names for one untyped value.

#SoTA-Echoing

Refresh this pattern when current work on constructor theory, process theory, effect systems, process modeling, graph and equivalence representations, or FPF's own method, work, and mechanism patterns changes the governing distinction among method, method description, formal substrate, mechanism, work plan, dated work, and evidence.

#Relations

• Builds on: A.1 holonic foundation, A.1.1 U.BoundedContext, A.2 role, A.2.1 U.RoleAssignment, A.2.2 U.Capability.
• Coordinates with: A.3.2 for method descriptions and method-relation descriptions; A.3.3 for dynamics; A.6.0 for formal-substrate declarations; A.6.1 and E.20 for mechanism claims; C.29 for mathematical-lens use; G.5 for method-family registries and selector outcomes; direct method-composition patterns such as B.1.5 when order-sensitive method composition is current; A.15.2 for work plans; A.15.1 for dated work; A.10 for evidence relations or provenance relations; C.2.P.DR for declarative representations overread as imperative routes or work sequences.
• Informs: E.18 and E.18.1 when transformation-flow-structure or P2W wording must keep flow-structure descriptions, graph/path mathematical expressions, method claims, and work claims separate.

#A.3.1:End

Last Updated: 2026-06-11 — this section last modified in upstream FPF commit 20c8a0a5 (github.com/ailev/FPF)