#U.Method: Reusable Way of Doing with Explicit Applicability

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 or practice claim as a document, program, workflow diagram, plan, run log, role assignment, capability statement, mechanism claim, cultural tradition, discipline position, or mathematical-model claim before those positions are recovered.

#Aliases

• U.Method

#Relations

#Content

#Problem frame

Use this pattern when a project needs to say how something is done in principle without prematurely treating that method or practice claim as a document, program, workflow diagram, plan, run log, role assignment, capability statement, mechanism claim, cultural tradition, discipline position, 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 practice, procedure, protocol, proof script, optimization model, control strategy, or recipe is intended for reuse 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, role assignment, cultural-evolution, discipline, and evidence are starting to collapse into one vague "method" or "practice" word.

Primary EntityOfConcern. The EntityOfConcern is the U.Method: one reusable semantic way of doing under stated participant meanings, applicability, preconditions, intended effects or preserved conditions, and bounds. Cite an exact effective reference scheme and local senses only when their variation changes that method meaning. U.Method is a non-agentive holon kind: methods can have submethods, compose into whole methods, and participate as submethods of larger methods. This does not make a method an actor, a method description, a work plan, or a dated work occurrence. A step label or step description is not a method part unless the recovered object is itself a U.Method.

First useful move. Name the reusable way of doing, its generic participant meanings, applicability, preconditions, intended effect or preserved condition, and the concern it addresses—for example changing, observing, comparing, classifying, evaluating, communicating, selecting, proving, or preserving. If local terminology changes that answer, cite the exact effective reference scheme and local senses. The method remains this pattern's primary EntityOfConcern; this semantic statement establishes no planned assignment, actual participant, actual transformation, or result.

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 sentence is about a document or representation that describes a method, schedules work, reports dated Work, declares a mechanism, presents a mathematical lens, cites evidence, decides a gate, asserts authority, or publishes a view, use that claim's owner. For a claim-bearing episteme about one exact Method, apply A.3.2's same-individual membership test; a carrier or representation is not thereby linked directly to the Method. State any planning, enactment, realization, evidence, gate, authority, publication, or representation relation only under its direct owner when it actually obtains.

#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 has enough identity stability to support comparison, reuse, teaching, improvement, and audit across many runs.
• Work still happens in dated situations with exact performer assignments, actual participants, resource uses, conditions, and separately governed effects; a method statement establishes none of those occurrence-side facts.
• Method descriptions can be executable, formal, graphical, procedural, declarative, or hybrid; publication form alone does not decide the method ontology.
• 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 remains applicable to 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 reusable semantic way of doing under stated applicability.

Local method mantra. Name the reusable way; say who or what it is for and when; state the intended result or preserved condition and the nearest stop; add an effective reference scheme or a selected structure only if changing it would change the method identification or the next decision; keep descriptions, plans, Work occurrences, and mechanisms separate. This is an attention aid, not a work order, U.WorkPlan, dated enactment, or DemonstrativeUnfoldingSlice@Context.

It is a non-agentive holon kind. Part methods can be selected, bounded, ordered, joined, adapted, and hidden or exposed through method interfaces to form a whole method with whole-level preconditions, effects, invariants, constraints, and assurance hooks. The whole method may then be used as a part method in a larger method.

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:

• semantically local: its identity uses the declared participant meanings, applicability, conditions, intended effects or preserved conditions, and bounds; add an effective reference scheme and local senses only when a meaning difference would change the method identification or a stated comparison;
• semantic: it is the way of doing that descriptions denote and work may enact;
• concern-explicit: it states what a future enactment is intended to do or decide—change, observe, compare, classify, evaluate, communicate, select, derive, prove, control, produce, or preserve—and its intended effect or preserved condition; it identifies no actual changed referent, participant, occurrence, or result;
• description-independent: one method may be described by several U.MethodDescription epistemes;
• run-independent: one method may be enacted by many Work occurrences admitted under U.Work;
• assignment-independent: method admission conditions may name role kinds or capability-fit conditions, but named holders and dated assignments belong elsewhere;
• participant-semantic: it may state generic participant meanings and method-side applicability without declaring RelationSignature SlotSpecs, OperationAlgebra argument or result positions, planned fillers, or actual participants.

Do not begin by replacing method or practice with a preferred technical word. First finish the ordinary sentence, "Here the text is trying to name or assert ___." Then use this one routing map:

#Strategy wording by claim position

