#U.MethodDescription: Description Episteme for a Way of Doing

A.3.2 · 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 engineers need reusable claims about how one method is carried out and must keep those claims distinct from the representation, publication, approval, plan, or actual work through which the method is discussed or enacted. In FPF terms, decide whether an already identified U.Episteme is a U.MethodDescription: whether its exact EntityOfConcern is one admitted U.Method and its claims say something substantive about that method as a way of doing.

#Aliases

• U.MethodDescription

#Keywords

• method-description membership
• claim-bearing episteme
• exact U.Method EntityOfConcern
• substantive way-of-doing claim
• same method versus equivalent descriptions
• representation versus publication versus plan versus Work.

#Relations

#Content

#Problem frame

Use this pattern when engineers need reusable claims about how one method is carried out and must keep those claims distinct from the representation, publication, approval, plan, or actual work through which the method is discussed or enacted. In FPF terms, decide whether an already identified U.Episteme is a U.MethodDescription: whether its exact EntityOfConcern is one admitted U.Method and its claims say something substantive about that method as a way of doing.

Plain reading. A method description is the knowledge object whose claims say how one identified method is done. Code, text, or a diagram may represent those claims; a publication occurrence may make an edition available; neither fact decides membership.

Recognizable working moments include:

• a maintenance team comparing a revised procedure with the method used to plan the next service window;
• a clinical team selecting a triage guideline while keeping guideline claims, approval, and patient-specific work separate;
• a production-planning team comparing scheduling-method claims while the MILP representation and solver runs change.

Use it when the working question is:

• which admitted U.Method is the exact EntityOfConcern;
• which claim states the method's transformation or enactment concern, applicability, precondition, effect, bound, or internal composition;
• whether anyone is proposing a use beyond membership; if so, what that use is, where it belongs, and which method claims it needs;
• which C.29 representation corresponds to the claims, which publication occurrence makes the selected edition available, which publication form expresses it, and which U.PresentationCarrier bears that form—but only when the proposed use needs those distinctions;
• whether two epistemes describe the same A.3.1-reidentified Method and, separately, whether their claims are equivalent for the proposed use. If their effective reference schemes differ, first establish the F.9 Bridge between the two SchemeSenseCell values. That Bridge establishes correspondence only. Positive reliance on the proposed reuse also needs a separate C.2.1 claim for that bounded use. For ordinary below-threshold evidence reliance with no assurance claim, require RelianceDisposition=pass from A.10. If an assurance claim is current or the B.3 material-reliance threshold is met, enter B.3; positive assurance requires a current positive claim with its sufficient record, while no claim or an insufficient record blocks or narrows the assurance use. A negative or absent use claim, a non-passing A.10 disposition, or a non-positive B.3 outcome blocks or narrows reuse while the Bridge remains true.

Primary governed object. A.3.2 examines one already identified claim-bearing U.Episteme candidate and judges whether that same individual belongs to the dependent kind U.MethodDescription. For positive membership, the candidate episteme's exact C.2.1 EntityOfConcern must resolve to one admitted U.Method, and at least one of its claims must concern that Method as a way of doing. The Method is the internal subject of the episteme's claims, not a second candidate and not the primary object of this membership judgment. A.3.2 adds neither another episteme identity nor a binary description relation.

Primary working reader. An engineer, researcher, publisher, teacher, planner, or auditor who must identify or rely on reusable claims about a method before planning, enactment, comparison, audit, revision, publication, or teaching.

Primary working concern. Identify the claim-bearing episteme and its Method first. When someone proposes a further use, name that use and its owner, then ask which claims the use needs and whether this edition contains them. With no proposed use, stop at membership.

Primary viewpoint. The practitioner selecting, comparing, or revising method descriptions while method identity and the surrounding representation and publication relations remain explicit.

First useful move. Name the candidate U.Episteme. Check two things: its C.2.1 EntityOfConcern is one admitted U.Method, and at least one claim says how that Method is done. If both hold, the same episteme is a U.MethodDescription; if either fails, it is not. Only then, if someone proposes a concrete further use, write that use's criterion and result under the pattern that owns it. Otherwise stop at membership; do not invent Work, a decision, or an adequacy result.

What goes wrong if missed. A visible file or diagram is classified by its form, a mere mention is mistaken for a description, or an episteme about a relation structure among several methods is treated as if it described one composite method. Planning, enactment, audit, and review then rely on the wrong governed object.

