A.6.M:11 - SoTA-Echoing
| Source or practice | Currentness or lineage use | Adopt | Adapt for FPF | Reject or boundary | Practitioner implication |
|---|---|---|---|---|---|
DoD OUSD(R&E) MOSA guidance and implementation guidebook (https://www.cto.mil/sea/mosa/; https://www.cto.mil/wp-content/uploads/2025/03/MOSA-Implementation-Guidebook-27Feb2025-Cleared.pdf) | Current official acquisition and engineering practice family for open modular systems; used as current practice guidance, not as a complete FPF ontology. | Modular design, interface standards, conformance verification, replacement policy, change policy, and competitive reuse are real conformance and substitution expectations. | Recover them as an independently identified InterfaceSpecification episteme plus an interfaceSpecificationRef that resolves it, PlatformGrammarRef, substitutabilityPolicyRef, changePolicyRef, conformance expectation, source relation, and evidence relation only where the recovered claim needs them. Non-module selection, procurement, policy, evidence, assurance, gate, decision, Work, system-role-assignment, responsibility, and mechanism claims keep their own direct patterns; a responsibility claim names its predicate or exact missing governor. | Do not treat open, interface publication, or modular-looking structure as substitutability, assurance, procurement suitability, supplier-set selection, policy authorization, quality proof, or decision authority. | A practitioner asking whether something is open first repairs the relation and interface specification; other claims remain with the patterns named in A.6.M:12. |
Conway’s law, the mirroring hypothesis, and Team Topologies and inverse Conway practice (https://www.melconway.com/Home/Committees_Paper.html; https://doi.org/10.1016/j.respol.2012.04.011; https://itrevolution.com/wp-content/uploads/2022/06/TTOP_excerpt.pdf) | Mature socio-technical law and empirical lineage plus current organization-design practice; used as diagnostic pressure, not as a proof rule. | Team communication structure, boundary placement, and delivery-responsibility relations can create real pressure on module and interface boundaries and useful correspondence clues. | Recover admitted Systems, exact system-role kinds and assignments, and Work through A.15 and A.2; use VP.AllocationResponsibility only as a viewpoint cue, then cite the direct responsibility predicate or exact missing governor. Connect that material to ModuleInterfaceStructure only through declared correspondence, allocation, boundary relation, and preserved and lost structure note. Use C.29 for a homomorphism-like claim. | Do not treat Conway’s law, an org chart, assignment, responsibility label, or delivery unit as proof of module interface, substitutability, modularity quality, evidence, gate passage, or architecture decision. | A practitioner may use team-boundary mismatch as a diagnostic prompt, then repair each exact relation before deciding what architecture change is warranted. |
Amdahl’s law and communication and synchronization extensions (https://www.cs.cmu.edu/~18742/papers/Amdahl1967.pdf; https://arxiv.org/abs/1306.3302; https://arxiv.org/abs/2603.20654) | Mature mathematical law plus current extension sources for communication, synchronization, and scalable-workload-fraction limits. | Serial work, synchronization, communication overhead, shared resources, and changing scalable workload fractions can limit the payoff of decomposition, parallelization, or specialization. | Use C.29 for mathematical speedup or value-scalable-fraction reasoning, E.18 for transformation-flow structure, C.30.TFS-REL when the module claim uses an architecture-to-transformation-flow relation, and C.31 and C.16 for modularity and characteristic tradeoffs. | Do not treat module count, team count, service count, transformation-flow path count, or accelerator count as improvement, scalability, throughput, or evolvability by itself. | A practitioner considering a module split names the serial part, shared bottleneck, synchronization or communication overhead, and characteristic tradeoff before claiming improvement. |
| SEI Views and Beyond, ISO/IEC/IEEE 42010:2022, and multi-view architecture practice | Mature architecture-description lineage plus current international view-description discipline; not used as a current module-quality source. | Module and component-and-connector views are distinct architecture descriptions. | Use ModuleInterfaceStructure and RuntimeInteractionStructure as structure-kind signals under C.30.ASV. | Do not reduce architecture to a module diagram. | Module repair stays one architecture-structure concern, not the whole architecture ontology. |
Platform and product-line engineering practice (https://tag-app-delivery.cncf.io/fr/whitepapers/platform-eng-maturity-model/; https://www.sei.cmu.edu/library/variability-in-software-product-lines/; https://arxiv.org/abs/2605.21353) | Mature product-line variability lineage plus current platform-engineering maturity-model and current SPLE-review cues; used for variability-slot and extension-rule discipline, not as one FPF platform kind. | Variation slots and extension rules matter for reuse and substitution. | Use PlatformGrammarRef, variabilitySlotRefs, and change policy instead of a platform root kind. | Do not treat platform name as architecture quality, architecture scale-preference evidence, procurement suitability, supplier-set selection, or decision authority. | The next module-repair action is to identify extension rules and substitution conditions; non-module quality, scale-preference, procurement, supplier-set, and decision claims are governed by the patterns named in A.6.M:12 when those claims are being made. |
| Architecture-operation language, with neural-network and software-system intakes as source examples | Current practitioner-language source examples accepted by the architecture workstream; used as recognition material, not as a standard or current-best-known authority. | C.30.STRAT source labels, including source examples such as block, layer, expert, router, cache, and state, are useful recognition prompts. | Keep them as source labels until the recovered FPF kind, relation, claim-use, or source-use disposition is known; use A.6.M only for module-interface relation, interface specification, platform grammar, substitutability, or open-architecture module-interface claims. | Do not import source-context labels as module kinds or evidence of adequacy. | The same repair works for neural-network block replacement, hardware module substitution, organizational module repair, and episteme-module repair without making any source context the ontology. |
Older or local sources may serve as lineage or worked examples only when the row says so. They do not stand in for current competitive source, and they do not make a module, interface, platform, or open-architecture claim admissible for comparison, assurance, gate, selection, or decision use without the subject pattern for that use.