About Resource Dependency & Criticality Standard
(RDCS)
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Parent Standard: Resource Dependency & Criticality Standard (RDCS)
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.
1. What RDCS Governs
RDCS governs the transition from knowing that a Resource is required to understanding what that requirement means for the function or system that depends upon it.
It establishes:
what depends upon the Resource; which function the Resource supports; how strong the Dependency is; what Resource conditions the function requires; how much degradation can be tolerated; how long interruption can be tolerated; what happens when Resource conditions deteriorate;
whether substitutes or alternative paths exist; how quickly operation can recover; and how critical the resulting Resource Dependency is.
Its principal governed outputs are the:
Resource Dependency Profile
and:
Resource Criticality Profile.
2. Why Resource Dependency Requires Governance
A Resource requirement alone does not explain how important that Resource is to continued operation.
Two functions may require the same quantity of electricity while having completely different dependencies.
One may tolerate hours of interruption.
The other may fail within seconds.
Similarly, a function consuming a large amount of Resource may be flexible or deferrable, while a function consuming very little may be unable to operate without uninterrupted Resource availability.
Therefore:
Resource Demand ≠ Resource Dependency ≠ Resource Criticality.
RDCS exists to preserve these differences.
3. From Resource Demand to Resource Dependency
RDGS establishes:
What Resource is required?
RDCS asks:
What happens to the function or system if that Resource is reduced, degraded, interrupted, delayed, or lost?
This creates a fundamental transition in RSGA™:
Resource Demand → Resource Dependency → Resource Criticality
Demand establishes the Resource requirement.
Dependency establishes reliance.
Criticality establishes the governance significance of that reliance.
4. Demand Magnitude Does Not Determine Dependency
The quantity of Resource required does not reveal the strength of Dependency.
A system requiring 100 units of Resource may continue operating at 60 units.
Another system requiring only 2 units may stop completely if those 2 units disappear.
Therefore:
Demand Magnitude ≠ Dependency Strength.
RDCS evaluates the operational relationship between Resource state and functional state rather than inferring Dependency from Resource quantity.
5. Dependency Does Not Automatically Mean Criticality
A function may be completely dependent upon a Resource while the consequence of losing that function remains limited.
Another function may have only a small Resource requirement but support a highly consequential operational capability.
Therefore:
High Dependency ≠ High Criticality by definition.
Criticality requires consequence context.
6. Direct and Indirect Dependency
Resource Dependency may be direct.
Example:
AI compute system → Electricity
It may also be indirect.
Example:
AI compute → Cooling → Electricity
The AI system therefore depends upon electricity not only directly through computation but also indirectly through the cooling infrastructure required to sustain operation.
RDCS preserves these Dependency chains rather than evaluating only the most visible Resource requirement.
7. Hidden Resource Dependencies
Some of the most important Resource Dependencies may not appear in the primary Resource Demand.
A production system may visibly require electricity and raw materials while also depending upon:
cooling; control power; network capacity; specialized gases; lubricants; water; backup infrastructure.
A Resource can therefore be operationally important even when it represents only a small portion of total Resource Demand.
A Resource not visible in the primary output may still be operationally critical.
8. Dependency Strength
RDCS determines how strongly operation changes when Resource conditions change.
A Dependency may be:
partial; complete; conditional; temporary; persistent; standby-related; emergency-related; recovery-related.
The objective is not to attach a generic Dependency label.
The objective is to describe the actual relationship between Resource state and operational capability.
9. Resource Thresholds
Many Resource Dependencies are not binary.
A function may continue operating while Resource conditions gradually deteriorate.
RDCS may therefore distinguish:
normal Resource requirement; Resource sufficiency threshold; degradation threshold; critical degradation state; failure threshold.
Canonical progression:
Normal Resource State → Reduced Resource State → Degradation Threshold → Critical Degradation → Failure Threshold → Functional Loss
This allows Dependency governance to represent operational reality more accurately than a simple available/unavailable model.
10. Dependency Tolerance
A function may tolerate Resource degradation in several dimensions.
It may tolerate:
lower quantity; lower delivery rate; reduced quality; temporary interruption; performance degradation; delayed Resource restoration.
RDCS identifies these tolerance boundaries.
11. Interruption Tolerance
Time is often fundamental to Resource Dependency.
One system may tolerate a power interruption of several hours.
Another may tolerate only seconds.
A water-dependent process may continue temporarily from stored Resource.
A compute system may continue through backup power.
The existence of a buffer changes the timing of consequences.
It does not necessarily remove the underlying Dependency.
Temporary Buffering ≠ Dependency Elimination.
12. Resource Quality Dependency
Resource quantity alone may not determine whether a function can operate.
A function may depend upon:
water purity; electricity quality; material grade; compute performance; network latency; temperature; pressure; other Resource-specific conditions.
A Resource may therefore exist in sufficient quantity while still failing to satisfy the actual Dependency.
13. Resource Source vs Resource Dependency
A function may have several Sources for the same Resource.
For example, a facility may have:
grid electricity; local generation; battery backup.
This may reduce Dependency upon one Source.
It does not necessarily remove Dependency upon electricity.
Therefore:
Source Substitutability ≠ Resource Independence.
14. Redundancy
Redundant Resource paths may reduce vulnerability.
However:
Resource Redundancy ≠ Resource Independence.
Two electricity feeds remain dependencies upon electricity.
Two water pipelines may still depend upon the same upstream reservoir.
Two network connections may still pass through the same infrastructure node.
RDCS therefore considers whether apparent redundancy contains common underlying dependencies.
15. Common-Mode Dependency
Multiple apparently independent Resource paths may fail together because they share:
one Resource Source; one infrastructure node; one geographic exposure; one upstream Resource; one technical dependency.
RDCS preserves this common-mode context where it materially affects Criticality.
16. Resource Substitutability
A Resource may have alternatives.
However, the existence of a theoretical alternative does not automatically reduce Resource Criticality.
A substitute must be evaluated in context.
Relevant questions include:
Can it perform the same function? Is it available? Is sufficient capacity available? How quickly can it be activated? Does it meet required quality? Does it require different infrastructure?
Therefore:
Theoretical Substitute ≠ Operationally Available Substitute.
Formal Resource Substitution & Flexibility governance remains within RSFS.
RDCS uses substitutability as Criticality context.
17. Resource Degradation Consequences
Resource Dependency becomes governance-relevant because changes in Resource state can change operational state.
Resource degradation may cause:
lower output; lower performance; reduced quality; service degradation; operational interruption; functional failure; recovery requirements; effects on dependent systems.
RDCS determines how these consequences affect Resource Criticality.
18. Consequence Timing
The same eventual consequence may have very different governance significance depending on when it occurs.
Resource interruption may create:
immediate consequence; delayed consequence; gradual degradation; threshold-triggered failure.
Buffers, stored Resource, redundancy, and operational tolerance can change this timing.
19. Dependency Propagation
Resource Dependency may extend beyond the first affected function.
Example:
Electricity loss → Cooling loss → Compute degradation → Digital service interruption
The original Resource Dependency therefore may propagate through multiple operational layers.
RDCS identifies the significance of that propagation for Resource Criticality.
Broader Resource Interdependency and system Resilience remain governed downstream by RIRS.
20. Resource Criticality
Resource Criticality represents the governance significance of a Resource Dependency under the relevant operational conditions.
It may depend upon:
Dependency strength; functional consequence; interruption tolerance; degradation tolerance; substitutability; substitution time; recovery time; dependency concentration; propagation; operating state; time horizon.
Criticality is therefore not simply a characteristic of a Resource.
21. Criticality Is Relational
Electricity is not universally “critical” at the same level.
Water is not universally “critical” at the same level.
Compute capacity is not universally “critical” at the same level.
Criticality exists in a relationship:
**Resource
Dependent Function Operating Context
Consequence → Resource Criticality**
Therefore:
Resource Criticality is relational and contextual.
22. Criticality Is Dynamic
Resource Criticality may change.
A new backup Resource may reduce immediate Criticality.
Loss of a substitute may increase it.
A change in operating mode may make a previously non-critical Resource temporarily critical.
A system redesign may remove a Dependency.
A seasonal condition may create a new Dependency.
Therefore:
Resource Criticality is a governed state, not a permanent label.
23. Criticality and Scarcity Are Different
A Resource may be abundant and still be critical to a function.
A Resource may be scarce while supporting a low-criticality function.
Therefore:
Resource Scarcity ≠ Resource Criticality.
Scarcity describes Resource constraint.
Criticality describes the significance of Dependency.
24. Criticality and Resource Price Are Different
Market price does not determine Resource Criticality.
An inexpensive component, Resource, or capacity may be essential to continued operation.
A highly expensive Resource may support a deferrable activity.
Therefore:
Resource Price ≠ Resource Criticality.
25. Criticality and Value Are Different
A Resource may support economically or strategically valuable activity.
That Value may be relevant to broader governance.
It does not replace Dependency analysis.
VEGA™ retains relevant Value Governance.
Value ≠ Resource Criticality.
26. Criticality and Harm
Loss of a Resource may create harmful consequences.
Where Harm itself must be governed, HAGA™ retains that domain.
RDCS may consume governed Harm evidence insofar as it affects Resource Criticality.
It does not absorb Harm Governance.
27. Criticality and Liability
Resource interruption may contribute to Liability.
LIGA™ retains Liability Governance.
Liability evidence may inform consequence context but does not define Resource Criticality by itself.
28. Criticality Does Not Determine Priority
Criticality is highly relevant to downstream Resource prioritization.
But it is not the same thing.
A Resource allocation decision may need to consider:
Criticality; Access rights; Resource availability; competing dependencies; governance obligations; other allocation conditions.
Therefore:
Resource Criticality ≠ Resource Priority.
RDCS provides governed evidence.
RPAS performs Resource Prioritization & Allocation.
29. Criticality Does Not Create Allocation
A function may be highly Resource-critical while available Resource remains insufficient to satisfy every critical dependency.
RDCS does not resolve that competition.
Critical Resource ≠ Automatically Allocated Resource.
30. Recovery Matters
Resource restoration does not always mean immediate operational recovery.
A system may require:
restart; recalibration; reheating or cooling; data recovery; process stabilization; material replacement; inspection.
Therefore:
Resource Restored ≠ Function Fully Recovered.
Recovery time may materially increase Resource Criticality.
31. Criticality Across Time
Criticality may change across different time horizons.
A Resource may be:
non-critical for 30 seconds; important after 10 minutes; critical after 2 hours; system-threatening after 24 hours.
A meaningful Criticality determination therefore requires temporal context.
32. Evidence-Based Criticality
RDCS does not assign Criticality merely because a Resource appears important.
Evidence may include:
technical architecture; operational telemetry; functional testing; historical interruption; engineering analysis; incident evidence; recovery evidence; validated Simulation; Resource substitution evidence.
The evidence required should be proportional to the governance significance of the determination.
33. Criticality Under Uncertainty
Not every Dependency can be known with certainty.
Uncertainty may exist around:
Dependency strength; failure threshold; interruption tolerance; substitute availability; consequence severity; recovery time; propagation.
RDCS preserves that uncertainty rather than hiding it behind a definitive Criticality label.
34. Resource Dependency Profile
The Resource Dependency Profile may contain:
Dependency ID; Resource ID; Demand Profile reference; Dependency Source; Function; Dependency Type; Dependency Boundary; Dependency Strength; Resource Threshold; Degradation Threshold; Failure Threshold; Interruption Tolerance; Substitution Context; Recovery Context; Evidence; Uncertainty; Dependency State; Version.
It establishes the governed Resource relationship before Criticality is finalized.
35. Resource Criticality Profile
The Resource Criticality Profile may contain:
Criticality ID; Dependency ID; Resource ID; Function; Dependency Strength; Consequence State; Consequence Timing; Tolerance State; Substitutability State; Recovery State; Propagation Context; Criticality State; Evidence; Uncertainty; Sufficiency State; Version.
This profile becomes governed evidence for downstream Resource governance.
36. What RDCS Does Not Decide
RDCS does not independently decide:
who may access the Resource; which Demand receives Resource first; how much Resource is allocated; how Resource is consumed; whether Scarcity response should activate; how Resource Recovery should operate; which Resource substitution should be executed; whether the Resource System is resilient; whether long-term Resource use is sustainable.
Those questions belong to subsequent RSGA™ governance spaces.
RDCS establishes the Dependency and Criticality reality those spaces need.
37. Use Case 1 — AI Data Center Electricity Dependency
RDGS establishes electricity Demand for an AI data center.
However, electricity Demand alone does not establish Criticality.
RDCS identifies several Dependency relationships.
AI compute depends directly upon electricity.
Cooling depends upon electricity.
Storage and networking depend upon electricity.
Control infrastructure depends upon electricity.
Battery systems may provide temporary backup.
Local generation may provide alternative supply.
But the existence of backup does not automatically remove electricity Dependency.
RDCS therefore evaluates:
how quickly each function degrades after grid interruption; how much backup duration exists; which functions can reduce operation; which functions must remain continuous; whether backup capacity supports all functions; how long recovery takes after Resource restoration; which downstream services are affected.
A function consuming only a small fraction of total electricity may prove more critical than a much larger deferrable AI workload.
The largest electricity consumer is not automatically the most electricity-critical function.
38. Use Case 2 — Regional Water Dependency
A regional water system supplies:
households; industrial production; agriculture; cooling infrastructure; public services.
RDGS establishes how much water these functions require.
RDCS determines how strongly each depends upon continued water availability.
Agricultural irrigation may represent the largest Demand by volume but tolerate temporary scheduling changes.
Some industrial processes may tolerate reduced production.
Certain cooling systems may have limited interruption tolerance.
Essential public services may require relatively modest quantities but experience severe consequences from sustained interruption.
Alternative water Sources may exist but require transport, treatment, infrastructure, or activation time.
RDCS therefore establishes Resource Criticality from Dependency, tolerance, substitution, consequence, and recovery rather than simply ranking users by water volume.
The largest water Demand is not automatically the most critical water Dependency.
39. 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
40. Canonical Statement
A Resource Dependency & Criticality Standard is a governance standard that establishes how strongly a function, system, process, service, infrastructure, participant, or other governed object relies upon a Resource and determines the governance significance of that reliance through Resource thresholds, degradation response, interruption tolerance, consequence, substitutability, recovery, propagation, evidence, and uncertainty.
Within RSGA™, that function is performed by the Resource Dependency & Criticality Standard (RDCS).
RDCS establishes the transition from:
a governed Resource Demand describing what Resource is required
to:
a governed Resource Dependency and Resource Criticality state describing how much that Resource matters to continued operation and what happens when the Resource is no longer sufficient.
41. Canonical Closing Statement
Resource Demand tells us what is required. It does not tell us what happens when that requirement cannot be met.
RDCS establishes the missing relationship — what depends upon the Resource, how that dependency behaves under degradation or interruption, what alternatives exist, how long consequences can be tolerated, and how critical the Resource becomes before Priority and Allocation decisions are made.
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)