UCCM — Usable Capacity Condition 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: Usable Resource Capacity Governance
Module ID: RSGA-RACS-UCCM-02
Origin ID: OOF-RSGA-RACS-UCCM
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
UCCM — Usable Capacity Condition Module governs how the portion of an available Resource or Resource capacity that can actually perform a defined Resource function is determined by identifying, evidencing, applying, and reassessing the physical, technical, quality, condition, compatibility, infrastructure, dependency, configuration, and other materially relevant conditions required for use.
UCCM converts available capacity into governed usable capacity.
Available Capacity ≠ Usable Capacity.
2. Operational Role
RADM establishes whether and to what extent a Resource is available.
UCCM asks the next question:
How much of that available Resource can actually perform the function for which it is being considered?
A Resource may be available while part or all of it remains unusable because of:
Quality Condition Technical incompatibility Configuration Supporting Resource constraints Infrastructure constraints Performance limitations Safety-related technical conditions Processing requirements Resource-specific functional requirements
UCCM prevents available quantity from becoming an automatic proxy for usable capacity.
3. Core Question
What portion of the available Resource capacity can actually perform the relevant Resource function, and under which 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 Resource Availability.
UCCM establishes Usable Capacity.
The remaining modules govern reservation, temporal availability, and location/accessibility conditions before RACS produces the final Resource Availability & Capacity Profile.
5. Governed Space
UCCM governs:
Usable Resource Capacity Governance
This space concerns the conditions that determine whether available Resource capacity can actually perform the relevant Resource function.
6. Governed Object
The primary Governed Object is:
The Usable Capacity State of an available Resource or Resource System.
The governed object may concern:
Physical Resource quantity Flow capacity Generation capacity Storage capacity Processing capacity Transmission capacity Compute capacity Cooling capacity Network capacity Material capacity Regenerative Resource capacity Recovered Resource capacity
7. Scope
UCCM applies to the determination of usable Resource capacity from Resource capacity already established as available through RADM.
Its Scope includes:
functional requirements; quality conditions; Resource condition; technical compatibility; configuration requirements; infrastructure requirements; supporting Resource requirements; performance conditions; processing conditions; conversion conditions; operating envelopes; capacity derating; partial usability; conditional usability; usable-capacity evidence; usable-capacity uncertainty; usable-capacity sufficiency; capacity change; reassessment.
UCCM does not determine:
Resource Availability itself; reservation legitimacy; final temporal availability; location-specific practical accessibility; access authorization; priority; allocation; actual consumption; scarcity; resilience; sustainability.
8. Entry Requirement
UCCM begins with a governed Resource Availability Profile produced by RADM.
Canonical input:
Resource Availability Profile → Usable Capacity Determination
The input should preserve:
Resource ID Available quantity or capacity Availability State Resource State Source Relevant constraints Location reference Temporal reference Evidence Uncertainty
9. Usability Definition
Resource Usability represents the capacity of an available Resource to perform the relevant Resource function under defined conditions.
Usability is function-dependent.
A Resource may be available without being usable for the required function.
10. Usable Capacity Definition
Usable Capacity is the portion of available Resource capacity that satisfies the material conditions required to perform the relevant Resource function.
Canonical relationship:
Available Capacity → Usability Conditions → Usable Capacity
11. Resource Function
Usable Capacity cannot be determined without sufficient understanding of the relevant Resource function.
Examples:
Water for cooling
Water for drinking
Electricity for compute
Electricity for emergency reserve
GPU capacity for a specific workload class
Material for manufacturing
Network capacity for a required data-transfer function
The same Resource may have different usable capacity for different functions.
12. Function-Specific Usability
A Resource may be usable for Function A while unusable for Function B.
Therefore:
Resource Usability is not universally transferable across functions.
Function must remain explicit where material.
13. Multi-Function Resource
A Resource may support multiple functions.
UCCM should preserve function-specific usable capacity where those functions have materially different requirements.
14. Functional Equivalence
Two Resource quantities should not be treated as functionally equivalent merely because their physical quantity is equal.
Physical Equivalence ≠ Functional Equivalence.
15. Usability Conditions
Usable Capacity may depend upon:
Quality Condition Technical specification Compatibility Configuration Infrastructure Supporting Resources Processing Conversion Performance Environmental conditions Operational envelope
Only materially relevant conditions should be included.
16. Quality Condition
Resource quality may determine whether available Resource can perform the required function.
Examples may include:
Water quality Material purity Material grade Fuel characteristics Electricity quality Data-transfer characteristics
Available Quantity ≠ Quality-Compatible Capacity.
17. Quality Threshold
Where a function requires a defined Resource quality threshold, UCCM should preserve that threshold.
The threshold must be grounded in the competent Resource domain.
UCCM does not invent Resource-specific scientific requirements.
18. Quality Range
Some Resource functions permit a range rather than a single threshold.
UCCM may represent:
Acceptable Range Conditionally Acceptable Range Unacceptable Range
where supported by the relevant domain.
19. Mixed Quality Resource
Aggregate Resource quantity may contain different quality classes.
UCCM must disaggregate them where quality materially affects usable capacity.
Total Resource Quantity ≠ Total Usable Resource Quantity.
20. Quality Degradation
Resource quality may degrade through:
Storage Time Contamination Environmental exposure Repeated use Technical degradation
UCCM must use the relevant current quality condition.
21. Resource Condition
Physical or technical Resource condition may affect usable capacity.
Relevant conditions may include:
Degraded Damaged Contaminated Aged Partially functional Maintenance-limited Recovery-dependent
22. Condition-Compatible Capacity
Only the portion of available Resource whose condition permits the relevant function should enter Condition-Compatible Capacity.
23. Technical Compatibility
An available Resource may be technically incompatible with the system in which it is intended to operate.
Examples:
Voltage incompatibility Interface incompatibility Material specification mismatch Compute architecture mismatch Network protocol limitation Storage-system incompatibility
Available Resource ≠ Technically Compatible Resource.
24. Compatibility Requirement
Technical compatibility requirements must be explicit where they materially determine usable capacity.
Compatibility: assumptions must not silently become facts.
25. Partial Compatibility
Resource may be compatible with only part of the relevant system.
UCCM should permit Partial Compatibility rather than forcing binary classification.
26. Conditional Compatibility
Resource may become compatible after:
Processing Conversion Configuration Adaptation Transformation
Such capacity is conditionally usable rather than immediately usable.
27. Configuration Condition
Resource capacity may require a specific configuration before use.
Examples include:
Compute configuration Network configuration Storage configuration Equipment configuration Resource blending
Available but unconfigured capacity must not automatically be treated as immediately usable.
28. Configuration Readiness
UCCM may distinguish:
Configured Configuration-Ready Configuration-Required Configuration-Blocked Configuration-Unknown
where relevant.
29. Processing Requirement
Some Resources require processing before performing the intended function.
Examples:
Water treatment Material refining Waste-resource separation Fuel processing Data preparation where the governed object is a relevant Resource
Processing requirement must remain visible.
30. Processing Capacity Dependency
The Resource may exist in available quantity while processing infrastructure limits usable capacity.
Available Raw Resource ≠ Usable Processed Resource.
31. Conversion Requirement
Resource may require conversion between forms.
Examples:
Stored energy → electrical output
Raw material → production-compatible material
Recovered material → secondary usable material
Conversion capacity may therefore limit usable capacity.
32. Conversion Loss
Where conversion materially reduces usable Resource quantity or capacity, the loss should remain represented.
Input Resource Quantity ≠ Output Usable Capacity.
33. Infrastructure Condition
Usability may depend upon infrastructure capable of supporting the Resource function.
Relevant infrastructure may include:
Processing Storage Transmission Distribution Cooling Transport Network Recovery Conversion
34. Infrastructure Capacity
Infrastructure itself may impose a ceiling on usable Resource capacity.
Example:
**100 MW available electricity
70 MW infrastructure capacity → maximum 70 MW infrastructure-compatible capacity**
subject to other conditions.
35. Supporting Resource Condition
Usability may depend upon another Resource.
Examples:
Compute + Electricity + Cooling
Water distribution + Electricity
Material processing + Energy
Cooling + Water + Electricity
UCCM may consume governed supporting Resource states.
36. Supporting Resource Sufficiency
A supporting Resource must be sufficiently available and usable for the relevant function.
Nominal supporting Resource capacity is not sufficient evidence.
37. Multi-Resource Usability
Some Resource functions require several Resources simultaneously.
Canonical logic:
**Primary Resource
Supporting Resource A Supporting Resource B Required Infrastructure → Functional Usability**
38. Dependency Bottleneck
The lowest materially relevant supporting capacity may constrain usable capacity.
This must follow actual Resource-system relationships rather than a universal mathematical rule.
39. Bottleneck Identification
UCCM may identify the active usability bottleneck where evidence supports it.
Possible bottlenecks include:
Quality Condition Technical compatibility Processing Infrastructure Supporting Resource Configuration Performance
40. Bottleneck Migration
Removing one usability bottleneck may expose another.
Usable Capacity must therefore be reassessed after material system changes.
41. Performance Condition
A Resource may technically function while failing to meet the performance required for the governed Resource function.
Examples:
Insufficient throughput Insufficient compute performance Insufficient cooling performance Insufficient pressure Insufficient material strength
Functional Operation ≠ Required Performance.
42. Minimum Functional Performance
Where the Resource function requires a minimum performance level, UCCM should preserve that requirement.
The competent technical domain establishes the requirement.
UCCM governs its effect on usable capacity.
43. Performance Degradation
Performance may degrade without complete Resource failure.
UCCM must support reduced usable capacity.
44. Capacity Derating
Capacity Derating represents reduction from nominal or available capacity because relevant usability conditions prevent full functional use.
Canonical logic:
Available Capacity → Usability Constraints → Derated Usable Capacity
45. Derating Basis
Derating should remain traceable to its cause.
Possible bases include:
Quality Condition Temperature Technical limitation Supporting Resource Infrastructure Performance Configuration
46. Multiple Derating Factors
Multiple derating factors may coexist.
They must not automatically be multiplied, added, or otherwise combined without a valid Resource-specific relationship.
Multiple constraints do not imply a universal derating formula.
47. Usable Capacity Ceiling
Usability conditions may establish a maximum usable capacity below available capacity.
The ceiling should remain linked to the active limiting condition.
48. Usable Capacity Floor
Where evidence supports a minimum reliably usable capacity, UCCM may represent it.
This can be useful under variable Resource conditions.
49. Usable Capacity Range
Where exact usable capacity cannot legitimately be established, UCCM may represent a governed range.
Governed Range ≠ False Precision.
50. Full Usability
Full Usability exists where all materially relevant capacity established as available satisfies the conditions necessary for the relevant Resource function.
51. Partial Usability
Partial Usability exists where only part of available capacity satisfies the relevant functional conditions.
Partial Usability must not be represented as Full Usability.
52. Conditional Usability
Conditional Usability exists where Resource capacity becomes usable only if defined conditions are satisfied.
Conditions must remain attached to the determination.
53. Temporarily Unusable Capacity
Resource may remain available while temporarily unusable because of:
Maintenance Configuration Processing delay Supporting Resource interruption Technical restriction
54. Unusable Capacity
Resource is Unusable for the relevant function where sufficient evidence establishes that the required conditions cannot currently be met.
Unusable for one function does not necessarily mean unusable for all functions.
55. Unknown Usability
Where evidence is insufficient:
Unknown Usability ≠ Unusable Resource.
This distinction is mandatory.
56. Function Change
If the intended Resource function changes, Usable Capacity may change without the Resource itself changing.
A new function therefore may require reassessment.
57. Resource-State Change
A change in Resource State may alter usable capacity.
UCCM should consume the updated state and reassess relevant usability conditions.
58. Quality Change
Material quality change should trigger reassessment where it may alter usable capacity.
59. Condition Change
Material Resource-condition change should trigger reassessment.
60. Configuration Change
A configuration change may:
Increase usability Reduce usability Enable a new function Disable an existing function
The effect should be evidenced.
61. Infrastructure Change
Infrastructure expansion, degradation, failure, repair, or replacement may change usable capacity.
62. Supporting Resource Change
Changes in supporting Resource capacity may alter the usable capacity of the Governed Resource.
63. Environmental Condition
Environmental conditions may affect Resource usability.
Examples may include:
Temperature Humidity Hydrological conditions Weather Ecological conditions
Specialized domains establish the underlying science.
64. Operating Envelope
Some Resources or systems have an operating envelope within which capacity is usable.
The envelope may include:
Temperature Pressure Load Quality Performance Environmental condition Technical configuration
65. Outside Operating Envelope
Capacity outside the valid operating envelope must not automatically be counted as usable.
66. Operating Margin
Where Resource-specific practice requires an operating margin, UCCM may preserve its effect on usable capacity.
UCCM does not invent engineering margins.
67. Safety-Related Technical Condition
A technical or physical condition may prevent use because competent domain rules establish that operation would be unsafe.
UCCM records the resulting usability restriction.
It does not replace Safety Governance.
68. Compliance-Dependent Usability
Where competent rules legally or technically prevent Resource use, the capacity may be unavailable for the relevant governed function despite physical capability.
UCCM may consume the resulting governed restriction.
It does not determine general legal compliance.
69. Quality vs Availability
RADM may establish that Resource is available.
UCCM determines whether quality allows functional use.
Available Resource ≠ Quality-Compatible Resource.
70. Condition vs Availability
Resource may remain available despite degradation.
UCCM determines the resulting usable capacity.
71. Accessibility Boundary
A Resource may be usable in principle while inaccessible at the required location.
LAAM governs detailed Location & Accessibility.
Usable in Principle ≠ Practically Accessible at Point of Use.
72. Temporal Boundary
A Resource may be usable whenever available, but its actual availability may vary through time.
TAVM governs detailed Temporal Availability.
Usable Capacity ≠ Continuously Available Capacity.
73. Reservation Boundary
Usable capacity may be reserved.
RVCM governs Reserved Capacity.
Usable Capacity ≠ Unreserved Capacity.
74. Access Authorization Boundary
Usability does not establish permission.
Usable Resource ≠ Authorized Resource Use.
RAGS governs Access.
75. Allocation Boundary
Usable capacity does not establish allocation.
Usable Capacity ≠ Allocated Capacity.
RPAS governs allocation.
76. Demand Boundary
Usable Capacity does not determine Resource Demand.
RDGS governs Demand.
77. Scarcity Boundary
Low Usable Capacity may contribute to scarcity.
UCCM does not determine Scarcity State.
Low Usable Capacity ≠ Scarcity by definition.
78. Consumption Boundary
Usable capacity does not establish actual consumption.
Usable ≠ Consumed.
RCUS governs Consumption & Utilization.
79. Recovery Boundary
Recovered Resource may become usable after relevant quality, condition, processing, and compatibility requirements are met.
RRCS governs Recovery.
UCCM governs resulting usability.
80. Substitution Boundary
A Resource may be technically usable as a substitute.
That does not establish that substitution should occur.
Technical Substitutability ≠ Governed Substitution Decision.
RSFS governs Substitution & Flexibility.
81. Resilience Boundary
Usable reserve or redundant capacity may contribute to resilience.
UCCM does not determine resilience.
RIRS retains that domain.
82. Sustainability Boundary
Usable capacity does not establish sustainable capacity.
Usable Today ≠ Sustainable Over Time.
RCSS governs Continuity & Sustainability.
83. Value Boundary
Functional usability does not establish Value.
Usable Capacity ≠ Valuable Capacity by definition.
VEGA™ and VFM® retain their respective Value domains.
84. Authority Boundary
Usability does not create authority.
Capability ≠ Authority.
GOA™ retains Governance Authority.
85. Native Capacity Measurement
Usable Capacity should remain expressed in the Resource's native or technically appropriate measurement where possible.
Examples:
m³ litres MW MWh tonnes units GPU-hours bandwidth throughput
86. Functional Measurement
Where usability depends upon functional output rather than physical quantity alone, a relevant functional measure may be necessary.
The measurement must remain traceable to the underlying Resource.
87. Conversion Between Measures
Conversions between Resource measurements must preserve:
Method Assumptions Conditions Source measure Resulting measure
where material.
88. Normalization Boundary
UCCM does not replace native usable-capacity measurement with a universal normalized Resource metric.
Native Usable Capacity ≠ Normalized Resource Significance.
89. Usability Evidence
Usable Capacity must be supported by evidence appropriate to the Resource function.
Evidence may include:
Technical measurement Quality testing Condition assessment Performance testing Infrastructure records Configuration records Supporting Resource states Specialized domain determinations
90. Evidence Provenance
Usability evidence should remain traceable to:
Resource Function Measurement or assessment Time Location Method Evidence Source Version where applicable
91. Evidence Freshness
Usability conditions may change.
Evidence freshness must therefore reflect the rate at which:
Quality Condition Configuration Infrastructure Supporting Resources Performance
can materially change.
92. Observed Usability
Observed Usability is supported by sufficiently direct evidence that the Resource performs the required function under relevant conditions.
93. Tested Usability
Tested Usability is supported by an applicable test of Resource function or performance.
The test conditions must remain relevant to actual use.
Tested Under One Condition ≠ Universally Usable.
94. Inferred Usability
Usability may be inferred from sufficient evidence.
The inference basis must remain explicit.
95. Declared Usability
An operator, supplier, or manufacturer may declare capacity usable.
Declaration must remain distinguishable from independent verification.
Declared Usability ≠ Verified Usability.
96. Rated Capability
A technical rating may support usability assessment.
Rated capability does not automatically establish actual current usable capacity.
97. Simulated Usability
Simulation may test possible Resource performance.
Simulated Usability ≠ Observed Usability.
SIMULOS® retains Simulation Governance.
98. Predicted Usability
Future usable capacity may be predicted.
Predicted Usable Capacity ≠ Current Usable Capacity.
PGA™ retains Prediction Governance.
99. Assumed Usability
Assumed Usability must remain explicitly identified.
Usability Assumption ≠ Usability Evidence.
100. Usability Uncertainty
Material uncertainty may concern:
Quality Condition Compatibility Configuration Performance Infrastructure Supporting Resources Measurement
It must remain attached to the relevant capacity determination.
101. Uncertainty Propagation
Uncertain Usable Capacity must remain uncertain downstream until resolved or legitimately bounded.
Uncertain Usability must not become certain allocable capacity without additional evidence.
102. Usability Conflict
Usability Conflict exists where credible evidence supports materially incompatible usable-capacity determinations.
Conflict must remain visible.
103. Conflict Resolution
Canonical logic:
**Usability Claim A
Usability Claim B → Function Check → Boundary Check → Condition Check → Time / Location Check → Measurement-Basis Check → Evidence Comparison → Resolution or Preserved Conflict**
104. Usability Sufficiency
Usability is sufficiently established when enough evidence exists to support subsequent RACS governance.
Possible states:
Usability Sufficient
Conditionally Sufficient
Partially Sufficient
Evidence-Limited
Conflicted
Insufficient
Unresolved
105. Usability Decision States
At minimum, UCCM should distinguish:
Fully Usable
Partially Usable
Conditionally Usable
Temporarily Unusable
Unusable for Defined Function
Usability Evidence-Limited
Usability Conflicted
Usability Unknown
Usability Unresolved
106. Usable Capacity Profile
The principal UCCM output is the:
Usable Capacity Profile
It should establish:
Resource Relevant function Available capacity input Usability requirements Active usability constraints Usable capacity Unusable / conditionally usable capacity Evidence Uncertainty Sufficiency Reassessment conditions
107. Minimum Profile Fields
A minimum Usable Capacity Profile should support:
Resource ID RADM Availability Profile Reference Relevant Resource Function Available Capacity Input Native Measurement Quality Condition Resource Condition Compatibility State
Configuration State Infrastructure Condition Supporting Resource Condition Active Usability Constraint Usable Capacity Usability State Evidence Basis Evidence Time Uncertainty Sufficiency State Version
108. Capacity Accounting
UCCM must preserve the relationship between:
Available Capacity Usable Capacity Conditionally Usable Capacity Unusable Capacity
where the Resource permits meaningful capacity accounting.
109. Capacity Conservation
Where scientifically and technically appropriate, usable-capacity accounting should not produce more Resource capacity than entered the relevant availability boundary without an explained transformation.
110. Capacity Double-Counting
The same usable capacity must not be counted multiple times because it can theoretically support multiple mutually exclusive functions.
Multiple Possible Functions ≠ Multiple Simultaneously Usable Capacities.
111. Shared Capacity
Where capacity can support multiple functions but cannot serve them simultaneously, UCCM should identify it as shared or function-contingent capacity where material.
112. Concurrent Usability
Where Resource capacity can genuinely support multiple functions simultaneously, the relationship must be evidenced.
Concurrency must not be assumed.
113. Capacity Aggregation
Usable capacity may be aggregated only where relevant capacities are functionally and methodologically compatible.
114. Capacity Disaggregation
Aggregate available capacity must be disaggregated where different portions have materially different usability conditions.
115. Cross-System Comparability
Two systems with identical available capacity may have different usable capacity because of:
Quality Configuration Infrastructure Technical compatibility Supporting Resource constraints Performance
Same Available Capacity ≠ Same Usable Capacity.
116. Cross-Time Comparability
Usable Capacity comparisons across time must preserve material changes in Resource and system conditions.
117. Cross-Location Comparability
Usable Capacity comparisons across locations must preserve relevant technical, infrastructure, Resource-quality, and supporting-Resource differences.
118. Usability Change
Usable Capacity may change without Resource Availability changing.
Examples:
Configuration improvement Quality degradation Infrastructure failure Supporting Resource constraint Performance degradation
This distinction is important.
119. Usability Change Event
A material event may include:
Quality change Condition change Configuration change Processing completion Conversion completion Infrastructure change Supporting Resource change Performance change Technical requirement change Function change
120. Reassessment Trigger
UCCM reassessment should occur following material:
Resource-State change Quality change
Condition change Function change Technical-requirement change Configuration change Infrastructure change Supporting Resource change Environmental change New evidence Evidence expiry RADM Availability change
121. Reassessment Logic
Canonical logic:
Existing Usable Capacity Profile → New Evidence / Material Change → Usability Impact Test → Capacity Retained or Revised → Version Update → Downstream RACS Reassessment
122. Versioning
Materially revised Usable Capacity Profiles should preserve:
Previous usable capacity New usable capacity Changed condition Reason Effective time Evidence Known downstream impact
123. Usability History
Historical Usable Capacity may support:
Audit Performance analysis Planning Reliability assessment Capacity forecasting Governance reassessment
Historical capacity must remain distinguishable from current usable capacity.
124. RACS Handoff
UCCM produces the Usable Capacity Profile required for subsequent RACS governance.
Canonical handoff:
RADM Resource Availability Profile → UCCM Usable Capacity Profile → RVCM Reserved Capacity State → TAVM Temporal Availability Profile → LAAM Location & Accessibility Profile → RACS Resource Availability & Capacity Profile
125. Downstream Release Condition
UCCM output may proceed when usable capacity is sufficiently established for subsequent RACS governance.
Conditional progression may occur where material uncertainty remains explicitly preserved.
Progression does not erase Usability uncertainty.
126. Failure Conditions
UCCM should not be considered sufficiently completed where:
available capacity is automatically treated as usable capacity; Resource function is materially ambiguous; quality requirements are ignored; Resource condition is ignored; technical incompatibility is ignored; configuration requirements are ignored; processing requirements are ignored; conversion losses are ignored where material; infrastructure limitations are ignored; supporting Resource requirements are ignored; performance requirements are ignored; nominal rating is represented as actual usable capacity without evidence; conditional usability is represented as unconditional; partial usability is represented as full usability; unknown usability is represented as unusability; the same capacity is double-counted across mutually exclusive functions; material uncertainty is hidden; stale evidence is treated as current; function-specific usability is generalized without justification.
127. Governance Requirements
A conforming UCCM implementation must:
1. receive a governed Resource Availability Profile; 2. identify the relevant Resource function; 3. distinguish available from usable capacity; 4. identify material usability conditions; 5. preserve quality requirements; 6. preserve Resource condition; 7. preserve technical compatibility; 8. preserve configuration requirements; 9. preserve processing requirements where relevant; 10. preserve conversion requirements and material losses; 11. preserve infrastructure conditions; 12. preserve supporting Resource requirements; 13. preserve performance conditions; 14. identify active usability bottlenecks; 15. support capacity derating; 16. support partial usability; 17. support conditional usability; 18. distinguish Unknown from Unusable; 19. preserve native capacity measurement; 20. preserve function-specific capacity; 21. prevent capacity double-counting; 22. preserve evidence provenance; 23. preserve evidence freshness; 24. distinguish observed, tested, inferred, declared, rated, simulated, predicted, and assumed usability where material;
25. preserve uncertainty; 26. preserve conflict; 27. support usable-capacity sufficiency determination; 28. support reassessment; 29. support versioning; 30. produce a governed Usable Capacity Profile.
128. Governance Logic
Canonical UCCM logic:
Resource Availability Profile → Relevant Resource Function → Functional Requirements → Quality Condition → Resource Condition → Technical Compatibility → Configuration → Processing / Conversion Requirements → Infrastructure Condition → Supporting Resource Condition → Performance Condition → Active Usability Constraints → Capacity Derating where applicable → Usable Capacity Determination → Evidence & Uncertainty → Sufficiency → Usable Capacity Profile
Where evidence is missing:
Usability Question → Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Reassessment
Where conditions change:
Existing Usable Capacity → Material Change → Usability Impact Test → Revised Capacity → Version Update → Downstream Reassessment
129. Governance Outputs
UCCM may produce:
Usable Capacity Profile Usability State Functional Requirement State Quality Compatibility State Condition Compatibility State Technical Compatibility State Configuration State Processing Requirement State Conversion Requirement State Infrastructure Compatibility State Supporting Resource Condition State Performance Condition State
Active Usability Constraint Usable Capacity Conditionally Usable Capacity Unusable Capacity Capacity Derating State Usability Evidence State Usability Uncertainty State Usability Conflict State Usability Sufficiency State Usability Version Reassessment Trigger RACS Handoff State
130. Minimum Implementation Framework
A minimum operational UCCM implementation must contain at least eight governed layers.
Layer 1 — Availability Input
Receive:
Resource ID RADM Resource Availability Profile Available Capacity Native Measurement
Layer 2 — Functional Definition
Identify:
Relevant Resource Function Minimum Functional Requirement Relevant Performance Requirement
Layer 3 — Resource Compatibility
Assess:
Quality Condition Technical Compatibility Configuration
Layer 4 — Transformation Requirements
Assess where relevant:
Processing Conversion Preparation Material losses
Layer 5 — System Conditions
Assess:
Infrastructure Supporting Resources Environmental / operating conditions
Layer 6 — Usability Constraint Determination
Identify:
Active Usability Constraints Derating conditions Functional bottleneck
Layer 7 — Evidence & Decision
Preserve:
Evidence Freshness Uncertainty Conflict Usability Decision State
Layer 8 — Governed Output & Reassessment
Produce:
Usable Capacity Profile Version Known limitations Reassessment triggers RACS handoff state
Minimum machine-readable logic:
Resource → Availability Profile → Function → Requirements[] → Quality / Condition → Compatibility[] → Infrastructure[] → Supporting Resources[] → Active Constraints[] → Evidence[] → Uncertainty[] → Usable Capacity → Usability State → Usable Capacity Profile
131. Minimum Decision States
At minimum:
Fully Usable
Partially Usable
Conditionally Usable
Temporarily Unusable
Unusable for Defined Function
Usability Evidence-Limited
Usability Conflicted
Usability Unknown
Usability Unresolved
132. Minimum Evidence Path
Where usable capacity cannot be sufficiently established:
Usability Unresolved → Material Missing Evidence → Minimum Evidence Requirement → Evidence Acquisition / Testing → Usability Reassessment → Updated Usable Capacity Profile
The objective is sufficient functional evidence, not unlimited testing.
133. Minimum Reassessment Framework
At minimum:
Current Usable Capacity Profile → New Evidence / Material Change → Usability Impact Test → Capacity Retained or Revised → Profile Version Update → Downstream RACS Reassessment where required
134. Use Case 1 — AI Compute Capacity
RADM establishes that an AI facility currently has compute capacity corresponding to:
8,900 available accelerators.
UCCM does not automatically treat all 8,900 as usable for a target AI workload.
The workload requires:
compatible accelerator architecture; sufficient memory; required interconnect capability; compatible software configuration; sufficient electricity; sufficient cooling; required network performance.
Evidence establishes:
8,900 accelerators available; 8,500 technically compatible; 8,300 correctly configured; supporting cooling and electricity sufficient for 8,100 at the required operating level.
UCCM may therefore establish:
Available Capacity: 8,900
Usable Capacity for Defined Function: 8,100
subject to the applicable evidence and conditions.
RVCM subsequently determines how much of that capacity is reserved.
TAVM determines when it is available.
LAAM determines relevant location and accessibility.
Available compute capacity is not the same as workload-usable compute capacity.
135. Use Case 2 — Water Resource for Industrial Cooling
RADM establishes:
50,000 m³/day of water as available Resource capacity.
The industrial cooling system requires water satisfying defined:
quality; temperature; treatment; delivery; technical compatibility
conditions.
Evidence establishes that:
50,000 m³/day is physically available; 42,000 m³/day meets the required quality directly; 5,000 m³/day can become usable after treatment; 3,000 m³/day cannot currently meet the relevant functional requirements.
UCCM preserves these distinctions.
It does not report:
50,000 m³/day available = 50,000 m³/day usable.
Instead, it establishes the function-specific Usable Capacity Profile and preserves conditional capacity requiring treatment.
The quantity of Resource that exists is not necessarily the quantity capable of performing the required function.
136. Critical Distinctions
Available Capacity ≠ Usable Capacity
Resource Availability ≠ Resource Usability
Physical Equivalence ≠ Functional Equivalence
Available Quantity ≠ Quality-Compatible Capacity
Available Resource ≠ Technically Compatible Resource
Available Raw Resource ≠ Usable Processed Resource
Input Resource Quantity ≠ Output Usable Capacity
Functional Operation ≠ Required Performance
Nominal Capability ≠ Actual Usable Capacity
Full Availability ≠ Full Usability
Partial Usability ≠ Full Usability
Conditional Usability ≠ Unconditional Usability
Unknown Usability ≠ Unusable Resource
Usable Capacity ≠ Continuously Available Capacity
Usable Capacity ≠ Unreserved Capacity
Usable Resource ≠ Authorized Resource Use
Usable Capacity ≠ Allocated Capacity
Usable ≠ Consumed
Technical Substitutability ≠ Governed Substitution Decision
Usable Today ≠ Sustainable Over Time
Usable Capacity ≠ Value
Capability ≠ Authority
Multiple Possible Functions ≠ Multiple Simultaneously Usable Capacities
Same Available Capacity ≠ Same Usable Capacity
Native Usable Capacity ≠ Normalized Resource Significance
137. Cross-Architecture Boundary
UCCM may consume technical, scientific, operational, infrastructure, Resource-specific, evidence, Prediction, and simulation inputs.
The originating domains retain governance of their own mechanisms.
UCCM governs only their effect on Resource Usable Capacity within RACS.
ORA™ retains general Operational Reality.
PGA™ retains Prediction Governance.
SIMULOS® retains Simulation Governance.
ADIT® retains Audit and Evidence Governance.
VALIDOS™ retains general Validation Governance.
GOA™ retains Governance Authority.
Specialized Resource domains retain Resource-specific science and engineering.
138. 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 laboratory may determine Resource quality.
An engineering system may determine technical compatibility.
A compute platform may determine hardware performance.
An infrastructure system may determine processing capability.
UCCM consumes those governed outputs to determine Usable Capacity.
It does not absorb the mechanisms that produced them.
139. Canonical Boundary
UCCM governs the conditions under which Resource capacity already established as available can actually perform a defined Resource function and determines the resulting Usable Capacity State.
It does not determine Resource Availability itself, reservation legitimacy, final temporal availability, location-specific practical accessibility, access authorization, prioritization, allocation, actual consumption, scarcity, resilience, or sustainability.
Its governed output is the Usable Capacity Profile required for subsequent RACS governance.
140. Canonical Closing Statement
Availability establishes that Resource capacity is there. Usability establishes whether that capacity can actually do what the Resource System requires.
UCCM prevents available capacity from being mistaken for functional capacity.