Treat strategy as ordinary source wording until the sentence's claim position is clear. Do not mint U.Strategy.

When the wording names a reusable way of deciding or acting under stated applicability, it identifies a U.Method. A clinical treatment strategy, manufacturing setup strategy, search strategy, or negotiation strategy qualifies only when it states the reusable action, participant meanings, preconditions, intended result, and bounds.

When a protocol, playbook, program, diagram, or prose passage describes that way, that episteme may be a U.MethodDescription. Reusable strategizing can itself be a U.Method; a dated strategy workshop, search episode, or planning session is a Work individual only when its A.15.1 occurrence basis is grounded.

When the sentence is about choosing among candidates, use A.19.SelectorMechanism and G.5 for the actual criteria, policy, and selector outcome. The label strategy does not replace those objects or prove that a reusable method has been stated.

Leave quoted or explanatory strategy wording alone when it carries no FPF claim. The repair is complete when a reader can say what the sentence asserts and which pattern owns that assertion, not when every occurrence has been replaced.

#Thin first-use method identification

Start with the least apparatus that lets another reader recognize the same method:

1. Ordinary use. State the reusable way of doing, the kinds of participants it is for, when it applies, what it is meant to achieve or preserve, and the nearest case in which it must not be used. If that sentence is enough for the decision at hand, stop.
2. Later comparison or reliance. Fill the Plain aid below when another person must later distinguish same-named methods, compare descriptions or variants, cite one edition in a plan, or audit why this method was selected.
3. Organization of several methods or uses. Open A.22, B.1.5, or another direct composition pattern only when the question is about the organization itself—for example, which methods were composed, selected, used as fallbacks, or enacted in the reviewed work. A list or diagram does not create those relations.

Moving to a heavier level must solve one of those concrete problems. More fields do not make the method real, authorize its use, or prove that work occurred.

The following is a Plain identification aid, not a record kind, ontic, serialization, or mandatory form. Omit every optional line that the stated decision does not use.

Method identification aid:
  MethodRef:
  SemanticBasisIfMeaningVaries:
  Applicability:
  GenericParticipantMeanings:
  MethodConcern:
  Preconditions:
  IntendedResultOrPreservedCondition:
  MethodDescriptionIfReliedOn:
  WorkRelationIfReliedOn:
  SelectedStructureOrModelUseIfReliedOn:
  RelationsThatMustObtain:
  RelianceWindow:
  ReviewIf:
  NotEstablished (ClaimBoundary):

NotEstablished states the nearest tempting stronger claim that this identification does not make—for example, permission to start work, a dated run, successful change, metrology acceptance, or evidence that the method works. Use the FPF term ClaimBoundary when another pattern consumes that boundary.

Add SemanticBasisIfMeaningVaries only when the same words have different meanings under another effective reference scheme or set of local senses. Add a claim scope, context slice, selected structure, or model-use relation only when its own predicate obtains and changing it would change the method identification or the later decision. None is a general container for method identity.

For every relied-on relation, name its participants, the relation that must obtain, and the pattern that governs it. A generic source, support, evidence, or current use entry is not a replay basis. RelianceWindow says which variant, time, or description edition the comparison relies on. ReviewIf names the concrete change that would make that comparison unsafe.

#Closure and bounded non-use

Close positively when a reader can write the reusable action, generic participant meanings, applicability, preconditions, intended result or preserved condition, and nearest stronger claim that remains unestablished. Resolve an effective reference scheme and local senses only when a meaning difference changes that answer. Cite a method description, selected structure, model-use relation, or Work relation only when the next decision actually reads that relation.

If the project also claims an actual change, finish the method identification first. Then open A.3.4 for the actual changed referent, temporal boundary, subject facts, and transformation identity; the reusable method supplies none of them.

Close by non-use when the source is only a description, plan, dated Work occurrence, mechanism declaration, selector result, role relation, evidence relation, publication use, or quoted wording. If the material does not distinguish those positions, retain the source phrase as an unresolved cue and stop rather than inferring U.Method.

#Method and mechanism settlement

Do not decide from words such as method, algorithm, process, or mechanism. First ask what the sentence lets the project assert:

A method statement may cite a mechanism episteme whose content declares operations used by that method. A shared concern or operation name does not make the two values identical. A selector may choose a method, and an A.6.1 application may bind a method as an actual value. State that use only when the selector outcome, application binding, or another admitted direct relation is present; otherwise keep the method and neighboring object separate. None authorizes Work merely by being named.

