Resource Dependency & Criticality Standard (RDCS)
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Parent Standard
Governed Space: Resource Dependency & Criticality Governance
Standard ID: RSGA-RDCS-04
Origin ID: OOF-RSGA-RDCS
Version: 1.0
Status: Draft Standard
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
Resource Dependency & Criticality Standard (RDCS) is the Parent Standard within RSGA™ that governs how the dependency of a function, system, process, service, infrastructure, participant, or other governed object upon a Resource is identified, structured, evidenced, qualified, and reassessed, and how the Criticality of that Resource dependency is determined from the consequences, tolerance, substitutability, recovery conditions, and operational significance associated with Resource degradation, interruption, insufficiency, or loss.
RDCS establishes the transition from:
Resource Demand
to:
governed Resource Dependency and Criticality.
Resource Demand ≠ Resource Dependency ≠ Resource Criticality.
2. Operational Role
RCHS establishes what Resource is being governed.
RACS establishes what Resource capacity is actually available, usable, reserved, temporally applicable, and practically accessible.
RDGS establishes what Resource is actually required.
RDCS determines:
how strongly the relevant function or system depends upon that Resource; what happens if the Resource becomes insufficient, degraded, interrupted, or unavailable; how much Resource loss can be tolerated; how long Resource interruption can be tolerated; whether substitutes or alternative operating paths exist; whether the dependency propagates into other functions or systems; and how critical the Resource dependency actually is.
RDCS therefore prevents Resource governance from treating Demand magnitude as a substitute for Dependency or Criticality.
3. Core Question
How strongly does the governed function, system, process, service, infrastructure, or participant depend upon the Resource, what happens when that Resource becomes degraded or unavailable, and how critical is that dependency under the relevant operating conditions?
4. Position in Architecture Governance Flow
Resource Characterization → Availability & Capacity → Demand → Dependency & Criticality → Access → Prioritization & Allocation → Consumption & Utilization → Scarcity & Constraint → Recovery & Circularity → Substitution & Flexibility → Interdependency & Resilience → Continuity & Sustainability
RDCS receives governed Resource Demand and establishes the Dependency and Criticality context required before Resource Access, Prioritization, and Allocation governance.
5. Governed Space
RDCS governs:
Resource Dependency & Criticality Governance
This space concerns the relationship between a Resource-dependent object and the Resource upon which its operation, capability, output, service, continuity, safety, recovery, or other materially relevant function depends.
6. Governed Object
The primary Governed Object is:
A Resource Dependency and its associated Resource Criticality State.
A Resource Dependency may connect a Resource to:
a function; a process; a system; a service; an infrastructure component; a participant; an operational capability; a societal capability; another materially relevant governed object.
7. Scope
RDCS applies wherever the absence, reduction, degradation, interruption, delay, or loss of a Resource may materially affect a Resource-dependent object.
Its Scope includes:
Resource Dependency identification; Dependency boundary; Dependency strength; Dependency type; Dependency direction; direct Dependency; indirect Dependency; partial Dependency; conditional Dependency; functional Dependency; technical Dependency; operational Dependency; Resource quality Dependency; Resource rate Dependency; Resource continuity Dependency; temporal Dependency; spatial Dependency; Dependency tolerance; minimum Resource requirement; Resource interruption tolerance; Resource degradation tolerance; Dependency consequence; Dependency propagation; substitutability context;
alternative Resource paths; recovery context; Resource Criticality; Criticality evidence; Criticality uncertainty; Criticality reassessment.
RDCS does not independently determine:
Resource Access authorization; Resource Priority; Resource Allocation; Resource Consumption; Scarcity response; Recovery execution; Resource Substitution governance; system-wide Resilience; long-term Resource Sustainability.
8. Resource Dependency
Resource Dependency exists where the state of a Resource materially affects the ability of a governed object to perform, continue, recover, or achieve a relevant operational result.
9. Dependency Relationship
Canonical relationship:
Governed Object → Requires Resource → Resource State affects Governed Object State
10. Dependency Source
The Dependency Source is the function, system, process, service, infrastructure, participant, or other object whose operation depends upon the Resource.
11. Dependency Target
The Dependency Target is the Resource or Resource capacity upon which the Dependency Source relies.
12. Dependency Identity
A material Resource Dependency should be identifiable independently of other Resource relationships.
13. Dependency Boundary
The Dependency Boundary establishes:
which governed object depends upon which Resource; for which function; under which conditions; within which operational boundary.
14. Dependency Boundary Integrity
Dependency boundaries must follow the governed operational reality rather than organizational structure or preferred governance outcome.
15. Demand vs Dependency
RDGS establishes what Resource is required.
RDCS establishes what the requirement means for continued operation.
Resource Demand ≠ Resource Dependency.
16. Demand Magnitude vs Dependency Strength
A large Resource Demand may support a function capable of operating at reduced Resource levels.
A small Resource Demand may support a function unable to operate without that Resource.
Therefore:
Demand Magnitude ≠ Dependency Strength.
17. Dependency vs Criticality
Dependency establishes reliance upon Resource.
Criticality establishes the governance significance of that reliance.
Dependency ≠ Criticality.
18. High Dependency vs High Criticality
A function may depend completely upon a Resource while the consequence of its interruption remains minor.
Therefore:
High Dependency ≠ High Criticality by definition.
19. Low Demand, High Criticality
A Resource requirement may be quantitatively small while supporting a highly consequential function.
Low Resource Demand ≠ Low Resource Criticality.
20. High Demand, Low Criticality
A Resource requirement may be large while supporting a flexible or deferrable function.
High Resource Demand ≠ High Resource Criticality.
21. Direct Dependency
Direct Dependency exists where the governed object itself requires the Resource.
Example:
AI compute system → Electricity
22. Indirect Dependency
Indirect Dependency exists where the governed object depends upon another function or system that itself requires the Resource.
Example:
AI compute → Cooling system → Electricity
The compute function therefore carries an indirect dependency upon electricity through cooling in addition to its direct electrical requirement.
23. Dependency Chain
Resource Dependency may propagate through multiple operational layers.
Canonical representation:
Function A → System B → Resource C
or:
Function A → Resource B → Infrastructure C → Resource D
24. Dependency Chain Integrity
Each material dependency link should remain independently identifiable.
25. Dependency Propagation
Failure of one Resource dependency may affect downstream functions or systems.
RDCS governs the dependency significance of this propagation.
RIRS later governs broader Resource Interdependency & Resilience.
26. Primary Dependency
A Primary Dependency directly supports the principal function being governed.
27. Supporting Dependency
A Supporting Dependency enables a supporting function necessary for the principal function.
28. Hidden Dependency
A Resource dependency may exist without being immediately visible in the primary Resource Demand representation.
Examples include:
cooling; network connectivity; control power; lubricants; specialized materials; backup infrastructure.
29. Hidden Dependency Principle
A Resource not visible in the primary output may still be operationally critical.
30. Partial Dependency
A function may continue operating at reduced capability after partial Resource loss.
31. Complete Dependency
Complete Dependency exists where the relevant function cannot continue without the Resource beyond the defined tolerance conditions.
32. Conditional Dependency
A Resource may become necessary only under defined operating conditions.
33. Standby Dependency
A Resource may be required only for standby or contingency operation.
34. Emergency Dependency
A Resource may become necessary during emergency operation.
35. Recovery Dependency
A Resource may be required specifically for recovery from interruption or failure.
36. Temporary Dependency
A Resource dependency may exist only during a defined period or operating state.
37. Persistent Dependency
A Persistent Dependency remains relevant throughout normal operation.
38. Dependency State
At minimum, RDCS may distinguish:
Direct
Indirect
Partial
Complete
Conditional
Standby
Emergency
Recovery
Temporary
Persistent
39. Functional Dependency
Functional Dependency describes the extent to which Resource availability affects the ability to perform a defined function.
40. Technical Dependency
Technical Dependency arises from the technical architecture of the governed system.
41. Operational Dependency
Operational Dependency arises from the way a system or process is actually operated.
42. Infrastructure Dependency
Infrastructure may create dependencies not inherent in the underlying function.
43. Resource Quality Dependency
A function may depend not merely on Resource quantity but on Resource quality.
Examples:
water purity; electricity quality; material grade; compute performance; network latency.
44. Quantity Dependency
A function may require a minimum Resource quantity.
45. Capacity Dependency
A function may require minimum available capacity.
46. Rate Dependency
A function may depend upon a minimum Resource delivery rate.
47. Performance Dependency
A function may require Resource performance above a defined threshold.
48. Continuity Dependency
A function may depend upon continuous Resource availability.
49. Temporal Dependency
A Resource may be required only during specific time windows.
50. Spatial Dependency
A function may depend upon Resource availability at a specific location.
51. Dependency Threshold
A Dependency Threshold identifies the Resource condition below which material degradation of the governed function begins.
52. Minimum Functional Resource Level
RDCS may use the minimum Resource level established through Demand governance as an input to dependency analysis.
It does not redefine the underlying Demand.
53. Resource Sufficiency Threshold
The Resource Sufficiency Threshold identifies the Resource state required to maintain the relevant functional state.
54. Degradation Threshold
A function may begin degrading before complete Resource loss occurs.
55. Failure Threshold
A Failure Threshold identifies the Resource state at which the relevant function can no longer perform the governed requirement.
56. Threshold Sequence
Where relevant:
Normal Resource State → Reduced Resource State → Degradation Threshold → Critical Degradation → Failure Threshold → Functional Loss
57. Binary Dependency Boundary
Resource dependency should not be represented as purely binary where operational reality contains meaningful degradation states.
58. Dependency Gradient
Dependency may vary across Resource states.
59. Resource Reduction Response
RDCS should determine how the governed object responds as Resource quantity, capacity, rate, quality, or continuity declines.
60. Dependency Sensitivity
Dependency Sensitivity describes how strongly functional performance changes in response to Resource degradation.
61. Low Sensitivity
A function may tolerate substantial Resource reduction with little immediate effect.
62. High Sensitivity
A small Resource reduction may cause substantial functional degradation.
63. Dependency Tolerance
Dependency Tolerance represents the amount or duration of Resource degradation that can occur before material consequences arise.
64. Quantity Tolerance
A function may tolerate a reduction in Resource quantity.
65. Rate Tolerance
A function may tolerate a temporary reduction in Resource rate.
66. Quality Tolerance
A function may tolerate Resource quality degradation within defined boundaries.
67. Interruption Tolerance
A function may tolerate complete Resource interruption for a limited period.
68. Interruption Tolerance Window
The interruption tolerance should preserve:
maximum tolerated interruption duration; relevant operating state; conditions; evidence.
69. Immediate Dependency
Some functions experience material consequence immediately after Resource interruption.
70. Delayed Dependency
Some functions can continue temporarily through:
storage; buffers; inventory; redundancy; thermal inertia; backup capacity.
71. Buffer-Mediated Dependency
Buffers may delay functional consequence without eliminating underlying Resource Dependency.
72. Storage Dependency Context
Stored Resource may temporarily decouple a function from current Resource supply.
Temporary Buffering ≠ Dependency Elimination.
73. Backup Resource Context
Backup capacity may reduce immediate dependency upon the primary Resource Source.
It does not necessarily eliminate dependency upon the Resource itself.
74. Source Dependency vs Resource Dependency
A function may be independent of one Resource Source while remaining completely dependent upon the Resource type.
Source Substitutability ≠ Resource Independence.
75. Resource Substitutability Context
A function may have alternative Resources capable of supporting the same or sufficiently equivalent function.
RSFS retains formal Resource Substitution & Flexibility governance.
RDCS records substitutability as Criticality context.
76. Immediate Substitute
A substitute may be immediately available.
77. Delayed Substitute
A substitute may exist but require time before it becomes usable.
78. Partial Substitute
A substitute may support only part of the required function.
79. Conditional Substitute
A substitute may operate only under defined conditions.
80. No Practical Substitute
A theoretically possible substitute may not be practically available within the relevant consequence window.
81. Theoretical vs Practical Substitutability
Theoretical Substitute ≠ Operationally Available Substitute.
82. Substitution Time
The time required to activate a substitute materially affects Resource Criticality.
83. Substitution Capacity
A substitute may exist but lack sufficient capacity.
84. Substitution Quality
Alternative Resource may fail to meet required quality or performance.
85. Dependency Redundancy Context
Multiple Resource Sources or pathways may reduce vulnerability to one Source.
86. Redundancy vs Independence
Resource Redundancy ≠ Resource Independence.
Two electricity feeds still represent dependency upon electricity.
87. Common-Mode Dependency
Apparently redundant Resource paths may share a common underlying dependency.
88. Common-Mode Failure
Multiple backup paths may fail together if they depend upon the same upstream Resource or infrastructure.
89. Dependency Concentration
Dependency may become concentrated where one Resource, Source, location, infrastructure node, or pathway supports many functions.
90. Concentrated Dependency Significance
High dependency concentration may increase the consequences of Resource interruption.
91. Resource Criticality
Resource Criticality represents the governance significance of a Resource Dependency under the relevant consequence, tolerance, substitution, recovery, and operating conditions.
92. Criticality Is Contextual
Criticality is not an inherent universal property of the Resource.
Resource Criticality is relational and contextual.
The same Resource may be critical to one function and non-critical to another.
93. Criticality Object
Criticality should attach to a defined:
**Resource
Dependency Source Function
Context**
rather than to Resource name alone.
94. Criticality Factors
Relevant Criticality factors may include:
Dependency strength; functional consequence; interruption tolerance; degradation tolerance; substitutability; substitution time; recovery time; Resource concentration; dependency propagation; operating state; temporal context; spatial context.
95. Criticality vs Demand Magnitude
Demand quantity may inform context.
It does not determine Criticality.
96. Criticality vs Resource Price
A costly Resource is not automatically critical.
A cheap Resource may be operationally indispensable.
Resource Price ≠ Resource Criticality.
97. Criticality vs Scarcity
A Resource may be critical while abundant.
A scarce Resource may support a low-criticality function.
Resource Scarcity ≠ Resource Criticality.
98. Criticality vs Strategic Importance
Strategic importance may contribute to Criticality analysis.
It should not replace operational dependency evidence.
99. Criticality vs Value
A high-Value function may create important Resource consequences.
VEGA™ retains Value Governance.
Value ≠ Resource Criticality.
100. Criticality vs Harm
Resource interruption may create Harm.
HAGA™ retains Harm Governance.
RDCS may consume relevant Harm consequence evidence without absorbing Harm governance.
101. Criticality vs Liability
Resource interruption may create Liability.
LIGA™ retains Liability Governance.
Liability does not define Resource Criticality by itself.
102. Criticality vs Priority
Criticality provides evidence relevant to downstream Resource Prioritization.
It does not itself allocate Resource.
Resource Criticality ≠ Resource Priority.
103. Criticality vs Allocation
Critical Resource ≠ Automatically Allocated Resource.
RPAS retains Resource Prioritization & Allocation governance.
104. Consequence of Resource Degradation
RDCS should determine what materially happens when Resource conditions deteriorate.
105. Functional Consequence
Resource degradation may reduce:
output; performance; quality; availability; service level; operational capability.
106. Continuity Consequence
Resource interruption may threaten continuation of a function or system.
107. Safety Consequence
Resource loss may affect safety.
RDCS records the relevance to Resource Criticality.
HAGA™ retains formal Harm governance where Harm analysis is required.
108. Economic Consequence
Resource loss may create economic effects.
Economic consequence alone does not define Criticality.
109. Societal Consequence
Some Resource dependencies may support broader societal functions.
110. Cascading Consequence
Failure of one Resource-dependent function may affect additional systems or functions.
111. Consequence Propagation
Canonical pattern:
Resource Degradation → Functional Degradation → Operational Consequence → Dependent-System Consequence
112. Consequence Boundary
RDCS governs consequences insofar as they establish Dependency and Criticality significance.
Specialized governance architectures retain their own domains.
113. Consequence Severity
Consequence severity should be evidenced rather than assumed from Resource identity.
114. Consequence Timing
The time between Resource degradation and material consequence matters.
115. Immediate Consequence
Material consequence may begin immediately.
116. Delayed Consequence
Buffers or operating tolerance may delay consequence.
117. Recoverable Consequence
A function may recover fully after Resource restoration.
118. Irrecoverable Consequence Context
Some Resource interruptions may produce consequences that cannot be fully reversed by later Resource restoration.
RDCS records this as Criticality context.
119. Recovery Time
Recovery time after Resource restoration may materially affect Criticality.
120. Resource Restoration vs Functional Recovery
Resource Restored ≠ Function Fully Recovered.
121. Criticality Time Horizon
Criticality may change across:
seconds; minutes; hours; days; seasons; long-term horizons.
122. Short-Term Criticality
A Resource may be highly critical over short intervals.
123. Long-Term Criticality
Long-term Criticality may arise from sustained Resource dependency even where short interruptions are tolerable.
124. Criticality State Change
Criticality may change as:
Resource conditions; function; buffers; substitutes; operating state; recovery capability
change.
125. Dynamic Criticality
Resource Criticality is a governed state, not a permanent label.
126. Criticality Classification
RDCS may classify Resource Criticality using governed states appropriate to the implementation.
At minimum, classification should preserve meaningful differences in consequence and tolerance.
127. Minimum Criticality States
A minimum implementation may support:
Low Criticality
Moderate Criticality
High Criticality
Critical
Criticality Evidence-Limited
Criticality Conflicted
Criticality Unknown
Criticality Unresolved
128. Classification Boundary
Criticality labels require defined methodology.
Words such as “critical” must not be assigned merely for rhetorical emphasis.
129. Criticality Thresholds
Where numerical or categorical thresholds are used, their methodology should remain explicit.
130. Universal Threshold Boundary
RDCS does not require one universal Criticality formula across all Resource types and governed contexts.
131. Criticality Scoring
A scoring system may be used where methodologically justified.
A score must not replace the underlying Dependency and consequence evidence.
132. Score Explainability
A Criticality score should remain traceable to the factors that produced it.
133. False Precision
Criticality should not be expressed with numerical precision unsupported by evidence.
134. Criticality Evidence
Material Criticality determinations should have an identifiable evidence basis.
135. Dependency Evidence
Dependency evidence may include:
technical architecture; Resource requirements; operational telemetry; process specifications; functional testing; system observations; engineering analysis.
136. Consequence Evidence
Consequence evidence may include:
operational history; failure testing; incident records; Simulation; technical analysis; recovery records; validated models.
137. Tolerance Evidence
Tolerance may be established through:
operational testing; technical specification; historical interruption; Simulation; engineering analysis.
138. Substitutability Evidence
Substitutability should be supported by evidence that the substitute can actually perform the relevant function under required conditions.
139. Recovery Evidence
Recovery assumptions should be supported where recovery time materially affects Criticality.
140. Evidence Provenance
Relevant evidence should preserve:
Resource ID
Dependency Source
Function
Evidence Source
Time
Operating State
Method
Version:
141. Evidence Freshness
Dependency and Criticality evidence may become stale after system or operational change.
142. Evidence Conflict
Credible evidence may support different Dependency or Criticality states.
The conflict should remain visible.
143. Dependency Uncertainty
Dependency uncertainty may concern:
Resource relationship; dependency strength; threshold; tolerance; substitution; consequence; recovery.
144. Criticality Uncertainty
Criticality uncertainty should remain attached to the Criticality determination where material.
145. Uncertainty Propagation
Uncertainty in Resource Dependency must propagate into Resource Criticality where the unresolved dependency materially affects the Criticality determination.
146. Dependency Sufficiency
Dependency is sufficiently governed when the Resource relationship is adequately established for Criticality determination and downstream Resource governance.
147. Criticality Sufficiency
Criticality is sufficiently governed when consequence, tolerance, substitution, recovery, and other materially relevant factors are adequately represented for downstream governance.
148. Dependency Decision States
At minimum:
Dependency Established
Conditionally Established
Partially Established
Dependency Evidence-Limited
Dependency Conflicted
Dependency Unknown
Dependency Unresolved
149. Resource Dependency Profile
A governed Resource Dependency should produce a structured:
Resource Dependency Profile
150. Minimum Resource Dependency Profile Fields
At minimum:
Dependency ID
Resource ID
Demand Profile Reference
Dependency Source
Function
Dependency Type
Dependency Boundary
Dependency Strength
Resource Threshold
Degradation Threshold
Failure Threshold where relevant
Interruption Tolerance
Substitution Context
Recovery Context
Evidence Basis
Dependency Uncertainty
Dependency State
Version:
151. Resource Criticality Profile
The Criticality determination should produce a:
Resource Criticality Profile
152. Minimum Resource Criticality Profile Fields
At minimum:
Criticality ID
Dependency ID
Resource ID
Function
Dependency Strength
Consequence State
Consequence Timing
Tolerance State
Substitutability State
Recovery State
Propagation Context
Criticality State
Evidence Basis
Criticality Uncertainty
Sufficiency State
Version:
153. Dependency-Criticality Relationship
Canonical logic:
Resource Demand → Resource Dependency → Dependency Strength → Tolerance → Resource Degradation / Interruption Consequence → Substitution Context → Recovery Context → Criticality Determination
154. Demand Independence
RDCS should not alter the RDGS Resource Demand Profile merely because the resulting Dependency or Criticality is high or low.
155. Criticality Independence
Criticality should follow evidence rather than a desired downstream Priority outcome.
156. Priority Independence
RDCS does not assign Resource Priority.
A Criticality state becomes evidence for RPAS rather than an Allocation instruction.
157. Access Independence
A highly critical Resource Dependency does not automatically establish Resource Access rights.
RAGS retains Resource Access Governance.
158. Availability Independence
A highly critical Resource may still be unavailable.
Criticality does not create capacity.
159. Scarcity Independence
Criticality exists independently of whether Resource is currently scarce.
160. Dependency Reassessment Trigger
Reassessment should occur following material:
Demand change; function change; Resource change; system reconfiguration; new substitute; loss of substitute; buffer change; Resource threshold change; new evidence; incident; recovery change.
161. Criticality Reassessment Trigger
Criticality should be reassessed following material changes to:
Dependency strength; consequence; tolerance; substitutability; recovery; operating state; dependency propagation; time horizon.
162. Reassessment Logic
Canonical logic:
Existing Dependency / Criticality Profile → New Evidence or Material Change → Dependency Impact Test → Consequence / Tolerance / Substitution / Recovery Reassessment → Criticality Retained or Revised → Version Update → Downstream Governance Reassessment
163. Versioning
Material Dependency or Criticality changes should create a new governed version.
164. Historical Criticality
Historical Criticality should remain distinguishable from current Criticality.
165. Resource Criticality Trend
Versioned Criticality states may reveal increasing or decreasing Resource vulnerability.
The underlying conditions should remain visible.
166. Governance Requirements
A conforming RDCS implementation must:
1. receive governed Resource Demand; 2. identify the Resource Dependency; 3. identify the Dependency Source; 4. identify the relevant function; 5. establish the Dependency boundary; 6. distinguish Demand from Dependency; 7. distinguish Dependency from Criticality; 8. identify direct and indirect Dependency; 9. identify material Dependency chains; 10. identify partial and complete Dependency; 11. identify conditional Dependency; 12. establish relevant Resource thresholds; 13. determine Resource degradation response; 14. determine interruption tolerance; 15. determine relevant quality, rate, capacity, and continuity requirements; 16. identify buffering where relevant; 17. identify substitute context; 18. distinguish Source substitution from Resource independence; 19. identify relevant redundancy; 20. identify common-mode Dependency where material; 21. determine material consequences; 22. determine consequence timing; 23. determine recovery context; 24. determine Resource Criticality; 25. preserve evidence provenance; 26. preserve material uncertainty; 27. preserve evidence conflict; 28. support reassessment;
29. support versioning; 30. produce structured Dependency and Criticality Profiles; 31. preserve the boundary between Criticality and Priority; 32. preserve unresolved limitations downstream.
167. Governance Logic
Canonical RDCS logic:
Resource Demand Profile → Dependency Source → Resource Dependency → Dependency Boundary → Dependency Type → Dependency Strength → Resource Thresholds → Degradation Response → Interruption Tolerance → Buffer / Redundancy Context → Substitution Context → Consequence → Consequence Timing → Recovery Context → Propagation Context → Evidence → Uncertainty → Criticality Determination → Resource Dependency Profile → Resource Criticality Profile
Where evidence is insufficient:
Dependency / Criticality Unresolved → Material Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Reassessment
168. Governance Outputs
RDCS may produce:
Resource Dependency Profile
Resource Criticality Profile
Dependency State
Dependency Strength
Dependency Type
Dependency Boundary
Resource Threshold State
Degradation State
Failure Threshold
Interruption Tolerance
Buffer State
Substitutability Context
Redundancy Context
Common-Mode Dependency State
Consequence State
Consequence Timing
Recovery Context
Propagation Context
Criticality State
Evidence State
Uncertainty State
Sufficiency State
Version:
Reassessment Trigger
169. Minimum Implementation Framework
A minimum RDCS implementation should contain eight governed layers.
Layer 1 — Demand Input
Receive:
Resource Demand Profile
Layer 2 — Dependency Identification
Establish:
Dependency Source Resource Function Dependency Boundary
Layer 3 — Dependency Characterization
Determine:
Direct / Indirect Partial / Complete Conditional / Persistent Dependency Strength
Layer 4 — Threshold & Tolerance
Determine:
Resource threshold Degradation threshold Failure threshold Interruption tolerance
Layer 5 — Alternative & Recovery Context
Assess:
Buffer Redundancy Substitute Substitution time Recovery
Layer 6 — Consequence
Determine:
Functional consequence Operational consequence Consequence timing Propagation
Layer 7 — Criticality
Determine:
Criticality State Evidence Uncertainty Sufficiency
Layer 8 — Governed Output
Produce:
Resource Dependency Profile Resource Criticality Profile Version Reassessment triggers Downstream handoff state
Minimum machine-readable logic:
Resource Demand Profile → Dependency → Dependency Strength → Thresholds → Tolerance → Buffer / Redundancy → Substitute Context → Consequence → Recovery → Propagation → Evidence[] → Uncertainty[] → Criticality State → Dependency & Criticality Profiles
170. Minimum Decision States
Dependency:
Dependency Established
Conditionally Established
Partially Established
Dependency Evidence-Limited
Dependency Conflicted
Dependency Unknown
Dependency Unresolved
Criticality:
Low Criticality
Moderate Criticality
High Criticality
Critical
Criticality Evidence-Limited
Criticality Conflicted
Criticality Unknown
Criticality Unresolved
171. Minimum Evidence Path
Where Dependency or Criticality cannot be sufficiently established:
Unresolved State → Material Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Dependency Reassessment → Criticality Reassessment → Updated Profiles
The objective is sufficient evidence for Resource governance, not maximum possible data collection.
172. Minimum Reassessment Framework
At minimum:
Current Dependency & Criticality Profiles → New Evidence / Material Change → Dependency Impact Test → Threshold / Tolerance / Consequence / Substitute / Recovery Reassessment → Criticality Retained or Revised → Profile Version Update → Downstream Reassessment
173. Failure Conditions
RDCS should not be considered sufficiently completed where:
Resource Demand is automatically treated as Resource Dependency; Demand magnitude is used as Dependency strength; Dependency is automatically treated as Criticality; Resource Criticality is assigned from Resource name alone; Criticality is inferred from Resource price; Scarcity is treated as Criticality; high Demand is treated as high Criticality; low Demand is treated as low Criticality;
Resource thresholds are undefined where material; interruption tolerance is ignored; Resource quality dependency is ignored; buffers are treated as elimination of Dependency; Source redundancy is treated as Resource independence; theoretical substitutes are treated as operational substitutes; substitution time is ignored; common-mode dependencies are ignored; consequence timing is ignored; Resource restoration is treated automatically as full functional recovery; Criticality evidence conflict is suppressed; uncertainty is hidden; Criticality is treated as Resource Priority; Criticality is treated as Allocation authority.
174. Critical Distinctions
Resource Demand ≠ Resource Dependency
Resource Dependency ≠ Resource Criticality
Demand Magnitude ≠ Dependency Strength
High Dependency ≠ High Criticality by definition
Low Resource Demand ≠ Low Resource Criticality
High Resource Demand ≠ High Resource Criticality
Temporary Buffering ≠ Dependency Elimination
Source Substitutability ≠ Resource Independence
Theoretical Substitute ≠ Operationally Available Substitute
Resource Redundancy ≠ Resource Independence
Resource Price ≠ Resource Criticality
Resource Scarcity ≠ Resource Criticality
Value ≠ Resource Criticality
Resource Criticality ≠ Resource Priority
Critical Resource ≠ Automatically Allocated Resource
Resource Restored ≠ Function Fully Recovered
Resource Criticality is relational and contextual
Resource Criticality is a governed state, not a permanent label
175. Cross-Architecture Boundary
RDCS governs Resource Dependency and Resource Criticality within RSGA™.
It may consume inputs from:
RCHS for Resource characterization; RACS for Resource Availability & Capacity context; RDGS for governed Resource Demand; PGA™ for predicted Resource or consequence states; SIMULOS® for simulated interruption, degradation, or recovery states;
ORA™ for operational evidence; HAGA™ for governed Harm evidence where relevant; LIGA™ for Liability evidence where relevant; VEGA™ for relevant Value context; specialized Resource architectures for Resource-specific technical mechanisms.
It does not absorb their governed mechanisms.
176. 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 technical system may establish how Resource loss affects performance.
A Simulation may establish possible interruption outcomes.
A Harm analysis may establish consequence evidence.
A Value analysis may establish economic or operational significance.
RDCS consumes these outputs where they are relevant to Resource Dependency and Criticality.
It does not absorb the mechanisms that produced them.
177. Canonical Boundary
RDCS governs how a Resource requirement becomes a governed Resource Dependency and how the significance of that Dependency is determined through Dependency strength, Resource thresholds, tolerance, degradation response, consequence, substitutability, recovery, propagation, evidence, and uncertainty.
It does not determine Resource Access authorization, Resource Priority, Resource Allocation, Consumption governance, Scarcity response, Recovery execution, Resource Substitution governance, system-wide Resilience, or long-term Sustainability.
Its principal governed outputs are the Resource Dependency Profile and Resource Criticality Profile .
178. Canonical Closing Statement
The amount of Resource a system requires does not reveal how much that Resource matters.
RDCS establishes what depends upon the Resource, how that dependency behaves when Resource conditions deteriorate, how much interruption can be tolerated, what alternatives exist, and what consequences follow — turning Resource requirement into governed Dependency and Criticality without confusing Criticality with Priority or Allocation.
Governed Links
About Resource Dependency & Criticality Standard (RDCS)
Resource Dependency Mapping Module (RDMM)
Resource Criticality Assessment Module (RCAM)
Resource Consequence Evaluation Module (RCEM)
Resource Dependency Chain Module (RDCM)
Resource Criticality Determination Module (RCDM)