RDMM — Resource Dependency Mapping Module
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Parent Standard: Resource Dependency & Criticality Standard (RDCS)
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Core Module
Governed Space: Resource Dependency Mapping Governance
Module ID: RSGA-RDCS-RDMM-01
Origin ID: OOF-RSGA-RDCS-RDMM
Version: 1.0
Status: Draft Module
Effective Date: 5 October 2026
Compatibility: Methodology OS — Modular Compatibility
GIE-Compatible: Yes
AI-Readable: Yes
Authority: OOF® — OriginOpen® Foundation
Protection: Protected Methodological Work
Canonical Language: English
1. Canonical Definition
RDMM — Resource Dependency Mapping Module governs how relationships between governed Resource Demand, Resource-dependent functions, systems, processes, services, infrastructure, participants, and the Resources upon which they rely are identified, bounded, structured, evidenced, classified, and represented as explicit Resource Dependency relationships before Dependency strength, consequence, and Resource Criticality are determined.
RDMM establishes the governed Resource Dependency structure.
Resource Requirement ≠ Established Resource Dependency Relationship until the dependent object, Resource, function, and dependency pathway are sufficiently identified.
2. Operational Role
RDGS establishes what Resource is required.
RDMM begins the Dependency stage by determining:
what depends upon the Resource; which Resource it depends upon; for which function; whether the Dependency is direct or indirect; which operational pathway creates the Dependency; whether supporting or hidden dependencies exist; whether dependencies form chains; and whether multiple functions or Resources are connected through a broader Dependency structure.
RDMM maps the Dependency reality before downstream modules evaluate its Criticality significance.
3. Core Question
Which function, system, process, service, infrastructure, participant, or other governed object depends upon which Resource, for what operational purpose, through which Dependency pathway, and with what evidence?
4. Position in RDCS Module Flow
RDMM — Resource Dependency Mapping Module → RCAM → RCEM → RDCM → RCDM
RDMM establishes the Dependency structure upon which the remaining RDCS modules operate.
5. Governed Space
RDMM governs:
Resource Dependency Mapping Governance
This space concerns identification and representation of Resource Dependency relationships and pathways.
6. Governed Object
The primary Governed Object is:
A Resource Dependency Relationship.
A Resource Dependency Relationship connects:
a Dependency Source
to:
a Resource
through:
a defined function, requirement, or operational pathway.
7. Scope
RDMM governs:
Dependency Source identification; Resource identification; functional Dependency identification; Dependency boundary; Dependency direction; direct Dependency; indirect Dependency; supporting Dependency; hidden Dependency; conditional Dependency; standby Dependency; emergency Dependency; recovery Dependency; Dependency chains; Dependency pathways; multi-Resource Dependency; multi-function Dependency; shared Resource Dependency; Resource Source relationships where relevant; Dependency evidence; Dependency provenance; Dependency uncertainty; Dependency conflict; Dependency mapping sufficiency; Dependency reassessment; Dependency versioning.
RDMM does not independently determine:
Dependency Criticality; final consequence severity; Resource Priority; Resource Access; Resource Allocation; Scarcity response; Resource Consumption; Resilience; long-term Sustainability.
8. Dependency Mapping Input
RDMM principally receives:
Resource Demand Profiles
from RDGS.
It may also consume relevant Resource characterization, capacity, operational, technical, and system evidence.
9. Dependency Mapping Principle
A Resource Demand indicates that Resource is required.
RDMM determines the operational relationship creating that requirement.
10. Dependency Source
The Dependency Source is the governed object whose state, function, capability, output, or continuity depends upon the Resource.
It may be:
a function; a process; a system; a service; an infrastructure component; a facility; a participant; an operational capability; another governed object.
11. Dependency Resource
The Dependency Resource is the Resource upon which the Dependency Source relies.
12. Dependency Function
Every material Dependency should, where possible, identify the function for which the Resource is required.
13. Dependency Relationship
Canonical representation:
Dependency Source → Function → Requires Resource
14. Resource-to-Function Relationship
A Resource should not be mapped to an object merely because the Resource exists within the same system.
There must be a materially relevant Resource relationship.
15. Dependency Boundary
The Dependency Boundary determines exactly what relationship is being governed.
It should identify:
dependent object; Resource; function;
operational context; relevant system boundary.
16. Boundary Integrity
The Dependency boundary must follow the governed operational reality, not the preferred organizational or analytical structure.
17. Dependency Identity
Each materially distinct Resource Dependency should have an identifiable Dependency identity.
18. Dependency ID
A Dependency ID should remain stable enough to support:
evidence linkage; versioning; reassessment; Criticality analysis; downstream traceability.
19. Dependency Direction
Resource Dependency is directional.
Canonical direction:
Dependent Object → Resource
The Resource does not become dependent upon the object merely because the object depends upon it.
20. Direction Integrity
Resource Dependency A → B ≠ Resource Dependency B → A.
Where both directions exist, they should be represented as distinct relationships.
21. Direct Dependency
Direct Dependency exists where the governed object directly requires the Resource to perform the relevant function.
Example:
Compute system → Electricity
22. Direct Dependency Evidence
Direct Dependency may be evidenced through:
technical architecture; Resource Demand; operational telemetry; engineering specification;
process requirement; observed operation.
23. Indirect Dependency
Indirect Dependency exists where the governed object depends upon another function, system, infrastructure, or process that itself depends upon the Resource.
24. Indirect Dependency Example
AI workload → Cooling system → Electricity
The AI workload therefore carries an indirect Dependency upon electricity through cooling.
25. Direct vs Indirect Dependency
Direct Dependency ≠ Indirect Dependency.
Both may exist simultaneously.
26. Supporting Dependency
A Supporting Dependency enables a supporting function required for the primary function.
27. Supporting Resource
A supporting Resource may not appear in the primary functional output while remaining necessary for operation.
28. Hidden Dependency
A Hidden Dependency is a materially relevant Resource relationship not immediately visible in the primary Demand or functional representation.
29. Hidden Dependency Sources
Hidden dependencies may arise through:
cooling; control systems; networking; lubrication; specialized materials; water treatment; backup systems; storage; transport; support infrastructure.
30. Hidden Dependency Principle
A Resource not visible in the primary output may still be necessary for the primary function.
31. Conditional Dependency
A Resource Dependency may exist only when defined conditions are present.
32. Conditional Dependency Context
Conditions may include:
operating mode; season; temperature; load level; emergency state; production configuration; Resource Source failure.
33. Standby Dependency
A Resource may be required only when a standby function is activated.
34. Emergency Dependency
A Resource may become necessary only during emergency operation.
35. Recovery Dependency
A Resource may be required to restore operation after disruption.
36. Startup Dependency
Some Resources may be required during startup but not during steady-state operation.
37. Shutdown Dependency
Some Resources may be required for controlled shutdown.
38. Persistent Dependency
Persistent Dependency exists throughout the relevant operating state.
39. Temporary Dependency
Temporary Dependency exists only during a defined interval or operational state.
40. Dependency State Context
Dependency mapping should preserve the conditions under which each relationship becomes active.
41. Functional Dependency Mapping
RDMM maps Resources to the functions they support.
42. One Function — One Resource
A function may depend upon one primary Resource.
43. One Function — Multiple Resources
A function may depend simultaneously upon multiple Resources.
Example:
AI inference → Compute → Electricity → Cooling → Network capacity
44. Multiple Functions — One Resource
One Resource may support many functions.
Example:
Electricity → Compute → Cooling → Networking → Control systems
45. Many-to-Many Dependency
Complex systems commonly contain many-to-many Resource Dependency structures.
46. Multi-Resource Dependency
Where several Resources are jointly required, each Resource relationship should remain independently identifiable.
47. Joint Resource Requirement
A function may fail if any one of several required Resources becomes unavailable.
48. Joint Requirement Boundary
Joint Resource Requirement ≠ Resource Equivalence.
Electricity, water, compute, materials, and network capacity remain distinct Resources.
49. Dependency Bundle
RDMM may represent multiple Resource dependencies associated with one function as a Dependency Bundle.
50. Dependency Bundle Integrity
A Dependency Bundle preserves relationships.
It does not physically aggregate different Resources.
51. Dependency Chain
Dependencies may form chains.
Example:
Digital Service → Compute → Cooling → Electricity
52. Dependency Chain Node
Each function, system, Resource, or infrastructure component within a Dependency chain may form a distinct node.
53. Dependency Chain Link
Each materially relevant relationship between nodes should remain identifiable.
54. Chain Direction
Dependency chains should preserve causal or operational direction.
55. Dependency Path
A Dependency Path represents the route through which a Resource condition can affect the governed object.
56. Multiple Dependency Paths
A function may depend upon the same Resource through multiple paths.
Example:
Electricity may support:
compute directly
and:
cooling indirectly.
57. Parallel Dependency Paths
Parallel paths should remain separately visible where they affect later Criticality analysis.
58. Alternative Dependency Paths
A function may have alternative operational paths requiring different Resources.
59. Path Activation
Alternative Dependency paths may activate under different operating conditions.
60. Path Availability Boundary
RDMM identifies the path.
It does not determine Resource Availability.
RACS retains Availability & Capacity governance.
61. Dependency Graph
Complex Resource systems may be represented through a Dependency Graph.
Nodes may represent:
Resources; functions; systems; services; infrastructure; facilities.
Edges represent:
Resource Dependency Relationships.
62. Dependency Graph Directionality
Dependency graph edges should preserve direction.
63. Dependency Graph Evidence
Material graph relationships should remain traceable to evidence.
64. Graph Complexity Boundary
The purpose of the Dependency Graph is governance clarity.
It should not map every possible system relationship where those relationships are immaterial to Resource governance.
65. Relevant Dependency Principle
Map every materially relevant Resource Dependency, not every possible technical relationship.
66. Resource Source Dependency
A function may depend upon a particular Resource Source.
67. Resource vs Source Dependency
Dependency upon a Resource Source should remain distinguishable from Dependency upon the Resource itself.
68. Source Dependency Example
A facility may depend operationally upon:
Grid Connection A
while functionally depending upon:
Electricity.
The Source relationship and Resource relationship are not identical.
69. Source Substitution Context
Alternative Sources may affect later Criticality analysis.
RDMM maps them where relevant.
70. Infrastructure Dependency
Resource delivery may depend upon infrastructure.
Examples:
electricity transmission; water pipeline; network link; material transport; cooling infrastructure.
71. Delivery Dependency
A function may depend upon both:
the Resource
and:
the mechanism that delivers the Resource.
These relationships should remain distinguishable.
72. Resource Dependency vs Infrastructure Dependency
Resource Dependency ≠ Infrastructure Dependency.
Infrastructure may be the pathway through which Resource Dependency is realized.
73. Shared Resource Dependency
Multiple functions may depend upon the same Resource.
74. Shared Dependency Node
A common Resource may form a shared node across several Dependency paths.
75. Dependency Concentration
Where many functions depend upon the same Resource or Resource pathway, RDMM should make that concentration visible.
76. Concentration Boundary
RDMM identifies Dependency concentration.
Later RDCS mechanisms determine its Criticality significance.
77. Common Dependency
Multiple apparently independent functions may share a hidden common Resource Dependency.
78. Common Dependency Example
Two separate digital services may use separate compute clusters while both rely upon:
the same electricity substation
or:
the same cooling-water Source.
79. Common-Mode Context
Common Dependency relationships should remain visible for later Criticality and Resilience analysis.
80. Dependency Layering
A Resource system may contain:
primary dependencies; supporting dependencies; infrastructure dependencies; Source dependencies; recovery dependencies.
81. Dependency Layer Integrity
Different Dependency layers should not be collapsed where they carry different governance meaning.
82. Resource Demand Relationship
Every RDMM mapping should, where relevant, retain linkage to the originating Resource Demand Profile.
83. Demand-to-Dependency Traceability
Canonical trace:
Resource Demand Profile → Demand Function → Dependency Source → Resource Dependency Relationship
84. Demand Does Not Prove Full Dependency
The existence of Demand establishes Resource requirement.
It does not by itself establish Dependency strength or Criticality.
85. Demand Quantity Boundary
RDMM may preserve Demand quantity as context.
It does not infer Dependency significance from quantity alone.
86. High Demand Boundary
High Resource Demand ≠ Strong Resource Dependency by definition.
87. Low Demand Boundary
Low Resource Demand ≠ Weak Resource Dependency by definition.
88. Dependency Evidence
Every material Dependency relationship should have an identifiable evidence basis.
89. Technical Evidence
Technical evidence may include:
system architecture; engineering diagrams; technical specifications; process requirements; Resource interfaces.
90. Operational Evidence
Operational evidence may include:
telemetry; logs; observed operation; Resource measurements; operating procedures.
91. Functional Evidence
Functional evidence may include:
FDIM outputs; process definitions; service requirements; functional tests.
92. Historical Evidence
Historical incidents may reveal dependencies not visible during normal operation.
93. Failure Evidence
Observed failures may demonstrate Dependency pathways.
94. Simulation Evidence
Simulation may identify possible Dependency relationships.
Simulated Dependency ≠ Observed Dependency.
SIMULOS® retains Simulation Governance.
95. Predicted Dependency
Future system configurations may create predicted Dependency relationships.
Predicted Dependency ≠ Current Dependency.
PGA™ retains Prediction Governance.
96. Assumed Dependency
An assumed Dependency should remain explicitly classified until sufficiently evidenced.
97. Dependency Evidence Provenance
At minimum, evidence should preserve where relevant:
Dependency ID; Resource ID; Dependency Source; Function; evidence source; evidence time; operating state;
method; version.
98. Dependency Evidence Freshness
Dependency evidence may become outdated after system change.
99. Dependency Conflict
Dependency Conflict exists where credible evidence supports materially different Dependency mappings.
100. Conflict Example
Technical documentation may indicate:
Function A → Resource X
while operational evidence indicates:
Function A → Resource X + Resource Y.
The discrepancy should remain visible until resolved.
101. Dependency Conflict Resolution
Canonical logic:
**Dependency Evidence A
Dependency Evidence B → Object Identity Check → Resource Identity Check → Function Check → Boundary Check → Operating-State Check → Evidence Quality Check → Resolution or Preserved Conflict**
102. Dependency Uncertainty
Uncertainty may concern:
whether Dependency exists; Dependency direction; Resource identity; function; pathway; operating condition; Source relationship; hidden Dependency.
103. Uncertainty Preservation
RDMM should not transform uncertain Dependency into certain Dependency merely to complete the map.
104. Dependency Unknown
Where the relationship cannot be established, the state should remain Unknown.
105. Dependency Unresolved
Where evidence exists but cannot yet support a sufficient determination, the state should remain Unresolved.
106. Dependency Evidence-Limited
Evidence-Limited Dependency indicates that a relationship may exist but available evidence is insufficient for reliable governance.
107. Dependency Mapping Sufficiency
A Dependency Map is sufficient when materially relevant Resource relationships are adequately represented for downstream Dependency and Criticality analysis.
108. Completeness Boundary
Sufficiency does not require mapping every technical component.
It requires mapping every materially relevant Resource Dependency within the governed boundary.
109. Dependency Mapping Decision States
At minimum:
Dependency Mapped
Conditionally Mapped
Partially Mapped
Dependency Evidence-Limited
Dependency Conflicted
Dependency Unknown
Dependency Unresolved
110. Resource Dependency Map
The principal RDMM output is the:
Resource Dependency Map
111. Dependency Map Structure
The Resource Dependency Map should represent:
Dependency Sources; Resources;
Functions; Dependency relationships; Dependency direction; Dependency paths; Dependency types; operating conditions; evidence; uncertainty.
112. Resource Dependency Relationship Profile
Each material Dependency relationship may also produce a structured:
Resource Dependency Relationship Profile
113. Minimum Relationship Profile Fields
At minimum:
Dependency ID
Resource ID
Resource Demand Profile Reference
Dependency Source ID
Dependency Source Type
Function ID / Function
Dependency Type
Dependency Direction
Dependency Boundary
Dependency Path
Operating Condition
Resource Source where relevant
Evidence Basis
Evidence Time
Dependency Uncertainty
Mapping State
Version:
114. Dependency Type Field
The Dependency Type may include:
Direct
Indirect
Supporting
Conditional
Standby
Emergency
Recovery
Startup
Shutdown
Persistent
Temporary
where relevant.
115. Multiple Type Assignment
A Dependency may legitimately carry more than one type.
Example:
Indirect + Conditional + Emergency
where each describes a distinct characteristic.
116. Dependency Map Version
Material changes to Dependency structure should create a new map version.
117. Dependency Addition
A newly discovered Resource relationship should be added without rewriting unrelated dependencies.
118. Dependency Removal
A Dependency should be removed from the active map where evidence establishes that the relationship no longer exists.
Historical versions should remain traceable.
119. Dependency Modification
Changes to:
function; Resource; pathway; operating condition; Source
may require Dependency revision.
120. System Reconfiguration
System reconfiguration should trigger Dependency mapping reassessment where Resource relationships may change.
121. Resource Substitution Change
Introduction of an alternative Resource may alter Dependency pathways.
Formal substitution governance remains with RSFS.
122. Infrastructure Change
Changes in delivery infrastructure may create, remove, or reroute Dependency paths.
123. Functional Change
Changes to the governed function may create new Resource dependencies or eliminate existing ones.
124. Demand Change
A material RDGS Demand change should trigger RDMM reassessment where the Resource Dependency structure may be affected.
125. Operating-State Change
Dependencies may differ between:
normal operation; Peak operation; standby; maintenance; emergency; recovery.
126. State-Specific Dependency Map
Where necessary, RDMM may maintain different Dependency relationships for different operating states.
127. Dynamic Dependency Mapping
Resource Dependency structure is not necessarily static.
128. Dependency Reassessment Trigger
Reassessment should occur following material:
Demand change; function change; Resource change; system reconfiguration; infrastructure change; Source change; operating-state change; new evidence; incident; discovered hidden Dependency.
129. Reassessment Logic
Canonical logic:
Existing Resource Dependency Map → New Evidence / Material Change → Dependency Impact Test → Affected Relationship Identification → Relationship Retained / Revised / Added / Removed → Evidence Update → Version Update → Downstream RDCS Reassessment
130. Dependency Mapping vs Criticality
RDMM establishes Dependency structure.
It does not determine how critical the mapped Dependency is.
131. Mapping Before Criticality
A Resource Dependency should be sufficiently identified before its Criticality is evaluated.
132. Dependency Mapping vs Priority
RDMM does not determine Resource Priority.
133. Dependency Mapping vs Access
RDMM does not establish Resource Access authorization.
134. Dependency Mapping vs Allocation
RDMM does not allocate Resource.
135. Dependency Mapping vs Scarcity
RDMM does not establish Resource Scarcity.
136. Dependency Mapping vs Resilience
RDMM may identify Dependency structures relevant to Resilience.
RIRS retains Resource Interdependency & Resilience Governance.
137. Dependency Mapping vs Sustainability
The existence of a mapped Resource Dependency does not establish whether satisfying it is sustainable.
138. Dependency Mapping Integrity Principle
A Resource Dependency must connect a defined dependent object to a defined Resource through a materially relevant operational relationship.
139. Direction Integrity Principle
Dependency direction must remain explicit wherever reversing the relationship would change governance meaning.
140. Hidden Dependency Principle
Resource governance must not assume that the most visible Resource requirement represents the complete Dependency structure.
141. Path Integrity Principle
Material Resource Dependency pathways must remain traceable through intermediate functions, systems, infrastructure, and Resources where those pathways affect downstream governance.
142. Evidence Integrity Principle
Dependency relationships should follow evidence rather than the preferred Criticality, Priority, or Allocation outcome.
143. Minimum Implementation Framework
A minimum operational RDMM implementation should contain seven governed layers.
Layer 1 — Demand Input
Receive:
Resource Demand Profile
Layer 2 — Dependency Source Identification
Identify:
Dependent object Function System / process context
Layer 3 — Resource Relationship Identification
Identify:
Resource Resource Source where relevant Direct / indirect relationship
Layer 4 — Dependency Path Mapping
Map:
Supporting dependencies Hidden dependencies Infrastructure dependencies Dependency chains Alternative paths
Layer 5 — Evidence & Integrity
Assess:
Evidence provenance Direction Boundary Duplication Conflict
Layer 6 — Uncertainty & Sufficiency
Determine:
Mapping uncertainty Mapping state Sufficiency
Layer 7 — Governed Output
Produce:
Resource Dependency Map Resource Dependency Relationship Profiles Version Reassessment triggers Downstream RDCS handoff state
Minimum machine-readable logic:
Resource Demand Profile → Dependency Source[] → Function[] → Resource[] → Dependency Relationship[] → Dependency Path[] → Dependency Type[] → Evidence[] → Conflict[] → Uncertainty[] → Mapping State → Resource Dependency Map
144. Minimum Decision States
At minimum:
Dependency Mapped
Conditionally Mapped
Partially Mapped
Dependency Evidence-Limited
Dependency Conflicted
Dependency Unknown
Dependency Unresolved
145. Minimum Evidence Path
Where a material Dependency cannot be sufficiently mapped:
Dependency Unresolved → Material Relationship Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Dependency Mapping Reassessment → Updated Resource Dependency Map
The objective is sufficient evidence of the Resource relationship, not arbitrary map completeness.
146. Minimum Reassessment Framework
At minimum:
Current Resource Dependency Map → New Evidence / Material Change → Dependency Impact Test → Affected Relationship Identification → Mapping Update → Version Update → Downstream RDCS Reassessment
147. Governance Requirements
A conforming RDMM implementation must:
1. receive governed Resource Demand; 2. identify the Dependency Source; 3. identify the relevant Resource; 4. identify the relevant function; 5. establish the Dependency boundary; 6. preserve Dependency direction; 7. distinguish Resource from Resource Source; 8. identify direct Dependency; 9. identify material indirect Dependency; 10. identify supporting Dependency; 11. identify hidden Dependency where materially relevant; 12. identify conditional Dependency; 13. identify standby, emergency, or recovery Dependency where relevant; 14. identify multi-Resource Dependency; 15. preserve joint Resource requirements without false Resource equivalence; 16. identify material Dependency chains; 17. identify material Dependency paths; 18. identify shared Resource dependencies; 19. identify common Dependency relationships; 20. preserve operating-state context; 21. preserve Demand-to-Dependency traceability; 22. preserve evidence provenance; 23. distinguish observed from simulated Dependency; 24. distinguish current from predicted Dependency; 25. preserve material uncertainty; 26. preserve evidence conflict; 27. determine mapping sufficiency; 28. support reassessment; 29. support versioning;
30. produce a Resource Dependency Map; 31. produce structured Dependency Relationship Profiles where required; 32. preserve downstream governance boundaries.
148. Governance Logic
Canonical RDMM logic:
Resource Demand Profile → Dependency Source Identification → Function Identification → Resource Identification → Dependency Boundary → Direct Dependency Mapping → Indirect / Supporting Dependency Mapping → Hidden Dependency Discovery → Dependency Path Construction → Shared / Common Dependency Identification → Operating-State Context → Evidence → Conflict → Uncertainty → Mapping Sufficiency → Resource Dependency Map
Where mapping is unresolved:
Candidate Dependency → Material Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Mapping Reassessment
Where Dependency structure changes:
Existing Resource Dependency Map → Material Change → Dependency Impact Test → Relationship Added / Revised / Removed → Version Update → Downstream RDCS Reassessment
149. Governance Outputs
RDMM may produce:
Resource Dependency Map
Resource Dependency Relationship Profile
Dependency ID
Dependency Source
Dependency Resource
Dependency Function
Dependency Boundary
Dependency Direction
Dependency Type
Dependency Path
Dependency Chain
Supporting Dependency State
Hidden Dependency State
Conditional Dependency State
Shared Dependency State
Common Dependency State
Resource Source Relationship
Operating-State Context
Evidence State
Conflict State
Uncertainty State
Mapping Sufficiency State
Version:
Reassessment Trigger
150. Downstream Release Condition
RDMM output may proceed deeper into RDCS where materially relevant Dependency relationships are sufficiently mapped or where remaining uncertainty is explicitly preserved.
Progression does not erase Dependency uncertainty.
151. Failure Conditions
RDMM should not be considered sufficiently completed where:
Resource Demand is treated automatically as a complete Dependency Map; the dependent object is unidentified; the relevant function is unidentified where material; Resource identity is ambiguous; Resource and Resource Source are conflated; Dependency direction is lost; indirect Dependency is ignored; supporting Resource dependencies are ignored; hidden dependencies are systematically excluded; multi-Resource dependencies are collapsed into one Resource; Dependency chains are truncated where intermediate relationships materially affect governance; shared dependencies are represented as independent relationships without context; common dependencies remain hidden; operating-state dependencies are treated as permanent dependencies; simulated Dependency is represented as observed Dependency; predicted Dependency is represented as current Dependency; uncertainty is hidden; evidence conflict is suppressed; mapping is manipulated to produce a preferred Criticality result; Dependency mapping is treated as Priority or Allocation governance.
152. Use Case 1 — AI Data Center Resource Dependency Mapping
RDGS establishes Resource Demand for an AI data center.
The primary visible Resource relationships may include:
AI Compute → Compute Capacity
AI Compute → Electricity
RDMM expands the operational Dependency Map.
For example:
AI Workload → Compute Infrastructure → Electricity
AI Workload → Compute Infrastructure → Cooling → Electricity
AI Workload → Compute Infrastructure → Cooling → Water
AI Workload → Storage Infrastructure → Electricity
AI Workload → Network Infrastructure → Electricity
The same facility may also contain:
backup electricity; stored water; alternative network paths.
RDMM maps these relationships without yet deciding which Dependency is most critical.
The result may reveal that a Resource appearing secondary in the primary Demand profile is embedded in several operational Dependency paths.
The Resource Dependency Map exposes what the workload actually relies upon, not merely what appears in its most visible Resource Demand.
153. Use Case 2 — Regional Water Resource Dependency Mapping
A regional water system serves:
households; industrial production; agriculture; cooling; public infrastructure.
RDGS establishes their water Demand.
RDMM maps the underlying Dependency relationships.
For example:
Residential Service → Treated Water
Treated Water → Water Treatment Infrastructure → Electricity
Industrial Process → Process Water
Agricultural Production → Irrigation Water
Cooling System → Cooling Water
Emergency Public Service → Potable Water
The mapping may reveal that the regional water system itself depends upon additional Resources:
electricity for pumping; chemicals for treatment; network infrastructure; storage capacity.
RDMM preserves these relationships without collapsing them into one Resource or assigning Criticality prematurely.
Water Dependency governance begins not with ranking users, but with understanding the Resource relationships that allow each function to exist.
154. Critical Distinctions
Resource Requirement ≠ Established Resource Dependency Relationship
Resource Dependency A → B ≠ Resource Dependency B → A
Direct Dependency ≠ Indirect Dependency
Joint Resource Requirement ≠ Resource Equivalence
Resource Dependency ≠ Infrastructure Dependency
High Resource Demand ≠ Strong Resource Dependency by definition
Low Resource Demand ≠ Weak Resource Dependency by definition
Simulated Dependency ≠ Observed Dependency
Predicted Dependency ≠ Current Dependency
Dependency Mapping ≠ Resource Criticality
Dependency Mapping ≠ Resource Priority
Dependency Mapping ≠ Resource Allocation
155. Cross-Architecture Boundary
RDMM governs Resource Dependency Mapping within RDCS.
It may consume inputs from:
RCHS for Resource identity and characterization; RACS for Resource Availability & Capacity context; RDGS for governed Resource Demand and functional Demand; ORA™ for operational relationships and evidence; SIMULOS® for simulated Dependency pathways; PGA™ for predicted future Dependency relationships; specialized Resource architectures for Resource-specific technical relationships.
It does not absorb their governed mechanisms.
156. Cross-Architecture Mechanism Principle
An operational mechanism may produce inputs for multiple governance architectures, but it belongs only to the architecture whose governed domain includes that mechanism itself. Other architectures govern only its domain- specific relevance or consequences.
A cooling system may create a Resource Dependency.
A network architecture may create a Resource Dependency.
A production process may create a Resource Dependency.
A Simulation may reveal a possible Dependency pathway.
RDMM maps the Resource Dependency relevance of those mechanisms.
It does not absorb the mechanisms themselves.
157. Canonical Boundary
RDMM governs how Resource-dependent objects, functions, Resources, Resource Sources, supporting systems, infrastructure, and operational pathways are identified and connected into explicit, evidenced Resource Dependency relationships and Dependency Maps.
It does not determine final Dependency strength, consequence severity, Resource Criticality, Resource Access, Resource Priority, Resource Allocation, Scarcity response, Resilience, or Sustainability.
Its principal governed outputs are the Resource Dependency Map and associated Resource Dependency Relationship Profiles .
158. Canonical Closing Statement
A Resource system cannot govern Criticality correctly if it does not first know what depends upon what.
RDMM makes Resource Dependency explicit — connecting functions, systems, infrastructure, and Resources through traceable operational relationships so that hidden, indirect, shared, and conditional dependencies are visible before their significance is judged.