C.2.P.DR:4.4 - Method, algorithm, mechanism, plan, and work settlement
Do not repair algorithm, program, solver, proof, recipe, method, workflow, process, procedure, access path, query plan, or control strategy by choosing one fashionable replacement.
Method-description membership guard. A code file, SOP, proof script, solver model, process model, protocol, recipe, diagram, or query plan is only a representation clue. First identify the claim-bearing episteme under C.2.1. Apply A.3.2 only when that same episteme has one admitted U.Method as its exact EntityOfConcern and at least one claim says how that method is done, such as its transformation or enactment concern, applicability, precondition, intended effect or preserved condition, bound, generic participant meaning, or internal method composition. A name, author, citation, approval, file form, runnable configuration, or representation correspondence alone is a near-miss. If the test fails, do not assign U.MethodDescription; keep the representation, publication, plan, dated work, result, formal substrate, mechanism declaration, evidence, or source use with its subject pattern. A representation or publication change does not decide membership. If claim content, exact method, or effective reference scheme changes, C.2.1 first identifies the resulting episteme; then apply A.3.2 to that individual.
Recover what the source is actually about and what it asserts:
| Current claim | Subject pattern |
|---|---|
| context-local semantic way of doing a transformation or enactment | A.3.1 U.Method |
| transformation or enactment kind stated inside a current method claim | keep it as one method-identity field or claim content under A.3.1; it is not a peer U.Method |
| independently grounded actual bounded change | A.3.4 U.Transformation |
| possible, required, desired, intended, planned, predicted, modeled, or asserted change | keep it as claim content under the exact requirement, architecture, capability-gap, functional-view, method, work-plan, dynamics-model, publication, or other subject pattern; wording alone admits no U.Transformation |
already identified episteme whose exact EntityOfConcern is one admitted U.Method and whose claims include at least one substantive way-of-doing claim | A.3.2 U.MethodDescription |
| formal substrate, signature, postulates, laws, or mathematical declaration | A.6.0; use C.29 when mathematical-lens use is current |
| operation algebra, admissibility predicates, transport, audit, realization, or mechanism-governing-definition assignment | A.6.1 and E.20 |
| planned work | A.15.2 U.WorkPlan |
| dated performed work | A.15.1 U.Work |
| evidence relation or provenance relation for a claim | A.10 |
| wording quoted from source with no FPF-governed use | quote-only source wording |
Cooling contrast. A reusable cooling procedure can be U.Method only after the context-local way of doing, its transformation or enactment kind, transformed referent or structure, preconditions, and intended effects are recovered. “Required cooling effect” alone is claim content, not a method. If a later cooling episode actually changes the governed loop state, that occurrence remains a separate A.3.4 U.Transformation and needs its own changed referent, boundary, conditions, actual facts, and continuity or reidentification basis.
When the source label hides method, mechanism, formal-substrate, work, evidence, gate, result, or temporal claims, use E.10.ARCH:3.1 to state the project concern in ordinary words, then identify each exact object and claim separately. Use this pattern to repair only the representation overread and name the subject pattern for the current claim; linked values remain under their own subject patterns rather than becoming one representation-repair claim.