What this buys. The project can identify, compare, revise, and reuse method descriptions while keeping the described U.Method, RelationSignature, OperationAlgebra, C.29 representations, publication occurrences and forms, presentation carriers, work plans, work occurrences, and evidence under their own governing patterns.

Not this pattern when. Do not infer membership from words such as algorithm, program, proof, workflow, process, procedure, recipe, or model. Ask what the sentence actually asserts. If its EntityOfConcern is not an admitted U.Method, or it says nothing substantive about that Method as a way of doing, A.3.2 does not apply. Use the owner of the actual method, selected structure, formal declaration, work plan, dated Work, evidence use, or publication use instead.

#Problem

Without a precise U.MethodDescription distinction, projects collapse several different claims:

1. Description as run. A flowchart, repository, executable, lab protocol, or solver file is treated as if it were the dated work occurrence.
2. Description as method semantics. A notation or file is treated as the method itself, so equivalent descriptions look like competing methods and different methods can hide behind one document name.
3. Description as plan or authority. A protocol, dashboard cue, gate-looking entry, or approved procedure note is treated as a work plan, permission, gate passage, or evidence result.
4. Description as declaration, mechanism, or formal substrate. A proof script, algorithm, model, or rule set is treated as if it already were a RelationSignature, an A.6.1 operation declaration, a mechanism law set, or a mathematical substrate.
5. Imperative overread. A declarative representation, graph path, query plan, constraint model, or state predicate is interpreted as an ordered work-control claim.
6. Subject identity and description equivalence collapse. Two epistemes that concern the same method are treated as equivalent despite incompatible claims, or a notational difference is used to fork method identity without the A.3.1 reidentification rule.

#Forces

#Solution

#Definition

U.MethodDescription is a same-individual dependent kind of U.Episteme. Membership holds when the already identified episteme has one admitted U.Method as its exact EntityOfConcern and its claims, interpreted under the effective U.ReferenceScheme, make at least one substantive claim about that method as a way of doing. Such a claim may state the method's transformation or enactment concern, generic participant meanings, applicability, precondition, intended effect or preserved condition, bound, or internal method composition. These are claims about method semantics, not planned assignments or actual participation. Naming the method, giving bibliographic metadata, or stating approval alone does not establish membership.

The C.2.1 claim content, exact EntityOfConcern, and effective U.ReferenceScheme remain the identity discriminators of the episteme; A.3.2 adds no second identity. Whether the claims are detailed, current, or reliable enough for a particular planning, enactment, comparison, audit, revision, publication, or teaching use is a separate evaluation. A new receiving use alone neither creates a new method description nor removes membership.

If someone claims empirical grounding, state the C.2.1 EpistemeEmpiricalGroundingRelation. If a proposed use depends on a test, write the tested claim, criterion, evidence path, and result under the evaluation, evidence, or assurance pattern that defines them. Do not add these as method-description fields or let a test change membership.

An assertion or description episteme about one dated Work occurrence may cite methodDescriptionRef when its claim depends on that description edition. The holder U.System performs the Work under an obtaining U.RoleAssignment; F.6 performedUnderAssignment(W, RA) attributes the Work to that assignment, and A.15.1 enactsMethod(W, M) relates it to the Method. The description itself neither performs Work nor is enacted.

#Representation-agnostic stance

Begin with the claim-bearing episteme, then distinguish how its claims are made available:

• a C.29 representation stands in a declared correspondence to the represented claims;
• an E.24.PUB publication form expresses the selected episteme edition for one publication use;
• a U.PresentationCarrier bears that publication form.

These are different objects and relations. None becomes U.MethodDescription by appearance. Only the claim-bearing episteme, not its representation, form, carrier, or publication occurrence, can meet the membership rule in 4.1.

The representation may use procedural text, code, a diagram, functional composition, a typed pipeline, a state machine, event rules, constraints, a solver formulation, a proof script, a statistical model, or a combination of notations. Notation choice does not decide membership. Read each assertion separately: use A.6.0 or C.29 when it asserts a formal object, A.6.1 or E.20 when it declares an operation family and laws, A.15.2 when it states intended Work, and A.10 or B.3 when another claim relies on it as evidence or assurance.

#Method-description claim content

The membership threshold is positive but small: at least one claim must answer a method-side question about the way of doing. A name, author, citation, catalogue entry, or approval status does not answer such a question. This threshold distinguishes description from mention; it is not a completeness test for a receiving use.

