A.3.2:2 - 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.