External result use
This release has one framework-edition dependency. It uses the First Principles Framework Core Conceptual
Specification, September 2026, specifically the use-specific assurance and
currentness edition FPF@2026-09-07-EA03-ASSURANCE-CURRENTNESS. Use that edition’s named PatternIDs below;
its B.3.3 assurance criteria, B.3.4 evidence-applicability result and G.11 currentness result supply the
MDPE.16/20 receiving use in the second row. The public FPF repository supplies the discovery route; the
edition designation identifies the content relied on, not whichever revision is newest. FPF remains
external: this DPF does not copy it or make FPF depend on this domain framework.
| Relied-on FPF results | Receiving use in this edition | Why this is a dependency | Reopen condition |
|---|---|---|---|
A.1, A.2, A.2.1, A.3.1, A.3.2, A.15.1, and C.2.1 | Keep Systems, Agents, Methods, MethodDescriptions, Work, results, assignments, and epistemes distinct across all MDPE.* patterns. | Removing or materially changing these distinctions would invalidate pattern subjects, result forms, or worked cases. | Recheck only the affected MDPE claims when one of these relied-on FPF results changes for the same use. |
A.10, B.3.3, B.3.4, C.11, C.28, and G.11 | Qualify evidence and assurance for the receiving use, make bounded choices, separate observation from causal contribution, and reconsider affected currentness. | MDPE.16/20 may retain sufficient availability evidence or a qualified forecast without a new check; actual rights, calibration, configuration and promised-use conditions still apply. | Recheck only the receiving relation whose claim, use or relevant premise changes. Preserve the minimum limitation needed by a later recipient. |
A.22, C.30, C.32.MWA, C.32.MLAO, and C.36 | Describe several architectures, reduce conflicts among structures and holon positions, and separate cultural generation, enactment, recognition, selection, transmission, retention, and loss. | MDPE.13, .14, .17, .19, .20, .21, .22, and .24 use these distinctions to avoid collapsing unlike world-side relations. | Recheck only the receiving architecture or cultural-evolution result whose governing FPF distinction changes. |
E.23.CDI and E.24.PUB | Keep capability development and publication occurrence separate from performance, artifact, availability, recognition, and use in MDPE.5, .10, and .23. | Without these external results the corresponding capability or publication claim lacks support and must return to a direct Method. | Recheck when the relied-on capability-development or publication result changes for the receiving use. |
Systems Engineering, Human Capability Development, Method Engineering, Organization Engineering, Operations Management, and Rhythmics are external specialization boundaries, not assumed dependencies of this edition. A pattern may use a published result from one of those DPFs when the pattern names the receiving use and the result is available and current for it. Until then, use the named direct Systems Engineering, teaching, organization, operations, rhythm, Music, or Dance Method and the pattern’s direct sources. A sibling product name, shared Suite membership, or a planned pattern establishes no dependency, compatibility, authority, or availability.
If a Music-or-Dance case exposes a working move that remains useful after all Music-and-Dance distinctions are removed, return a bounded amendment proposal to FPF. The proposal must name the recurring situation, changed action, first useful result, what remains after subtracting the contribution of current FPF, evidence, and reopen condition. The domain observation does not become a Core result until the separate FPF decision accepts it, and FPF does not acquire a reverse dependency merely because the discovery began here.