Name the receiving use before asking whether this method-description edition is adequate for it. A receiving use is not required for U.MethodDescription membership. If no use is current, stop at the membership result and make no adequacy claim.

A.3.2 creates no universal method-description-use relation. Name the concrete receiving object and its owner. Comparing claim sets, revising a publication, or checking teaching content does not require a fabricated Work occurrence or decision object.

Then inspect the claim concerns that matter for that named use:

Calendars, assignees, work authorization, gate passage, and dated execution witnesses are governed by planning, assignment, gate, or work-occurrence patterns. They may cite a method description but do not become its claim content merely because they appear beside it.

A U.MethodDescription describes one admitted Method. It is not the RelationSignature that declares participants for one relation kind, the A.6.1 OperationAlgebra content that declares arguments and results for an operation family, the U.WorkPlan that states intended work, a dated Work occurrence, or any actual-participation relation of that occurrence.

#Method-description acceptance and use boundaries

A project may accept, regulate, prefer, deprecate, or forbid a method description for one stated use, organization, or policy scope. Record that separate publication, gate, authority, or policy claim under its own pattern. It neither establishes U.MethodDescription membership nor turns the description into Work, evidence, a gate decision, or a mechanism.

When a method description is used to prepare or enact work, keep the chain explicit:

1. C.2.1 identifies one episteme through its claim content, exact EntityOfConcern, and effective U.ReferenceScheme; A.3.2 judges that same episteme to be U.MethodDescription. Plainly saying that the method description describes the method is shorthand for this constitution and membership judgment, not another binary relation occurrence.
2. U.WorkPlan may cite that episteme when preparing dated work.
3. The holder U.System performs dated Work under an obtaining U.RoleAssignment; F.6 performedUnderAssignment(W, RA) attributes it to the assignment, and A.15.1 enactsMethod(W, M) relates it to the Method. A separate assertion cites methodDescriptionRef only when its claim depends on that edition.
4. The word result is only a cue. Ask which claim is being made: an A.6.1 application returned a value, a referent changed under A.3.4, Work produced something under A.15.PROD, or a measurement, evaluation, delivery, or acceptance occurred. If the use needs a Work-to-result relation and no owner admits one, keep Work and result separate and return missing-governor[work-to-result]. A log, trace, measurement, or result episteme supports another claim only through its evidence relation.

#Method, mechanism, and formal-substrate boundary

Do not classify by the source word alone. First say in plain words what someone is trying to change, produce, select, derive, control, or maintain and what the sentence asserts about it. Then use E.10.ARCH:3.1 to separate method, mechanism, formal-object, plan, Work, and result claims; write each claim under its own pattern.

For A.3.2 ask only: is this episteme about one admitted Method, and does at least one claim say how that Method is done? If the same source also asserts a mechanism, formal declaration, work plan, dated Work, evidence use, gate, result, publication, or temporal claim, state that claim separately. Sharing one source does not connect those objects.

Use these claim checks instead of forcing distinct claims into one generic relation:

• A method-description membership judgment identifies one admitted U.Method as the episteme's exact EntityOfConcern and finds at least one substantive claim about that method as a way of doing.
• A method claim states the reusable way of doing, its participant meanings, applicability, conditions, intended result or preserved condition, and bounds.
• A formal-substrate claim concerns the selected formal object, structure, invariant, or mathematical declaration used for reasoning.
• A mechanism-declaration claim concerns the law-governed operation family, direct subject and range fields, operation algebra, law set, admissibility predicates, and applicability. Transport, audit, realization, evaluation, and evidence-use relations remain separately governed neighboring claims.
• A work claim concerns one dated occurrence: the holder system that performs it, the covering assignment and F.6 attribution, enacted method, temporal extent, and containing system. Add participant, resource, or work-to-referent claims only through relations that actually obtain; otherwise return the corresponding missing-governor result.

Connect these claims only through an admitted relation whose predicate and participants are present. If no owner admits the needed relation, keep the objects separate rather than inferring dual typing or turning a method description into Work. Example: a scheduling-method episteme can meet the membership rule while a MILP file represents some of its claims. Another episteme may describe the mathematical formulation; a selector mechanism may declare operations over candidate methods; a dated solver run is Work; and an issued production-schedule episteme is a separate result. Use that result as evidence only through a current A.10 path and its bounded disposition. Without that path, keep the result available but do not rely on it as evidence for another claim.