Keep the nearby relation families distinct once, here. An F.9 Bridge between two exact F.17 SchemeSenseCell values states a cross-context sense correspondence; it does not change an effective reference scheme or establish identity. A claim that this Bridge suits one named use remains a separate C.2.1 bounded-use claim, and A.10 or B.3 governs reliance on that claim. An A.6.1 realization relation connects a mechanism declaration to a realizer; it is not the mechanism content. C.29 governs a mathematical preservation or representation claim. E.20 governs where mechanism meaning is maintained. Evaluation, measurement, and evidence-use patterns support their own claims; they do not add content to the method or mechanism.

When neither the reusable way nor the reusable operation declaration can be stated, keep the source wording unresolved. Replacing it with a more technical noun is not a repair.

#Method, MethodDescription, WorkPlan, Work

Keep the four positions separate.

The same solver model, repository, protocol, diagram, or run packet may figure in several claims, so say what each sentence is about. The solver-model episteme may describe a method; its mathematical representation may expose a C.29 formal substrate; a dated solver run may be Work; and a measurement or evaluation result may support another claim through its evidence relation. None substitutes for another.

#Method statement fields

A useful U.Method statement can usually answer these questions in ordinary project language:

This table is a recognition checklist, not a data schema. Start with the ordinary method sentence. Use A.6.1 for a reusable operation declaration, A.6.5 for a reusable direct-relation declaration, A.15.2 for planned use, and the exact direct relation or A.6.1 application binding for actual participation.

#Representation and programming-paradigm discipline

A U.Method need not be written as an imperative sequence. Code, rules, constraints, process diagrams, SQL queries, proof scripts, optimization models, and functional or effect-handler programs can all describe or represent a way of doing without becoming that way.

Choose by the claim being made:

• If the sentence states the reusable action, participants, applicability, intended result, and boundary, use A.3.1.
• If it points to code, prose, a protocol, diagram, solver model, or other episteme that describes the method, use A.3.2. Use A.6.0 or C.29 when the claim is instead about a formal declaration or mathematical representation.
• If it declares a law-governed operation family or asks where that declaration is maintained, use A.6.1 or E.20.
• If it schedules future work or reports a dated occurrence, use A.15.2 or A.15.1.
• If it claims evidence, provenance, or support, use A.10 and the direct evaluation or measurement owner. If a graph, path, query, table, dashboard, or publication face is being made to route or authorize action by metaphor, apply C.2.P.DR before choosing that owner.

Keep cross-context and application claims separate from those five choices. F.9 governs a Bridge between two exact F.17 SchemeSenseCell values. A claim that this Bridge suits one named use remains separate under C.2.1, and A.10 or B.3 governs reliance on that claim. C.2.1, A.6.3, A.6.3.RT, A.6.4, or A.1.1 governs an actual change of episteme edition, reference scheme, representation scheme, retargeting, or model-use relation. A.6.1 governs a mechanism realization or application binding. State one of these only when its participants and predicate are present; otherwise stop at the source objects without asserting the relation.

Thus algorithm and practice remain source cues. “The SQL query is the method” fails unless the project can state the reusable way of querying, its admissible inputs, intended result, and stop independently of that query text. “Our review practice is the method” fails when the sentence is actually about a team assignment, dated review, discipline, tradition, evidence record, or publication.

#Constructor and process-theory settlement

When a method concerns change, its statement says what change a future enactment is meant to achieve; it does not assert that any referent changed. Observation, comparison, classification, evaluation, communication, selection, proof, and preservation methods use the same rule: the reusable way can be identified without fabricating an actual change occurrence.

The constructor-theory and process-theory source line supports this separation but does not supply a universal method ontology. FPF uses it as follows:

• An admitted U.System performs dated Work under an obtaining U.RoleAssignment. F.6 performedUnderAssignment(W, RA) attributes that Work to the assignment, while the holder system performs it; the assignment neither acts nor enacts the method. A.15.1 separately requires the actual enactsMethod, extent, and executedWithin relations.
• The U.Method is the reusable way under stated participant meanings, applicability, conditions, intended result or preserved condition, and bounds. A U.MethodDescription is an episteme that describes it.
• A formal substrate or mathematical lens can make the method analyzable, and a U.Mechanism can declare the relevant operation family and laws. Neither becomes the method by providing a formula or implementation.
• A cross-context Bridge, changed reference or model-use relation, mechanism realization, evaluation, or evidence-use claim remains a separately stated relation with its own participants.
• A U.WorkPlan prepares or schedules dated Work; a Work individual is the occurrence that actually happened.

