CRDM — Core Resource Demand Module
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Parent Standard: Resource Demand Governance Standard (RDGS)
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Core Module
Governed Space: Core Resource Demand Governance
Module ID: RSGA-RDGS-CRDM-01
Origin ID: OOF-RSGA-RDGS-CRDM
Version: 1.0
Status: Draft Module
Effective Date: 5 October 2026
Compatibility: Methodology OS — Modular Compatibility
GIE-Compatible: Yes
AI-Readable: Yes
Authority: OOF® — OriginOpen® Foundation
Protection: Protected Methodological Work
Canonical Language: English
1. Canonical Definition
CRDM — Core Resource Demand Module governs how a candidate Resource requirement is identified, bounded, attributed to a Demand Source, associated with the relevant Resource, quantified in an appropriate native measurement, evidenced, qualified, and converted into a governed Core Resource Demand State before more detailed functional, peak, concurrency, and consolidation governance occurs.
CRDM establishes the foundational Demand object within RDGS.
Resource Requirement Signal ≠ Governed Resource Demand.
2. Operational Role
CRDM is the first Core Module of RDGS.
It receives Resource-related requirement signals from operational systems, participants, infrastructure, processes, plans, measurements, or other relevant sources and determines whether those signals can be represented as a governed Resource Demand object.
Its role is to establish:
what Resource is being demanded; what entity, system, process, or function generates the Demand; what Demand boundary applies; what quantity, capacity, rate, or other Resource requirement is represented; which native measurement applies; which evidence supports the Demand; which uncertainty remains; and whether the Demand is sufficiently established to proceed through RDGS.
3. Core Question
What Resource requirement actually exists, what is its governed boundary, who or what generates it, how much Resource is required, and what evidence supports that requirement?
4. Position in RDGS Module Flow
CRDM — Core Resource Demand Module → FDIM — Functional Demand Identification Module → PKDM — Peak Demand Module → CPDM — Concurrent & Parallel Demand Module → DCMM — Demand Consolidation & Management Module
CRDM establishes the Core Demand object upon which the remaining RDGS modules operate.
5. Governed Space
CRDM governs:
Core Resource Demand Governance
This space concerns the transformation of Resource requirement signals into sufficiently identified, bounded, measured, evidenced, and governable Resource Demand objects.
6. Governed Object
The primary Governed Object is:
A Candidate Resource Demand and its resulting Core Resource Demand State.
The Demand may concern:
Resource quantity; Resource capacity; Resource flow; Resource throughput; Resource rate; Resource availability requirement; Resource performance requirement; other Resource-specific requirement.
7. Scope
CRDM applies whenever a Resource requirement must be established before downstream Resource Demand Governance can occur.
Its Scope includes:
Demand signal identification; Demand Source identification; Resource identification; Demand object formation; Demand boundary definition; Demand quantity; Demand capacity; Demand rate; native measurement; measurement basis; Demand evidence; Demand provenance; Demand uncertainty; Demand conflict; Demand duplication screening; Demand sufficiency; Demand state formation; Demand change; Demand reassessment; Demand versioning.
CRDM does not independently govern:
detailed functional Demand decomposition; Peak Demand determination; Demand concurrency and parallelism; final Demand consolidation; Resource Dependency; Criticality; Access authorization; Priority; Allocation; Consumption; Scarcity; Resilience; Sustainability.
8. Entry Condition
CRDM may receive a candidate Resource requirement from:
Operational measurement
Participant request
System request
Technical specification
Infrastructure requirement
Workload signal
Production requirement
Process requirement
Historical Resource record
Operational plan
Prediction output
Simulation output
Derived technical requirement
Other sufficiently identifiable Demand signal
The existence of an input does not establish governed Demand.
9. Demand Signal
A Demand Signal is any observation, request, measurement, record, calculation, or system state indicating that Resource may be required.
A Demand Signal is an input to governance.
It is not automatically the governed Demand.
Demand Signal ≠ Resource Demand.
10. Signal Classification
CRDM should identify the nature of the incoming Demand Signal.
Possible classifications include:
Observed
Measured
Requested
Declared
Derived
Estimated
Planned
Predicted
Simulated
Assumed
11. Signal Provenance
The origin of the Demand Signal should remain traceable.
Where relevant, provenance includes:
Source system
Participant
Sensor
Technical model
Operational process
Prediction methodology
Simulation
Planning process
Timestamp
Version:
12. Demand Source
Every Core Resource Demand should identify the Demand Source.
The Demand Source is the entity, system, process, function, infrastructure, or other operational object from which the Resource requirement originates.
13. Demand Source Identity
Demand Source identity should be sufficiently precise to distinguish one Resource requirement from another.
Generic labels should not replace identifiable Demand Sources where the distinction materially affects governance.
14. Demand Source vs Resource Source
The Demand Source and Resource Source are different concepts.
Demand Source ≠ Resource Source.
Demand Source identifies where the requirement originates.
Resource Source identifies where Resource supply originates.
15. Demand Source vs Resource Origin
The origin of Resource does not identify the origin of Demand.
Demand Origin ≠ Resource Origin.
16. Participant Demand
A human, organization, institution, system, or other participant may generate a Resource request or requirement.
CRDM governs the Resource Demand object, not the participant's general identity governance.
17. System Demand
An operational system may generate Resource Demand automatically.
Examples include:
Compute system
Cooling system
Manufacturing line
Water treatment system
Electrical infrastructure
Network infrastructure
18. Process Demand
A process may create a Resource requirement independently of the overall system's maximum Resource capability.
The relevant process should remain identifiable.
19. Infrastructure Demand
Infrastructure may require Resource capacity for:
operation; standby; maintenance; recovery; supporting services.
These requirements may need separate Demand objects.
20. Resource Identification
Every Demand object must identify the Resource being demanded.
CRDM should consume the governed Resource identity established through RCHS where available.
21. Resource Identity Integrity
A Demand for one Resource must not be silently represented as Demand for another Resource merely because both support the same function.
22. Cross-Resource Requirement
A single operation may generate several distinct Resource Demand objects.
Example:
AI workload → Compute Demand → Electricity Demand → Cooling Demand → Water Demand → Network Demand
Each Resource remains independently governed.
23. Resource Bundle Boundary
Several Resources may be operationally required together.
Their relationship may be represented.
Their physical identity must not be collapsed.
Joint Requirement ≠ Resource Equivalence.
24. Candidate Demand Object
A Candidate Demand Object is formed when:
Demand Source + Resource + Requirement Signal
are sufficiently identifiable to begin Demand governance.
25. Demand Object Identity
Every material Demand object should have a stable identifier where system complexity requires traceability.
26. Demand Object Persistence
A Demand object may persist through multiple measurements, revisions, and operating states.
Identity persistence does not imply that its Demand quantity remains unchanged.
27. Demand Boundary
The Demand Boundary defines which Resource requirement belongs to the Demand object.
It should identify:
included requirement; excluded requirement; Demand Source; Resource; relevant operating boundary.
28. Boundary Integrity
Demand boundaries must follow operational Resource reality rather than organizational convenience.
29. Organizational Boundary
A department, company, facility, or administrative unit may provide a useful Demand boundary.
It should not override the actual Resource-dependent system boundary where those differ.
30. Functional Boundary
Where a Resource requirement belongs to a particular operational function, the Demand boundary should preserve that relationship.
FDIM performs deeper functional governance downstream.
31. Physical Boundary
A physical system boundary may determine which Resource requirements belong to the Demand object.
32. Infrastructure Boundary
Infrastructure may define a Demand boundary where Resource consumption or capacity requirement can be materially isolated.
33. Temporal Boundary
A Demand object may apply only during a defined interval.
CRDM should preserve the temporal boundary where known.
Detailed Demand temporal structures may be refined downstream.
34. Spatial Boundary
A Demand object may apply to a specific:
facility; site; network node; region; system location.
35. Boundary Overlap
Two Candidate Demand objects may overlap.
CRDM should detect potential overlap before treating them as independent Demand.
36. Boundary Duplication
Where two Demand records represent the same underlying Resource requirement, they should not automatically become two additive Demand objects.
37. Demand Duplication Risk
Duplication may arise through:
multiple reporting systems; organizational records; participant requests; technical monitoring; planning systems; replicated databases.
38. Duplicate Demand Screening
CRDM should compare:
Resource ID
Demand Source
Demand boundary
time
location
underlying requirement
before establishing independent Demand objects.
39. Independent Demand
Two Resource requirements may be treated as independent only where their underlying operational requirements are sufficiently distinct.
40. Demand Quantity
Demand Quantity represents the amount of Resource required within the defined Demand boundary.
41. Demand Capacity
Some Resource requirements are capacity requirements rather than accumulated quantity.
Examples:
MW
GPU capacity
storage capacity
network bandwidth
42. Demand Rate
Flow-based Resources may require a rate.
Examples:
m³/hour
litres/second
MW
GB/s
tonnes/hour
43. Quantity vs Capacity
A total Resource quantity and required Resource capacity must remain distinguishable.
44. Quantity vs Rate
Required Quantity ≠ Required Rate.
A system may have sufficient Resource quantity while lacking the necessary rate of delivery.
45. Capacity vs Consumption
Required capacity is not the same as Resource consumed.
Demand Capacity ≠ Resource Consumption.
46. Native Measurement
CRDM should preserve Resource Demand in a Resource-native or technically appropriate measurement wherever possible.
47. Native Measurement Examples
Examples include:
m³
m³/day
MW
MWh
tonnes
kg/hour
GPU-hours
accelerator-equivalent units
GB
GB/s
48. Measurement Definition
Every Demand measurement should preserve what the value actually represents.
A number without measurement semantics may be insufficient for governance.
49. Measurement Basis
The measurement basis may include:
direct measurement; technical derivation; operational calculation; declared requirement; historical inference; Prediction; Simulation; assumption.
50. Measurement Period
Where Resource Demand is measured across time, the measurement period should remain explicit.
51. Measurement Granularity
Granularity should reflect the Resource requirement.
Annual Demand may be insufficient where hourly peaks matter.
Millisecond measurements may be unnecessary where Demand changes slowly.
52. Measurement Sufficiency
CRDM requires sufficient relevant measurement detail, not maximum possible measurement detail.
53. Unit Integrity
Demand values expressed in different units must not be combined without valid conversion.
54. Conversion Traceability
Where unit conversion occurs, the conversion basis should remain traceable.
55. Physical Measurement Preservation
Native physical Resource measurements should be preserved before normalization or derived comparison.
Native Resource Demand ≠ Normalized Resource Significance.
56. Requested Quantity
A requested quantity may initiate Demand governance.
It does not establish validated Demand.
Requested Quantity ≠ Governed Demand Quantity.
57. Declared Quantity
A participant or system may declare a Resource requirement.
Declared Quantity ≠ Validated Demand Quantity.
58. Installed Consumption Capability
Installed infrastructure may establish the maximum Resource capacity the system could consume.
It does not establish actual Demand.
Installed Consumption Capability ≠ Resource Demand.
59. Maximum Theoretical Requirement
Maximum theoretical Resource use may define an upper technical boundary.
It must not automatically become governed Demand.
60. Historical Consumption
Historical Consumption may provide Demand evidence.
It is not Demand itself.
Historical Consumption ≠ Current Resource Demand.
61. Current Consumption
Current Consumption may provide evidence about Resource requirement.
A system may consume above or below actual Demand.
Current Consumption ≠ Resource Demand by definition.
62. Low Consumption Under Constraint
Resource shortage may suppress Consumption.
Therefore:
Low Consumption ≠ Low Demand.
63. Excess Consumption
A system may consume more Resource than required because of inefficiency, waste, configuration, or operational behaviour.
Therefore:
High Consumption ≠ High Demand by definition.
64. Demand Derivation
Where Demand is derived rather than directly measured, the derivation method must remain explicit.
65. Derivation Inputs
Derived Demand may use:
workload; production volume; technical Resource coefficient; system configuration; operational requirement; process model.
66. Derivation Integrity
A derived Demand value is only as reliable as the assumptions, inputs, and mechanism used to derive it.
67. Estimated Demand
Where direct measurement is unavailable, CRDM may represent estimated Demand.
The estimation status must remain visible.
68. Demand Range
Where exact Demand cannot be justified, CRDM may establish a range.
Example:
Required Capacity: 80–95 MW
may be more governable than unsupported:
Required Capacity: 88.4 MW
69. False Precision
CRDM should reject unjustified precision.
Numerical Precision ≠ Evidentiary Precision.
70. Minimum Demand
Where supported, CRDM may establish the minimum Resource requirement necessary for the relevant Demand object.
This does not determine Criticality.
71. Maximum Demand Boundary
CRDM may establish an upper Demand boundary where evidence supports it.
Maximum Demand does not automatically equal expected or current Demand.
72. Demand Evidence
Every material Core Resource Demand should have an identifiable evidence basis.
73. Direct Evidence
Direct evidence may include:
meter readings; system telemetry; Resource measurements; operational measurements; verified technical state.
74. Technical Evidence
Technical evidence may include:
equipment specifications; system requirements;
process specifications; capacity requirements; engineering documentation.
75. Operational Evidence
Operational evidence may include:
workload records; production schedules; process activity; system operating states; Resource-dependent operational outputs.
76. Historical Evidence
Historical evidence may support Demand determination where the historical operating conditions remain relevant.
77. Planning Evidence
Operational plans may support future Demand.
Planning evidence must remain distinguishable from current operational evidence.
78. Prediction Evidence
Predicted Demand may be used where future Resource requirements matter.
PGA™ governs the Prediction methodology.
CRDM preserves its Prediction status.
79. Simulation Evidence
Simulation may produce Resource Demand under hypothetical conditions.
SIMULOS® governs Simulation.
CRDM preserves its simulated status.
80. Assumption
An assumption may temporarily support a Demand object where evidence is incomplete.
The assumption must remain explicit.
Assumption ≠ Evidence.
81. Evidence Hierarchy Boundary
CRDM does not impose one universal evidence hierarchy across all Resource types.
Evidence quality depends upon the governed Resource and Demand context.
82. Evidence Relevance
Evidence should support the actual Resource requirement being governed.
Evidence of installed capability may not prove operational Demand.
83. Evidence Time
Demand evidence should preserve the time at which it represented the relevant Resource requirement.
84. Evidence Freshness
Demand evidence may become stale after operational change.
85. Evidence Validity
Evidence validity should reflect:
Demand volatility; system change; Resource function; measurement basis; governance consequence.
86. Evidence Provenance
At minimum, provenance should preserve where relevant:
Evidence source
Demand Source
Resource
Measurement or derivation method
Time
Version:
87. Evidence Conflict
Two credible evidence sources may support different Demand values.
The conflict should remain visible.
88. Demand Conflict State
A Demand should enter a Conflicted state where incompatible evidence cannot yet be legitimately resolved.
89. Conflict Resolution Logic
Canonical logic:
**Demand Evidence A
Demand Evidence B → Resource Identity Check → Demand Source Check → Boundary Check → Measurement Basis Check → Time Check → Unit Check → Evidence Relevance Check → Resolution or Preserved Conflict**
90. Demand Uncertainty
Demand uncertainty may arise from:
measurement limitations; variable operation; incomplete evidence; unknown conditions; future state; conflicting evidence; derivation assumptions.
91. Quantitative Uncertainty
Demand quantity may be represented as:
exact value where justified; range; minimum; maximum; distribution where appropriate; unknown.
92. Structural Uncertainty
Uncertainty may concern whether the Demand boundary itself is correct.
93. Source Uncertainty
The system generating Demand may be partially unresolved.
94. Resource Uncertainty
The Resource being demanded may be ambiguously identified.
Where Resource identity is unresolved, CRDM should not silently proceed as though it were certain.
95. Measurement Uncertainty
Measurement uncertainty should remain attached to the Demand value where material.
96. Uncertainty Propagation
Uncertain Demand must remain uncertain downstream until resolved or legitimately bounded.
97. Demand Sufficiency
CRDM determines whether the Core Resource Demand object is sufficiently established for further RDGS governance.
98. Sufficient Core Demand
A Core Resource Demand may be considered sufficiently established where:
Resource is identified; Demand Source is identified; Demand boundary is sufficiently defined; quantity/capacity/rate is represented appropriately; measurement basis is known; material evidence exists; material uncertainty is represented.
99. Conditional Core Demand
A Demand may proceed conditionally where limitations remain explicit and downstream governance can legitimately preserve them.
100. Partially Established Demand
A Demand may be partially established where some required components are known while others remain unresolved.
101. Evidence-Limited Demand
A Demand is Evidence-Limited where Resource requirement cannot be established with sufficient confidence because material evidence is missing or inadequate.
102. Conflicted Demand
A Demand is Conflicted where credible evidence supports incompatible Demand states.
103. Demand Unknown
Demand is Unknown where the Resource requirement cannot currently be established.
104. Demand Unresolved
Demand is Unresolved where a governance determination cannot yet be completed.
105. Core Demand Decision States
At minimum, CRDM should support:
Core Demand Established
Conditionally Established
Partially Established
Demand Evidence-Limited
Demand Conflicted
Demand Unknown
Demand Unresolved
106. Core Resource Demand Profile
The principal CRDM output is the:
Core Resource Demand Profile
It provides the foundational Demand object for subsequent RDGS modules.
107. Minimum Profile Fields
A minimum Core Resource Demand Profile should support:
Demand ID
Resource ID
Demand Source ID
Demand Source Type
Demand Boundary
Demand Quantity / Capacity
Demand Rate where relevant
Native Measurement
Measurement Basis
Relevant Time Reference
Relevant Location Reference
Evidence Basis
Evidence Time
Uncertainty
Demand State
Sufficiency State
Version:
108. Demand Identity Persistence
A revised Demand value should not automatically create a new Demand identity where the underlying Demand object remains the same.
109. Demand Versioning
Material Demand changes should create a new governed version.
110. Version Record
A Demand version record should preserve where relevant:
Previous value
New value
Changed boundary
Changed Resource
Changed Demand Source
Changed measurement basis
Reason for change
Evidence
Effective time
111. Demand Creation
A new Demand object may be created where a materially distinct Resource requirement emerges.
112. Demand Activation
A previously conditional or standby Demand may become active.
CRDM records the change in Core Demand State.
Detailed functional and temporal interpretation continues downstream.
113. Demand Suspension
A Demand may temporarily cease to apply while retaining identity.
114. Demand Termination
A Demand object may terminate where the underlying Resource requirement no longer exists.
115. Demand Reopening
A terminated or inactive Demand may reappear.
CRDM should determine whether it represents:
the same Demand object reactivated
or:
a new Demand object.
116. Material Change
Material changes may include:
Resource change; Demand Source change; boundary change; quantity change; capacity change; rate change; measurement basis change; evidence change; operational state change.
117. Reassessment Trigger
CRDM reassessment should occur following material:
new measurement; new operational evidence; Demand Source change; Resource change; system reconfiguration; boundary change; evidence expiry; evidence conflict; Demand activation; Demand suspension; Demand termination.
118. Reassessment Logic
Canonical logic:
Existing Core Resource Demand Profile → New Evidence / Material Change → Demand Impact Test → Demand Retained or Revised → Version Update → Downstream RDGS Reassessment
119. Demand vs Functional Demand
CRDM establishes the Core Demand object.
FDIM determines the detailed relationship between Demand and the Resource-dependent function.
Core Demand Identification ≠ Full Functional Demand Governance.
120. Demand vs Peak Demand
CRDM may preserve observed or stated Demand values.
PKDM determines Peak Demand structures.
Core Demand Quantity ≠ Peak Demand Determination.
121. Demand vs Concurrent Demand
CRDM identifies individual Demand objects.
CPDM determines whether multiple Demand objects apply simultaneously or in parallel.
Individual Demand ≠ Concurrent Demand Structure.
122. Demand vs Consolidated Demand
CRDM does not establish the final consolidated Demand state across multiple Demand objects.
DCMM owns Demand consolidation and management.
123. Demand vs Resource Availability
CRDM establishes Resource requirement independently of whether sufficient Resource capacity exists.
Demand ≠ Availability.
RACS retains Resource Availability & Capacity Governance.
124. Demand vs Resource Dependency
CRDM establishes what Resource is required.
RDCS determines how strongly the governed system depends upon that Resource.
125. Demand vs Criticality
CRDM does not determine the consequence of failing to satisfy Demand.
Demand Quantity ≠ Criticality.
126. Demand vs Access
Demand does not establish permission to access Resource.
Demand ≠ Access Authorization.
127. Demand vs Priority
A larger Demand does not automatically deserve greater Priority.
Demand Magnitude ≠ Resource Priority.
128. Demand vs Allocation
CRDM does not allocate Resource.
Governed Demand ≠ Allocated Resource.
129. Demand vs Consumption
CRDM determines Resource requirement.
RCUS governs actual Resource Consumption & Utilization.
130. Demand vs Scarcity
Demand may later contribute to Scarcity governance.
CRDM does not establish Scarcity State.
131. Demand vs Sustainability
A valid Resource Demand may still be unsustainable.
CRDM does not determine long-term Resource Sustainability.
132. Demand vs Value
A Resource Demand may support high or low Value.
Value does not redefine the amount of Resource actually required.
VEGA™ retains relevant Value Governance.
133. Demand vs Willingness to Pay
A participant's willingness to pay does not establish the underlying Resource requirement.
134. Demand vs Authority
The ability to submit or declare a Demand does not create Resource authority.
Demand Declaration Capability ≠ Resource Authority.
135. Resource Availability Context
CRDM may receive RACS Resource Availability & Capacity information as context.
It must not alter the Demand object merely to fit available capacity.
136. Demand-Capacity Independence
If:
Demand = 100
and:
Available Capacity = 60
CRDM should preserve Demand at 100 where evidence supports it.
The 40-unit difference becomes a downstream governance issue.
137. Suppressed Demand
Where Consumption is constrained by limited Resource Availability, actual Resource requirement may exceed observed Consumption.
CRDM should support recognition of suppressed Demand where evidence supports it.
138. Latent Demand
A Resource requirement may exist without being expressed as active Consumption or a formal request.
Latent Demand should only be represented where sufficient evidence supports the underlying requirement.
139. Demand Inflation
Requests or declared Demand may exceed the actual Resource requirement.
CRDM should not automatically inherit inflated claims.
140. Demand Understatement
Declared Demand may also understate actual Resource requirements.
Governance should follow evidence rather than the preferred numerical outcome.
141. Demand Integrity Principle
The Demand boundary and quantity must follow the governed Resource requirement, not the preferred allocation outcome.
142. Evidence Independence Principle
Evidence should establish Demand.
Demand should not determine which evidence is accepted merely because a particular value is desired.
143. Demand Reality Principle
Resource Demand is a governed representation of Resource requirement, not a negotiation position.
144. Minimum Implementation Framework
A minimum operational CRDM implementation should contain eight governed layers.
Layer 1 — Demand Signal
Receive:
Requirement signal Request
Measurement System state Operational evidence
Layer 2 — Demand Identity
Establish:
Demand ID Resource ID Demand Source
Layer 3 — Demand Boundary
Define:
Included requirement Excluded requirement Relevant system/process boundary
Layer 4 — Measurement
Determine:
Quantity Capacity Rate where relevant Native measurement Measurement basis
Layer 5 — Evidence
Preserve:
Evidence source Evidence time Provenance Validity
Layer 6 — Integrity Checks
Assess:
Duplication Boundary overlap Unit integrity Measurement relevance Evidence conflict
Layer 7 — Uncertainty & Sufficiency
Determine:
Uncertainty Demand State Sufficiency State
Layer 8 — Governed Output
Produce:
Core Resource Demand Profile Version Known limitations
Reassessment triggers FDIM handoff state
Minimum machine-readable logic:
Demand Signal → Resource → Demand Source → Demand Boundary → Quantity / Capacity / Rate → Native Measurement → Evidence[] → Integrity Checks[] → Uncertainty[] → Demand State → Sufficiency → Core Resource Demand Profile
145. Minimum Decision States
At minimum:
Core Demand Established
Conditionally Established
Partially Established
Demand Evidence-Limited
Demand Conflicted
Demand Unknown
Demand Unresolved
146. Minimum Evidence Path
Where Core Resource Demand cannot be sufficiently established:
Demand Unresolved → Material Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Demand Reassessment → Updated Core Resource Demand Profile
The objective is sufficient evidence of Resource requirement, not unlimited data collection.
147. Minimum Reassessment Framework
At minimum:
Current Core Resource Demand Profile → New Evidence / Material Change → Demand Impact Test → State Retained or Revised → Profile Version Update → Downstream RDGS Reassessment
148. Governance Requirements
A conforming CRDM implementation must:
1. identify the Demand Signal; 2. preserve Signal provenance; 3. identify the Resource; 4. identify the Demand Source; 5. establish Demand identity; 6. establish Demand boundary; 7. distinguish Demand Source from Resource Source; 8. preserve cross-Resource distinctions; 9. determine Demand quantity, capacity, or rate as appropriate; 10. preserve native measurement; 11. preserve measurement basis; 12. preserve measurement period where relevant; 13. distinguish request from governed Demand; 14. distinguish installed capability from Demand; 15. distinguish Consumption from Demand; 16. support derived and estimated Demand; 17. support governed Demand ranges; 18. prevent false precision; 19. preserve evidence provenance; 20. preserve evidence freshness; 21. detect material evidence conflict; 22. detect potential Demand duplication; 23. preserve material uncertainty; 24. determine Demand sufficiency; 25. support conditional progression; 26. support Demand state change; 27. support reassessment; 28. support versioning; 29. produce a Core Resource Demand Profile; 30. preserve unresolved limitations downstream.
149. Governance Logic
Canonical CRDM logic:
Resource Requirement Signal → Signal Classification → Demand Source Identification → Resource Identification → Candidate Demand Object → Demand Boundary → Quantity / Capacity / Rate → Native Measurement → Measurement Basis → Evidence → Duplication Check → Conflict Check → Uncertainty → Sufficiency Determination → Core Resource Demand State → Core Resource Demand Profile
Where evidence is insufficient:
Candidate Demand → Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Reassessment
Where Demand changes:
Existing Core Demand → Material Change → Demand Impact Test → Revised Demand → Version Update → Downstream Reassessment
150. Governance Outputs
CRDM may produce:
Core Resource Demand Profile
Demand ID
Demand Source State
Resource Requirement State
Demand Boundary
Demand Quantity
Demand Capacity
Demand Rate
Native Measurement State
Measurement Basis
Demand Evidence State
Demand Provenance State
Demand Duplication State
Demand Conflict State
Demand Uncertainty State
Demand Sufficiency State
Demand Version
Reassessment Trigger
FDIM Handoff State
151. Downstream Release Condition
CRDM output may proceed into FDIM where the Core Resource Demand is sufficiently established for functional Demand governance or where remaining limitations can legitimately remain explicit.
Progression does not erase Demand uncertainty.
152. Failure Conditions
CRDM should not be considered sufficiently completed where:
a request is automatically treated as Demand; a Demand Source is materially unidentified; the Resource is materially unidentified; Demand boundary is materially undefined; duplicate Demand is counted independently; installed capability is treated automatically as Demand; historical Consumption is treated automatically as current Demand; current Consumption is treated automatically as Demand; low Consumption under Resource constraint is interpreted automatically as low Demand; declared quantity is treated as validated quantity without evidence; units are ambiguous; quantity and rate are confused; measurement basis is unknown; derived Demand hides its derivation; assumed Demand is represented as evidenced Demand; false precision is introduced; material evidence conflict is suppressed; material uncertainty is hidden; stale evidence is treated as current; Demand is changed merely to match Resource Availability; Demand is confused with Priority or Allocation.
153. Use Case 1 — AI Compute Resource Demand
An AI system has infrastructure capable of using:
10,000 accelerator-equivalent units.
A workload scheduler requests:
9,000 units.
Historical operation shows:
6,800–8,200 units.
Current workload telemetry and technical requirements establish:
7,600–8,000 accelerator-equivalent units
as the supported Core Resource Demand range under the current operating state.
CRDM distinguishes:
10,000 installed capability
from:
9,000 requested capacity
from:
historical Resource Consumption
from:
the currently evidenced Resource requirement.
It creates the Core Resource Demand Profile with the evidence basis and remaining uncertainty.
FDIM subsequently determines the detailed functional structure of that Demand.
Installed compute capability does not define actual compute Demand.
154. Use Case 2 — Industrial Water Resource Demand
An industrial facility is permitted and technically capable of receiving:
50,000 m³/day.
Its internal planning system requests:
45,000 m³/day.
Historical Consumption averaged:
38,000 m³/day.
Current production requirements and process measurements establish:
34,000–37,000 m³/day
as the evidenced Core Resource Demand under the current operating state.
CRDM does not treat:
permitted intake capacity, requested capacity, or historical Consumption
as automatically equivalent to Demand.
It establishes the Resource requirement from the governed evidence.
The amount a facility can receive, asks to receive, or previously consumed is not automatically the amount it currently requires.
155. Critical Distinctions
Demand Signal ≠ Resource Demand
Demand Source ≠ Resource Source
Demand Origin ≠ Resource Origin
Joint Requirement ≠ Resource Equivalence
Required Quantity ≠ Required Rate
Demand Capacity ≠ Resource Consumption
Native Resource Demand ≠ Normalized Resource Significance
Requested Quantity ≠ Governed Demand Quantity
Declared Quantity ≠ Validated Demand Quantity
Installed Consumption Capability ≠ Resource Demand
Historical Consumption ≠ Current Resource Demand
Current Consumption ≠ Resource Demand by definition
Low Consumption ≠ Low Demand
High Consumption ≠ High Demand by definition
Numerical Precision ≠ Evidentiary Precision
Assumption ≠ Evidence
Core Demand Identification ≠ Full Functional Demand Governance
Core Demand Quantity ≠ Peak Demand Determination
Individual Demand ≠ Concurrent Demand Structure
Demand ≠ Availability
Demand Quantity ≠ Criticality
Demand ≠ Access Authorization
Demand Magnitude ≠ Resource Priority
Governed Demand ≠ Allocated Resource
Demand Declaration Capability ≠ Resource Authority
156. Cross-Architecture Boundary
CRDM governs foundational Resource Demand formation within RDGS.
It may consume inputs from:
RCHS for Resource identity and characterization; RACS for Resource Availability & Capacity context; PGA™ for predicted Demand; SIMULOS® for simulated Demand; ORA™ for operational evidence; VEGA™ for relevant efficiency and Resource-use information; specialized Resource systems for technical Resource requirements.
It does not absorb their governed mechanisms.
157. 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 workload scheduler may produce compute requirements.
A production system may produce material requirements.
A building-management system may produce cooling or electricity requirements.
A hydrological model may produce water-demand estimates.
CRDM consumes those outputs to form governed Resource Demand.
It does not absorb the mechanisms that produced them.
158. Canonical Boundary
CRDM governs the foundational transformation of a Resource requirement signal into an identified, bounded, measured, evidenced, uncertainty-aware, and sufficiently governable Core Resource Demand object.
It does not determine detailed Functional Demand, Peak Demand, Demand concurrency, final Demand consolidation, Resource Dependency, Criticality, Access, Priority, Allocation, Consumption, Scarcity, Resilience, or Sustainability.
Its principal governed output is the Core Resource Demand Profile used by the remaining RDGS Core Modules.
159. Canonical Closing Statement
A Resource requirement does not become governed Demand merely because it appears in a request, a technical specification, a consumption record, or a system configuration.
CRDM establishes the Demand object itself — what Resource is required, who or what requires it, how much is required, where its boundary lies, and what evidence supports that requirement — before Resource Demand is allowed to proceed deeper into governance.