#Constructor and process-theory note

In the constructor-theory and process-theory interpretation used here, both informational and physical procedures are understood through possible or impossible transformations. That motivates a broad method-description kind without making software code privileged:

• an episteme about an information-transformation method may be represented through a program, proof script, or solver model;
• an episteme about a material, energetic, organizational, or mixed-transformation method may be represented through a procedure, lab protocol, or control recipe;
• an assertion or description about dated Work may cite a method description; the holder system still performs the Work under an obtaining assignment, F.6 performedUnderAssignment carries attribution, and A.15.1 enactsMethod relates Work to Method. No actor or TransformerRole follows from the description;
• a mechanism may declare law-governed operation structure for transformations, but that mechanism claim is separate from the method-description claim.

This interpretation does not justify classifying every algorithm-looking expression as U.MethodDescription. It only explains why FPF can treat many representation forms uniformly after the current claim and described method are recovered.

#Declarative representation boundary

Some method descriptions use declarative representations: constraint sets, graph patterns, state predicates, SQL-like queries, policy rules, e-graphs, monoidal diagrams, or process constraints. Do not translate such representations into an imperative route unless the method claim actually states an ordered action structure.

If wording turns a graph path, evidence path, query plan, predicate, checklist, publication face, or pattern relation into a route, first say what it represents and whether the source actually asserts an order. Use C.2.P.DR to stop layout from creating a dispatch, call, or work-control sequence; state a genuine ordered method or WorkPlan only under its own pattern.

#Composite methods and independent method structures

When claims concern relations among methods, first determine whether the related methods construct one admitted composite U.Method.

If admitted methods are actual method parts whose organization constitutes one composite method under A.3.1 and, when order-sensitive composition is current, B.1.5, the composite U.Method remains the exact EntityOfConcern. A U.MethodDescription can make substantive claims about that composite method's internal organization without changing its object of concern to an independently selected structure.

Description nodes, workflow boxes, code blocks, proof-script blocks, diagram paths, and table rows are representation constituents. They do not become method parts by position in the description. A constituent can participate in method-holon composition only after the recovered object is itself an admitted U.Method.

If a selected relation structure instead connects several methods as alternatives, substitutes, fallbacks, comparison candidates, or members of a family without constituting one composite method, the selected U.Structure is the exact EntityOfConcern under A.22 and C.2.1. The resulting episteme can describe that structure, but the present rule does not classify it as U.MethodDescription.

An algebraic, graph, categorical, process-calculus, effect-calculus, matrix, embedding, distributed, or neural representation can be used to express or analyze either case. Its correspondence to claims is governed separately through C.29. A work plan, work occurrence, method-family registry, or selector result also keeps its own governed object and governing pattern.

#Archetypal Grounding

Across the slices below, recognize the claim-bearing episteme before examining how it is represented or published. Ask in this order:

1. Which admitted U.Method is its exact EntityOfConcern?
2. Which claim says something substantive about that method as a way of doing?
3. Is anyone proposing a use beyond membership? If so, name the use, its owner, and the claims it needs; if not, stop at membership.
4. When expression or availability matters, which C.29 representation corresponds to the claims, which publication occurrence makes the selected edition available, which publication form expresses it, and which U.PresentationCarrier bears that form?

#Industrial procedure

A procedure episteme about EtchAl2O3@FabA qualifies when its claims state how the etching method is done: gas-feed participant meanings, temperature bounds, chamber preconditions, intended etch profile, failure conditions, operator role kind, calibration capability threshold, or admitted parameter ranges.

A PDF publication form may express one edition of those claims, and a PLC ladder representation may correspond to some of them. Their visible forms do not establish membership. The scheduled maintenance-window preparation is a U.WorkPlan; tool run W-143 is Work. A metrology result supports another claim only through the evidence relation for that claim.

