A.6.P | A.6.M is an RPR specialization for module-interface claim and interface-specification language; its record forms do not create a direct relation occurrence. |
A.6.RSIR | Bare interface-like wording is recovered before A.6.M is applied; A.6.M governs only recovered module-interface claim content, interface specification, platform grammar, substitutability policy, change policy, or open-architecture slice. |
A.6.RCD and A.6.REL | A needed reusable direct module relation requires its subject pattern and A.6.RCD for participants, obtaining, applicability, recurrence, and identity. A.6.REL applies only after the direct relation is admitted and a later use must distinguish obtaining occurrences. |
C.2.1, A.2.6, and A.22 | Govern the ModuleInterfaceClaim episteme, the separate InterfaceSpecification episteme, effective reference scheme, ClaimScope, and any independently selected dependency or model-use structure. None creates a module relation. |
C.30.STRAT | Recovers stratification and architecture-operation source labels before A.6.M governs only recovered module-interface relation cases. |
E.16 | Governs autonomy-budget, autonomous operation, independent acting, unsupervised decision or action, and freedom-of-action claims when those description or view uses are being made; A.6.M keeps only the module-interface relation, boundary, interface specification, and substitution or change-policy slice. |
A.14 | Component and part-whole wording uses A.14 first unless a module-interface relation is being claimed. |
A.6.0 and A.6.5 | Signatures, slots, ports, endpoints, and field structure remain governed by signature and slot discipline. |
A.6.B, A.6.C, and A.6.P:4.11a | Boundary, interface-specification, API, protocol, service, promise, and duty wording uses A.6.M only when the claim is module-interface relation, interface specification, substitutability, change policy, platform grammar, or open-architecture module-interface claim. |
C.30 and C.30.ASV | Architecture claims and module-interface structural views stay architecture-governed. |
C.33, C.34, and C.35 | Use these only when a module carrier, interface carrier, view, source label, generated map, or discovered structure needs architecture-specific captured-structure adequacy, lost-structure adequacy, preservation adequacy, or generated-carrier admission support. Use A.6.M for module-interface relation, interface specification, substitutability, change-policy, and platform-grammar claims. |
A.6.F | Function and functional wording stays distinct from module allocation. |
A.15 and A.2 | Method, WorkPlan, performed Work, exact system-role-kind and assignment claims, team-boundary wording, and delivery-unit wording keep their own defining or constraining patterns. Responsibility claims use an admitted direct domain predicate or the exact A.6.RCD missing-governor result; VP.AllocationResponsibility is only a recognition cue. Use A.6.M only for a recovered module-interface relation or correspondence. |
E.18 and C.30.TFS-REL | E.18 transformation-flow relations, path slices, crossings, and flow valuations are not interface specifications. |
C.31 | Modularity and reusable-structure characteristics are governed by C.31 after relation repair when characteristic or measurement use is being made. |
C.31.RSA | Reusable-structure accounting is governed by C.31.RSA when reusable loci, bespoke residue, or report-only share claims are being made. |
C.16 | Measurement, score, scale, unit, comparability, and evidence-stub admissibility remain C.16-governed. |
A.10, B.3, A.20, A.21, C.28, E.20, G.5, C.11 | Evidence, assurance, gates, causal use, mechanism suites, set-return selection, and local decisions use their subject patterns; they are not A.6.M claims. |