RCEM — Resource Consequence Evaluation 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 Consequence Governance
Module ID: RSGA-RDCS-RCEM-03
Origin ID: OOF-RSGA-RDCS-RCEM
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
RCEM — Resource Consequence Evaluation Module governs how the consequences arising from degradation, insufficiency, interruption, delay, quality deterioration, restricted delivery, or loss of a Resource are identified, bounded, structured, temporally located, evidenced, evaluated, and related to the affected Resource Dependency so that Resource Criticality reflects what actually happens when the Resource can no longer support the dependent function under the governed conditions.
RCEM establishes the consequence layer of Resource Dependency & Criticality governance.
Resource Interruption ≠ Resource Consequence until the effect upon the dependent function or system is established.
2. Operational Role
RDMM establishes:
what depends upon what.
RCAM assesses:
how critical the Dependency is under relevant Resource conditions.
RCEM establishes:
what actually happens when those Resource conditions deteriorate.
It evaluates:
functional degradation; functional loss; operational disruption; continuity effects; consequence timing; consequence duration; consequence propagation; recoverability; persistent effects; and the evidence supporting those consequence relationships.
RCEM strengthens Resource Criticality by grounding it in explicit consequence pathways rather than assumed importance.
3. Core Question
What materially happens to the Resource-dependent function, system, process, service, infrastructure, participant, or other governed object when the relevant Resource becomes degraded, insufficient, interrupted,
delayed, restricted, or unavailable, when does that consequence occur, how far does it propagate, and what evidence supports that relationship?
4. Position in RDCS Module Flow
RDMM — Resource Dependency Mapping Module → RCAM — Resource Criticality Assessment Module → RCEM — Resource Consequence Evaluation Module → RDCM → RCDM
RCEM provides the explicit consequence evidence required for mature Resource Dependency and Criticality governance.
5. Governed Space
RCEM governs:
Resource Dependency Consequence Governance
This space concerns consequences created when a Resource Dependency can no longer be satisfied under its governed conditions.
6. Governed Object
The primary Governed Object is:
A Resource Dependency Consequence.
Canonical relationship:
Resource State Change → Dependency Impact → Functional Effect → Operational Consequence
where materially relevant:
→ Propagated Consequence
7. Scope
RCEM governs:
Resource degradation consequence; Resource insufficiency consequence; Resource interruption consequence; Resource delay consequence; Resource quality deterioration consequence; Resource rate restriction consequence; Resource loss consequence; functional degradation; functional failure; operational disruption; continuity consequence; consequence onset; consequence duration; consequence escalation; consequence propagation; consequence reversibility;
persistent consequence; recovery-related consequence; consequence evidence; consequence uncertainty; consequence conflict; consequence reassessment.
RCEM does not independently govern:
Harm as a complete governance lifecycle; Liability; Resource Access; Resource Priority; Resource Allocation; Resource Scarcity response; formal Resource Substitution; system-wide Resilience; long-term Sustainability.
8. Consequence Evaluation Input
RCEM principally receives:
Resource Dependency Maps; Resource Dependency Relationship Profiles; Resource Criticality Assessment Profiles.
It may also consume relevant:
operational evidence; failure evidence; incident evidence; technical analysis; Simulation outputs; Prediction outputs; recovery evidence; specialized domain evidence.
9. Consequence Principle
A Resource should not be considered consequential merely because its loss is theoretically possible.
RCEM establishes the relationship between Resource deterioration and actual or sufficiently evidenced functional consequence.
10. Resource State Change
A Resource consequence may originate from changes in:
quantity; capacity; rate; quality; availability; continuity; delivery timing; location; accessibility; other materially relevant Resource conditions.
11. Resource Degradation
Resource Degradation exists where the Resource remains present but no longer satisfies its previous condition.
12. Resource Insufficiency
Resource Insufficiency exists where Resource conditions fall below the level required by the relevant Dependency.
13. Resource Interruption
Resource Interruption exists where Resource delivery or availability ceases temporarily.
14. Resource Loss
Resource Loss exists where the Resource relationship becomes unavailable beyond the relevant governed interval or operational condition.
15. Resource Delay
A Resource may remain available but arrive too late to support the dependent function.
16. Resource Quality Deterioration
Resource quantity may remain sufficient while quality becomes inadequate.
17. Resource Rate Restriction
A Resource may remain available in total quantity while delivery rate becomes insufficient.
18. Consequence Trigger
A Consequence Trigger is the Resource condition that initiates material effect upon the dependent function.
19. Trigger Integrity
The Resource condition causing consequence should remain distinguishable from the consequence itself.
Resource Failure ≠ Functional Consequence.
20. Consequence Path
Canonical consequence path:
Resource Condition Change → Dependency Threshold Crossing → Functional Effect → Operational Consequence
where applicable:
→ Downstream Consequence
21. Functional Effect
The first material consequence may occur directly within the Resource-dependent function.
22. Functional Degradation
Functional Degradation occurs where the function continues but with reduced capability.
23. Functional Performance Loss
Resource degradation may reduce:
throughput; speed; precision; quality; availability; capacity; service level.
24. Partial Functional Loss
A function may remain partially operational.
25. Complete Functional Loss
A Resource condition may cause complete loss of the relevant function.
26. Functional State Transition
Where useful:
Normal Function → Degraded Function → Severely Degraded Function → Functional Failure
27. Threshold-Driven Consequence
Functional consequence may begin only after a Resource threshold identified by RCAM is crossed.
28. Progressive Consequence
Consequence may increase progressively as Resource conditions deteriorate.
29. Non-Linear Consequence
A small additional Resource degradation may cause a disproportionately large consequence after a critical threshold.
30. Binary Consequence Boundary
RCEM should not reduce consequence to:
No Consequence / Failure
where meaningful intermediate functional states exist.
31. Operational Consequence
Functional degradation may produce broader operational effects.
32. Output Consequence
Resource degradation may reduce operational output.
33. Quality Consequence
Resource degradation may reduce output or service quality.
34. Capacity Consequence
Available operational capacity may decline.
35. Performance Consequence
Operational performance may deteriorate.
36. Availability Consequence
A service or capability may become partially or fully unavailable.
37. Continuity Consequence
Resource deterioration may threaten continued operation.
38. Shutdown Consequence
Resource loss may require:
controlled shutdown; partial shutdown; emergency shutdown; automatic shutdown.
39. Restart Consequence
Restoring Resource may require a restart process before operation resumes.
40. Consequence Onset
RCEM should establish when material consequence begins after the relevant Resource condition changes.
41. Immediate Consequence
Some consequences occur effectively immediately.
42. Delayed Consequence
Some consequences occur only after:
buffers are depleted; storage is exhausted; temperature changes; inventory is consumed; backup capacity expires; operational tolerance is exceeded.
43. Time-to-Impact
Time-to-Impact represents the interval between the relevant Resource condition change and the beginning of material consequence.
44. Time-to-Failure
Time-to-Failure represents the interval before the relevant function reaches its governed failure condition.
45. Time-to-Impact vs Time-to-Failure
Time-to-Impact ≠ Time-to-Failure.
Functional degradation may begin long before complete failure.
46. Consequence Duration
RCEM should determine how long the consequence persists where material.
47. Temporary Consequence
A consequence may disappear after Resource restoration.
48. Persistent Consequence
A consequence may continue after the Resource itself has been restored.
49. Permanent Consequence Context
Some consequences may not be fully reversible through Resource restoration.
RCEM records this condition where relevant to Resource Dependency.
50. Consequence Escalation
A Resource consequence may become more severe as interruption or degradation continues.
51. Escalation Curve
Where useful:
Resource Interruption Duration → Consequence Severity
may be represented explicitly.
52. Duration-Dependent Consequence
The same Resource interruption may produce:
minor consequence at 5 minutes; material consequence at 1 hour; critical consequence at 6 hours.
53. Consequence Plateau
Some consequences may reach a maximum state beyond which additional interruption does not materially change the affected function.
54. Consequence Recovery
Resource restoration may begin recovery.
It does not guarantee immediate restoration of the dependent function.
55. Resource Restoration Boundary
Resource Restored ≠ Consequence Resolved.
56. Functional Recovery
Functional Recovery occurs when the affected function returns to the required governed state.
57. Recovery Delay
Recovery may lag Resource restoration.
58. Recovery Requirements
Recovery may require:
restart; inspection; reconfiguration; recalibration; reheating; cooling; cleaning; data recovery; material replacement; process stabilization.
59. Recovery Resource Dependency
Recovery itself may require additional Resources.
60. Recovery Consequence
The burden or delay associated with recovery may materially increase the significance of Resource interruption.
61. Recovery Time
RCEM should preserve recovery time where it materially affects consequence.
62. Recovery Uncertainty
Uncertain recovery conditions should remain explicit.
63. Reversible Consequence
A Reversible Consequence can be restored within the governed recovery conditions without persistent material effect.
64. Partially Reversible Consequence
Some effects may be recoverable while others persist.
65. Irreversible Consequence Context
Some effects may remain after Resource restoration and recovery efforts.
66. Consequence Propagation
A Resource consequence may propagate beyond the directly dependent function.
67. Direct Consequence
Direct Consequence occurs in the object directly affected by the Resource Dependency.
68. Indirect Consequence
Indirect Consequence occurs through another affected function, system, process, or infrastructure component.
69. Propagated Consequence
Canonical structure:
Resource Loss → Function A Degradation → System B Disruption → Function C Consequence
70. Consequence Chain
A Consequence Chain represents linked consequence relationships.
71. Consequence Chain Integrity
Each material link should remain identifiable where it affects Resource Criticality.
72. Propagation Depth
Consequence may propagate through one or multiple operational layers.
73. Propagation Breadth
One Resource consequence may affect multiple dependent functions simultaneously.
74. Shared Resource Consequence
Where several functions depend upon the same Resource, one Resource disruption may create multiple consequences.
75. Common Dependency Consequence
Common Dependency identified by RDMM may create correlated consequences across apparently separate systems.
76. Consequence Concentration
A single Resource relationship may therefore concentrate operational consequence.
77. Local Consequence
A consequence may remain confined to one function or location.
78. System Consequence
A local Resource disruption may become system-wide.
79. Cross-System Consequence
A Resource Dependency may affect multiple systems.
80. Spatial Consequence
Consequence may differ by location.
81. Temporal Consequence
Consequence may differ by time or operating state.
82. Operating-State Consequence
The same Resource loss may produce different consequences during:
normal operation; Peak operation; maintenance; startup; shutdown; emergency; recovery.
83. Contextual Consequence
Consequence must therefore be attached to the relevant Resource Dependency context.
84. Consequence Magnitude
Where measurable, consequence magnitude may be represented quantitatively.
85. Consequence Severity
Where appropriate, consequence may be classified using governed severity states.
86. Severity Boundary
Severity should not be assigned merely from Resource identity.
87. Minimum Consequence States
A minimum implementation may distinguish:
Limited Consequence
Moderate Consequence
Major Consequence
Severe Consequence
Consequence Evidence-Limited
Consequence Conflicted
Consequence Unknown
Consequence Unresolved
88. Limited Consequence
The affected function experiences limited material degradation within the governed context.
89. Moderate Consequence
Material operational degradation occurs but remains manageable within relevant tolerance and recovery conditions.
90. Major Consequence
Substantial functional or operational degradation occurs.
91. Severe Consequence
Resource degradation or interruption creates severe functional or operational loss within the governed context.
92. Consequence Evidence-Limited
Evidence is insufficient for a stronger consequence determination.
93. Consequence Conflicted
Credible evidence supports materially different consequence states.
94. Consequence Unknown
Available evidence does not establish the relevant consequence.
95. Consequence Unresolved
Evidence exists but does not yet support a sufficiently governed consequence determination.
96. Consequence Type vs Consequence Severity
Consequence Type ≠ Consequence Severity.
A functional consequence may be minor or severe.
A continuity consequence may also vary substantially in severity.
97. Consequence Magnitude vs Criticality
Consequence severity is an important Criticality input.
It is not necessarily identical to Resource Criticality.
98. Consequence vs Dependency Strength
A strong Dependency may produce limited consequence where the affected function has low operational significance.
A partial Dependency may produce substantial consequence under certain conditions.
99. Consequence vs Demand
High Resource Demand ≠ Severe Resource Consequence.
100. Consequence vs Scarcity
Resource Scarcity ≠ Resource Consequence.
Scarcity describes Resource constraint.
Consequence describes what that constraint does to the dependent object.
101. Consequence vs Priority
Severe consequence may inform downstream Priority.
RCEM does not determine Priority.
102. Consequence vs Allocation
RCEM does not allocate Resource.
103. Consequence vs Harm
Resource consequence and Harm must remain distinct.
A Resource interruption may cause:
functional degradation
without necessarily producing:
Harm
within HAGA™.
104. Harm Boundary
Where Resource consequence produces or may produce Harm:
RCEM governs the Resource Dependency consequence relationship.
HAGA™ governs Harm.
105. Consequence vs Liability
Resource consequence may create circumstances relevant to Liability.
LIGA™ retains Liability Governance.
106. Consequence vs Value Loss
Resource consequence may reduce Value.
VEGA™ retains Value Governance.
107. Consequence vs Resilience
RCEM may identify propagation relevant to Resilience.
RIRS retains broader Resource Interdependency & Resilience Governance.
108. Consequence Evidence
Material consequence determinations should remain traceable to evidence.
109. Operational Evidence
Evidence may include:
telemetry; performance logs; operational records; service records; production records.
110. Failure Evidence
Observed Resource interruptions may reveal consequence relationships.
111. Incident Evidence
Historical incidents may establish:
Time-to-Impact; degradation progression; failure conditions; recovery duration; propagation.
112. Technical Evidence
Engineering models and technical specifications may establish consequence thresholds.
113. Experimental Evidence
Controlled testing may establish Resource-to-function consequence relationships.
114. Simulation Evidence
Simulation may establish possible consequence states where direct testing is impractical.
115. Simulation Boundary
Simulated Consequence ≠ Observed Consequence.
SIMULOS® retains Simulation Governance.
116. Prediction Evidence
Predicted future conditions may inform future consequence evaluation.
117. Prediction Boundary
Predicted Consequence ≠ Current Consequence.
PGA™ retains Prediction Governance.
118. Assumed Consequence
Where consequence is assumed rather than established, that status must remain explicit.
119. Consequence Evidence Provenance
At minimum, evidence should preserve where relevant:
Consequence ID; Dependency ID; Resource ID; affected function; evidence source; evidence time; operating state; method; version.
120. Evidence Freshness
Consequence evidence may become outdated following material system change.
121. Consequence Evidence Conflict
Technical models, historical evidence, and operational observation may produce different consequence assessments.
The conflict should remain visible until governed resolution.
122. Consequence Uncertainty
Uncertainty may concern:
trigger condition; threshold; Time-to-Impact; severity; duration; propagation; recovery; persistence.
123. Uncertainty Preservation
Uncertainty should not be removed merely because downstream Criticality requires a decision.
124. Consequence Confidence
Where confidence is represented, it should reflect evidence sufficiency.
125. False Precision
RCEM should not assign precise consequence values where evidence supports only ranges or categorical states.
126. Consequence Range
Where appropriate, consequence may be represented as:
minimum; expected; maximum; bounded range
provided the methodology supporting the range is explicit.
127. Scenario-Specific Consequence
Different Resource degradation scenarios may produce different consequence states.
128. Scenario Integrity
Scenario-specific consequences should not be silently merged into one universal consequence.
129. Current Consequence vs Potential Consequence
Current Consequence ≠ Potential Consequence.
130. Observed Consequence vs Modeled Consequence
Observed Consequence ≠ Modeled Consequence.
131. Resource Consequence Profile
The principal RCEM output is the:
Resource Consequence Profile
132. Minimum Resource Consequence Profile Fields
At minimum:
Consequence ID
Dependency ID
Criticality Assessment Reference
Resource ID
Affected Object
Affected Function
Resource Condition Trigger
Resource Threshold
Consequence Type
Functional Effect
Consequence State
Time-to-Impact
Time-to-Failure where relevant
Consequence Duration
Escalation State
Propagation State
Recovery State
Recovery Time where relevant
Persistence State
Evidence Basis
Consequence Uncertainty
Sufficiency State
Version:
133. Extended Consequence Fields
Where relevant:
location; operating state; affected downstream functions; consequence chain; buffer state; substitute state; scenario reference; Simulation reference; Prediction reference; reassessment trigger.
134. Consequence Graph
Complex systems may represent Resource consequences as a directed graph.
135. Consequence Graph Nodes
Nodes may represent:
Resource states; functions; systems; services; infrastructure; consequence states.
136. Consequence Graph Edges
Edges represent sufficiently evidenced consequence relationships.
137. Graph Direction
Consequence direction should remain explicit.
138. Graph Evidence
Material graph edges should remain traceable to evidence.
139. Consequence Cascade
A Resource condition may initiate a cascade.
Canonical representation:
Resource State Change → Dependency Impact → Functional Consequence → Operational Consequence → Propagated Consequence
140. Cascade Boundary
RCEM maps consequence propagation only as far as required to establish Resource Dependency significance.
It does not absorb complete governance of every downstream domain.
141. Consequence Aggregation
Multiple consequences should not be blindly summed.
142. Consequence Overlap
Two consequence pathways may describe the same downstream effect.
Duplication should be identified.
143. Shared Consequence
Several Dependency paths may converge on one consequence.
144. Consequence Deduplication
Shared downstream consequences should not be counted repeatedly where doing so would create false severity.
145. Cross-Domain Consequence
Resource loss may generate consequences relevant to:
operations; Harm; Liability; Value; continuity; other governance domains.
RCEM preserves the Resource consequence relationship while leaving domain-specific governance to the competent architecture.
146. Consequence Reassessment
Resource consequences should be reassessed after material change.
147. Reassessment Triggers
Triggers may include:
Resource threshold change; Dependency change; function change; buffer change; new redundancy; new substitute; loss of substitute; new incident evidence; new failure test; recovery change; system redesign;
new Simulation; new operational evidence.
148. Reassessment Logic
Canonical logic:
Existing Resource Consequence Profile → New Evidence / Material Change → Consequence Impact Test → Trigger / Timing / Severity / Propagation / Recovery Reassessment → Consequence Retained or Revised → Version Update → Criticality Reassessment
149. Consequence Versioning
Material consequence changes should create a new governed version.
150. Historical Consequence
Historical consequence states should remain distinguishable from current consequence states.
151. Consequence Learning
Historical incidents may improve future consequence governance without automatically defining future consequence.
152. Historical Boundary
Historical Consequence ≠ Guaranteed Future Consequence.
153. Structured Output Principle
RCEM should support:
Resource Evidence → Resource State Change → Dependency Impact → Functional Consequence → Operational Consequence → Propagation → Recovery → Governed Consequence State
rather than:
Resource Interruption → Assumed Catastrophe.
154. Minimum Implementation Framework
A minimum operational RCEM implementation should contain eight governed layers.
Layer 1 — Dependency & Criticality Input
Receive:
Resource Dependency Relationship Profile Resource Criticality Assessment Profile
Layer 2 — Resource Condition
Identify:
Degradation Insufficiency Interruption Delay Quality Deterioration Rate Restriction Loss
Layer 3 — Consequence Trigger
Determine:
Resource Threshold Trigger Condition Operating State
Layer 4 — Functional Effect
Determine:
Functional Degradation Partial Functional Loss Complete Functional Loss
Layer 5 — Temporal Consequence
Determine:
Time-to-Impact Time-to-Failure Duration Escalation
Layer 6 — Propagation & Recovery
Determine:
Propagation Consequence Chain Recovery Condition Recovery Time Persistence
Layer 7 — Evidence & Sufficiency
Assess:
Evidence Conflict Uncertainty Sufficiency
Layer 8 — Governed Output
Produce:
Resource Consequence Profile Version Reassessment triggers Criticality reassessment input
Minimum machine-readable logic:
Dependency Profile → Resource Condition Trigger → Threshold → Functional Effect → Consequence Type → Consequence State → Time-to-Impact → Duration → Propagation[] → Recovery → Evidence[] → Conflict[] → Uncertainty[] → Resource Consequence Profile
155. Minimum Decision States
At minimum:
Limited Consequence
Moderate Consequence
Major Consequence
Severe Consequence
Consequence Evidence-Limited
Consequence Conflicted
Consequence Unknown
Consequence Unresolved
156. Minimum Evidence Path
Where consequence cannot be sufficiently established:
Consequence Unresolved → Material Consequence Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition / Testing / Simulation where appropriate → Consequence Reassessment → Updated Resource Consequence Profile
The objective is sufficient consequence evidence for Resource Dependency and Criticality governance.
157. Minimum Reassessment Framework
At minimum:
Current Resource Consequence Profile → New Evidence / Material Change → Consequence Impact Test → Trigger / Functional / Temporal / Propagation / Recovery Reassessment → Consequence Retained / Revised → Version Update → Criticality Reassessment
158. Governance Requirements
A conforming RCEM implementation must:
1. receive a mapped Resource Dependency; 2. identify the relevant Resource condition change; 3. identify the consequence trigger; 4. preserve the Resource threshold where relevant; 5. identify the affected function; 6. distinguish Resource condition from functional consequence; 7. identify functional degradation where present; 8. identify partial or complete functional loss where relevant; 9. identify operational consequence; 10. establish Time-to-Impact where material; 11. distinguish Time-to-Impact from Time-to-Failure; 12. identify consequence duration where material; 13. identify escalation where material; 14. identify consequence propagation where material; 15. preserve direct and indirect consequence relationships; 16. identify recovery conditions; 17. distinguish Resource restoration from functional recovery; 18. identify persistent consequence where material; 19. preserve operating-state context; 20. preserve location context where material; 21. preserve evidence provenance; 22. distinguish observed from simulated consequence; 23. distinguish current from predicted consequence; 24. preserve assumptions; 25. preserve material uncertainty; 26. preserve evidence conflict; 27. prevent false precision; 28. prevent consequence double counting; 29. support reassessment; 30. support versioning; 31. produce a Resource Consequence Profile; 32. preserve the boundary between Resource consequence and Harm; 33. preserve the boundary between consequence and Priority; 34. preserve the boundary between consequence and Allocation.
159. Governance Logic
Canonical RCEM logic:
Mapped Resource Dependency → Resource Condition Change → Dependency Threshold → Consequence Trigger → Functional Effect → Operational Consequence → Consequence Timing → Escalation → Propagation → Recovery → Persistence
→ Evidence → Conflict → Uncertainty → Consequence State → Resource Consequence Profile
Where consequence is unresolved:
Candidate Consequence → Material Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition / Testing / Simulation → Consequence Reassessment
160. Governance Outputs
RCEM may produce:
Resource Consequence Profile
Consequence ID
Resource Condition Trigger
Threshold State
Functional Effect
Functional Degradation State
Functional Loss State
Operational Consequence State
Time-to-Impact
Time-to-Failure
Consequence Duration
Escalation State
Propagation State
Consequence Chain
Recovery State
Recovery Time
Persistence State
Evidence State
Conflict State
Uncertainty State
Sufficiency State
Version:
Reassessment Trigger
161. Failure Conditions
RCEM should not be considered sufficiently completed where:
Resource interruption is automatically treated as consequence without identifying functional effect; Resource condition and functional consequence are conflated; Resource quantity alone is used to infer consequence severity; functional degradation is ignored until complete failure; Time-to-Impact is ignored where material; Time-to-Failure is confused with Time-to-Impact; consequence duration is ignored where material; escalation is ignored; propagated consequences are ignored where material; shared consequences are double counted; Resource restoration is treated automatically as consequence resolution; recovery delay is ignored; persistent consequences are ignored; simulated consequence is represented as observed consequence; predicted consequence is represented as current consequence; historical consequence is treated as guaranteed future consequence; uncertainty is hidden; evidence conflict is suppressed; Resource consequence is automatically treated as Harm; consequence severity is automatically treated as Resource Priority; consequence is treated as Allocation authority.
162. Use Case 1 — AI Data Center Electricity Interruption
RDMM identifies electricity dependencies across:
AI compute; cooling; storage; network infrastructure; control systems.
RCAM establishes different Criticality states and interruption tolerances.
RCEM then evaluates what actually happens during electricity degradation or interruption.
For example:
Grid interruption → battery systems activate → selected infrastructure remains operational
while:
non-essential AI training workload is suspended.
Cooling may continue briefly through:
backup electricity; thermal inertia; reduced compute load.
If interruption continues:
cooling capability declines → equipment temperature rises → compute capacity is reduced → additional workloads are suspended → service capability may eventually degrade.
Resource restoration may not produce immediate full operation because systems may require:
restart; thermal stabilization; integrity checks; workload rescheduling.
RCEM preserves:
which consequence occurs; when it begins; how it escalates; what functions it reaches; and how long recovery requires.
The result is a governed consequence pathway rather than a generic statement that “electricity is critical.”
163. Use Case 2 — Regional Water Interruption
A regional water system supplies:
households; industry; agriculture; cooling infrastructure; public services.
RDMM maps the dependencies.
RCAM establishes their differing Criticality and tolerance conditions.
RCEM evaluates consequences under declining water availability.
A short reduction may produce:
limited operational effects
because:
storage exists; some Demand is deferrable; some processes can reduce throughput.
A longer interruption may cause:
industrial production reduction; cooling restrictions; service degradation; depletion of stored water; loss of selected operational functions.
Consequences may occur at different times across different users.
Restoration of water supply may also require:
network stabilization; quality verification; process restart; system flushing
before every function returns to normal.
RCEM therefore distinguishes:
Resource interruption
from:
the sequence of consequences created by that interruption.
164. Critical Distinctions
Resource Interruption ≠ Resource Consequence until the effect upon the dependent function or system is established
Resource Failure ≠ Functional Consequence
Time-to-Impact ≠ Time-to-Failure
Resource Restored ≠ Consequence Resolved
Consequence Type ≠ Consequence Severity
High Resource Demand ≠ Severe Resource Consequence
Resource Scarcity ≠ Resource Consequence
Current Consequence ≠ Potential Consequence
Observed Consequence ≠ Modeled Consequence
Simulated Consequence ≠ Observed Consequence
Predicted Consequence ≠ Current Consequence
Historical Consequence ≠ Guaranteed Future Consequence
Resource Consequence ≠ Harm
Resource Consequence ≠ Liability
Resource Consequence ≠ Resource Priority
Resource Consequence ≠ Resource Allocation Authority
165. Cross-Architecture Boundary
RCEM governs consequences specifically insofar as they arise from Resource Dependency and are required to establish Resource Criticality.
It may consume or provide evidence to:
RCAM for Resource Criticality; ORA™ for Operational Reality evidence; SIMULOS® for simulated consequence pathways; PGA™ for predicted consequence states; HAGA™ for Harm governance where Resource consequences create Harm; LIGA™ for Liability governance where Resource consequences create Liability relevance; VEGA™ where Resource consequences affect governed Value; RIRS for broader Resource Interdependency & Resilience governance.
RCEM does not absorb these domains.
166. 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 Resource interruption may create functional degradation.
That degradation may later create Harm.
It may create economic Value loss.
It may create Liability relevance.
It may expose Resilience weakness.
RCEM governs the Resource Dependency consequence.
The competent architecture governs each subsequent domain-specific meaning.
167. Canonical Boundary
RCEM governs how changes in Resource condition become evidenced functional and operational consequences within a Resource Dependency, including consequence trigger, functional degradation, timing, duration, escalation, propagation, recovery, persistence, evidence, uncertainty, and reassessment.
It does not determine Harm, Liability, 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 Consequence Profile .
168. Canonical Closing Statement
A Resource interruption becomes governance-significant not because the Resource disappeared, but because something that depended upon it changed as a result.
RCEM makes that change explicit — what fails or degrades, when the consequence begins, how it develops, where it propagates, and what remains after the Resource returns — so that Resource Criticality is grounded in consequence rather than assumed importance.