For example, “the etch method changed Wafer-22” contains at least two claims. A.3.1 identifies the reusable etch method. Only if an actual bounded change of Wafer-22 is independently grounded does A.3.4 identify that transformation; any claim connecting the Work and transformation additionally needs its own predicate or an honest missing-governor result.

This settlement works for welding, milling, reagent mixing, clinical triage, proof construction, optimization, scheduling, training, inference, and software execution without treating code as the privileged form of a method.

#Semantic identity and variants

Two U.MethodDescription epistemes may describe the same U.Method when the later comparison or reuse decision relies on the same method bases:

• effective reference scheme and local senses, when a meaning difference matters;
• generic participant meanings and declared applicability;
• compatible preconditions;
• compatible intended effects or preserved conditions;
• compatible safety and other non-functional bounds;
• accepted nondeterminism or search behavior; and
• the same work-facing acceptance relation, when that relation is part of the comparison.

Different control flow, proof notation, programming paradigm, diagram notation, or prose does not by itself make a different method. The converse also holds: the same name, repository, supplier label, or diagram family does not prove identity.

Keep one method across parameter ranges, equipment envelopes, or representation variants only when its declared applicability and the bases used by the comparison admit that variation. A changed intended result, participant meaning, safety bound, semantic basis, or acceptance criterion requires a stated refinement, substitution, or distinct-method decision.

Same-name locality replay. An emergency-department Triage method applies to patient presentations awaiting clinical assessment; a clinician enacting it uses clinical signs to assign urgency, escalates unsafe cases, and stops when the evidence cannot support that assignment. A software-defect Triage method applies to defect reports awaiting product handling; a product team enacting it uses reproduction evidence, severity, and ownership to choose routing and release impact, and stops when the report cannot support that choice. The shared label identifies neither method. Their participants, applicability, local senses, intended results, and stops distinguish them without a generic context object.

No-extra-locality replay. EuclideanGCD over positive integers closes as one method when the integer meanings, division-with-remainder rule, positivity precondition, decreasing-remainder invariant, and greatest-common-divisor result are stated. If those facts answer the comparison, add no claim scope, context slice, model-use structure, or other locality object.

#Method relation structure, composition, and work enactment

First decide whether the question is about one reusable way, a composite way, or relations among already identified objects:

• one reusable way is a U.Method;
• submethods assembled into a whole remain a U.Method, with B.1.5 used when order-sensitive composition is claimed;
• relations among methods, descriptions, selectors, or Work occurrences remain those exact relations; select a U.Structure under A.22 only when their organization changes the next question or action.

MethodRelationStructure is only a local designator for such an already selected A.22 U.Structure. It is not a durable U-kind, method holon, or relation type, and the label contributes nothing to identity. Candidate relation families—composition such as serial, parallel, choice, or iteration; method change such as refinement, substitution, decomposition, or parameterization; and selection or use such as family membership, fallback, or enactment—are recognition cues. Method-description membership is not one of those relations: A.3.2 judges the episteme itself. Every selected relation occurrence must already obtain under its direct pattern.

Filled A.22 basis — enacted-method review. For this one-off review, a practitioner selects only two A.15.1 enactsMethod occurrences. No durable selection judgment is asserted, and no composition, fallback, selector, or work-to-pump relation is created.

• Independently identified constituents. InspectPumpSeal@PumpMaintenance-2026 and ClassifyPumpSealCondition@PumpMaintenance-2026 are independently identified U.Method values. Pump37SealInspectionWork-2026-07-25T0900-0908 and Pump37SealClassificationWork-2026-07-25T0910-0916 are independently admitted A.15.1 Work occurrences: PumpDiagnosticService-A : U.System performs each under obtaining Pump37DiagnosticAssignment-2026-07-25 : U.RoleAssignment; the corresponding F.6 performedUnderAssignment occurrences, exact extents, and executedWithin(..., Pump37MaintenanceCell-A) occurrences obtain. The fixture states no direct Work-to-Pump_37 predicate, so neither Work is said to affect or concern the pump merely because its designator contains Pump37.
• Selected obtaining relations. enactsMethod(Pump37SealInspectionWork-2026-07-25T0900-0908, InspectPumpSeal@PumpMaintenance-2026) and enactsMethod(Pump37SealClassificationWork-2026-07-25T0910-0916, ClassifyPumpSealCondition@PumpMaintenance-2026) obtain under A.15.1. Their labels, times, or adjacency would not make them obtain.
• Applied constraint claims. DiagnosticReviewWindowConstraint states that an eligible enactsMethod occurrence must have one of the two independently admitted Work individuals as its Work participant and an extent within 09:00-09:20 on 2026-07-25. NoCompositionFromEnactmentOrderConstraint states that their timestamps and order establish no serial, fallback, or whole-method relation.
• Selection-use frame. DiagnosticMethodEnactmentFrame states the question: which methods did these two Work occurrences enact during the review window? The admissible action is to list the two enactsMethod occurrences in that review. The prohibited overread is a composite method, work plan, method quality, causal success, authority, or any relation to Pump_37.

