A.3.2:9 - Consequences

Benefit	Cost or caution
Method descriptions become reusable across notations.	Users must separate method identity from description form.
Audits can distinguish description, plan, work, evidence, and authority.	The first repair is to identify the claim-bearing episteme, its Method, and one substantive method claim; replacing vocabulary is not enough.
Software, lab, industrial, organizational, and proof-centered descriptions can be compared under one FPF kind.	Some files contain several current claims and must be split into several subject-pattern statements.
Equivalent descriptions can be declared without forcing identical notation.	Equivalence and refinement need local criteria.
Declarative representations can be used without being turned into ordered work-control claims.	An order inferred solely from form or layout needs `C.2.P.DR`; a supported order needs its subject assertion with its defining or constraining ClaimGraph.

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.