A.3.1:4 - 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 any applicable limit or stop condition; 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. Use this as an attention aid.

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.

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 and its intended effect or preserved condition;
• 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 local system-role kinds or capability-fit conditions, but named holders and obtaining 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 table:

A.3.1:4.0a - 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 contains the defining content for that assertion, not when every occurrence has been replaced.

A.3.1:4.1 - 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 any applicable use limits or stop conditions. If that sentence is enough for the decision at hand, stop.
2. Later comparison or reliance. Use the needed entries in the Plain aid below when the ordinary statement is insufficient for another person to 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.

Moving to a heavier level must solve one of those concrete problems.

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

Use NotEstablished only for a stronger reading that passes F.19:4’s plausible-reader guard test. State the smallest clear correction; omit the entry when the positive identification suffices. Use the FPF term ClaimBoundary when a named neighboring subject assertion depends on 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.

For every relied-on relation, name its participants, the relation that must obtain, and the pattern that defines or constrains it. A generic source, support, evidence, or current use entry is not a replay basis. RelianceWindow states the temporal conditions under which the comparison is relied on. Identify the compared Method variants and relied-on description editions separately. ReviewIf names the concrete change that would make that comparison unsafe.

A.3.1:4.1a - 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 any use limit or stop condition that changes the identification or decision. 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 depends on 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.

Close by non-use when the source is only a description, plan, dated Work occurrence, mechanism declaration, selector result, system-role-kind relation, another direct 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.

A.3.1:4.2 - 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.

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. A.10 governs bounded reliance on that claim; use B.3 only for an actual named assurance 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.

A.3.1:4.3 - 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.

A.3.1:4.4 - 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.

A.3.1:4.5 - Representation and programming-paradigm discipline

A U.Method need not be written as an imperative sequence. A way of doing may be described or represented through code, rules, constraints, process diagrams, SQL queries, proof scripts, optimization models, or functional or effect-handler programs.

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 pattern. If a representation’s form or layout is being treated as sufficient to prescribe or authorize action, apply C.2.P.DR before choosing the pattern for that claim.

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. A.10 governs bounded reliance on that claim; use B.3 only for an actual named assurance 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.

A.3.1:4.6 - 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. The same identification rule applies to methods for other concerns, such as observation, comparison, classification, evaluation, communication, selection, proof, and preservation.

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 exact actual performer first has the A.13 core; A.15.1 then independently identifies the dated Work, at least one obtaining enactsMethod relation, time, and at least one obtaining locally declared containing-system relation. Another enactment relation is named only when the receiving claim relies on it. F.6 enters only when that claim also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. The System’s classification and the obtaining assignment remain separate claims.
• 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.
• 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 a missing-governor result.

Apply the same distinction across physical, informational, organizational, and mathematical work.

A.3.1:4.7 - Semantic identity and variants

Two U.MethodDescription epistemes describe the same U.Method when their EntityOfConcern references resolve to the same A.3.1 identity. For the proposed comparison or reuse, compare their claims about the following method bases separately:

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

A.3.1:4.8 - Method relations, composition, and Work enactment

Start with the practical question, not a graph or the umbrella word specialization. Ask what must be decided now.

Before claiming refinement or replacement, decide whether the changed account still identifies the same Method. If it does, state what was preserved and what changed; do not invent a relation between two Methods. If two Methods are identified, a refinement comparison states its direction and use, the semantics retained from the first Method, what the second narrows or strengthens, and the action or result that changes.

A replacement comparison says which Method may replace which other Method, for what use, under which preconditions, with which intended result or preserved condition, and which bounds, interfaces, losses, and guards must remain visible. Do not infer the reverse direction. Shared kind criteria or similar descriptions do not prove replacement.

When the replacement question concerns a constituent used by one or several encompassing Methods, B.1.5.RS supplies the comparison: follow the candidate through each relevant use and retain any adaptation or narrower applicability. For the distinct question of which Methods are being enacted together through a current action, use B.1.5.EW.

A parameter change inside the Method’s declared applicability and identity rule is variation of the same Method. A change to a participant meaning, result, bound, interface, or acceptance condition that matters to identity identifies another Method or leaves the identity question unresolved.

A G.5 family row cites already identified Methods and states why they are grouped for the current use. A fallback can belong to a B.1.5 whole construction, a G.5 selector rule or result, or a local relation-bearing claim. A dispatch rule says which selector branch applies; state the current branch and its basis.

When FPF has no admitted predicate for refinement, replacement, fallback, or another relation-bearing claim, use A.6.RCD to choose the lightest sufficient result. For one use, a local claim may be enough; repeated use of the same rule may justify a reusable predicate definition. Continue through E.24 and E.24.UK only when a named later use must treat the relation occurrences themselves as stable objects. A local claim or predicate definition cannot become an A.22 edge.

Short positive. ChangeImpactReview can meet two Method-kind criteria and also be required by the independent constructions of ApproveControlSoftwareRelease and InvestigateFieldIncident. Those judgments and two methodPartOf facts remain separate.

Selector anti-case. A RapidRecoveryMethods row groups RollbackRelease, DisableFeatureFlag, and ShiftTraffic for one selector. Its stated grouping basis and fallback policy may support a G.5 result, but they do not establish a Method kind, one composite Method, or a refinement or replacement relation. If the fallback condition is incomplete, return the missing fact instead of drawing an edge.

MethodRelationStructure is only a local name for an A.22 structure selected from independently identified constituents and relations that already obtain. It is not a durable kind, Method holon, or relation type. Composition, refinement, replacement, parameter variation, family grouping, fallback, dispatch, and enactment are recognition cues; the cue does not decide the claim.

Filled A.22 basis — enacted-method review. For this one-off review, a practitioner selects only two A.15.1 enactsMethod occurrences.

• Independently identified constituents. InspectPumpSeal@PumpMaintenance-2026 and ClassifyPumpSealCondition@PumpMaintenance-2026 are two U.Method values. Pump37SealInspectionWork-2026-07-25T0900-0908 and Pump37SealClassificationWork-2026-07-25T0910-0916 are two admitted A.15.1 Work occurrences.

  PumpDiagnosticAssignment is a declared U.SystemRoleAssignment species. Under A.2.1 it defines the holder and assigned-kind participant meanings and uses PumpDiagnosticSystemRoleKindDomain as the local assigned-kind domain. Occurrence Pump37DiagnosticAssignment-2026-07-25 has PumpDiagnosticService-A : U.System as holder, PumpDiagnosticSystemRole as the assigned-kind value admitted by that domain, and an extent covering both Work occurrences. That System performs each Work under the assignment and within Pump37MaintenanceCell-A.

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

• 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 that Work’s temporal extent must lie 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.

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. 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 C.11 choice claim only if one is asserted. If responsibility for that choice is also claimed, cite its direct domain predicate, actual participants, applicability, and occurrence identity or return the exact missing governor.

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 subject pattern 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. A registry row lists or describes candidates; state any relation among them separately under its defining pattern.