| Gate‑as‑law | Preconditions written as “laws” in the signature | Breaks substitution; violates A.6.0’s separation of signature vs mechanism gates | Move predicates to Mechanism.AdmissibilityConditions; keep signature laws truth‑conditional. |
| RFC‑keywords in invariants | “MUST” appears inside Definition: blocks | Confuses deontics with mathematical admissibility; undermines auditability | Rewrite as declarative predicate; reference predicates by ID or canonical location from CC when needed. |
| Paraphrase drift | Same constraint restated across faces with changed meaning | Creates hidden divergence; breaks L/A/D/E claim-classification discipline and evidence accountability | Cite claim IDs or canonical locations and preserve their meaning in readable face prose. Use a Claim Register when stable reuse needs it. |
| Interface-as-promiser and Work-result bundle | “The interface promises delivery” assigns an individual commitment to the interface description, or “A.15.1 delivered the result” identifies Work with its result | A description is made an agent, while Work, result, transfer, evidence, and acceptance lose their own identity conditions | Name the actual bearer of the individual commitment; use A.6.C when ambiguity about promise, utterance, or governance changes interpretation or use. Use A.15.1 for dated Work; then exactly one applicable A.15.1:4.6 row for each separate result, delivery, evidence, or acceptance claim. |
| Carrier-as-effect guarantee | “Guaranteed latency” or “the log proves the change” with no exact actual occurrence and evidence relation | A description or carrier is treated as creating Work, change, or another effect; natural or formal change may also be forced into Work | Name the actual occurrence first: A.15.1 for grounded Work, A.3/A.3.4 or the exact interaction or causal-use pattern for non-Work change; then add the minimum A.10 path needed for reliance. |
| Face called a view by form | A face, diagram, query result, or publication form is called U.View without exact E.17.0 conformance | Appearance or construction history replaces the dependent-kind condition | Recover the exact candidate and viewpoint epistemes, test E.17.0 conformance, and keep optional A.6.3 construction and publication relations separate. |
| Unresolved deontic subject | “The system or service SHALL …” is used without deciding whether the sentence states behavior, a general prescription, or an obtaining individual commitment. | The phrase hides the actual subject, constitutive basis, and direct predicate; a system-role kind or assignment may be mistaken for the duty bearer or for responsibility. | Recover the exact admitted System or other party; state an actual E-* behavior claim separately only when its actual basis is supplied; then state either normative content or one direct A.2.8 commitment. Test responsibility independently. |
| One‑doc monoculture | Same document mixes unclassified laws, gates, duties, and evidence | Change impact is hard to isolate; updates can affect unrelated claim kinds | Use the stack: separate Signature, Mechanism, Norms, and Evidence sections; classify by matrix. |
| Authority-word overread | “Allowed”, “approved”, or a visible permit is treated as a complete authorization result | The word hides which claim exists and which source grounds it | Select one A6-AW-* row; if no row’s closure condition is met, keep only A6-AW-SOURCE or stop the unsupported use. |