DCMM — Demand Consolidation & Management 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: Resource Demand Consolidation & Management Governance
Module ID: RSGA-RDGS-DCMM-05
Origin ID: OOF-RSGA-RDGS-DCMM
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
DCMM — Demand Consolidation & Management Module governs how Core Resource Demand, Functional Demand, Peak Demand, and Concurrent & Parallel Demand are reconciled, consolidated, structured, maintained, updated, and released as a coherent governed Resource Demand representation without erasing material differences in function, time, location, operating state, concurrency, evidence, uncertainty, or Demand status.
DCMM establishes the consolidated Demand output of RDGS.
Demand Consolidation ≠ Simple Demand Summation.
2. Operational Role
CRDM establishes the Core Resource Demand object.
FDIM establishes why the Resource is required.
PKDM establishes materially relevant Peak Demand.
CPDM establishes which Resource requirements actually occur together.
DCMM consolidates these governed states into a coherent Resource Demand representation for downstream RSGA™ governance.
Its role is to determine:
which Demand objects belong together; which Demand objects must remain separate; which values can legitimately be aggregated; which Demand relationships must remain visible; how normal, Peak, concurrent, conditional, and unresolved Demand are represented;
how duplication is prevented; how uncertainty propagates; how Demand changes are maintained; and what Demand state may legitimately proceed downstream.
3. Core Question
What is the coherent governed Resource Demand state after Core, Functional, Peak, Concurrent, Parallel, temporal, spatial, evidentiary, and uncertainty relationships have been reconciled without creating false aggregation or losing material Demand distinctions?
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
DCMM is the final Core Module of RDGS.
Its principal output becomes the governed Demand input for downstream RSGA™ stages.
5. Governed Space
DCMM governs:
Resource Demand Consolidation & Management Governance
This space concerns the formation, maintenance, reconciliation, and controlled evolution of the consolidated Resource Demand representation.
6. Governed Object
The primary Governed Object is:
The consolidated Resource Demand state for a defined Resource, Resource System, Demand boundary, location, time horizon, or governed Resource context.
The Governed Object may contain:
Core Demand; Functional Demand; Normal Demand; Peak Demand; Concurrent Demand; Parallel Demand; Shared Demand; Conditional Demand; Future Demand; Residual Demand; Unresolved Demand.
7. Scope
DCMM applies wherever multiple governed Demand states must be reconciled into a coherent Resource Demand representation.
Its Scope includes:
Demand consolidation; Demand reconciliation; Demand aggregation; Demand disaggregation; Demand hierarchy; Demand deduplication; Demand grouping; Demand segmentation; Demand portfolio representation; normal Demand; Peak Demand; concurrent Demand; parallel Demand; shared Demand; conditional Demand; residual Demand; future Demand; Demand ranges; Demand uncertainty; Demand conflict; Demand sufficiency; Demand state management; Demand lifecycle management; Demand versioning; Demand reassessment; Demand release; downstream Demand handoff.
DCMM does not independently determine:
Resource Dependency; Criticality; Access authorization; Resource Priority; Resource Allocation; Resource Consumption; Scarcity response; Recovery; Substitution; Resilience; long-term Sustainability.
8. Entry Inputs
DCMM may receive:
Core Resource Demand Profile
Functional Demand Profile
Peak Demand Profile
Concurrent & Parallel Demand Profile
together with relevant evidence, uncertainty, state, and version information.
9. Consolidated Resource Demand
Consolidated Resource Demand is the governed representation of Resource requirement after relevant Demand relationships have been reconciled.
It is not necessarily one number.
10. Consolidation Principle
A complex Resource Demand reality should not be reduced to a single value where doing so would destroy material governance information.
11. Consolidation vs Summation
Consolidation may involve:
summation; segmentation; hierarchical representation; range representation; temporal profile; functional profile; concurrent profile; separate unresolved states.
Therefore:
Demand Consolidation ≠ Simple Demand Summation.
12. Consolidation Objective
The objective is not numerical simplification.
The objective is:
coherent Demand representation.
13. Demand Reconciliation
DCMM reconciles Demand states produced by upstream RDGS modules.
14. Reconciliation Questions
DCMM should determine:
Do these Demand objects represent the same Resource?
Do they belong to the same Demand boundary?
Do they occur within compatible time intervals?
Are they independent or overlapping?
Are they additive?
Does one already include another?
Do they represent normal, Peak, concurrent, or conditional states?
Are they observed, predicted, simulated, planned, or assumed?
15. Resource Identity Integrity
Only Resource Demand that is methodologically compatible should be aggregated.
16. Cross-Resource Boundary
Demand for different Resources must not be physically summed into one Resource quantity.
17. Cross-Resource Demand Representation
A multi-Resource requirement may be represented as:
Resource A Demand = X
Resource B Demand = Y
Resource C Demand = Z
rather than:
X + Y + Z = Total Resource Demand.
18. Native Measurement Preservation
DCMM should preserve native Resource measurement before any governed normalization.
Native Resource Demand ≠ Normalized Resource Significance.
19. Unit Compatibility
Demand values should only be aggregated where their units and measurement semantics are compatible.
20. Measurement Semantic Integrity
Two values expressed in the same unit may still represent different Resource conditions.
Example:
MW instantaneous capacity
and:
MW averaged across a different interval
may require additional reconciliation.
21. Demand Boundary Compatibility
Demand objects should share a sufficiently compatible governance boundary before aggregation.
22. Boundary Mismatch
Demand from different:
facilities; systems; functions;
regions; network zones; time periods
should not be merged without preserving the distinction where material.
23. Demand Hierarchy
DCMM should preserve hierarchical Demand structures.
Example:
Facility Demand
may contain:
Compute Demand
Cooling Demand
Networking Demand
Shared Infrastructure Demand
24. Parent Demand
A Parent Demand may represent an aggregate Resource requirement containing multiple Demand components.
25. Child Demand
A Child Demand represents a component already included within a Parent Demand.
26. Hierarchy Integrity
Parent Demand + Included Child Demand ≠ Valid Consolidated Demand.
27. Demand Deduplication
DCMM should prevent the same underlying Resource requirement from appearing multiple times in the consolidated state.
28. Duplicate Demand Sources
Duplication may arise from:
multiple monitoring systems; separate organizational reporting; copied planning records; parallel databases; overlapping Demand boundaries; aggregate and component records.
29. Duplicate Detection
Relevant comparison may include:
Demand ID
Resource ID
Demand Source
Function
Boundary
Time
Location
Measurement basis
Underlying requirement
30. Duplicate vs Similar Demand
Two similar Demand values are not automatically duplicates.
They may represent independent Resource requirements.
31. Demand Aggregation
Demand may be aggregated where:
Resource identity is compatible; measurement semantics are compatible; Demand boundaries permit aggregation; time relationships are valid; additivity is established; duplication is excluded.
32. Demand Disaggregation
An aggregate Demand may need to remain decomposable into its material components.
33. Reversible Consolidation
Where practical, DCMM should preserve sufficient structure to explain how consolidated Demand was formed.
34. Consolidation Traceability
A consolidated Demand state should remain traceable to upstream Demand objects.
35. Consolidation Provenance
At minimum, provenance should identify relevant:
CRDM Profiles
FDIM Profiles
PKDM Profiles
CPDM Profiles
evidence
transformations
versions
36. Core Demand Preservation
DCMM should preserve the foundational Demand established by CRDM.
37. Functional Demand Preservation
Functional Demand structure should remain available where function materially affects downstream governance.
38. Peak Demand Preservation
Peak Demand should not disappear into an average or normal Demand value.
39. Concurrent Demand Preservation
Concurrent Resource requirements should remain identifiable.
40. Parallel Demand Preservation
Operationally parallel Demand relationships should remain visible where relevant.
41. Shared Demand Preservation
Shared Resource Demand should remain represented without duplication.
42. Residual Demand Preservation
Unexplained or residual Demand should not be silently distributed into known functions.
43. Conditional Demand Preservation
Demand dependent upon specified conditions should remain conditional.
44. Future Demand Preservation
Future Demand should retain its future-state classification.
45. Observed Demand
Observed Demand should remain distinguishable from non-observed Demand states.
46. Predicted Demand
Predicted Demand should retain Prediction provenance.
Predicted Demand ≠ Observed Demand.
47. Simulated Demand
Simulated Demand should retain Simulation provenance.
Simulated Demand ≠ Observed Demand.
48. Planned Demand
Planned Demand should remain distinguishable from current operational Demand.
49. Assumed Demand
Assumed Demand must remain explicitly identified.
50. Demand Epistemic Integrity
Observed, measured, derived, planned, predicted, simulated, and assumed Demand must not be silently collapsed into one epistemically undifferentiated state.
51. Normal Demand
DCMM may preserve a normal operating Resource Demand state.
52. Peak Demand
Peak Demand remains a separate upper Resource requirement condition.
53. Normal vs Peak Demand
Normal Demand ≠ Peak Demand.
Both may belong to the consolidated Resource Demand representation.
54. Concurrent Demand
Concurrent Demand represents the Resource requirement occurring simultaneously across relevant Demand objects.
55. Consolidated Peak Demand
A Consolidated Peak represents the highest materially relevant Demand condition after concurrency and hierarchy have been reconciled.
56. Individual Peak vs Consolidated Peak
Sum of Individual Peaks ≠ Consolidated Peak Demand by definition.
57. Peak Coincidence
Consolidated Peak Demand should use CPDM Peak coincidence information.
58. Non-Coincident Peaks
Non-coincident Peaks should remain separate rather than being artificially summed.
59. Peak Diversity
Temporal diversity may reduce consolidated simultaneous Peak Demand.
It does not eliminate the underlying individual Resource requirements.
60. Demand Curve
Where appropriate, DCMM may preserve a time-indexed Resource Demand curve.
61. Demand Curve Components
A Demand curve may show:
baseline Demand; normal variation; Peak Demand; concurrent Demand; conditional Demand; Demand transitions.
62. Demand Envelope
Where exact future or variable Demand cannot be represented by one curve, DCMM may maintain a Demand Envelope.
63. Demand Envelope Definition
A Demand Envelope may contain:
minimum Demand; normal Demand range; Peak Demand range; conditional upper state; uncertainty bounds.
64. Demand Range
Demand ranges should be used where evidence does not justify a single precise value.
65. False Consolidation Precision
Consolidating uncertain Demand does not make the uncertainty disappear.
66. Uncertainty Aggregation
DCMM should not mechanically add uncertainty values unless the method is valid.
67. Uncertainty Propagation
Material upstream uncertainty must propagate into the consolidated Demand representation.
68. Demand Conflict
Conflicted upstream Demand states should not be silently resolved by averaging them.
69. Conflict Preservation
Where evidence conflict cannot be legitimately resolved, the consolidated state should preserve the conflict.
70. Demand Reconciliation Conflict
Conflict may concern:
Resource identity; Demand quantity; function; time; location; Peak state; concurrency; measurement basis; Demand provenance.
71. Conflict Resolution Logic
Canonical logic:
**Demand State A
Demand State B → Resource Check → Boundary Check → Function Check → Temporal Check → Location Check → Measurement Check → Hierarchy Check → Concurrency Check → Evidence Check → Resolution or Preserved Conflict**
72. Demand Sufficiency
DCMM determines whether the consolidated Resource Demand representation is sufficiently governed for downstream RSGA™ use.
73. Sufficient Consolidated Demand
A consolidated Demand state may be sufficient where material:
Resource identity; Demand boundary; quantity/capacity/rate; function; time; Peak; concurrency; evidence; uncertainty
are adequately represented for the intended downstream governance.
74. Conditional Consolidated Demand
A consolidated Demand state may proceed conditionally where remaining limitations are explicit.
75. Partially Consolidated Demand
Some Demand components may remain unresolved while others are sufficiently governed.
76. Demand Evidence-Limited
Insufficient evidence may prevent reliable consolidation.
77. Demand Conflicted
Material unresolved evidence conflicts may produce a Conflicted consolidated state.
78. Demand Unknown
Demand may remain Unknown where the Resource requirement cannot be sufficiently determined.
79. Demand Unresolved
Demand may remain Unresolved where governance cannot yet complete the consolidation.
80. Consolidated Demand Decision States
At minimum:
Consolidated Demand Established
Conditionally Consolidated
Partially Consolidated
Demand Evidence-Limited
Demand Conflicted
Demand Unknown
Demand Unresolved
81. Resource Demand Profile
The principal RDGS output produced through DCMM is the:
Resource Demand Profile
82. Resource Demand Profile Role
The Resource Demand Profile represents the governed Demand reality that may proceed into downstream RSGA™ governance.
83. Minimum Resource Demand Profile Fields
At minimum:
Resource Demand Profile ID
Resource ID
Demand Boundary
Demand Source(s)
CRDM References
FDIM References
PKDM References
CPDM References
Core Demand
Functional Demand Structure
Normal Demand
Peak Demand
Concurrent Demand
Native Measurement
Temporal Reference
Location Reference
Demand State
Evidence Basis
Evidence Time
Uncertainty
Sufficiency State
Version:
84. Extended Profile Fields
Where relevant, the profile may also include:
Demand Rate
Demand Duration
Peak Duration
Peak Recurrence
Concurrent Demand Curve
Shared Demand
Residual Demand
Conditional Demand
Future Demand
Prediction Reference
Simulation Reference
Reassessment Trigger
85. Demand Portfolio
Complex Resource Systems may require a Demand Portfolio rather than one aggregate Demand value.
86. Demand Portfolio Structure
A Demand Portfolio may preserve Demand by:
function; participant; facility; location; time; operating state; Resource Source relationship; Demand status.
87. Portfolio Integrity
A Demand Portfolio should not imply that all contained Demand is simultaneous or additive.
88. Demand Segmentation
DCMM may segment Demand into governance-relevant categories.
89. Temporal Segmentation
Demand may be segmented by:
current; near-term; future; seasonal; event-driven; recurring.
90. Functional Segmentation
Demand may be segmented by function.
91. Spatial Segmentation
Demand may be segmented by location or Resource node.
92. Operational Segmentation
Demand may be segmented by operating state.
93. Epistemic Segmentation
Demand may be segmented by:
observed; measured; derived; planned; predicted; simulated; assumed.
94. Demand Management
Demand Management within DCMM means:
maintaining the governed Demand representation as Resource requirements change.
It does not mean deciding which Demand should be satisfied.
95. Demand Management Boundary
Demand Management ≠ Resource Allocation Management.
96. Demand State Maintenance
DCMM should maintain the current governed Demand state as upstream Demand objects change.
97. Demand Addition
A new governed Demand object may enter the consolidated profile.
98. Demand Removal
A terminated Demand object may be removed from the active consolidated state while remaining in historical records.
99. Demand Modification
Material changes to Demand should update the consolidated profile.
100. Demand Activation
Conditional or inactive Demand may become active.
101. Demand Deactivation
Active Demand may become inactive.
102. Demand Suspension
Demand may be temporarily suspended without terminating the underlying Demand identity.
103. Demand Termination
A Resource requirement may permanently cease.
104. Demand Reopening
A previously inactive or terminated Demand may reappear.
Its identity relationship should be determined rather than assumed.
105. Demand Lifecycle
A Demand object may transition through:
Candidate → Established → Active → Modified → Conditional → Suspended → Reactivated → Terminated
where applicable.
106. Lifecycle Flexibility
Not every Demand object must pass through every state.
107. Demand State Transition Evidence
Material state transitions should preserve evidence.
108. Demand Change Detection
DCMM should detect material upstream changes affecting the consolidated profile.
109. Change Sources
Changes may originate from:
CRDM; FDIM; PKDM; CPDM; new operational evidence; system configuration; new Demand object; Demand termination; time progression.
110. Change Propagation
A material upstream change should propagate to affected consolidated Demand states.
111. Change Isolation
A change to one Demand object should not unnecessarily invalidate unrelated Demand objects.
112. Demand Versioning
Material consolidated Demand changes should create a new profile version.
113. Version Traceability
Each version should preserve:
previous state; new state; changed Demand objects; reason for change; evidence; effective time.
114. Current vs Historical Demand
Historical Resource Demand Profiles should remain distinguishable from current profiles.
115. Demand Baseline
A governed baseline may be maintained for comparison.
116. Baseline Boundary
The baseline does not automatically define current Demand.
117. Demand Trend
Versioned Demand states may reveal trends.
Trend analysis should preserve changes in:
boundary; measurement; function; operating conditions.
118. Demand Growth
Increasing Demand may reflect:
higher workload; expanded function; population growth; system expansion; lower efficiency; changed operating conditions.
DCMM records the Demand change.
It does not determine whether the growth is justified.
119. Demand Reduction
Demand may decline because of:
lower activity; efficiency improvement; function termination; technical change; Demand shifting; Resource substitution.
120. Demand Reduction vs Suppression
Reduced observed Resource use may result from supply constraint rather than lower Demand.
Reduced Consumption ≠ Reduced Demand by definition.
121. Suppressed Demand
Where Resource shortage prevents Demand from being served, DCMM should preserve the governed Demand rather than replacing it with actual Consumption.
122. Unmet Demand
A portion of governed Demand may remain unmet.
This does not invalidate the Demand.
123. Unmet Demand Boundary
DCMM may represent unmet Demand as Demand state information.
It does not determine the allocation response.
124. Latent Demand
Latent Demand supported by evidence may remain represented separately from active Demand.
125. Demand Shift
Resource Demand may move from one time interval to another.
126. Demand Shift Accounting
A Demand shift should update:
original interval; new interval; Peak relationships; concurrency relationships; consolidated Demand curve.
127. Demand Shift vs Demand Reduction
Demand Shift ≠ Demand Reduction.
128. Demand Substitution Boundary
A function may change the Resource it requires.
RSFS governs Resource Substitution & Flexibility.
DCMM updates the Demand representation based on the governed change.
129. Resource Replacement
Where Resource A Demand is replaced by Resource B Demand, DCMM should not treat the two as one physically equivalent Resource quantity.
130. Demand and Availability
DCMM may compare the Resource Demand Profile with the RACS Resource Availability & Capacity Profile.
The two remain separate governance objects.
131. Demand-Capacity Relationship
A downstream comparison may show:
Available Capacity > Demand
Available Capacity ≈ Demand
Available Capacity < Demand
Relationship Unresolved
132. Demand-Capacity Independence
Resource Demand must not be altered merely to make it fit available capacity.
Resource Demand Reality ≠ Resource Capacity Reality.
133. Demand and Dependency
The Resource Demand Profile may proceed to RDCS.
RDCS determines Dependency and Criticality.
134. Demand vs Dependency
How much Resource is required ≠ How strongly the system depends upon it.
135. Demand and Criticality
Demand magnitude does not establish Criticality.
136. Demand and Access
The Resource Demand Profile does not establish Resource Access authorization.
Governed Demand ≠ Resource Access Right.
137. Demand and Priority
DCMM does not rank Demand.
Consolidated Demand ≠ Resource Priority.
138. Demand and Allocation
DCMM does not decide which Demand receives Resource.
Resource Demand Profile ≠ Allocation Decision.
139. Demand and Consumption
Actual Resource Consumption may later differ from governed Demand.
140. Demand and Utilization
Resource utilization does not redefine the Demand Profile unless new evidence changes the underlying Resource requirement.
141. Demand and Scarcity
Demand may contribute to a Scarcity condition when compared with Resource capacity and other governance factors.
DCMM does not establish Scarcity.
142. Demand and Recovery
Recovered Resource may affect Resource capacity.
It does not automatically alter underlying Demand.
143. Demand and Flexibility
Flexible Demand may be shifted, reduced, deferred, or satisfied through alternative mechanisms where downstream governance permits.
DCMM preserves the Demand characteristics.
144. Demand and Resilience
Resource Demand profiles may inform resilience analysis.
RIRS retains Resource Interdependency & Resilience Governance.
145. Demand and Sustainability
A fully governed Demand Profile may still describe an unsustainable Resource requirement.
Governed Demand ≠ Sustainable Demand by definition.
146. Demand and Value
A Resource Demand may support Value.
Value does not determine Demand quantity.
VEGA™ retains relevant Value Governance.
147. Demand and Harm
Demand satisfaction or non-satisfaction may contribute to Harm.
HAGA™ retains Harm Governance.
148. Demand and Liability
Demand states do not establish Liability.
LIGA™ retains Liability Governance.
149. Demand and Authority
DCMM does not create authority over Resource.
Demand Governance ≠ Resource Authority.
150. Demand Release
A sufficiently governed Resource Demand Profile may be released to downstream RSGA™ stages.
151. Release Condition
Release requires sufficient Demand representation for the intended downstream governance.
It does not require all uncertainty to disappear.
152. Conditional Release
Demand may proceed conditionally where remaining uncertainty is explicitly preserved.
153. Release with Conflict
Material unresolved conflict should remain visible and may restrict downstream decisions depending on governance consequence.
154. Downstream Demand Consumers
The Resource Demand Profile may inform:
RDCS — Resource Dependency & Criticality Standard
RAGS — Resource Access Governance Standard
RPAS — Resource Prioritization & Allocation Standard
and later RSGA™ stages.
155. Demand Handoff Integrity
Downstream governance should receive:
Demand state; evidence; uncertainty;
conditions; version; material unresolved issues
rather than a context-free number.
156. Structured Output Principle
DCMM should prioritize structured Demand objects before narrative representation.
Canonical order:
Evidence → Governed Demand Objects → Demand Relationships → Consolidated Demand State → Downstream Decision Evidence → Narrative
157. Narrative Boundary
A narrative summary may explain Demand.
It should not replace the structured Resource Demand Profile.
158. Machine-Readable Demand
Where implemented computationally, DCMM should support machine-readable representation of:
Demand objects; relationships; states; evidence; uncertainty; versions; reassessment triggers.
159. Auditability
A downstream user should be able to determine:
where Demand came from; which Demand objects were included; which were excluded; which were shared; which were deduplicated; which Peaks were concurrent; which evidence supported the result; which uncertainty remains.
160. Explainability
DCMM should be able to explain why the consolidated Demand state differs from:
sum of requests; sum of installed capability; sum of individual Peaks;
historical Consumption; current Consumption.
161. Consolidation Integrity Principle
Consolidation must preserve the Resource reality that created Demand, not merely produce the smallest or simplest dataset.
162. Demand Separation Principle
Demand states that differ materially in function, time, location, evidence, concurrency, or epistemic status must remain distinguishable after consolidation.
163. Demand Non-Distortion Principle
Demand must not be increased or reduced merely to support a preferred downstream governance outcome.
164. Uncertainty Preservation Principle
Consolidation may organize uncertainty; it does not erase uncertainty.
165. Evidence Preservation Principle
A consolidated Demand state must remain traceable to the evidence and governed Demand objects from which it was formed.
166. Management Boundary Principle
Managing the representation of Demand is not the same as deciding whether, when, or how that Demand should be satisfied.
167. Minimum Implementation Framework
A minimum operational DCMM implementation should contain nine governed layers.
Layer 1 — Governed Demand Inputs
Receive:
CRDM Profiles FDIM Profiles PKDM Profiles CPDM Profiles
Layer 2 — Compatibility
Assess:
Resource identity Units Measurement semantics Demand boundary
Time Location
Layer 3 — Hierarchy & Deduplication
Determine:
Parent Demand Child Demand Duplicate Demand Shared Demand Residual Demand
Layer 4 — Demand Relationship Preservation
Preserve:
Functional Demand Peak Demand Concurrent Demand Parallel Demand Conditional Demand
Layer 5 — Consolidation
Determine:
Valid aggregation Required segmentation Demand ranges Demand curve / envelope Demand portfolio
Layer 6 — Evidence & Conflict
Preserve:
Evidence provenance Epistemic state Conflict Unresolved evidence
Layer 7 — Uncertainty & Sufficiency
Determine:
Demand uncertainty Consolidated Demand State Sufficiency State
Layer 8 — Demand Management
Maintain:
Lifecycle state Changes Version Reassessment triggers
Layer 9 — Governed Output
Produce:
Resource Demand Profile Known limitations
Downstream release state
Minimum machine-readable logic:
**CRDM[]
FDIM[] PKDM[] CPDM[] → Compatibility Checks[] → Hierarchy[] → Deduplication[] → Functional / Peak / Concurrent Relationships[] → Consolidation → Evidence[] → Conflict[] → Uncertainty[] → Demand State → Sufficiency → Resource Demand Profile → Downstream Release**
168. Minimum Decision States
At minimum:
Consolidated Demand Established
Conditionally Consolidated
Partially Consolidated
Demand Evidence-Limited
Demand Conflicted
Demand Unknown
Demand Unresolved
169. Minimum Evidence Path
Where consolidated Demand cannot be sufficiently established:
Demand Unresolved → Material Consolidation Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Upstream Module Reassessment where required → Consolidation Reassessment → Updated Resource Demand Profile
The objective is sufficient evidence for a coherent Demand representation, not artificial completeness.
170. Minimum Reassessment Framework
At minimum:
Current Resource Demand Profile → New Evidence / Upstream Change / Material Event → Demand Impact Test → Affected Module Reassessment
→ Consolidation Update → Profile Version Update → Downstream Reassessment Trigger
171. Governance Requirements
A conforming DCMM implementation must:
1. receive governed outputs from upstream RDGS modules; 2. preserve Resource identity; 3. preserve native measurement; 4. verify unit compatibility; 5. verify measurement semantics; 6. preserve Demand boundaries; 7. preserve functional Demand; 8. preserve Peak Demand; 9. preserve concurrency relationships; 10. preserve parallel Demand relationships; 11. preserve shared Demand; 12. preserve residual Demand; 13. preserve conditional Demand; 14. preserve future Demand status; 15. distinguish observed from predicted Demand; 16. distinguish observed from simulated Demand; 17. preserve Demand hierarchy; 18. detect duplicate Demand; 19. prevent hierarchical double-counting; 20. prevent invalid Peak summation; 21. support valid Demand aggregation; 22. support Demand disaggregation; 23. support Demand ranges; 24. preserve material uncertainty; 25. preserve material conflict; 26. determine Demand sufficiency; 27. maintain Demand lifecycle state; 28. support Demand reassessment; 29. support versioning; 30. produce a governed Resource Demand Profile; 31. preserve downstream traceability; 32. prevent Demand Management from becoming Priority or Allocation governance.
172. Governance Logic
Canonical DCMM logic:
**CRDM Profiles
FDIM Profiles PKDM Profiles CPDM Profiles → Resource Compatibility → Boundary Compatibility → Unit / Measurement Compatibility → Demand Hierarchy → Duplicate Detection → Functional Relationship Preservation → Peak Relationship Preservation → Concurrency Preservation → Shared / Residual / Conditional Demand → Valid Aggregation / Required Segmentation → Evidence Reconciliation → Conflict
→ Uncertainty → Demand Sufficiency → Resource Demand Profile → Downstream Release**
Where Demand is unresolved:
Consolidated Demand State → Material Evidence / Relationship Gap → Minimum Evidence Requirement → Upstream or Direct Evidence Acquisition → Reassessment → Updated Consolidation
Where Demand changes:
Existing Resource Demand Profile → Material Change → Affected Demand Object Identification → Upstream State Update → Consolidation Update → Version Update → Downstream Reassessment
173. Governance Outputs
DCMM may produce:
Resource Demand Profile
Consolidated Demand State
Normal Demand State
Peak Demand State
Concurrent Demand State
Parallel Demand State
Functional Demand Structure
Shared Demand State
Residual Demand State
Conditional Demand State
Future Demand State
Demand Curve
Demand Envelope
Demand Portfolio
Demand Hierarchy
Demand Deduplication Record
Demand Conflict State
Demand Uncertainty State
Demand Sufficiency State
Demand Version
Reassessment Trigger
Downstream Release State
174. Downstream Release State
Possible states may include:
Released
Conditionally Released
Released with Explicit Uncertainty
Released with Explicit Conflict
Held for Evidence
Held for Reassessment
Not Sufficiently Governed
175. Failure Conditions
DCMM should not be considered sufficiently completed where:
Demand consolidation is treated as simple summation; different Resources are physically summed; incompatible units are combined; measurement semantics are ignored; Demand boundaries are collapsed without justification; Parent and Child Demand are double-counted; duplicate Demand records are counted independently; individual Peaks are automatically summed; non-concurrent Demand is represented as simultaneous; shared Demand is counted repeatedly; residual Demand is silently distributed; conditional Demand is represented as unconditional; predicted Demand is represented as observed Demand; simulated Demand is represented as observed Demand; planned Demand is represented as current Demand; uncertainty disappears during aggregation; conflicting Demand is averaged without methodological basis; available capacity is used to alter Demand artificially; Consumption replaces governed Demand; Demand Management is used to rank Demand; Demand Management becomes Allocation; Demand state is released without traceable evidence; material upstream changes fail to trigger reassessment.
176. Use Case 1 — AI Data Center Consolidated Electricity Demand
CRDM establishes a Core electricity Demand.
FDIM identifies:
AI compute
Cooling
Storage & networking
Shared infrastructure
PKDM identifies materially relevant Peaks.
CPDM determines which functional Demands and Peaks actually overlap.
A naive system might report:
Compute Peak = 48 MW
Cooling Peak = 12 MW
Storage & Network Peak = 4 MW
Shared Infrastructure Peak = 5 MW
and conclude:
Total Peak Demand = 69 MW.
CPDM establishes that the individual Peaks do not all occur simultaneously.
DCMM therefore preserves:
Normal consolidated Demand
Functional Demand structure
Actual coincident Peak Demand
Peak windows
Shared infrastructure Demand
Evidence and uncertainty
rather than creating a false 69 MW system Peak.
The resulting Resource Demand Profile can then proceed to Dependency, Access, Priority, and Allocation governance.
Consolidation explains the Resource requirement as a system; it does not merely add every visible number.
177. Use Case 2 — Regional Water Demand Consolidation
A regional water system contains Demand from:
Residential use
Industrial processes
Agriculture
Cooling
Public infrastructure
FDIM identifies the functional requirements.
PKDM identifies seasonal and functional Peaks.
CPDM determines which Peaks and normal Demand states overlap.
DCMM preserves:
normal regional Demand; summer Demand range; actual concurrent Peak; location-specific Demand; conditional agricultural Demand; future predicted Demand; unresolved Demand components.
It does not combine:
current Demand
and:
predicted future Demand
into one undifferentiated number.
It does not automatically sum every functional Peak.
It does not treat historical Consumption as current Demand.
The resulting Resource Demand Profile represents the actual governed Demand structure required by downstream RSGA™ governance.
One regional Demand number may be convenient. A governed Resource Demand Profile must preserve the Resource reality behind that number.
178. Critical Distinctions
Demand Consolidation ≠ Simple Demand Summation
Native Resource Demand ≠ Normalized Resource Significance
Parent Demand + Included Child Demand ≠ Valid Consolidated Demand
Predicted Demand ≠ Observed Demand
Simulated Demand ≠ Observed Demand
Normal Demand ≠ Peak Demand
Sum of Individual Peaks ≠ Consolidated Peak Demand by definition
Consolidating uncertain Demand does not make uncertainty disappear
Demand Management ≠ Resource Allocation Management
Reduced Consumption ≠ Reduced Demand by definition
Demand Shift ≠ Demand Reduction
Resource Demand Reality ≠ Resource Capacity Reality
How much Resource is required ≠ How strongly the system depends upon it
Governed Demand ≠ Resource Access Right
Consolidated Demand ≠ Resource Priority
Resource Demand Profile ≠ Allocation Decision
Governed Demand ≠ Sustainable Demand by definition
Demand Governance ≠ Resource Authority
179. Cross-Architecture Boundary
DCMM governs Resource Demand consolidation and Demand-state management within RDGS.
It may consume inputs from:
RCHS for Resource characterization; RACS for Resource Availability & Capacity context; CRDM for Core Resource Demand; FDIM for Functional Demand; PKDM for Peak Demand; CPDM for Concurrent & Parallel Demand; PGA™ for predicted Demand; SIMULOS® for simulated Demand; ORA™ for operational evidence; VEGA™ for relevant efficiency and Value information; specialized Resource systems for technical Resource requirements.
It does not absorb their governed mechanisms.
180. 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.
Operational systems may generate Resource Demand.
Prediction systems may estimate future Demand.
Simulation systems may test Demand scenarios.
Scheduling systems may change concurrency.
Efficiency systems may reduce Resource requirements.
DCMM consumes their governed outputs where relevant.
It does not absorb the mechanisms that produced them.
181. Canonical Boundary
DCMM governs how the Resource Demand states established across RDGS are reconciled, consolidated, structured, maintained, versioned, and released as a coherent Resource Demand Profile while preserving material functional, temporal, spatial, Peak, concurrency, evidentiary, epistemic, and uncertainty distinctions.
It does not determine Resource Dependency, Criticality, Access authorization, Priority, Allocation, Consumption governance, Scarcity response, Recovery, Substitution, Resilience, or long-term Sustainability.
Its principal governed output is the Resource Demand Profile , representing the final governed Demand state of RDGS.
182. Canonical Closing Statement
A Resource system does not have one meaningful Demand merely because its many requirements can be reduced to one number.
DCMM preserves the structure behind Resource Demand — what is required, for which functions, under which conditions, at what times, at what Peaks, and in which combinations — so that downstream governance receives Resource Demand reality rather than an arithmetic simplification.