Named-use replay — preparing WP-Etch-MW-47. The maintenance planner needs four claims before drafting this A.15.2 U.WorkPlan: the chamber is empty, inert, and leak-check complete before gas feed; the method's temperature range is 58–62 °C; calibration is no more than 24 hours old; and pressure above the stated bound stops the run. EtchAl2O3-Description-e7 passes A.3.2 membership because it concerns EtchAl2O3@FabA and says how that Method is done. It also states all four needed claims. To verify that this is the current edition, the planner checks its ClaimGraph against publication occurrence Pub-Etch-e7, publication form EtchAl2O3-SOP-e7, and carrier FabA-MethodRepository-2026, plus the source trace from EtchDescriptionReleaseWork-e7, performed under EtchDescriptionMaintainerAssignment-4 with method trace ClaimGraphReleaseCheck-v2. A.10 path EP-Etch-e7-Plan47 links those sources to claim C-Etch-e7-has-Plan47-claims. Its bounded use is citing e7 while drafting WP-Etch-MW-47; unsupported uses are gate passage, authorization, safe execution, and a claim that Work occurred. Its window reopens when e7, RecipeWindow-Al2O3-3, the calibration rule, or a source named in the path changes. RelianceDisposition=pass therefore supports citing e7 only for this drafting use.

EtchAl2O3-Description-brief-e7 still passes membership because it concerns the same Method and states the gas-feed and temperature procedure. It omits the 24-hour calibration condition and pressure stop. A.10 path EP-Etch-brief-e7-Plan47 points to that brief edition and cannot evidence the two missing claims, so RelianceDisposition=blocked-current-use applies to drafting WP-Etch-MW-47. Reopen after selecting an edition that states both claims; until then the planner stops or selects another edition. Membership is unchanged. If the result must persist, C.2.1 owns its result episteme and ClaimGraph, A.10 owns the evidence path and disposition, and A.15.2 owns the plan. A.3.2 creates no generic adequacy relation.

#Optimization model

A scheduling-method episteme qualifies when its exact EntityOfConcern is JSScheduleV4@Plant2026 and its claims state how a production schedule is produced or evaluated. A MILP representation and an explicitly recovered solver-configuration representation can stand in declared correspondence to those claims.

A separate formal-substrate episteme can make claims about variables, constraints, objective, admissible solution set, or invariants. A publication form expressing that episteme may be borne by the same presentation carrier, but the carrier does not make the claims or establish their truth. A timestamped solver run is work. A selector mechanism, if declared, is governed by A.6.1 and E.20. Solver search order does not by itself state the project work sequence.

#Proof script

An episteme about a reusable derivation or checking method qualifies when it identifies that U.Method exactly and makes a substantive claim about how the derivation or check is done. A proof-assistant script may represent those claims. The script's notation does not establish membership.

A concrete proof-checking session is work. Claims about a formal substrate, a theorem, or evidence for the theorem remain separately governed even when publication forms expressing those epistemes are borne by the same carrier. A publication occurrence, not the form or carrier, makes a selected edition available to an audience for a bounded use.

#Clinical guideline

A guideline episteme qualifies when its exact EntityOfConcern is AcuteAppendicitisTriage@HospitalContext and its claims state the triage method through patient-information and resource participant meanings, exclusions, decision criteria, relevant role kinds and capabilities, intended effects, or failure response. A publication form expresses one selected edition, and a publication occurrence can make that edition available; approval status remains a separate claim.

Patient-specific dated enactment is a Work individual admitted under U.Work. If a causal claim relies on a triage disposition, diagnostic finding, or measurement result, name that premise and apply C.28. Merely using the guideline during Work establishes neither a causal effect nor a causal-use result.

#Workflow diagram

An episteme whose claims state one reusable method may qualify as U.MethodDescription; a BPMN or object-centric process model may represent those claims. A diagram can also represent a work plan, event-log model, or independently selected structure, so its notation does not settle the exact EntityOfConcern.

If readers treat the diagram as a route that tokens or workers must follow, compare that reading with the source claim. Keep an ordered sequence only when the method claim actually states one. When order comes only from layout, use C.2.P.DR and stop at the represented graph, constraints, objects, or events.

#Bias-Annotation

This pattern mainly blocks six recurring biases:

• carrier-as-description bias: a PDF file, repository, screen, or presentation carrier is treated as the method description. Identify the episteme whose ClaimGraph is being read, then record its C.29 representation and publication relations separately;
• description-as-method bias: the representation is treated as the way of doing itself;
• description-as-work bias: executable or operational-looking representation is treated as dated work;
• approval-as-proof bias: accepted, approved, or regulated descriptions are treated as evidence, gate passage, or safe execution;
• notation-prestige bias: code, formal notation, or solver files are treated as more authoritative than procedures, diagrams, or guidelines. Compare the actual method claims; representation form supplies no priority;
• imperative-metaphor bias: graph, query, predicate, or process-model representation is treated as an ordered work-control claim.

