RADM — Resource Availability Determination Module
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Parent Standard: Resource Availability & Capacity Standard (RACS)
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Core Module
Governed Space: Resource Availability Determination Governance
Module ID: RSGA-RACS-RADM-01
Origin ID: OOF-RSGA-RACS-RADM
Version: 1.0
Status: Draft Module
Effective Date: 4 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
RADM — Resource Availability Determination Module governs how the actual availability of a characterized Resource or Resource System is established, evidenced, qualified, bounded, and reassessed so that Resource existence, nominal quantity, Source capacity, installed capacity, theoretical capacity, or declared availability are not treated automatically as actual Resource availability.
RADM establishes the first governed Availability State within RACS.
Resource Existence ≠ Resource Availability.
2. Operational Role
RADM receives a Governed Resource Characterization from RCHS and determines whether, where, when, and under which conditions the Resource is actually available.
Its role is to transform:
Characterized Resource
into:
Governed Resource Availability State
before later RACS modules determine usable capacity, reservation state, temporal availability, location-specific accessibility, and Potentially Allocable Capacity.
RADM answers:
Does the Resource actually exist in an available state? How much is available? Where is it available? When is it available? Under what conditions is it available? What evidence establishes that availability? What uncertainty remains? When must the determination be reassessed?
3. Core Question
What portion of the characterized Resource is actually available under the relevant Resource conditions?
4. Position in RACS Module Flow
RADM — Resource Availability Determination Module → UCCM — Usable Capacity Condition Module → RVCM — Reserved Capacity Module → TAVM — Temporal Availability Module → LAAM — Location & Accessibility Module
RADM establishes the foundational Availability State.
The subsequent modules refine what that availability means for usability, reservation, time, location, accessibility, and downstream capacity governance.
5. Governed Space
RADM governs:
Resource Availability Determination Governance
This space concerns whether a characterized Resource exists in a condition that permits it to be represented as actually available within the governed Resource System.
6. Governed Object
The primary Governed Object is:
The Availability State of a characterized Resource or Resource System.
The object may represent:
Resource stock Resource flow Generation capacity
Storage capacity Processing capacity Transmission capacity Compute capacity Cooling capacity Network capacity Regenerative Resource capacity Recovered Resource capacity Other materially constrained Resource capacity
7. Scope
RADM applies to the determination of actual Resource availability from a sufficiently characterized Resource.
Its Scope includes:
availability identification; available quantity or capacity; availability basis; availability conditions; Source-related availability; Resource-State effects on availability; physical and technical availability constraints; supporting Resource effects; availability evidence; availability uncertainty; availability sufficiency; availability change; availability versioning; availability reassessment.
RADM establishes whether Resource is available.
It does not independently determine:
full Usable Capacity; reservation legitimacy; final temporal availability profile; location-specific accessibility; access authorization; priority; allocation; consumption; scarcity; resilience; sustainability.
8. Entry Requirement
RADM begins with a sufficiently characterized Governed Resource.
Canonical input:
Governed Resource Characterization → RADM Availability Determination
The input should preserve materially relevant:
Resource Boundary Resource Type Constraint Profile Resource State Origin
Source Resource Context Evidence Uncertainty
Availability must not be determined from an unidentified or materially ambiguous Resource.
9. Availability as a Governed State
Availability is not merely a numerical quantity.
It is a governed Resource State established from evidence and applicable conditions.
A complete availability representation may require:
Quantity or capacity Location Time Resource State Source Condition Relevant constraints Evidence basis Uncertainty
10. Resource Existence
Resource Existence establishes that the Resource is present within the relevant Resource reality.
Existence is necessary for ordinary availability.
It is not sufficient.
Existing Resource ≠ Available Resource.
11. Availability Determination
Availability Determination establishes whether and to what extent an existing Resource can legitimately be represented as available within the governed conditions.
Canonical logic:
**Existing Resource
Relevant Conditions Evidence → Availability Determination**
12. Actual Availability
Actual Availability represents Resource availability supported by sufficient evidence applicable to the relevant time, location, boundary, and Resource conditions.
Actual Availability must not be inferred solely from nominal capacity.
13. Nominal Availability
Nominal Availability is an availability representation derived primarily from:
Rated capacity Installed capacity Recorded inventory Contracted capacity Theoretical capacity Declared capacity
Nominal Availability may be useful as an input.
It is not automatically Actual Availability.
Nominal Availability ≠ Actual Availability.
14. Physical Availability
Physical Availability concerns whether the Resource physically exists in a state relevant to the governed Resource System.
Physical presence alone does not establish usability or accessibility.
15. Technical Availability
Technical Availability concerns whether technical conditions permit the Resource or capacity to participate in the relevant Resource System.
Technical Availability may depend upon:
Equipment state System configuration Connectivity Supporting infrastructure Technical compatibility
16. Operational Availability
Operational Availability concerns whether Resource capacity is presently capable of participating in the relevant operational Resource environment.
RADM may establish this availability dimension where necessary.
ORA™ retains general Operational Reality governance.
17. Source Availability
ROSM establishes Source identity and Source structure.
RADM determines whether the relevant Resource is actually available from that Source.
Source Existence ≠ Source Availability.
18. Source Capacity
A Source may possess nominal capacity.
That does not establish that the capacity is currently available.
Source capacity may be constrained by:
Resource input Technical state Infrastructure Time Environment Supporting Resources Maintenance
19. Multi-Source Availability
Where Resource is supplied through multiple Sources, RADM may determine availability by Source.
This prevents aggregate availability from hiding Source-specific constraints.
20. Source Aggregation
Available Resource from multiple Sources may be aggregated only where aggregation is methodologically legitimate.
Aggregation requires sufficient compatibility in:
Resource identity Boundary Time Location Measurement basis Resource function
21. Source Independence
Multiple Sources must not automatically be treated as independent.
Two nominally different Sources may depend upon the same upstream infrastructure, Resource, processor, network, or other common dependency.
RADM preserves this where it materially affects actual availability.
22. Resource-State Availability
RSDM establishes Resource State.
RADM determines whether that state permits the Resource to be represented as available.
Examples:
Stored → potentially available
Degraded → conditionally available
Recoverable → not yet available as recovered Resource
Contaminated → physically existing but availability-limited
Resource State informs Availability; it does not equal Availability.
23. Stored Resource
Stored Resource may contribute to availability.
Its availability may depend upon:
Release capability Resource condition Infrastructure Location Time Technical constraints
Stored Resource ≠ Automatically Available Resource.
24. Residual Resource
Residual Resource may physically exist after use.
Residual existence does not establish current availability for a new function.
Recovery or processing may first be required.
25. Recoverable Resource
A Recoverable Resource has potential to return to useful Resource circulation.
It is not necessarily currently available.
Recoverable Resource ≠ Available Recovered Resource.
26. Recovered Resource
Recovered Resource may become available when it reaches a sufficiently established state for participation in the relevant Resource System.
RRCS governs the Recovery mechanism.
RADM determines the resulting Availability State.
27. Regenerating Resource
A Resource undergoing regeneration must not automatically be counted as currently available merely because future regeneration is expected.
Regenerating Resource ≠ Currently Available Resource.
28. Regenerated Resource
A regenerated Resource may enter Availability Determination when sufficient evidence establishes the relevant regenerated state.
Regeneration does not automatically establish unlimited availability.
29. Degraded Resource
A degraded Resource may remain partly available.
RADM should preserve whether degradation affects:
Quantity Capacity Condition Availability duration Availability certainty
UCCM later determines detailed usable-capacity conditions.
30. Damaged Resource
Damaged Resource may physically exist while being partially or completely unavailable.
The Availability State must follow actual Resource condition.
31. Contaminated Resource
Contamination may reduce or eliminate availability for a particular Resource function.
Physical existence must not be confused with functionally relevant availability.
32. Unavailable Resource
A characterized Resource is Unavailable where sufficient evidence establishes that it cannot presently participate in the relevant Resource System under the governed conditions.
Unavailable does not mean nonexistent.
Unavailable Resource ≠ Nonexistent Resource.
33. Temporarily Unavailable Resource
Resource may be temporarily unavailable due to:
Maintenance Outage Seasonal condition Infrastructure interruption Temporary Source loss Temporary supporting Resource constraint
The expected duration should remain visible where material.
34. Conditionally Available Resource
A Resource is Conditionally Available where availability depends upon one or more explicit conditions.
The conditions must remain attached to the Availability State.
Conditional Availability must not be represented as unconditional availability.
35. Partially Available Resource
A Resource may be partially available.
RADM must support partial availability rather than forcing binary Available / Unavailable classifications.
36. Availability Fraction
Where appropriate, Resource availability may be represented as:
Available quantity Available capacity Available proportion Available flow Available throughput
The native Resource measure should be preserved.
37. Binary Availability
Binary availability may be appropriate only where Resource reality genuinely supports it.
RADM must not force binary representation onto continuous or multidimensional Resource availability.
38. Availability Quantity
Available Quantity represents the physical amount of Resource established as available under the governed conditions.
Quantity must retain its native measurement basis.
39. Availability Capacity
Available Capacity represents the capacity capable of participating in the relevant Resource System.
Capacity may be expressed through:
Power Rate Throughput Storage Compute capability Network capability Processing capability Other Resource-native measures
40. Availability Rate
For flow-constrained Resources, availability may require a rate rather than total quantity alone.
Available Quantity ≠ Available Flow Rate.
41. Availability Duration
Resource availability may have a duration.
Relevant states may include:
Momentary Temporary Sustained Periodic Conditional Unknown
Duration may materially affect downstream governance.
42. Availability Continuity
A Resource may be available intermittently.
RADM should preserve continuity characteristics where necessary for accurate Availability Determination.
Availability continuity does not itself establish long-term sustainability.
43. Spatial Basis
Availability must be associated with location where location materially affects Resource reality.
A Resource available in one place may be unavailable in another.
LAAM later performs detailed Location & Accessibility governance.
44. Temporal Basis
Availability must be associated with the relevant time where availability changes materially through time.
TAVM later performs detailed Temporal Availability governance.
RADM must nevertheless avoid context-free availability claims.
45. Present Availability
Present Availability represents availability under the current governed conditions.
Present Availability ≠ Future Availability.
46. Historical Availability
Historical availability may support analysis.
It must not be represented as current availability.
47. Future Availability
Future availability may be relevant to planning.
Where future availability is predicted:
Predicted Availability ≠ Current Availability.
PGA™ governs Prediction.
48. Availability Window
Resource availability may apply only within a defined time window.
The window must remain attached to the determination where material.
49. Availability Context
RCXM establishes Resource Context.
RADM uses relevant Context to determine availability.
Context may include:
Location Time Quality Condition Infrastructure Environmental conditions Source conditions Supporting Resource conditions
Context informs Availability; Context does not automatically determine Availability.
50. Quality and Availability
Resource quality may affect availability for the governed function.
A Resource may exist in substantial quantity while only a portion meets the required quality condition.
Total Quantity ≠ Available Quality-Compatible Quantity.
51. Condition and Availability
Resource condition may materially affect availability.
RADM must preserve condition-based reductions where evidence supports them.
52. Infrastructure and Availability
Resource availability may depend upon infrastructure.
Relevant infrastructure may include:
Generation Processing Storage Transport Transmission Distribution Cooling Network Recovery
Resource Stock Sufficiency ≠ Infrastructure Availability.
53. Supporting Resource Availability
A Governed Resource may require another Resource to become available.
Examples:
Compute requires electricity.
Cooling may require water and electricity.
Water distribution may require electricity.
Material processing may require energy.
RADM may consume governed availability states of supporting Resources.
54. Dependency-Limited Availability
Where a supporting Resource limits the Governed Resource, the resulting availability reduction should remain traceable.
Example:
**10,000 installed accelerators
electricity sufficient for 7,000 → compute availability cannot automatically remain 10,000**
55. Multi-Dependency Availability
A Resource may depend upon several supporting Resources simultaneously.
Effective availability may therefore depend upon the combined condition of multiple dependencies.
56. Bottleneck Availability
Where one supporting condition limits the Resource, RADM may identify the active Availability bottleneck.
The bottleneck must be evidence-based.
57. Bottleneck Change
The active bottleneck may change.
Removing one constraint may expose another.
RADM therefore supports reassessment after material Resource-system change.
58. Constraint Activation
RTCM identifies Resource constraint characteristics.
RADM determines whether a relevant constraint is currently affecting Availability.
Potential Constraint ≠ Active Availability Constraint.
59. Active Availability Constraint
An Active Availability Constraint is a constraint currently reducing, limiting, conditioning, or preventing Resource availability.
The constraint should remain traceable to its evidence basis.
60. Inactive Constraint
A known Resource constraint may currently be inactive.
It should not reduce current Availability merely because it could become relevant in another state.
61. Constraint Interaction
Multiple active constraints may interact.
Their combined effect may differ from the sum of individual effects.
RADM should preserve material interactions where known.
62. Availability Ceiling
A Resource System may have a maximum availability ceiling under current conditions.
The ceiling may be lower than nominal capacity.
63. Availability Floor
Where appropriate, a Resource System may have a minimum reliably established availability level.
This may be useful where variable conditions prevent a single deterministic capacity claim.
64. Availability Range
Where exact availability cannot legitimately be established, RADM may represent a governed range.
Example:
Available Capacity: 70–80 MW
provided the range has an evidence basis.
Governed Range ≠ False Precision.
65. Availability Threshold
A domain may define thresholds relevant to whether Resource is considered sufficiently available for a particular function.
Thresholds must be explicit and evidence-based.
66. Availability Sufficiency for Function
A Resource may be available but insufficient for a particular required function.
Available Resource ≠ Sufficient Resource for every function.
RADM may preserve this distinction without performing Demand governance.
67. Demand Boundary
RADM determines Resource availability independently from Demand determination.
RDGS governs Demand.
Availability ≠ Demand.
RADM must not reduce Resource availability merely because current demand is low.
Likewise, high demand does not increase physical Resource availability.
68. Scarcity Boundary
Low availability may contribute to scarcity.
RADM does not determine Scarcity State.
Low Availability ≠ Scarcity by definition.
RSCS governs Scarcity & Constraint.
69. Access Boundary
RADM determines whether Resource is available.
It does not determine whether an actor may legitimately access it.
Available Resource ≠ Authorized Resource Access.
RAGS governs Access.
70. Allocation Boundary
Availability does not establish allocation.
Available Resource ≠ Allocated Resource.
RPAS governs Prioritization & Allocation.
71. Reservation Boundary
RADM may identify that capacity is available before detailed reservation treatment.
RVCM governs Reserved Capacity as the dedicated RACS module.
RADM must not convert reservation status into an access-authority determination.
72. Usability Boundary
RADM establishes Availability.
UCCM determines detailed Usable Capacity Conditions.
Available Capacity ≠ Usable Capacity.
This boundary is central to RACS.
73. Temporal Boundary
RADM preserves time sufficient for legitimate Availability Determination.
TAVM governs the detailed temporal availability structure.
74. Location & Accessibility Boundary
RADM preserves location where necessary.
LAAM governs detailed location and practical accessibility.
Available at Source ≠ Accessible at Point of Use.
75. Consumption Boundary
Resource availability does not establish actual Resource consumption.
RCUS governs Consumption & Utilization.
Available ≠ Consumed.
76. Recovery Boundary
RADM may receive Recovered Resource as an input.
RRCS governs the Recovery process.
Recovery Mechanism ≠ Availability Determination.
77. Substitution Boundary
Alternative Resource availability may become an input to substitution governance.
RSFS determines whether substitution is appropriate.
Alternative Resource Availability ≠ Valid Substitution.
78. Resilience Boundary
Availability may affect resilience.
RADM does not determine resilience.
RIRS governs Interdependency & Resilience.
79. Sustainability Boundary
Current availability does not establish long-term sustainability.
Current Availability ≠ Long-Term Sustainability.
RCSS governs Continuity & Sustainability.
80. Value Boundary
Resource availability does not establish Value.
A highly valuable Resource may be unavailable.
An abundant Resource may have low Value in a particular context.
Availability State ≠ Value State.
81. Authority Boundary
Availability does not create authority.
Available Resource ≠ Authority to Use Resource.
GOA™ retains Governance Authority.
82. Availability Evidence
Every material Availability Determination should be supported by evidence proportionate to its governance significance.
Evidence may include:
Direct measurement Sensor data Inventory evidence Technical records Operational records Infrastructure status Source records Specialized Resource determinations
83. Evidence Provenance
Availability evidence should remain traceable to:
Evidence Source Resource Boundary Location Time Method Measurement basis Version where applicable
84. Evidence Freshness
Availability may change rapidly.
Evidence freshness must therefore follow the rate at which the Resource reality can materially change.
Previously Available ≠ Currently Available.
85. Directly Observed Availability
Directly Observed Availability is established through sufficiently direct observation or measurement of the Resource under relevant conditions.
The observation remains bounded by its time and location.
86. Inferred Availability
Availability may be inferred where direct measurement is unavailable.
The inference basis must remain explicit.
Inferred Availability ≠ Directly Observed Availability.
87. Declared Availability
An operator, supplier, institution, or other actor may declare Resource availability.
Declaration is evidence input.
It is not automatically verified fact.
Declared Availability ≠ Verified Availability.
88. Contracted Availability
Contracted Resource capacity may be relevant.
Contractual entitlement or commitment does not establish physical availability.
Contracted Capacity ≠ Physically Available Capacity.
89. Predicted Availability
Predicted future availability must remain distinguishable from current availability.
PGA™ governs the underlying Prediction.
90. Simulated Availability
Simulation may produce potential Availability States.
SIMULOS® governs the simulation.
Simulated Availability ≠ Observed Availability.
91. Assumed Availability
Assumed Availability may be used temporarily where explicitly necessary.
The assumption must remain visible.
Availability Assumption ≠ Availability Evidence.
92. Availability Confidence
Where useful, RADM may represent confidence in the Availability Determination.
Confidence must derive from evidence quality and uncertainty rather than arbitrary scoring.
93. Availability Uncertainty
Material uncertainty may concern:
Quantity Capacity Source Time Location Resource State Constraint activation Supporting Resource availability Evidence freshness
Uncertainty must remain attached to the relevant determination.
94. Uncertainty Propagation
Where Availability uncertainty could materially affect downstream governance, it must propagate.
Uncertain Availability must not become certain capacity downstream without new evidence.
95. Availability Conflict
Availability Conflict exists where credible evidence supports materially incompatible Availability States.
The conflict must remain visible until resolved or legitimately bounded.
96. Conflict Resolution
Canonical logic:
**Availability Claim A
Availability Claim B → Boundary Check → Time Check → Location Check → Measurement-Basis Check → Evidence Comparison → Resolution or Preserved Conflict**
97. Availability Evidence Gap
Where required evidence is missing, RADM should identify the specific gap rather than merely labeling the Resource unavailable.
Unknown Availability ≠ Unavailable Resource.
98. Unknown Availability
Unknown Availability means available evidence is insufficient to establish whether the Resource is available.
It must remain distinct from actual Unavailability.
99. Availability Sufficiency
An Availability Determination is sufficient when available evidence and represented conditions are adequate for the downstream governance purpose.
Sufficiency does not require universal knowledge.
100. Availability Decision States
RADM should support at minimum:
Available
Conditionally Available
Partially Available
Temporarily Unavailable
Unavailable
Availability Evidence-Limited
Availability Conflicted
Availability Unknown
Availability Unresolved
101. Availability State Transition
Resource Availability may transition between states.
Example:
Available → Outage → Temporarily Unavailable → Restoration → Available
Transitions should preserve cause and effective time where material.
102. Availability Change Event
A material Availability Change Event may include:
Source loss Source restoration Outage Maintenance Infrastructure failure Infrastructure restoration Resource degradation Recovery completion Regeneration Supporting Resource loss Supporting Resource restoration
103. Availability Change Detection
Canonical logic:
Existing Availability State → New Evidence / Event
→ Availability Impact Test → Material / Immaterial → State Retained or Revised
104. Availability Reassessment Trigger
Reassessment should occur following material:
Resource-State change Source change Constraint activation Constraint removal Infrastructure change Supporting Resource change Location change Time change Quality change Condition change New evidence Evidence expiry RCHS re-characterization
105. Reassessment Frequency
Reassessment frequency should follow:
Resource volatility Context volatility Evidence freshness Dependency sensitivity Governance consequence
A highly dynamic Resource may require event-driven or frequent reassessment.
106. Availability Versioning
Materially revised Availability States should be versioned where required.
A version should preserve:
Prior state New state Effective time Reason for change Evidence basis Known uncertainty
107. Availability History
Availability History may support:
Audit Trend analysis Planning Prediction inputs Reliability assessment Governance reassessment
Historical states must remain distinguishable from current states.
108. Availability Comparability
Two Availability States may be compared only where relevant conditions are sufficiently aligned.
Relevant alignment may include:
Resource boundary Time Location Measurement basis Resource State Source Context
109. Cross-Time Comparability
Availability at different times may differ materially.
Comparison must preserve temporal context.
110. Cross-Location Comparability
Availability in different locations may differ materially.
Comparison must preserve spatial context.
111. Cross-Source Comparability
Availability from different Sources may have different:
Continuity Capacity Constraint Location Evidence Dependency
Aggregate comparison must preserve material differences.
112. Availability Aggregation
Availability may be aggregated only where:
Resource identity is compatible; measurement bases are compatible; time periods are compatible; locations can legitimately be combined; capacity is not double-counted.
113. Availability Disaggregation
Aggregate availability must be disaggregated where internal differences materially affect downstream governance.
114. Availability Double-Counting
RADM must prevent the same Resource capacity from being counted more than once through:
Multiple Source labels Multiple functional labels Overlapping infrastructure records Duplicate inventories Overlapping capacity claims
115. Native Measurement
Availability should remain expressed in the Resource's appropriate native measurement wherever possible.
Examples:
litres / m³ MW / MWh tonnes units GPU-hours bandwidth throughput
116. Normalization Boundary
RADM does not replace native Resource measurement with a universal normalized Resource unit.
Any later normalization must preserve the native Availability basis.
Native Availability Measurement ≠ Normalized Resource Significance.
117. Availability Profile
The principal RADM output is the:
Resource Availability Profile
It should contain sufficient information to identify:
what Resource is available; how much is available; under which conditions; where; when; from which relevant Source; with which active constraints; on what evidence; with what uncertainty.
118. Availability Profile Minimum Fields
A minimum Resource Availability Profile should support:
Resource ID Characterization Reference Availability State Available Quantity / Capacity Native Measurement Relevant Source Relevant Resource State
Location Reference Temporal Reference Active Availability Constraints Evidence Basis Evidence Time Uncertainty Sufficiency State Version
119. RACS Handoff
RADM does not complete RACS.
Its Resource Availability Profile becomes an input to the remaining RACS modules.
Canonical handoff:
Resource Availability Profile → Usable Capacity Conditions → Reserved Capacity → Temporal Availability → Location & Accessibility → RACS Resource Availability & Capacity Profile
120. Downstream Release
RADM output may proceed when Availability is sufficiently established for further RACS governance.
Conditional progression may occur where unresolved uncertainty remains explicitly preserved.
Progression does not erase Availability uncertainty.
121. Failure Conditions
RADM should not be considered sufficiently completed where:
Resource existence is treated automatically as availability; nominal capacity is represented as actual availability without evidence; installed capacity is treated automatically as available capacity; Source existence is treated automatically as Source availability; stored Resource is treated automatically as immediately available; recoverable Resource is represented as recovered available Resource; predicted availability is represented as current availability; historical availability is represented as current availability; declared availability is represented as verified availability; contracted capacity is represented as physical availability; unknown availability is represented as unavailability; supporting Resource constraints are ignored where material; active constraints are ignored; availability is double-counted; material uncertainty is hidden; availability evidence is materially stale; time or location is omitted where material.
122. Governance Requirements
A conforming RADM implementation must:
1. receive a sufficiently characterized Governed Resource;
2. establish Resource Existence separately from Resource Availability; 3. identify the applicable Availability basis; 4. determine actual available quantity or capacity where possible; 5. preserve native Resource measurement; 6. distinguish nominal from actual availability; 7. preserve relevant Source availability; 8. preserve Resource-State effects on availability; 9. preserve material quality and condition effects; 10. preserve infrastructure effects; 11. preserve supporting Resource effects; 12. identify active Availability constraints; 13. distinguish active from potential constraints; 14. preserve spatial context where material; 15. preserve temporal context where material; 16. distinguish present from future availability; 17. distinguish observed, inferred, declared, contracted, predicted, simulated, and assumed availability; 18. preserve evidence provenance; 19. preserve evidence freshness; 20. preserve material uncertainty; 21. distinguish Unknown from Unavailable; 22. support partial and conditional availability; 23. prevent Availability double-counting; 24. support Availability aggregation only where legitimate; 25. support disaggregation where material; 26. support Availability change detection; 27. support reassessment; 28. support versioning; 29. identify downstream RACS handoff conditions; 30. produce a governed Resource Availability Profile.
123. Governance Logic
Canonical RADM logic:
Governed Resource Characterization → Resource Existence → Availability Basis → Resource-State Check → Source Availability Check → Active Constraint Check → Supporting Resource Check → Spatial & Temporal Context → Actual Availability Determination → Evidence Assessment → Uncertainty Assessment → Sufficiency Determination → Resource Availability Profile
Where evidence is insufficient:
Availability Question → Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Reassessment
Where conditions change:
Existing Availability State → Material Change → Availability Impact Test → Revised State → Version Update → Downstream Reassessment
124. Governance Outputs
RADM may produce:
Resource Availability Profile Availability State Available Quantity Available Capacity Availability Basis Source Availability State Physical Availability State Technical Availability State Operational Availability State Conditional Availability State Partial Availability State Availability Constraint State Availability Evidence State Availability Uncertainty State Availability Conflict State Availability Sufficiency State Availability Change Event Availability Version Reassessment Trigger RACS Handoff State
125. Minimum Implementation Framework
A minimum operational RADM implementation must contain at least eight governed layers.
Layer 1 — Resource Reference
Receive:
Resource ID Governed Resource Characterization Boundary Version
Layer 2 — Existence Check
Determine:
Existing Existence Conditional Existence Evidence-Limited Existence Unresolved
Layer 3 — Availability Basis
Identify relevant:
Quantity Capacity Flow Throughput Source Resource State
Layer 4 — Availability Conditions
Assess:
Physical Technical Infrastructure Supporting Resource Spatial Temporal Quality / Condition
conditions where material.
Layer 5 — Constraint Activation
Determine whether known Resource constraints are:
Active Inactive Conditional Unknown
for current Availability.
Layer 6 — Evidence & Uncertainty
Classify the determination as supported through:
Observed Inferred Declared Contracted Predicted Simulated Assumed
evidence or basis.
Preserve uncertainty.
Layer 7 — Availability Decision
Determine:
Available Conditionally Available Partially Available Temporarily Unavailable Unavailable Evidence-Limited Conflicted Unknown Unresolved
Layer 8 — Governed Output & Reassessment
Produce:
Resource Availability Profile Version Known limitations Reassessment triggers RACS handoff state
Minimum machine-readable logic:
Resource → Characterization → Existence
→ Availability Basis → Conditions[] → Active Constraints[] → Evidence[] → Uncertainty[] → Availability State → Availability Profile
126. Minimum Decision States
At minimum, implementations must distinguish:
Available
Conditionally Available
Partially Available
Temporarily Unavailable
Unavailable
Availability Evidence-Limited
Availability Conflicted
Availability Unknown
Availability Unresolved
These states must not be collapsed into a simple yes/no flag where doing so would materially distort Resource reality.
127. Minimum Evidence Path
Where Availability cannot be established:
Availability Unresolved → Material Missing Evidence → Minimum Evidence Requirement → Evidence Acquisition → Availability Reassessment → Updated Availability State
RADM should seek sufficient evidence for governance rather than unlimited evidence accumulation.
128. Minimum Reassessment Framework
At minimum:
Current Availability Profile → New Evidence / Material Event → Availability Impact Test → State Retained or Revised → Profile Version Update → Downstream RACS Reassessment where required
129. Use Case 1 — AI Compute Availability
An AI data center contains:
10,000 installed accelerators.
Inventory therefore reports nominal compute capacity corresponding to 10,000 units.
RADM does not automatically classify all 10,000 as available.
Evidence establishes:
400 units under maintenance; 200 units technically degraded; electricity conditions currently support operation of 8,900 units; cooling conditions support 9,200 units.
The Resource reality therefore differs materially from installed capacity.
RADM establishes the actual Resource Availability Profile from the governing constraints rather than reporting:
Installed = Available.
UCCM subsequently determines detailed usable-capacity conditions.
RVCM determines reserved capacity.
TAVM determines temporal availability.
LAAM determines location and practical accessibility.
10,000 installed accelerators do not establish 10,000 available accelerators.
130. Use Case 2 — Regional Water Availability
A regional water system identifies a total physical Resource stock of:
100 million m³.
The physical quantity alone does not establish current Resource availability.
Relevant evidence shows that portions of the Resource are:
seasonally constrained; temporarily quality-limited; outside currently functional delivery infrastructure; subject to Source-specific flow constraints.
RADM establishes which portion can legitimately be represented as currently available under the governed conditions.
It does not determine:
who may access the water; which users receive priority; how the Resource should be allocated; whether the region is in a governed Scarcity State; whether current use is sustainable.
Those determinations remain downstream.
Physical Resource stock is the starting point of Availability Determination, not its conclusion.
131. Critical Distinctions
Resource Existence ≠ Resource Availability
Existing Resource ≠ Available Resource
Unavailable Resource ≠ Nonexistent Resource
Unknown Availability ≠ Unavailable Resource
Nominal Availability ≠ Actual Availability
Installed Capacity ≠ Available Capacity
Source Existence ≠ Source Availability
Stored Resource ≠ Automatically Available Resource
Recoverable Resource ≠ Available Recovered Resource
Regenerating Resource ≠ Currently Available Resource
Resource State ≠ Availability State
Potential Constraint ≠ Active Availability Constraint
Available Quantity ≠ Available Flow Rate
Present Availability ≠ Future Availability
Historical Availability ≠ Current Availability
Predicted Availability ≠ Current Availability
Simulated Availability ≠ Observed Availability
Declared Availability ≠ Verified Availability
Contracted Capacity ≠ Physically Available Capacity
Availability Assumption ≠ Availability Evidence
Available Capacity ≠ Usable Capacity
Available Resource ≠ Authorized Resource Access
Available Resource ≠ Allocated Resource
Availability ≠ Demand
Low Availability ≠ Scarcity by definition
Available ≠ Consumed
Current Availability ≠ Long-Term Sustainability
Availability State ≠ Value State
Native Availability Measurement ≠ Normalized Resource Significance
132. Cross-Architecture Boundary
RADM may consume governed inputs from:
RCHS specialized Resource domains technical systems infrastructure systems operational systems evidence systems Prediction systems simulation systems
It does not absorb their governance domains.
PGA™ governs Prediction.
SIMULOS® governs Simulation.
ORA™ governs general Operational Reality.
ADIT® governs Audit and Evidence Governance.
VALIDOS™ governs general Validation Governance.
GOA™ governs Governance Authority.
RADM governs only Resource Availability Determination within RACS.
133. 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 hydrological system may establish physical water conditions.
A grid system may establish electricity-system conditions.
A compute platform may establish hardware state.
A storage system may establish stored Resource quantity.
RADM consumes those governed outputs to determine Resource Availability.
It does not absorb the mechanisms that produced them.
134. Canonical Boundary
RADM governs whether and to what extent a sufficiently characterized Resource or Resource System is actually available under the relevant physical, technical, spatial, temporal, infrastructural, Source, Resource-State, and supporting Resource conditions.
It does not independently determine full Usable Capacity, reservation legitimacy, final temporal availability structure, location-specific accessibility, access authorization, prioritization, allocation, consumption, scarcity, resilience, or sustainability.
Its governed output is the Resource Availability Profile required for subsequent RACS governance.
135. Canonical Closing Statement
A Resource is not available because a record says it exists, because infrastructure says it is installed, or because a Source says it can supply it.
RADM establishes availability from the Resource reality that can actually be evidenced.