A.15:8 - Common Anti-Patterns and How to Avoid Them

• System-role-kind as part. Do not place InspectorSystemRole, a capability, fit condition, or evidence or assurance record in structural decomposition merely because it appears on an architecture diagram.
• Universal assignment signature. Do not give U.SystemRoleAssignment one permissive root signature. Recover the direct species and its exact local assigned-kind domain.
• Generic assignment beside an appointment. Let the specialized appointment occurrence itself belong to U.SystemRoleAssignment; F.6 uses its common holder projection.
• Recipe as evidence. A MethodDescription can identify or constrain a Method but does not prove performed Work.
• Plan as performed Work. A schedule or intended-assignment claim remains distinct from dated Work, which is identified independently under A.15.1; use A.15.2 for WorkPlan membership.
• Capability as Work. Ability, a capability statement, or a passing fit condition is not performance.
• Assignment as responsibility or authority. Recover the direct neighboring relation required by the claim, for example responsibility, commitment, permission, authority, access, or gate passage, or return its exact missing governor.
• Approval collapse. Keep approval or authorization Work and the operational Work it permits as separate occurrences and effect relations.
• Process soup. Resolve ambiguous source wording before relying on it; do not create a generic process object.
• Appearance as execution. Use A.15.4 when a dashboard, credential, copied approval, generated explanation, provenance label, or command-like cue is being relied on by appearance.
• P2W publication as Work. A principle scheme, functional diagram, scenario, screen, or explanation can guide planning without becoming Method, WorkPlan, Work, result, evidence, gate, or justification.