First identify the claim-bearing episteme, the claim it makes, and the Method it concerns. Then keep its C.29 representation, publication occurrence, publication form, and presentation carrier separate, and send each plan, Work, evidence, gate, authority, mechanism, formal, or mathematical claim to its own pattern.

#Conformance Checklist

CC-A3.2-1 (Episteme membership). A.3.2 judges one already identified U.Episteme candidate. That same individual is a U.MethodDescription only when its C.2.1 EntityOfConcern is one admitted U.Method and at least one claim says how that Method is done. Representation form, publication form, carrier, approval, and use adequacy do not decide membership; no binary description relation is minted.

CC-A3.2-2 (Positive description threshold). The episteme must make at least one substantive claim about the method as a way of doing, such as its transformation or enactment concern, generic participant meanings, applicability, precondition, intended effect or preserved condition, bound, or internal composition. A name, citation, author, catalogue entry, or approval status alone is mention, not method-description membership.

CC-A3.2-3 (No automatic trigger repair). Wording such as algorithm, program, proof, solver, workflow, process, procedure, recipe, or model is only a cue. Classify the episteme as U.MethodDescription only after its claim and admitted Method pass CC-A3.2-1 and CC-A3.2-2.

CC-A3.2-4 (Description not work). Executable-looking material is not a Work occurrence. A program run, proof-checking session, solver run, lab run, or clinical application is Work only after A.15.1 identifies the world-side occurrence, holder system, covering assignment and F.6 attribution, enacted Method, temporal extent, and containing system. Any participant, resource-use, or work-to-referent claim needs its own admitted relation; if none exists, return the corresponding missing-governor result.

CC-A3.2-5 (Description not plan or authority). A method description is not a work plan, gate decision, permission, approval, external-rule authorization, or evidence relation. Those claims may cite the description but require their own governing patterns.

CC-A3.2-6 (Description not mechanism or declaration). A method description is neither a RelationSignature nor A.6.1 OperationAlgebra content and does not close a mechanism claim. If reusable direct-relation participant declaration is current, use A.6.0 and A.6.5. If operation algebra, law set, admissibility predicates, or applicability is current, use A.6.1; transport, audit, realization, evaluation, and evidence-use relations remain with their direct patterns.

CC-A3.2-7 (Description not formal substrate). A method description does not close a formal-substrate or mathematical-lens claim. If variables, equations, invariants, structure, substrate, or mathematical payoff are current, use A.6.0, C.29, or the direct mathematical pattern.

CC-A3.2-8 (No people or calendars inside the description claim). A method description may state role kinds and capability thresholds that bound admissible enactment. Named people, dates, schedules, launch values, and work witnesses belong to work planning, role assignment, or work occurrence claims.

CC-A3.2-9 (Parameters and use time). A method description may state parameter meanings and ranges. A U.WorkPlan names planned values against the declaration that gives them meaning. An actual participant or operation value requires an obtaining subject relation or A.6.1 application binding; otherwise keep it planned and return missing-governor[actual-use].

CC-A3.2-10 (Same subject versus equivalent descriptions). Two descriptions concern the same U.Method only when their EntityOfConcern references resolve to the same A.3.1 method identity. A scheme difference may require an F.9 Bridge to interpret a comparison, but the Bridge does not establish Method identity. Shared subject also does not make the epistemes equivalent: state which claims are preserved, absent, incompatible, or inaccurate for the proposed use. Notation or control structure alone establishes neither a different Method nor equivalent claim content.

CC-A3.2-11 (Edition and refinement). A later file or episteme edition does not by itself refine the Method. Use C.2.1 for the edition relation; state which description claims a comparison preserves or strengthens; and use A.3.1, B.1.5, or another admitted method relation only for an actual refinement claim. If no owner admits refinement, keep the two Methods and stop at the edition or comparison result.

CC-A3.2-12 (Nondeterminism). When a description permits search, optimization, sampling, nondeterministic choice, or learned behavior, state the admissible result range and the criterion that will evaluate actual Work or results. Name that criterion's owner; the description itself establishes neither actual performance nor an evaluation result.