Those four discriminators identify DiagnosticMethodEnactmentStructure-2026-07-25-0900-0920, locally designated MethodRelationStructure for this use. Reidentify it only from its four constituents, two obtaining relations, two applied constraint claims, and use frame. Its label, selecting system, selection Work, result episteme, graph, or table is not an identity field. If the project relies on a persisted selection, separately identify the system that made it, the selection method and dated Work, the participation relation or A.6.1 binding used by that Work, and the C.2.1 result episteme. Add a decision claim only if the project also asserts an accountable choice; A.22 puts none of these neighboring objects into structure identity.

Missing-governor stop. Suppose a note additionally calls ClassifyPumpSealCondition@PumpMaintenance-2026 a fallback for InspectPumpSeal@PumpMaintenance-2026, but supplies no direct fallback predicate, compatible participant meanings, or occurrence-identity rule. Keep the two methods and the note, omit the fallback relation, and return missing-governor: fallback relation for <ClassifyPumpSealCondition@PumpMaintenance-2026, InspectPumpSeal@PumpMaintenance-2026>. If the question is specifically about fallback organization, do not select a positive structure until that relation and all four A.22 discriminators are available.

Method-holon composition is not A.14 component mereology. Source labels such as SerialStepOf or ParallelFactorOf remain cues until B.1.5 or another direct owner supplies an admitted relation with participants and an obtaining rule. A method-description node is not a submethod unless the described object is independently identified as a U.Method.

Work composition is occurrence-side. Work may interleave, split, retry, or fail differently from the method description. A temporal Work part can enact the same whole method, and an episode can change Work continuity without changing method identity. Call a candidate a submethod only when it has its own reusable action, preconditions, intended result or preserved condition, boundary, and whole-method relation.

Quick distinction. A step label, graph node, detector component, event-log segment, telemetry interval, work-plan item, or document section is not a submethod by position. If it states a reusable way with method-level conditions and a relation to the whole method, test it under A.3.1 and B.1.5. If it states what happened, when it happened, what a component did, or what a record shows, use the direct Work, mechanism, evidence, or description pattern instead.

Mathematical or graphical notation may describe the selected structure under C.29 or occur in a U.MethodDescription. It does not become the method, structure, plan, Work, mechanism, or selector registry by form. Likewise, a registry row merely lists or describes candidates; it establishes no relation among them.

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

For these kinds of participants and conditions, what reusable way should a future enactment follow; what should it observe, compare, classify, decide, derive, change, produce, control, or preserve; what result or preserved condition is intended; and when should it stop?

Non-transformative method replay. DuplicateDefectReportComparison applies to two defect reports for the same product and release when both contain the required symptom and version data. An evaluator enacting it compares those fields and records same incident, different incidents, or insufficient information; missing version data is a stop. This closes a method statement without claiming that either report, product, or incident changed and without opening A.3.4.

Actual-transformation branch. The filled Etch_Al2O3 replay in 5.1 closes the reusable method without actual-change facts. If a later assertion says that Wafer-22 changed during Work W-143, identify the Work under A.15.1 and the actual transformation of Wafer-22 under A.3.4 separately; connect them only through a declared predicate or return missing-governor[work-to-change].

Manufacturing, optimization, proof, graph or query overread, and clinical triage differ in material, representation, and assurance needs, but they share the same method-identification question. 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

Situation. A fab process engineer must decide whether two current SOP editions describe the same alumina-etch method before either description is cited in a work plan. The engineer needs a reusable method identification, not permission to run the tool and not proof that any wafer changed.

