RCAM — Resource Criticality Assessment 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 Criticality Assessment Governance
Module ID: RSGA-RDCS-RCAM-02
Origin ID: OOF-RSGA-RDCS-RCAM
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
RCAM — Resource Criticality Assessment Module governs how a mapped Resource Dependency is systematically assessed to determine the governance significance of that Dependency by evaluating Dependency strength, functional sensitivity, Resource thresholds, interruption tolerance, degradation tolerance, substitutability context, recovery conditions, consequence significance, temporal urgency, and other materially relevant Criticality factors without treating Resource Demand, Resource quantity, price, scarcity, or strategic importance as automatic substitutes for Resource Criticality.
Resource Dependency ≠ Resource Criticality.
2. Operational Role
RDMM establishes:
what depends upon what.
RCAM determines:
how significant that Dependency is.
It converts mapped Resource Dependency relationships into structured Resource Criticality assessments suitable for downstream governance.
3. Core Question
How critical is the mapped Resource Dependency under the relevant operating conditions, given the strength of reliance, Resource thresholds, tolerance, consequence, substitution possibilities, recovery conditions, and time sensitivity associated with Resource degradation or loss?
4. Position in RDCS Module Flow
RDMM — Resource Dependency Mapping Module → RCAM — Resource Criticality Assessment Module → RCEM → RDCM → RCDM
RDMM establishes the Dependency structure.
RCAM performs the first governed assessment of Criticality across that structure.
5. Governed Space
RCAM governs:
Resource Criticality Assessment Governance
6. Governed Object
The primary Governed Object is:
The Criticality of a mapped Resource Dependency.
Criticality attaches to a relationship rather than to a Resource name alone.
Canonical relationship:
**Resource
Dependent Object Function Operating Context Dependency Conditions → Resource Criticality**
7. Scope
RCAM governs:
Dependency strength assessment; functional sensitivity; Resource sufficiency thresholds; degradation thresholds; failure thresholds;
interruption tolerance; Resource quality tolerance; Resource rate tolerance; continuity requirements; substitutability context; substitution readiness; buffer context; redundancy context; recovery context; consequence significance; consequence timing; Criticality factors; Criticality assessment methodology; Criticality state; Criticality evidence; Criticality uncertainty; Criticality conflict; Criticality reassessment.
RCAM does not determine:
Resource Access; Resource Priority; Resource Allocation; Resource Consumption; Scarcity response; formal Resource Substitution governance; system-wide Resilience; long-term Sustainability.
8. Criticality Assessment Input
RCAM principally receives:
Resource Dependency Map
and:
Resource Dependency Relationship Profiles
from RDMM.
It may consume additional governed evidence relevant to Criticality.
9. Criticality Assessment Principle
Criticality should emerge from the governed Dependency reality.
It should not be assigned because a Resource is generally described as important.
10. Criticality Is Relational
Resource Criticality is relational and contextual.
A Resource may be Critical for one function and non-critical for another.
11. Criticality Object Integrity
A Criticality assessment should identify:
Resource; dependent object; function; operating state; relevant time horizon.
12. Resource Name Boundary
Resource Name ≠ Resource Criticality.
Calling electricity, water, compute, land, or a critical material “important” does not establish Criticality for a specific Dependency.
13. Dependency Strength
Dependency Strength describes how strongly the functional state of the dependent object relies upon the Resource.
14. Dependency Strength vs Demand
Dependency Strength must not be inferred directly from Resource Demand magnitude.
Demand Magnitude ≠ Dependency Strength.
15. Complete Dependency
Complete Dependency exists where the relevant function cannot continue beyond the governed tolerance boundary without the Resource.
16. Partial Dependency
Partial Dependency exists where the function can continue at reduced capability after Resource degradation.
17. Conditional Dependency Strength
Dependency Strength may change according to operating conditions.
18. Dependency Gradient
Dependency may exist along a continuum rather than as a binary state.
19. Functional Sensitivity
Functional Sensitivity describes how strongly functional performance responds to changes in Resource condition.
20. Low Functional Sensitivity
Substantial Resource degradation may produce little immediate functional effect.
21. High Functional Sensitivity
A small Resource degradation may produce substantial functional deterioration.
22. Sensitivity Curve
Where useful, RCAM may represent:
Resource State → Functional State
as a governed sensitivity relationship.
23. Linear Sensitivity
Functional degradation may approximately track Resource degradation.
24. Non-Linear Sensitivity
Small Resource changes may create disproportionately large functional effects.
25. Threshold Sensitivity
A function may operate normally until a threshold is crossed and then degrade rapidly.
26. Resource Sufficiency Threshold
The Resource Sufficiency Threshold represents the Resource condition required to sustain the relevant function at the governed level.
27. Degradation Threshold
The Degradation Threshold identifies the point at which Resource deterioration begins materially affecting the function.
28. Failure Threshold
The Failure Threshold identifies the Resource condition beyond which the function can no longer satisfy the governed requirement.
29. Threshold Sequence
Where relevant:
Normal Resource State → Reduced Resource State → Degradation Threshold → Critical Degradation → Failure Threshold → Functional Loss
30. Threshold Evidence
Thresholds should be evidenced where they materially affect Criticality.
31. Threshold Uncertainty
Uncertain thresholds should remain explicitly uncertain.
32. Binary Model Boundary
A Resource Dependency should not be represented as simply:
Available / Failed
where material intermediate states exist.
33. Quantity Tolerance
Quantity Tolerance represents the Resource quantity reduction a function can absorb before material consequence occurs.
34. Capacity Tolerance
A function may tolerate reduced Resource capacity while maintaining sufficient operation.
35. Rate Tolerance
A function may tolerate temporary reductions in Resource delivery rate.
36. Quality Tolerance
A function may tolerate Resource quality degradation within defined boundaries.
37. Performance Tolerance
A function may tolerate reduced Resource performance.
38. Continuity Tolerance
Some functions require continuous Resource supply.
Others tolerate interruption.
39. Interruption Tolerance
Interruption Tolerance establishes how long Resource supply may be interrupted before material consequence begins.
40. Time-to-Impact
RCAM should identify:
Time-to-Impact
where the interval between Resource loss and material functional consequence affects Criticality.
41. Immediate Impact
Material consequence may begin effectively immediately.
42. Delayed Impact
Buffers, inventory, thermal inertia, storage, redundancy, or operational flexibility may delay consequence.
43. Time-to-Failure
Where appropriate, RCAM may distinguish:
Time-to-Impact
from:
Time-to-Failure.
A function may begin degrading before complete failure.
44. Interruption Duration
Criticality may increase as interruption duration increases.
45. Duration-Dependent Criticality
A Resource Dependency may be:
Low Criticality at 30 seconds
but:
Critical at 6 hours.
46. Temporal Criticality Profile
Where material, RCAM should preserve Criticality across relevant time horizons rather than assigning one timeless label.
47. Buffer Context
A buffer may delay the effect of Resource interruption.
Examples:
battery storage; water storage; material inventory; thermal storage; compute queue flexibility.
48. Buffer Duration
Buffer capacity should be translated into relevant operational duration where possible.
49. Buffer Reliability
A theoretical buffer should not automatically be treated as an effective buffer.
50. Buffer Availability
The buffer must itself be available under the relevant conditions.
51. Buffer Dependency
A buffer may depend upon other Resources.
Example:
A battery may require:
control power; inverter functionality; cooling.
52. Buffer Boundary
Temporary Buffering ≠ Dependency Elimination.
53. Redundancy Context
Multiple Resource Sources or pathways may reduce immediate vulnerability.
54. Redundancy Effectiveness
RCAM should evaluate whether redundancy is:
independent; available; sufficient; activatable; appropriately located; capable of supporting the required function.
55. Apparent Redundancy
Two Resource paths may appear independent while sharing a common upstream Dependency.
56. Common-Mode Dependency
Common-mode relationships identified by RDMM should be considered in Criticality assessment.
57. Redundancy Boundary
Resource Redundancy ≠ Resource Independence.
58. Substitutability Context
A different Resource may potentially support the function.
59. Substitute Functional Adequacy
A substitute must be capable of supporting the relevant function.
60. Substitute Capacity
The substitute must have sufficient capacity for the required operating state.
61. Substitute Availability
A substitute that exists but is unavailable during the relevant interval may provide little Criticality reduction.
62. Substitute Activation Time
Criticality may depend upon how quickly the substitute can become operational.
63. Substitute Quality
Alternative Resource quality must satisfy the relevant functional requirements.
64. Substitute Infrastructure
A substitute may require infrastructure that is not currently available.
65. Partial Substitute
A substitute may support only part of the required function.
66. Conditional Substitute
A substitute may operate only under specific conditions.
67. Theoretical Substitute Boundary
Theoretical Substitute ≠ Operationally Available Substitute.
68. Source Substitution
Alternative Sources of the same Resource may reduce Source Dependency.
69. Resource Substitution
A different Resource may potentially perform the function.
These are distinct conditions.
70. Source Substitutability Boundary
Source Substitutability ≠ Resource Independence.
71. Formal Substitution Boundary
RCAM assesses substitutability as Criticality context.
RSFS governs formal Resource Substitution & Flexibility.
72. Consequence Significance
Criticality requires understanding what materially happens when the Resource Dependency cannot be satisfied.
73. Functional Consequence
Resource degradation may affect:
output; performance; quality; availability; service level; capability.
74. Operational Consequence
Functional degradation may affect broader operation.
75. Continuity Consequence
Resource interruption may threaten continued operation.
76. Safety-Relevant Consequence
A Resource Dependency may carry safety-relevant consequences.
HAGA™ retains Harm Governance.
RCAM consumes relevant consequence evidence without absorbing Harm governance.
77. Economic Consequence
Economic loss may inform consequence context.
It does not independently determine Criticality.
78. Societal Consequence
A Resource Dependency may support broader societal functions.
79. Consequence Scope
Consequence may remain:
local; functional; system-wide; cross-system; regional; societal
depending upon the governed context.
80. Consequence Timing
The timing of consequence affects Criticality.
81. Consequence Reversibility
Some consequences may be fully reversible after Resource restoration.
Others may not be.
82. Recoverable Consequence
A function may return to normal operation after Resource restoration.
83. Persistent Consequence
Effects may continue after Resource availability returns.
84. Recovery Context
Criticality assessment should consider how quickly the dependent function can recover.
85. Resource Restoration vs Recovery
Resource Restored ≠ Function Fully Recovered.
86. Recovery Time
Recovery may require:
restart; inspection; reconfiguration; recalibration; reheating; cooling; data recovery; material replacement; process stabilization.
87. Recovery Dependency
Recovery itself may depend upon additional Resources.
88. Recovery Capability
Available recovery capability may reduce prolonged consequence.
89. Recovery Uncertainty
Uncertain recovery time should remain visible in Criticality assessment.
90. Propagation Context
A Resource Dependency may affect downstream functions.
91. Dependency Chain Propagation
RDMM provides Dependency chains.
RCAM evaluates whether Resource failure across those chains materially increases Criticality.
92. Local vs Propagated Consequence
A Resource failure may remain local or propagate through multiple systems.
93. Propagation Timing
Propagation may be:
immediate; progressive; threshold-triggered; delayed.
94. Propagation Boundary
RIRS retains broader Resource Interdependency & Resilience governance.
RCAM uses propagation only insofar as it affects Criticality of the mapped Dependency.
95. Dependency Concentration
Many functions may depend upon one Resource or Resource pathway.
96. Concentration Significance
Dependency concentration may increase consequence if that Resource relationship fails.
97. Concentration Boundary
High concentration does not automatically establish Criticality.
Its actual consequence must be assessed.
98. Criticality Factors
A Resource Criticality Assessment may consider:
Dependency Strength; Functional Sensitivity; Resource Thresholds; Interruption Tolerance; Time-to-Impact; Time-to-Failure; Buffering; Redundancy; Substitutability; Substitution Time; Consequence Significance; Consequence Timing; Recovery Time; Propagation; Dependency Concentration.
99. Factor Relevance
Not every factor must be used for every Resource Dependency.
Only materially relevant factors should govern the assessment.
100. Criticality Assessment Structure
Canonical structure:
Mapped Dependency → Dependency Strength → Functional Sensitivity → Thresholds → Tolerance → Buffer / Redundancy → Substitutability → Consequence → Time Sensitivity → Recovery → Propagation → Criticality Assessment
101. Criticality Classification
RCAM should produce a governed Criticality State.
102. Minimum Criticality States
At minimum:
Low Criticality
Moderate Criticality
High Criticality
Critical
Criticality Evidence-Limited
Criticality Conflicted
Criticality Unknown
Criticality Unresolved
103. Low Criticality
Low Criticality indicates that Resource degradation or interruption produces limited governed consequence within the relevant conditions.
104. Moderate Criticality
Moderate Criticality indicates material consequence that remains manageable within available tolerance, alternatives, or recovery capability.
105. High Criticality
High Criticality indicates substantial consequence, limited tolerance, constrained alternatives, difficult recovery, or materially significant propagation.
106. Critical
Critical indicates that Resource degradation or interruption can create severe or unacceptable functional or operational consequence within the governed context and relevant time horizon.
107. Criticality Evidence-Limited
Available evidence is insufficient to support a stronger Criticality determination.
108. Criticality Conflicted
Credible evidence supports materially different Criticality assessments.
109. Criticality Unknown
Insufficient information exists to determine Criticality.
110. Criticality Unresolved
Relevant evidence exists but a sufficiently governed Criticality determination has not yet been established.
111. Criticality Classification Method
Criticality classification should use a documented method.
112. Qualitative Assessment
Criticality may be assessed qualitatively where evidence and context support categorical governance.
113. Quantitative Assessment
Quantitative methods may be used where meaningful measurements exist.
114. Hybrid Assessment
A combination of quantitative and qualitative evidence may be appropriate.
115. Universal Formula Boundary
RCAM does not impose one universal mathematical Criticality formula across all Resource types and operational contexts.
116. Resource-Specific Assessment
Specialized Resource domains may require different technical indicators while remaining compatible with the same RDCS governance logic.
117. Criticality Score
Implementations may produce a Criticality score where methodologically justified.
118. Score Traceability
A Criticality score should remain traceable to the factors and evidence that produced it.
119. Score Boundary
Criticality Score ≠ Criticality Evidence.
The score represents an assessment outcome.
It does not replace the underlying evidence.
120. False Precision
Criticality should not be expressed with precision unsupported by evidence.
121. Criticality Evidence
Each material Criticality determination should retain evidence supporting its relevant factors.
122. Evidence Sources
Evidence may include:
Resource Demand Profiles; Resource Dependency Maps; technical specifications; operational telemetry; functional testing; failure testing; historical interruption; incident evidence; recovery evidence; validated Simulation; engineering analysis.
123. Observed Evidence
Observed operational evidence should remain distinguishable from modeled evidence.
124. Simulation Evidence
Simulation may support Criticality assessment.
Simulated Consequence ≠ Observed Consequence.
SIMULOS® retains Simulation Governance.
125. Prediction Evidence
Predicted future Resource or consequence states may inform future Criticality.
Predicted Criticality ≠ Current Criticality.
PGA™ retains Prediction Governance.
126. Assumption
Where a Criticality factor depends upon assumption, the assumption should remain explicit.
127. Evidence Provenance
At minimum, relevant evidence should preserve:
Criticality Assessment ID; Dependency ID; Resource ID; Function; evidence source; evidence time; operating state; method; version.
128. Evidence Freshness
Criticality evidence may become outdated after material operational change.
129. Evidence Conflict
Conflicting evidence should not be silently averaged into a false certainty.
130. Criticality Uncertainty
Uncertainty may concern:
Dependency Strength; Threshold; Tolerance; Buffer effectiveness; Redundancy; Substitutability; Consequence; Recovery; Propagation.
131. Uncertainty Propagation
Material uncertainty in Criticality factors should propagate into the Criticality State.
132. Criticality Confidence
Where implementations use confidence measures, confidence should reflect evidence sufficiency rather than rhetorical certainty.
133. Evidence Sufficiency
The evidence requirement should be proportional to the significance of the Criticality determination.
134. Criticality Assessment Profile
The principal RCAM output is the:
Resource Criticality Assessment Profile
135. Minimum Profile Fields
At minimum:
Criticality Assessment ID
Dependency ID
Resource ID
Dependent Object
Function
Operating State
Time Horizon
Dependency Strength
Functional Sensitivity
Resource Sufficiency Threshold
Degradation Threshold
Failure Threshold where relevant
Interruption Tolerance
Time-to-Impact
Time-to-Failure where relevant
Buffer Context
Redundancy Context
Substitutability Context
Consequence State
Consequence Timing
Recovery Context
Propagation Context
Criticality State
Evidence Basis
Criticality Uncertainty
Sufficiency State
Version:
136. Multi-Horizon Criticality
Where Criticality changes materially over time, the profile should preserve multiple Criticality horizons.
Example:
0–5 minutes — Low
5–60 minutes — Moderate
1–4 hours — High
>4 hours — Critical
where evidence supports those boundaries.
137. Operating-State Criticality
Criticality may differ between:
normal operation; Peak operation; maintenance; standby; emergency; recovery.
138. Location-Specific Criticality
The same Resource Dependency may carry different Criticality at different locations because alternatives, buffers, infrastructure, or recovery conditions differ.
139. Current vs Future Criticality
Current and future Criticality should remain distinct.
140. Criticality Reassessment
Criticality should be reassessed after material change.
141. Reassessment Triggers
Triggers may include:
Dependency change; Demand change; Resource threshold change; buffer change; new redundancy; loss of redundancy; new substitute; loss of substitute; operating-state change; consequence evidence; incident; recovery change; new Simulation; system redesign.
142. Reassessment Logic
Canonical logic:
Existing Criticality Assessment → Material Change / New Evidence
→ Affected Criticality Factor Identification → Factor Reassessment → Criticality Retained or Revised → Version Update → Downstream RDCS Reassessment
143. Versioning
Material Criticality changes should create a new assessment version.
144. Historical Criticality
Historical Criticality should remain distinguishable from current Criticality.
145. Criticality Trend
Version: history may reveal increasing or decreasing Criticality.
The underlying factor changes should remain explainable.
146. Criticality vs Resource Demand
Resource Demand tells us what is required.
Resource Criticality tells us what the consequences of Dependency mean.
147. Criticality vs Resource Availability
A Resource may be highly Critical and currently available.
It may also be highly Critical and unavailable.
Criticality does not create Resource capacity.
148. Criticality vs Scarcity
Resource Scarcity ≠ Resource Criticality.
149. Criticality vs Price
Resource Price ≠ Resource Criticality.
150. Criticality vs Value
VEGA™ governs Value.
Value ≠ Resource Criticality.
151. Criticality vs Harm
HAGA™ governs Harm.
Harm evidence may inform Resource Criticality without making Harm and Criticality equivalent.
152. Criticality vs Liability
LIGA™ governs Liability.
Liability ≠ Resource Criticality.
153. Criticality vs Access
A highly Critical Dependency does not create Resource Access authorization.
154. Criticality vs Priority
Criticality may become important evidence for Priority.
It is not Priority itself.
Resource Criticality ≠ Resource Priority.
155. Criticality vs Allocation
Critical Resource ≠ Automatically Allocated Resource.
156. Criticality vs Resilience
Criticality concerns significance of a Resource Dependency.
RIRS later governs broader Resource Interdependency & Resilience.
157. Criticality vs Sustainability
A Critical Resource may still be consumed unsustainably.
Resource Criticality ≠ Resource Sustainability.
158. Assessment Independence
RCAM must not manipulate Criticality to produce a preferred downstream Allocation outcome.
159. Evidence Independence
Evidence should determine Criticality.
Desired Criticality should not determine accepted evidence.
160. Structured Output Principle
RCAM should support:
Evidence → Criticality Factors → Governed Factor States → Resource Criticality Assessment → Downstream Decision Evidence
rather than:
Resource Name → Assumed Importance → Criticality Label.
161. Minimum Implementation Framework
A minimum operational RCAM implementation should contain eight governed layers.
Layer 1 — Dependency Input
Receive:
Resource Dependency Map Resource Dependency Relationship Profile
Layer 2 — Dependency Strength
Assess:
Partial / Complete Functional Sensitivity Operating-State Dependency
Layer 3 — Threshold & Tolerance
Determine:
Sufficiency Threshold Degradation Threshold Failure Threshold Interruption Tolerance Time-to-Impact
Layer 4 — Buffer & Alternative Context
Assess:
Buffer Redundancy Substitutability Substitution Time
Layer 5 — Consequence
Determine:
Functional Consequence Operational Consequence Consequence Timing Propagation
Layer 6 — Recovery
Determine:
Recovery Time Recovery Capability Recovery Dependency
Layer 7 — Criticality Determination
Determine:
Criticality State Evidence Uncertainty Sufficiency
Layer 8 — Governed Output
Produce:
Resource Criticality Assessment Profile Version Reassessment triggers Downstream RDCS handoff state
Minimum machine-readable logic:
Dependency Profile → Dependency Strength → Functional Sensitivity → Threshold[] → Tolerance[] → Buffer → Redundancy → Substitute Context → Consequence[] → Recovery → Propagation → Evidence[] → Uncertainty[] → Criticality State → Resource Criticality Assessment Profile
162. Minimum Decision States
At minimum:
Low Criticality
Moderate Criticality
High Criticality
Critical
Criticality Evidence-Limited
Criticality Conflicted
Criticality Unknown
Criticality Unresolved
163. Minimum Evidence Path
Where Criticality cannot be sufficiently assessed:
Criticality Unresolved → Material Criticality Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Factor Reassessment → Criticality Reassessment → Updated Resource Criticality Assessment Profile
The objective is sufficient evidence for Criticality governance, not maximum possible data collection.
164. Minimum Reassessment Framework
At minimum:
Current Resource Criticality Assessment → New Evidence / Material Change → Criticality Factor Impact Test → Affected Factor Reassessment → Criticality Retained / Revised → Version Update → Downstream RDCS Reassessment
165. Governance Requirements
A conforming RCAM implementation must:
1. receive a sufficiently mapped Resource Dependency; 2. identify the Criticality object; 3. preserve Resource, dependent object, and function identity; 4. establish the relevant operating state; 5. establish the relevant time horizon; 6. assess Dependency Strength; 7. assess Functional Sensitivity; 8. identify relevant Resource thresholds; 9. identify interruption tolerance; 10. identify Time-to-Impact where material; 11. identify Time-to-Failure where material; 12. identify buffer context; 13. evaluate effective redundancy; 14. identify common-mode limitations where known; 15. assess substitutability context; 16. distinguish theoretical from operational substitution; 17. assess consequence significance; 18. assess consequence timing; 19. assess recovery context; 20. assess propagation where relevant; 21. determine a governed Criticality State; 22. preserve evidence provenance; 23. preserve assumptions; 24. distinguish observed from simulated evidence; 25. distinguish current from predicted Criticality; 26. preserve material uncertainty; 27. preserve evidence conflict; 28. support multi-horizon Criticality where necessary; 29. support operating-state-specific Criticality where necessary; 30. support reassessment; 31. support versioning; 32. produce a Resource Criticality Assessment Profile; 33. preserve the boundary between Criticality and Priority; 34. preserve the boundary between Criticality and Allocation.
166. Governance Logic
Canonical RCAM logic:
Mapped Resource Dependency → Criticality Object → Dependency Strength → Functional Sensitivity → Resource Thresholds → Interruption Tolerance → Time-to-Impact → Buffer / Redundancy → Substitutability → Consequence → Consequence Timing → Recovery → Propagation → Evidence → Uncertainty → Criticality State → Resource Criticality Assessment Profile
Where evidence is insufficient:
Criticality Unresolved → Material Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Reassessment
167. Governance Outputs
RCAM may produce:
Resource Criticality Assessment Profile
Criticality Assessment ID
Dependency Strength State
Functional Sensitivity State
Resource Threshold State
Degradation Threshold
Failure Threshold
Interruption Tolerance
Time-to-Impact
Time-to-Failure
Buffer State
Redundancy State
Substitutability State
Consequence State
Consequence Timing
Recovery State
Propagation State
Criticality State
Evidence State
Uncertainty State
Sufficiency State
Version:
Reassessment Trigger
168. Failure Conditions
RCAM should not be considered sufficiently completed where:
Resource Criticality is assigned from Resource name alone; Demand magnitude is treated as Criticality; Dependency existence is treated automatically as high Criticality; Resource quantity is treated as Dependency Strength; Resource thresholds are ignored where material; interruption tolerance is ignored; Time-to-Impact is ignored where material; buffers are treated as Dependency elimination; nominal redundancy is assumed to be effective redundancy; common-mode Dependency is ignored where known; theoretical substitution is treated as operational substitution; substitution time is ignored; consequence timing is ignored; Resource restoration is treated automatically as functional recovery; Criticality is inferred from Resource price; Scarcity is treated as Criticality; Value is treated as Criticality; predicted Criticality is represented as current Criticality; simulated consequence is represented as observed consequence; evidence conflict is suppressed; uncertainty is hidden; Criticality is manipulated to produce a preferred Priority; Criticality is treated as Allocation authority.
169. Use Case 1 — AI Data Center Electricity Criticality
RDMM maps several electricity dependencies in an AI data center:
AI Compute → Electricity
Cooling → Electricity
Storage → Electricity
Network Infrastructure → Electricity
Control Systems → Electricity
Their Criticality is not identical.
A portion of AI training workload may be interruptible.
Storage systems may have short battery protection.
Network infrastructure may have independent backup.
Cooling may continue briefly through thermal inertia but become increasingly critical as heat accumulates.
Control systems may require only a small amount of electricity but may need near-continuous supply.
RCAM therefore assesses each Dependency according to:
Dependency Strength; interruption tolerance; Time-to-Impact; backup duration; alternative supply; consequence; recovery time.
The result may show that the function with the smallest electricity Demand carries the highest immediate Criticality.
Electricity Demand magnitude does not determine electricity Criticality.
170. Use Case 2 — Regional Water Criticality
RDMM maps water dependencies across:
residential supply; industrial production; agriculture; cooling infrastructure; public services.
Agriculture may represent the largest water Demand by volume.
Some agricultural Demand may tolerate scheduling or temporary reduction.
An industrial process may tolerate reduced production for several hours.
Certain cooling functions may have much shorter interruption tolerance.
Essential public services may require comparatively little water but experience severe consequence after sustained interruption.
RCAM therefore evaluates:
water Dependency Strength; minimum functional water requirement; interruption tolerance; stored water; alternative Sources; substitution feasibility; consequence timing; recovery conditions.
The resulting Criticality states may differ substantially from the ranking produced by water volume alone.
The largest water user is not automatically the most water-critical dependency.
171. Critical Distinctions
Resource Dependency ≠ Resource Criticality
Demand Magnitude ≠ Dependency Strength
High Dependency ≠ High Criticality by definition
Resource Name ≠ Resource Criticality
Temporary Buffering ≠ Dependency Elimination
Resource Redundancy ≠ Resource Independence
Theoretical Substitute ≠ Operationally Available Substitute
Source Substitutability ≠ Resource Independence
Resource Restored ≠ Function Fully Recovered
Criticality Score ≠ Criticality Evidence
Simulated Consequence ≠ Observed Consequence
Predicted Criticality ≠ Current Criticality
Resource Scarcity ≠ Resource Criticality
Resource Price ≠ Resource Criticality
Value ≠ Resource Criticality
Resource Criticality ≠ Resource Priority
Critical Resource ≠ Automatically Allocated Resource
Resource Criticality ≠ Resource Sustainability
172. Cross-Architecture Boundary
RCAM governs Resource Criticality Assessment within RDCS.
It may consume:
RDMM Dependency Maps; RDGS Demand Profiles; RACS Availability & Capacity context; ORA™ operational evidence; SIMULOS® simulated consequence evidence; PGA™ predicted future conditions; HAGA™ Harm evidence where relevant; LIGA™ Liability evidence where relevant; VEGA™ Value context where relevant; specialized Resource-domain evidence.
It does not absorb those governance domains.
173. 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 Simulation may establish a possible interruption outcome.
A Harm analysis may establish harmful consequence.
A Value assessment may establish economic or operational Value.
A technical system may establish failure thresholds.
RCAM consumes these outputs only insofar as they establish Resource Criticality.
174. Canonical Boundary
RCAM governs the systematic assessment of the governance significance of a mapped Resource Dependency through Dependency Strength, Functional Sensitivity, Resource thresholds, tolerance, buffering, redundancy, substitutability, consequence, time sensitivity, recovery, propagation, evidence, and uncertainty.
It does not determine Resource Access, Resource Priority, Resource Allocation, Scarcity response, formal Resource Substitution, system-wide Resilience, or long-term Sustainability.
Its principal governed output is the Resource Criticality Assessment Profile .
175. Canonical Closing Statement
A Resource is not critical merely because it is heavily consumed, expensive, scarce, or generally important.
RCAM establishes Criticality from the dependency itself — how strongly the function relies upon the Resource, how quickly degradation matters, what alternatives exist, what consequences follow, and how recovery changes those consequences — before Criticality is allowed to influence downstream Resource governance.