CC-A3.2-13 (Cross-context and semantic-locality boundary). F.9 answers only whether a Bridge obtains between two SchemeSenseCell values. For proposed reuse, state a separate C.2.1 claim with the use, direction, correspondence rule, loss tolerance, and affirmative or negative polarity. Positive polarity alone is not reliance. An ordinary below-threshold use with no assurance claim needs RelianceDisposition=pass on its A.10 path. When an assurance claim is made or the B.3 threshold is met, enter B.3: positive assurance requires a current positive claim and sufficient record, while no claim or an insufficient record stops or narrows the assurance use. A negative or absent use claim, non-passing A.10 disposition, or non-positive B.3 outcome stops or narrows reuse even while the Bridge obtains. None of those premises says that comparison, publication, planning, or Work occurred. Changes of reference scheme, unit, role taxonomy, claim scope, or model use stay under their own patterns.

CC-A3.2-14 (Declarative representation). A declarative graph, query, predicate, or model does not state an ordered work route by layout. Use C.2.P.DR to recover what it represents; assert a route, dispatch, call, or work-control sequence only when its own pattern admits that claim, otherwise stop at the representation.

CC-A3.2-15 (Causal-use boundary). A method description may describe intervention assignment, target-trial emulation, realized-counterfactual sampling, simulation, or causal-evidence collection. It does not by itself establish causal use. If causal effect, intervention success, counterfactual comparison, causal fairness, or policy effect is claimed, use C.28.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Quick use cards

• Claims first. The claim-bearing episteme can be U.MethodDescription; its exact U.Method, C.29 representation, publication occurrence, publication form, and U.PresentationCarrier remain distinct.
• Executable is still not a run. Runs are Work individuals admitted under U.Work only when A.15.1 grounds their occurrences.
• Representation is not enough. Read what the code, proof, solver file, procedure, diagram, or workflow actually asserts and name its subject. Only the claim-bearing episteme can pass A.3.2 membership; C.29 keeps the representation correspondence.
• Mechanism needs its declaration. Use A.6.1 when operation algebra, laws, admissibility, or applicability is current; keep transport, audit, realization, evaluation, and evidence-use relations under their direct patterns.
• Math needs its own claim. Use A.6.0 and C.29 when formal substrate or mathematical-lens use is current.
• No ordered-action overread. Use C.2.P.DR when declarative representations are overread as ordered action structures.

#Rationale

Projects need reusable claims about ways of doing before any dated work occurs. Treating a file as the method description by appearance hides two decisions that later work needs: which episteme is being relied on, and which admitted method its claims concern. The positive claim threshold makes this distinction usable without demanding a complete procedure card.

The pattern is representation-agnostic because a method can be described through procedural text, code, diagrams, mathematical notation, protocols, or combinations of them. The episteme can be revised and evaluated while its C.29 representations, publication occurrences, publication forms, and presentation carriers change independently. This separation lets a project compare descriptions and judge fitness for a receiving use without turning notation, approval, publication, or enactment into kind membership.

#SoTA-Echoing

Refresh this pattern when current work on process theory, effect systems, executable specifications, process modeling, graph and equivalence representations, or FPF's own method, method-description, work, mechanism, and mathematical-lens patterns changes the governing distinction.

#Relations

• Builds on: C.2.1 for the identity, grounding, and edition relations of the same claim-bearing episteme; A.3.1 for the exact U.Method; and E.24.UK for admission of the dependent U-kind.
• Coordinates with: A.3.1 and B.1.5 for actual method parts, method identity, and composite-method organization; A.22 for an independently selected structure among several methods; A.1.1 only when an independently selected BoundedModelUseStructure changes the proposed use; F.9 only for cross-context SchemeSenseCell correspondence; C.2.1 for the separate claim that one obtaining Bridge suits one bounded use; A.10 for ordinary evidence reliance on that claim and B.3 only for the assurance or material-threshold branch; C.29 for representation correspondence; E.24.PUB for publication occurrence and form; A.15.2 U.WorkPlan; A.15.1 U.Work; A.2 and A.2.1 for role and role-assignment claims; A.2.2 for capability thresholds; C.28 for causal-use claims.
• Separates from: A.6.0 formal-substrate declarations; C.29 mathematical-lens use; A.6.1 U.Mechanism; E.20 mechanism-meaning introduction and revision.
• Uses for precision restoration: E.10, E.10.ARCH, F.18, and C.2.P.DR when source wording leaves unclear what claim is made, what object it concerns, or whether a visible route is merely representational.

#A.3.2:End

---

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