Reusable way and applicability. Etch_Al2O3 applies to alumina-coated silicon wafers whose substrate class and coating range satisfy RecipeWindow-Al2O3-3, using a qualified PE-4 plasma-etcher family and the gas-mixture range declared by that window. Its generic participants are the wafer surface, qualified etcher, admitted gas mixture, target-depth parameter, and safety bounds; none is an actual run participant merely because it is named here. A future enactment holds the admitted pressure and temperature envelopes, adjusts exposure until the declared target-depth stop, and preserves the substrate and maximum-temperature conditions.

Preconditions and stop. The method is applicable only when the wafer material and coating range are known, the selected PE-4 calibration is current for the planned use, the admitted gas mixture is available, and the safety interlocks required by RecipeWindow-Al2O3-3 are part of the intended setup. If the wafer is outside that range, the calibration basis is missing, or the target-depth and preservation limits are absent, keep alumina etch as a method cue and stop; do not widen this method by name.

Visible identification result. Under effective FabProcessScheme-2026, where Al2O3, target depth, and substrate preservation have the local senses used above, the engineer can write:

MethodRef: Etch_Al2O3
SemanticBasisIfMeaningVaries: FabProcessScheme-2026 (`Al2O3`, `target depth`, and `substrate preservation`)
Applicability: alumina-coated silicon wafer; RecipeWindow-Al2O3-3; qualified PE-4 family
GenericParticipantMeanings: wafer surface; qualified etcher; admitted gas mixture; target-depth parameter
MethodConcern: remove the admitted alumina layer to the declared target-depth stop
Preconditions: material and coating range known; calibration current; gas and safety setup available
IntendedResultOrPreservedCondition: target depth reached; substrate and maximum-temperature bounds preserved
NotEstablished (ClaimBoundary): no work authorization, dated run, actual participant, actual wafer transformation, metrology acceptance, or evidence claim

This result lets the engineer compare the two SOP claim sets against one method identity and lets a later work plan cite that method and the selected description edition. The SOP, PLC program, calibration recipe, and supplier note remain U.MethodDescription candidates when A.3.2 identifies what each episteme describes (EntityOfConcern) and the substantive claims it carries. The identification does not authorize Work W-143, establish that the run occurred, or establish that Wafer-22 changed or passed metrology. Those stronger claims open their own A.15.2, A.15.1, A.3.4, measurement, evidence, assurance, or gate routes.

#Optimization model

Situation and reusable way. JS_Schedule_v4 applies when the jobs, eligible machines, durations, precedence constraints, feasibility rules, and optimization objective are all stated for the scheduling problem. A planner or solver system enacting it constructs candidate assignments, rejects infeasible candidates, compares the remainder by the declared objective, and records the selected schedule or no feasible schedule. Missing precedence data, an unstated objective, or incompatible machine eligibility is a stop rather than permission to guess a method variant.

This identification lets a planner compare two solver packages as descriptions of the same scheduling method. The MILP formulation and solver configuration are U.MethodDescription or formal-substrate candidates according to the claim. The selected production schedule is a U.WorkPlan; the dated solver run is Work; and its decision record is a separate result episteme. None becomes the method merely by containing the same job and machine names.

#Proof or derivation

Gauss_Elimination applies to a matrix and right-hand side over a declared algebraic domain in which the required row operations and pivots are valid. A mathematician or proof system enacting it applies equivalence-preserving row operations until solved or echelon form is reached. A missing admissible pivot, unsupported division, or unspecified domain is a stop. The visible result here is a method identification that a later derivation may enact; it is not the derived solution or proof that one run succeeded.

A textbook explanation, proof-assistant script, and formal rule set are method descriptions. A concrete proof-assistant run is Work, and the algebraic structure may be a formal substrate. Using the resulting proof for a project decision additionally needs an evidence or assurance relation.

#Graph or query overread

A graph path, SQL query, checklist predicate, or dashboard table normally represents a relation, state, evidence structure, provenance structure, or publication face. It supports a method identification only when the project can separately state the reusable action, admissible inputs, branch criterion, intended result, and stop. A query text that returns rows is still a description or executable representation until that semantic way is stated.

If wording says that the graph “routes” a project, the query “calls” a work sequence, or the table “authorizes” action, apply C.2.P.DR. A visible arrow or row order is the tempting wrong action: it establishes neither method order, dated Work, gate passage, nor authority.

#Clinical triage protocol

