Resource Availability & Capacity Standard (RACS)
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Parent Standard
Governed Space: Resource Availability & Capacity Governance
Standard ID: RSGA-RACS-02
Origin ID: OOF-RSGA-RACS
Version: 1.0
Status: Draft Standard
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
Resource Availability & Capacity Standard (RACS) is the Parent Standard within RSGA™ that governs how the actual availability, accessibility, usable capacity, reserved capacity, and potentially allocable capacity of a characterized Resource or Resource System are determined across relevant spatial, temporal, technical, physical, and operational conditions.
RACS establishes what Resource quantity or capacity is actually capable of participating in downstream Resource governance.
It prevents Resource existence, nominal stock, installed capacity, theoretical capacity, Source capacity, or aggregate inventory from being treated automatically as available, usable, or potentially allocable Resource capacity.
Resource existence does not imply Resource availability, and Resource availability does not imply allocable capacity.
2. Operational Role
RCHS establishes what Resource is being governed.
RACS determines what portion of that characterized Resource is actually available under the conditions relevant to the governed Resource System.
Its operational role is to distinguish:
What exists What is available What is practically accessible What is technically or physically usable What is reserved What may potentially enter allocation governance
RACS prevents nominal Resource quantity from becoming a false representation of actual Resource capacity.
3. Core Question
What Resource quantity or capacity is actually available, accessible, usable, reserved, and potentially allocable under relevant temporal and spatial conditions?
4. Position in RSGA™ Governance Flow
Resource Characterization → Availability & Capacity → Demand → Dependency & Criticality → Access → Prioritization & Allocation → Consumption & Utilization → Scarcity & Constraint → Recovery & Circularity → Substitution & Flexibility → Interdependency & Resilience → Continuity & Sustainability
RACS is the second Parent Standard.
It receives the Governed Resource Characterization established by RCHS and converts that characterization into a governed Resource Availability & Capacity State.
5. Governed Space
RACS governs:
Resource Availability & Capacity Governance
This includes determination of the Resource quantity or capacity that is actually available, practically accessible, technically or physically usable, reserved, and potentially capable of entering downstream allocation governance.
6. Governed Object
The primary Governed Object is:
The availability and capacity state of a characterized Resource or Resource System.
This may concern:
Physical Resource stock Resource flow Generation capacity Processing capacity Storage capacity Transmission capacity Network capacity Compute capacity Cooling capacity Recovery-derived Resource capacity Regenerative Resource capacity Other materially constrained Resource capacity
7. RCHS Entry Requirement
RACS begins from a sufficiently characterized Resource.
Canonical entry:
Governed Resource Characterization → Availability & Capacity Determination
The characterization should preserve, where material:
Boundary Resource Type Constraint characteristics Resource State Origin Source Context Uncertainty
RACS must not silently replace missing Resource Characterization with assumed Resource availability.
8. Availability Definition
Resource Availability represents the quantity or capacity of a Governed Resource that exists under conditions permitting it to be considered for practical Resource use or subsequent governance within the relevant time, location, and Resource context.
Availability is not synonymous with existence.
Existing Resource ≠ Available Resource.
9. Capacity Definition
Resource Capacity represents the amount, rate, throughput, capability, volume, stock, or other native Resource measure through which a Resource can potentially support relevant Resource functions.
Capacity may be:
Physical Technical Operational Flow-based Storage-based Processing-based Regenerative Infrastructure-based
Capacity must be interpreted according to the Resource reality.
10. Stock vs Capacity
Resource stock and Resource capacity must remain distinguishable.
A large physical stock may have low usable delivery capacity.
A relatively small stock may support high short-term flow.
Resource Stock ≠ Resource Capacity.
11. Nominal Resource
A nominal Resource quantity represents stated, rated, installed, recorded, designed, theoretical, or otherwise non- adjusted Resource quantity or capacity.
Nominal quantity is an input.
It is not the final RACS determination.
Nominal Resource ≠ Available Resource.
12. Installed Capacity
Installed Capacity represents capacity physically or technically installed within a system.
Installed capacity may include capacity that is:
Offline Under maintenance Degraded Disconnected Reserved Unsupported by required dependencies Otherwise unusable
Therefore:
Installed Capacity ≠ Available Capacity.
13. Theoretical Capacity
Theoretical Capacity represents a maximum or modeled capacity under defined assumptions.
It must not be represented as actual capacity unless the relevant assumptions hold.
Theoretical Capacity ≠ Actual Available Capacity.
14. Rated Capacity
Rated Capacity may describe designed or certified capacity under defined conditions.
Actual Resource conditions may differ.
RACS preserves the distinction between rating and current Resource reality.
15. Gross Capacity
Gross Capacity represents Resource capacity before relevant constraints, reservations, losses, accessibility limitations, or usability conditions are applied.
Gross Capacity is not automatically usable or allocable.
16. Available Capacity
Available Capacity is the Resource capacity currently or relevantly capable of participating in the Resource System after material conditions affecting availability are considered.
Available Capacity must remain associated with:
Time Location Resource State Relevant constraints Evidence
17. Practical Accessibility
RACS governs practical Resource Accessibility as the physical, technical, infrastructural, spatial, or operational ability to reach or obtain the Resource.
This must remain separate from governance authorization.
Resource Accessibility ≠ Resource Access Authorization.
RAGS governs who may legitimately access the Resource.
18. Accessible Resource
A Resource may be available in principle while not practically accessible to the relevant system.
Examples include:
Water without delivery infrastructure Electricity behind transmission constraints Material in inaccessible storage Compute in disconnected infrastructure
Therefore:
Available Resource ≠ Accessible Resource.
19. Usable Resource
A Resource is Usable where its relevant condition, quality, configuration, capability, and supporting dependencies allow it to perform the required Resource function.
Accessible Resource ≠ Usable Resource.
20. Usable Capacity
Usable Capacity is the portion of Resource capacity capable of performing the relevant function under the applicable Resource conditions.
Usability may depend upon:
Quality Condition Technical compatibility Infrastructure Supporting Resources Location Time Operational configuration
21. Allocable Capacity
Allocable Capacity represents capacity that could legitimately enter allocation governance after relevant availability, accessibility, usability, reservation, and applicable constraint conditions are represented.
RACS identifies:
Potentially Allocable Capacity
It does not determine the final allocation.
22. Potentially Allocable Capacity
Potentially Allocable Capacity is Resource capacity sufficiently available, accessible, usable, and not otherwise excluded from consideration such that it may proceed into downstream Access, Priority, and Allocation governance.
Potentially Allocable ≠ Allocated.
23. Availability State Progression
A conceptual Resource progression may include:
Existing Resource → Available Resource → Accessible Resource → Usable Resource / Capacity
→ Reserved / Unreserved State → Potentially Allocable Capacity
This is a governance progression.
It is not a universal physical formula.
24. Non-Linear Availability Logic
Availability conditions may overlap.
A Resource may simultaneously be:
Available but reserved
Accessible but unusable
Usable but temporally unavailable
Technically available but spatially inaccessible
RACS must therefore avoid simplistic subtraction models where Resource reality is multidimensional.
25. Reservation State
RACS records Reserved Capacity as a Resource capacity state.
It does not determine whether the reservation is legitimate.
Reserved Capacity State ≠ Reservation Authority.
Reservation legitimacy and conditions belong to Resource Access Governance.
26. Reserved Capacity
Reserved Capacity is capacity identified as withheld, protected, designated, or otherwise unavailable for general allocation under an existing reservation condition.
RACS records the capacity consequence of reservation.
27. Unreserved Capacity
Unreserved Capacity is Resource capacity not currently represented as reserved.
Unreserved does not automatically mean allocable.
Other constraints may still apply.
Unreserved Capacity ≠ Allocable Capacity.
28. Reservation Overlap
Multiple reservations must not result in double-counting of the same Resource capacity.
Where reservation claims overlap, RACS must preserve the conflict or uncertainty rather than inflate Reserved Capacity.
29. Capacity Double-Counting
Resource capacity must not be counted multiple times merely because it can support different functions.
Example:
One battery capacity may be described as:
Emergency Reserve Grid Balancing Capacity Peak Support Capacity
If the same physical capacity cannot perform all functions simultaneously, it must not be represented as three independent capacities.
Multiple Resource Functions ≠ Multiple Independent Resource Capacities.
30. Availability Double-Counting
The same Resource quantity must not appear as simultaneously available through multiple Source representations where those representations refer to the same underlying Resource.
RACS must preserve Source identity from ROSM where material.
31. Temporal Availability
Resource availability is time-dependent.
RACS may determine:
Immediate Availability Current Availability Peak Availability Scheduled Availability Seasonal Availability Future Availability Recovery-Dependent Availability Regeneration-Dependent Availability
These states must remain distinguishable.
32. Current Availability
Current Availability represents Resource capacity available under current governed conditions.
Current Availability ≠ Future Availability.
33. Immediate Availability
Immediate Availability represents Resource capable of being used or activated within the relevant immediate operational horizon.
A Resource may be available eventually but not immediately.
34. Scheduled Availability
Resource capacity may become available according to a defined schedule.
Scheduled Availability must remain distinguishable from current availability.
35. Seasonal Availability
Some Resources have materially seasonal availability.
Annual totals must not conceal seasonal capacity constraints.
Annual Resource Quantity ≠ Seasonal Availability.
36. Peak Availability
Peak Availability represents Resource capacity available during periods of peak requirement or peak Resource-system stress.
Average capacity does not establish peak capacity.
Average Availability ≠ Peak Availability.
37. Future Availability
Future Availability must be represented according to the evidence basis supporting it.
Where future availability depends upon prediction:
Predicted Availability ≠ Current Availability.
PGA™ governs the Prediction methodology.
38. Conditional Availability
A Resource may be available only when defined conditions hold.
Conditions may include:
Infrastructure status Weather Source activation Supporting Resource availability Maintenance completion Recovery completion Regeneration Operational configuration
Conditional availability must retain its activation conditions.
39. Availability Duration
Availability may be:
Momentary Short-term Sustained Seasonal Long-term Conditional Unknown
Duration may materially alter Resource governance significance.
40. Availability Window
A Resource may be available only during a defined time window.
RACS must preserve that window where downstream use depends upon timing.
41. Spatial Availability
Resource availability is location-dependent where Resource movement, transmission, transport, infrastructure, or physical location matters.
Availability at Source ≠ Availability at Point of Use.
42. Source Availability
A Resource may be available at its Source.
This does not establish deliverability to the relevant consuming system.
43. Delivered Availability
Delivered Availability represents Resource capacity capable of reaching the relevant location through the required pathway.
Source capacity and delivered capacity must remain separate.
Source Capacity ≠ Delivered Availability.
44. Location-Specific Capacity
Resource capacity may differ by location because of:
Transmission Distribution Transport Storage Processing Infrastructure Environmental conditions Technical constraints
RACS must preserve location-specific Resource reality.
45. Transfer Constraint
A Resource may physically exist but be constrained in movement between locations.
Examples:
Transmission bottleneck Pipeline limit Transport capacity Network bottleneck Material logistics constraint
RACS represents the resulting availability consequence.
46. Flow Availability
Flow-constrained Resources require availability representation that includes rate and continuity.
A total Resource quantity may be sufficient while flow capacity remains insufficient.
Available Quantity ≠ Available Flow Rate.
47. Throughput Capacity
Processing, transport, network, recovery, or other Resource Systems may depend upon throughput.
RACS may determine Resource capacity in appropriate native throughput measures.
48. Storage Availability
Stored Resource must not automatically be treated as immediately available.
Availability may depend upon:
Release capacity Discharge rate Infrastructure Reservation Resource condition Location Time
49. Generation Availability
Installed generation does not establish available generation.
Availability may depend upon:
Resource input Maintenance Environmental conditions Technical condition Supporting infrastructure Grid conditions
50. Compute Availability
Installed compute hardware does not establish usable compute capacity.
RACS may require consideration of:
Hardware condition Power Cooling Storage Network Configuration Reservation Maintenance
Installed Compute ≠ Available Compute ≠ Usable Compute.
51. Network Availability
Nominal network capacity may differ from practically available network capacity due to:
Congestion Routing Infrastructure state Location Reservation Failure conditions
RACS preserves the actual capacity distinction.
52. Cooling Availability
Installed cooling infrastructure does not establish available cooling capacity.
Cooling may depend upon:
Electricity Water Ambient conditions Equipment state Maintenance Operational configuration
53. Regenerative Resource Availability
Regenerative Resources require availability determinations that preserve current stock and regeneration conditions.
Regenerative Capacity ≠ Unlimited Availability.
RACS does not determine sustainable extraction.
54. Recovery-Derived Availability
Recovered Resource may contribute to availability only after it reaches a state capable of entering the relevant Resource System.
Recoverable Resource ≠ Available Recovered Resource.
55. Secondary Resource Availability
Secondary Resource may become available following recovery, processing, validation, transport, or other necessary conditions.
Secondary status alone does not establish availability.
56. Quality-Constrained Availability
A Resource may exist in sufficient quantity while only part meets required quality conditions.
RACS may therefore distinguish:
Total Resource Quantity Quality-Compatible Resource Quantity
Quantity Available ≠ Quality-Compatible Capacity.
57. Condition-Constrained Availability
Degraded, damaged, contaminated, or otherwise condition-limited Resource may reduce actual usable capacity.
Resource condition must therefore be reflected where material.
58. Dependency-Constrained Availability
A Resource may depend upon another Resource to become available.
Example:
Compute Capacity depends upon Electricity + Cooling + Network
If a supporting Resource is constrained, available compute capacity may fall even when hardware remains unchanged.
59. Infrastructure-Constrained Availability
Resource availability may be limited by infrastructure rather than Resource stock.
Resource Stock Sufficiency ≠ Infrastructure Sufficiency.
RACS must preserve this distinction.
60. Bottleneck Capacity
Where multiple capacity layers operate sequentially, effective availability may be constrained by a bottleneck.
RACS may identify the effective bottleneck where evidence supports it.
It must not assume that nominal capacities are additive.
61. Bottleneck Migration
When one bottleneck is removed, another may become limiting.
RACS must therefore support reassessment after material capacity changes.
Capacity Expansion at one layer does not guarantee equivalent Resource Availability expansion.
62. Supporting Resource Availability
Where availability depends materially upon supporting Resources, their relevant governed states may become inputs.
RACS does not take ownership of those Resources.
It determines their effect on the availability of the Governed Resource.
63. Dependency Chain Availability
Availability may propagate through a dependency chain.
Example:
Water Availability → Cooling Availability → Compute Availability
A downstream Resource may therefore have lower effective availability than its own nominal capacity suggests.
64. Availability Constraint Profile
RACS may establish an Availability Constraint Profile identifying conditions currently limiting Resource availability.
This Profile may include:
Physical constraint Technical constraint Infrastructure constraint Spatial constraint Temporal constraint Quality constraint Condition constraint Dependency constraint
RTCM identifies general Resource constraint characteristics.
RACS determines their current relevance to Availability & Capacity.
65. Availability Reduction
Where Resource capacity is reduced from a nominal or prior level, RACS should identify the material cause where evidence supports it.
Reduction may arise from:
Outage Maintenance Degradation Source loss Infrastructure limit Supporting Resource constraint Reservation Seasonality Recovery delay
66. Availability Increase
Availability may increase through:
New Source Recovery Regeneration Infrastructure restoration Capacity expansion Reservation release Constraint removal
An increase must be evidenced rather than assumed from planned capacity.
67. Planned Capacity
Planned capacity must remain separate from existing capacity.
Planned Capacity ≠ Installed Capacity ≠ Available Capacity.
68. Capacity Under Construction
Capacity under construction may be relevant to future planning.
It must not be represented as current available capacity.
69. Commissioned Capacity
Commissioned capacity may become an input to RACS.
Commissioning does not automatically establish full usability under every Resource condition.
70. Decommissioned Capacity
Decommissioned capacity must not remain within current available capacity merely because it exists historically in inventory records.
71. Capacity Degradation
Capacity may decline over time.
Examples include:
Battery degradation Equipment degradation Network degradation Storage degradation Processing degradation
RACS must use current governed capacity where material.
72. Capacity Restoration
Repair, maintenance, recovery, replacement, or regeneration may restore capacity.
Restored capacity should enter the availability state only when sufficient evidence establishes the restoration.
73. Buffer Capacity
Buffer capacity may support availability during disruption or variability.
RACS may identify the capacity state.
RIRS governs broader resilience significance.
74. Reserve Capacity
Reserve capacity is capacity maintained for defined contingencies or purposes.
Reserve must not automatically be included in general potentially allocable capacity.
Reserve Capacity ≠ General Allocation Capacity.
75. Emergency Capacity
Emergency capacity may become available only under defined activation conditions.
Its existence must not be treated as ordinary Resource availability.
76. Redundant Capacity
Redundant capacity may support continuity.
Redundancy does not automatically increase usable capacity for normal operation where the redundant capacity must remain protected for failure conditions.
77. Availability and Resource State
RSDM establishes Resource State.
RACS determines how that state affects availability.
Examples:
Stored → potentially available
Reserved → available but restricted from general allocation
Degraded → partially usable
Recoverable → not yet available as recovered Resource
Resource State informs Availability; it does not replace Availability determination.
78. Availability and Source
ROSM establishes Origin & Source.
RACS determines whether capacity from those Sources is actually available.
Source Existence ≠ Source Availability.
79. Availability and Context
RCXM establishes Resource Context.
RACS uses that Context to determine actual Availability & Capacity.
Context shapes Availability but does not predetermine it.
80. Availability and Demand
RACS determines supply-side Resource Availability & Capacity.
RDGS determines Demand.
Availability ≠ Demand.
The two later interact in Resource governance without becoming the same governed state.
81. Availability and Dependency
Resource availability does not establish dependency.
A highly available Resource may be critically depended upon.
A constrained Resource may have low dependency.
RDCS governs Dependency & Criticality.
82. Availability and Access
RACS governs practical accessibility.
RAGS governs legitimate access.
Physical / Technical Accessibility ≠ Governance Access Authorization.
This distinction is mandatory.
83. Availability and Priority
RACS does not determine priority.
Potentially Allocable Capacity becomes an input to downstream prioritization.
Available Capacity ≠ Priority.
84. Availability and Allocation
RACS does not allocate Resource.
RPAS determines prioritization and allocation.
Potentially Allocable Capacity ≠ Allocation Decision.
85. Availability and Consumption
Available capacity does not establish actual consumption.
RCUS governs Consumption & Utilization.
Available ≠ Consumed.
86. Availability and Scarcity
Low availability may contribute to scarcity.
It does not alone establish Scarcity State because scarcity also depends upon demand, dependency, context, and other governed conditions.
Low Availability ≠ Scarcity by definition.
RSCS governs Scarcity & Constraint.
87. Availability and Recovery
Recovery may create future or current Resource availability.
RRCS governs Recovery & Circularity.
RACS determines when recovered Resource becomes actually available within the relevant Resource System.
88. Availability and Substitution
Alternative Resource or Source availability may affect substitution options.
RSFS governs the substitution decision.
Alternative Availability ≠ Valid Substitution.
89. Availability and Resilience
Reserve, buffer, redundant, or diversified capacity may support resilience.
RACS establishes the capacity state.
RIRS determines resilience.
Reserve Capacity ≠ Resilience by itself.
90. Availability and Sustainability
High current availability does not establish sustainability.
A Resource may be abundant today while future continuity is deteriorating.
Current Availability ≠ Long-Term Sustainability.
RCSS governs Continuity & Sustainability.
91. Availability and Value
Resource availability does not establish Resource Value.
Likewise, high Value does not establish availability.
Availability State ≠ Value State.
92. Availability and Authority
RACS determines Resource Availability & Capacity.
It does not establish authority over that Resource.
Available Resource ≠ Authorized Resource Use.
GOA™ retains Governance Authority.
93. Availability Evidence
Availability determinations must be supported by evidence appropriate to the Resource.
Evidence may include:
Measurement Inventory Sensor data Infrastructure status Technical capacity records Source records Operational records Storage records Recovery records Specialized domain outputs
94. Capacity Evidence
Capacity claims must identify their basis where material.
Examples:
Installed rating Measured capacity Observed throughput Technical assessment Operational capacity record
Nominal claims must not silently become actual capacity.
95. Availability Evidence Freshness
Availability can change rapidly.
Evidence freshness must therefore follow Resource volatility and governance significance.
Previously Available ≠ Currently Available.
96. Availability Provenance
A governed Availability & Capacity determination should remain traceable to:
Resource ID Characterization reference Boundary version Source State Context Evidence Measurement time Location Relevant constraints Determination version
97. Observed Availability
Observed Availability is supported by direct or sufficiently proximate evidence of Resource availability.
Observation remains bounded by its time, location, and conditions.
98. Inferred Availability
Availability may be inferred from evidence.
The inference basis must remain traceable.
Inferred Availability ≠ Directly Observed Availability.
99. Declared Availability
An operator, supplier, or other actor may declare capacity available.
Declaration alone does not establish independent availability.
Declared Availability ≠ Verified Availability.
100. Predicted Availability
Predicted future Resource availability must remain explicitly predicted.
Predicted Availability ≠ Current Availability.
PGA™ governs the underlying Prediction.
101. Simulated Availability
Simulation may produce possible availability states under defined scenarios.
Simulated Availability ≠ Observed Availability.
SIMULOS® retains Simulation Governance.
102. Availability Assumption
Assumed availability must remain identified as an assumption where material.
Availability Assumption ≠ Availability Evidence.
103. Availability Uncertainty
RACS must support uncertainty.
Possible states include:
Availability Established Availability Conditionally Established Availability Evidence-Limited Availability Conflicted Availability Unresolved
104. Capacity Uncertainty
Capacity may be uncertain due to:
Incomplete measurement Variable operating conditions Unknown degradation Unknown Source contribution
Dependency uncertainty Future conditions
Uncertainty must propagate downstream where material.
105. Availability Conflict
Conflicting availability evidence must not be resolved through arbitrary preference.
Conflict should trigger:
Evidence comparison Time check Location check Boundary check Measurement-basis check Reassessment
106. Availability Sufficiency
An Availability & Capacity determination is sufficient when enough materially relevant information exists to support downstream Resource governance.
Possible states:
Availability & Capacity Sufficient Conditionally Sufficient Partially Sufficient Evidence-Limited Conflicted Insufficient Unresolved
107. Capacity Accounting
Where Resource quantity or capacity can be meaningfully accounted for, RACS should preserve relationships between relevant capacity states.
Accounting must avoid:
Double-counting Overlapping reservations Duplicate Source capacity Nominal/actual conflation Current/future conflation
108. Capacity Reconciliation
Where multiple capacity records describe the same Governed Resource, RACS should reconcile them according to:
Boundary Time Location Resource State Measurement basis Source Function
Unreconciled material differences must remain explicit.
109. Capacity Aggregation
Capacity may be aggregated only where component capacities can legitimately be combined.
Capacity Aggregation requires compatibility of Resource function, time, location, and independence.
Nominally similar capacities must not be added automatically.
110. Capacity Disaggregation
Aggregate capacity must be disaggregated where internal differences materially affect availability.
Relevant differences may include:
Location Source Reservation Quality Condition Resource State Time Supporting dependency
111. Availability Comparability
Two Resource Availability determinations are comparable only where relevant conditions are sufficiently aligned.
Relevant alignment may include:
Resource boundary Time Location Resource State Capacity basis Quality Source Context
112. Capacity Comparability
Two systems reporting the same nominal capacity may have materially different actual capacity.
Same Nominal Capacity ≠ Same Available Capacity.
Comparisons must preserve the capacity basis.
113. Availability Change
Availability may change without Resource identity changing.
Examples:
Source outage Infrastructure repair Reservation release Seasonal shift
Resource degradation Recovery completion
RACS must support dynamic state updates.
114. Capacity Change
Capacity may change through:
Expansion Degradation Maintenance Repair Decommissioning Recovery Infrastructure change Supporting Resource change
Material changes require reassessment.
115. Reassessment Trigger
RACS reassessment should occur following material:
Source addition or loss Outage Maintenance Degradation Infrastructure change Reservation change Resource State change Location change Seasonal change Recovery Regeneration Supporting Resource change New evidence Evidence expiry RCHS re-characterization
116. Reassessment Logic
Canonical logic:
Existing Availability & Capacity State → New Evidence / Material Change → Availability Impact Test → State Retained or Revised → Version Update → Downstream Reassessment Trigger where material
117. Availability Versioning
Material changes should produce distinguishable Availability & Capacity State versions where required.
The version should preserve:
Previous state Revised state
Change reason Effective time Evidence change Affected capacity Known downstream implications
118. Availability History
Historical Availability & Capacity States may be preserved for trend, comparison, audit, and future governance.
Historical availability must not be represented as current availability.
119. Availability State Model
RACS may represent the Resource through states such as:
Existing Nominal Available Accessible Usable Reserved Unreserved Potentially Allocable Unavailable Conditionally Available Evidence-Limited
The appropriate state structure depends upon Resource reality.
120. Availability & Capacity Profile
The principal RACS output is the:
Resource Availability & Capacity Profile
The Profile may contain:
Resource ID Characterization reference Nominal Resource quantity/capacity Available capacity Accessibility state Usable capacity Reserved capacity Potentially allocable capacity Temporal availability Spatial availability Source availability Delivered availability Constraint profile Evidence Uncertainty Sufficiency state Version Reassessment triggers
121. Governance Requirements
A conforming RACS implementation must:
1. begin from a sufficiently characterized Governed Resource; 2. distinguish Resource existence from Resource availability; 3. distinguish stock from capacity; 4. distinguish nominal, installed, rated, theoretical, and gross capacity from actual available capacity where applicable; 5. determine practical Resource accessibility; 6. distinguish practical accessibility from governance access authorization; 7. determine usable Resource capacity where applicable; 8. preserve quality and condition constraints; 9. preserve temporal availability; 10. preserve spatial availability; 11. distinguish Source availability from delivered availability; 12. preserve flow and throughput constraints where relevant; 13. preserve storage and release constraints; 14. preserve supporting Resource dependencies where material; 15. identify reserved capacity; 16. distinguish Reserved Capacity State from reservation authority; 17. prevent reservation double-counting; 18. prevent capacity double-counting; 19. determine Potentially Allocable Capacity without making allocation decisions; 20. distinguish current from future availability; 21. distinguish observed, inferred, declared, predicted, simulated, and assumed availability; 22. preserve material uncertainty; 23. preserve evidence and evidence freshness; 24. support capacity reconciliation; 25. support capacity aggregation only where legitimate; 26. support disaggregation where material; 27. support dynamic reassessment; 28. support Availability & Capacity versioning; 29. identify downstream reassessment triggers; 30. produce a governed Resource Availability & Capacity Profile.
122. Governance Logic
Canonical RACS governance logic:
Governed Resource Characterization → Resource Existence → Nominal / Relevant Capacity → Availability Conditions → Practical Accessibility → Usability Conditions → Available / Usable Capacity → Reservation State → Potentially Allocable Capacity → Evidence & Uncertainty → Sufficiency Determination → Resource Availability & Capacity Profile
Where uncertainty remains:
Availability Uncertainty → Missing Evidence → Additional Evidence → Reassessment
Where material change occurs:
Existing Availability State → Material Change → Availability Impact Test
→ Revised State → Downstream Reassessment
123. Governance Outputs
RACS may produce:
Resource Availability State Resource Capacity State Available Capacity State Practical Accessibility State Usable Capacity State Reserved Capacity State Unreserved Capacity State Potentially Allocable Capacity State Temporal Availability State Spatial Availability State Source Availability State Delivered Availability State Availability Constraint Profile Availability Evidence State Availability Uncertainty State Availability & Capacity Sufficiency State Availability & Capacity Profile Availability Version Reassessment Trigger Downstream Reassessment Trigger
124. Critical Distinctions
Resource Existence ≠ Resource Availability
Resource Stock ≠ Resource Capacity
Nominal Resource ≠ Available Resource
Installed Capacity ≠ Available Capacity
Rated Capacity ≠ Actual Capacity
Theoretical Capacity ≠ Actual Available Capacity
Gross Capacity ≠ Usable Capacity
Available Resource ≠ Accessible Resource
Accessible Resource ≠ Usable Resource
Resource Accessibility ≠ Resource Access Authorization
Usable Capacity ≠ Allocable Capacity
Potentially Allocable ≠ Allocated
Reserved Capacity State ≠ Reservation Authority
Unreserved Capacity ≠ Allocable Capacity
Reserve Capacity ≠ General Allocation Capacity
Source Existence ≠ Source Availability
Source Capacity ≠ Delivered Availability
Available Quantity ≠ Available Flow Rate
Stored Resource ≠ Immediately Available Resource
Recoverable Resource ≠ Available Recovered Resource
Current Availability ≠ Future Availability
Average Availability ≠ Peak Availability
Predicted Availability ≠ Current Availability
Simulated Availability ≠ Observed Availability
Declared Availability ≠ Verified Availability
Availability Assumption ≠ Availability Evidence
Availability ≠ Demand
Availability ≠ Dependency
Available Capacity ≠ Priority
Potentially Allocable Capacity ≠ Allocation Decision
Available ≠ Consumed
Low Availability ≠ Scarcity by definition
Reserve Capacity ≠ Resilience
Current Availability ≠ Long-Term Sustainability
Availability State ≠ Value State
Available Resource ≠ Authorized Resource Use
125. Cross-Architecture Boundary
RACS may consume operational, technical, scientific, infrastructure, evidence, Prediction, simulation, and specialized Resource inputs.
It does not absorb their governance domains.
RCHS governs Resource Characterization.
GOA™ governs Governance Authority.
ORA™ governs general Operational Reality.
ADIT® governs Audit and Evidence Governance.
VALIDOS™ governs general Validation Governance.
PGA™ governs Prediction.
SIMULOS® governs Simulation.
VEGA™ governs justified Resource consumption within Intelligence Value Execution.
Specialized Resource architectures govern Resource-specific operational mechanisms.
RACS governs the Resource Availability & Capacity state required for downstream RSGA™ governance.
126. Boundary with Resource Access Governance
RACS may determine that Resource is practically accessible.
It does not determine whether an actor is legitimately permitted to access it.
Resource Accessibility ≠ Resource Access Authorization.
RAGS governs:
Eligibility Access conditions Reservation governance Restriction Withdrawal Access conflict
This boundary must remain explicit.
127. Boundary with Resource Prioritization & Allocation
RACS may determine Potentially Allocable Capacity.
It does not decide:
Who receives it How much each actor receives Which dependency has priority Whether reallocation should occur
Those determinations belong to RPAS.
Capacity Eligibility for Allocation ≠ Allocation Decision.
128. Boundary with VEGA™
VEGA™ may determine whether Resource consumption by an intelligent system is justified relative to validated Value.
RACS determines whether the Resource capacity actually exists and is available within RSGA™.
Resource Justification ≠ Resource Availability.
Resource Justification ≠ Resource Entitlement.
Resource Justification ≠ Resource Allocation Authority.
129. Specialized Resource Domain Boundary
RACS remains Resource-agnostic.
Specialized domains may determine:
Hydrological capacity Grid capacity Battery capacity Compute capacity Material processing capacity Biological stock capacity Network capacity
RACS consumes those governed determinations and applies common Availability & Capacity governance.
Specialized Resource Reality → RACS Availability Input
RACS does not replace specialized Resource science or engineering.
130. 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 grid model may establish transmission capacity.
A hydrological model may establish water flow.
A compute system may establish hardware capacity.
A biological methodology may establish Resource stock.
RACS consumes those outputs to determine Resource Availability & Capacity.
It does not govern the originating mechanisms.
131. Reassessment Principle
Resource Availability & Capacity is dynamic.
A valid determination remains valid only while its material conditions remain sufficiently unchanged.
A previously valid Availability State does not remain valid after material Resource change merely because the Resource retains the same name or nominal capacity.
132. Canonical Boundary
Resource Availability & Capacity Standard (RACS) governs what quantity or capacity of a characterized Resource is actually available, practically accessible, usable, reserved, and potentially capable of entering downstream allocation governance under relevant spatial, temporal, technical, physical, and operational conditions.
It does not establish:
Access entitlement Allocation priority Allocation authority Actual allocation Consumption justification Scarcity response Resilience Sustainability
133. Canonical Closing Statement
A Resource cannot support a dependency merely because it exists on paper, appears in inventory, or is installed in infrastructure.
RACS establishes what Resource capacity is actually there, actually reachable, actually usable, and actually capable of proceeding into governance.
Governed Links
About Resource Availability & Capacity Standard (RACS)
Resource Availability Determination Module (RADM)
Usable Capacity Condition Module (UCCM)
Reserved Capacity Module (RVCM)
Temporal Availability Module (TAVM)
Location & Accessibility Module (LAAM)