SepsisTriage_v3 applies to adult emergency-department presentations inside its declared population and assessment window. A clinician enacting it evaluates the stated signs and measurements, assigns an urgency class, and selects the next clinical response. Insufficient evidence, a patient outside the admitted population, or a presentation requiring another protocol is a stop. The visible result here is the reusable triage method and its boundary, not an admission decision or proof of benefit.

The protocol PDF, order-set screen, and decision-support rule are method descriptions or publication faces. A clinician's dated assessment is Work. The physiological model or score formula may be a formal substrate or mathematical lens. Admission policy, treatment release, and evidence that triage reduced harm remain neighboring claims under their own patterns.

#Bias-Annotation

This pattern mainly blocks seven recurring biases:

• description-as-method bias: a publication, program, diagram, or protocol is treated as the method instead of a method description;
• practice-as-method bias: a source says "practice" and the repair silently chooses U.Method without checking whether the current claim is work, role assignment, discipline, cultural-evolution, evidence, source label, or method relation structure;
• 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 to wording, a document, publication, or evidence face before the reusable action and its boundary have been stated.

Use one concrete test in every case: can the reader state the reusable action, its participants, applicability, intended result, and stop? If yes, identify the U.Method; apply A.3.2 separately to each candidate U.MethodDescription episteme; route any plan to A.15.2; and state only those enactment, evidence, or other relations that actually obtain. If not, keep the source phrase unresolved or route the claim to the owner shown in §4.

#Conformance Checklist

CC-A3.1-1 (Method identity). U.Method is one reusable way of doing under a stated concern, participant meanings, applicability, preconditions, intended result or preserved condition, and bounds. It establishes no actual participant or A.3.4 transformation. A description, plan, dated Work occurrence, evidence relation, role assignment, capability, mechanism declaration, formal declaration, publication face, or pattern relation does not close this test. If the sentence also makes one of those claims, write that claim under its owner and state only the relation to the method that actually obtains.

CC-A3.1-2 (Semantic locality). State the applicability, participant meanings, conditions, intended result, and bounds that distinguish the method. Add an effective reference scheme and local senses only when different meanings would change the identification. Add a claim scope, context slice, selected structure, or model-use relation only when its predicate obtains and changing that object would change the identification or the stated later decision. Same spelling, team, discipline, repository, or location proves none of those bases.

CC-A3.1-3 (Method-description membership and use). When work, assurance, gate, or audit reliance depends on a method description, name the exact episteme and verify that it meets A.3.2 membership for this Method. If several epistemes are treated as descriptions of the same Method, their EntityOfConcern references must resolve to the same A.3.1 identity; compare their claim sets separately for the proposed use.

CC-A3.1-4 (Assignment-free method). A method may state role-kind admission conditions or capability-fit conditions. These are method-side admissibility conditions, not deontic obligations by default. The method does not bind named people, teams, organizations, or calendar allocations.

CC-A3.1-5 (Runtime-free method). A dated run is a Work individual under U.Work, not a method field. A.15.1 separately grounds its performer system, covering assignment and attribution, enacted method, extent, containing system, and every participation or resource relation used by the claim. Telemetry, logs, measurements, evaluations, production, delivery, acceptance, and result records remain separate claims.

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, mechanism declaration, realizer, or control model can constrain or help explain a method only through a relation with stated participants. Use E.10.ARCH:3.1 to classify that neighboring claim. It does not identify the method until the reusable action, applicability, intended result, and boundary are stated.

CC-A3.1-8 (Programming-paradigm neutrality). Imperative, functional, logical, constraint, object-centric event, effect-handler, and hybrid forms remain descriptions or representations until the reusable way and its boundary are stated.

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 parts, structures, and Work parts). Call a candidate a submethod only when its reusable action, preconditions, intended result or preserved condition, boundary, and relation to the whole method are stated. Otherwise keep the step, graph node, description fragment, Work part, episode, component behavior, or telemetry slice under its own pattern. A selected method-side U.Structure must have all four A.22 discriminators; layout and list membership establish none of them. Mathematical or graphical notation remains a description or C.29 representation.

CC-A3.1-11 (Practice wording recovery). For a source word such as practice, ask what the sentence lets the reader do: reuse a way, inspect a description, schedule or report Work, allocate a holder, classify a discipline or tradition, cite evidence, or merely quote a label. Choose the corresponding owner only when that action is stated; otherwise retain an unresolved source cue.

CC-A3.1-12 (Parameter and variant discipline). Parameters may be method semantics or content of a U.MethodDescription. A U.WorkPlan may name planned values only against the declaration that gives those values their meaning. An actual value or participant requires an obtaining direct subject relation or A.6.1 application binding; neither method nor description makes it actual. Effects, bounds, participant meanings, applicability, and any semantic basis used by the comparison determine variant identity.

CC-A3.1-13 (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 one explicit choice: before relying on words such as method, practice, algorithm, workflow, process, procedure, program, recipe, proof, or solver, say whether the source means a reusable way, its description, planned or performed Work, a mechanism, a representation, or another concrete claim.

#Lowering and local repair conditions

Withdraw a U.Method identification when the text cannot answer the ordinary method question: what reusable action is meant, for which participant kinds and conditions, with what intended result or preserved condition, and where it stops. Also withdraw it when the supposed method is only a document, repository, diagram, model, run log, team, supplier label, or authorization; when one value is called both method and mechanism without a governing dual-typing rule; or when a graph or table is being read as an execution order without C.2.P.DR recovery.

Keep a source word such as practice unresolved when the sentence does not reveal whether it means a reusable way, a description, planned or performed Work, an assignment, a discipline or tradition, evidence, or a quoted label. Do not force one of those meanings merely to complete the form.

Repair locally:

• If the reusable way is recoverable, rewrite its identification with the missing applicability, participant meaning, condition, result, or stop.
• If a description, plan, Work occurrence, mechanism, representation, evidence claim, or result has occupied the method position, move that claim to its owner. State a relation back to the method only if that owner admits it; otherwise keep the two objects separate.
• If a relied-on episteme no longer meets A.3.2 membership, or its cited edition, claim set, acceptance relation, semantic basis, or variant condition changed, review that changed basis and the comparisons that used it; do not invalidate every use of the method.

A new method-description edition changes the method only when it changes a method basis that the comparison relied on. A changed Work fact, measurement, evaluation, production, delivery, acceptance, or evidence result repairs that neighboring claim, not the reusable method by default. Return to G.5 or the direct method-family owner only when the available family or selector no longer separates the needed methods and variants. Poor explanation is a didactic defect to repair; it is not evidence that the method itself changed.

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

A method claim states the reusable way of doing, participant meanings, applicability, conditions, effects, and bounds. The mechanism episteme declares a law-governed operation family, its subject and range fields, operation algebra, laws, admissibility predicates, and Applicability. A Bridge, realization, evaluation, or evidence-use claim may relate to that episteme without entering its semantic content. The method and mechanism may be linked, but they are not two names for one untyped value.

#SoTA-Echoing

Review a project's U.Method identification when a change in participant meaning, applicability, precondition, intended result, preserved condition, safety bound, effective scheme, selected structure, model-use relation, or work-facing acceptance criterion could make a reader identify a different method or allow a different case. If only a description edition, Work occurrence, transformation, representation, measurement, or evidence relation changed, review that neighboring claim unless the change also alters one of those method bases.

Use G.11 when a later decision depends on the freshness or edition of a cited method description or source. A newer paper, implementation, or run is a reason to inspect the relation that cites it, not automatic evidence of a new method. Reopen A.3.1 itself only when stronger work overturns one of the distinctions that the project actually relies on.

#Relations

• Identity and meaning: builds on A.1, A.2, A.2.1, A.2.2, and C.2.1; use F.17 when a local sense matters and G.11 when a comparison relies on source or edition currentness.
• Description, composition, and variation: coordinates with A.3.2 for method descriptions, A.3.3 for dynamics, B.1.5 for order-sensitive method composition, B.2 for whole reidentification, and G.5 for method families and selector outcomes.
• Work and change: coordinates with A.15.2 for plans, A.15.1 for dated Work, and A.3.4 only after an actual changed referent and transformation are independently claimed. Role values, assignments, and role relations remain under A.2, A.2.1, and A.2.7.
• Mechanism and representation: coordinates with A.6.0 for formal declarations, A.6.1 and E.20 for mechanisms, C.29 for mathematical-lens use, F.9 for sense Bridges, and A.1.1 only for an obtaining model-use relation or selected BoundedModelUseStructure that changes the method decision.
• Source-wording exits: coordinates with C.20, C.36, and C.36.P for discipline and cultural-evolution uses of practice; A.10 for evidence and provenance; and C.2.P.DR for representations overread as routes or Work sequences.
• Informs: E.18 and E.18.1 when flow-structure or P2W wording must keep descriptions, mathematical paths, method claims, and Work claims separate.

#A.3.1:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)