CPDM — Concurrent & Parallel 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: Concurrent & Parallel Resource Demand Governance
Module ID: RSGA-RDGS-CPDM-04
Origin ID: OOF-RSGA-RDGS-CPDM
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
CPDM — Concurrent & Parallel Demand Module governs how multiple Resource Demand objects, Functional Demands, and Peak Demand states are temporally aligned, compared, related, and evidenced to determine which Resource requirements actually occur simultaneously, overlap partially, operate in parallel, remain mutually exclusive, or occur independently across time so that non-concurrent Resource requirements are not automatically aggregated as simultaneous Resource Demand.
CPDM establishes the Concurrent & Parallel Demand State within RDGS.
Demand A + Demand B ≠ Concurrent Demand unless their relevant Resource requirements actually overlap in time.
2. Operational Role
CRDM establishes Core Resource Demand.
FDIM establishes the functional structure of Resource Demand.
PKDM establishes Peak Demand.
CPDM determines which of those Resource requirements exist together.
Its role is to establish:
which Demand objects overlap; when they overlap; for how long they overlap; to what degree they overlap; whether their Peaks coincide; whether they operate independently or in parallel; whether they are mutually exclusive; whether they share underlying Resource requirements; and what simultaneous Resource requirement actually results.
3. Core Question
Which Resource Demand objects actually occur at the same time, how much of their Demand overlaps, for how long, under which conditions, and what simultaneous Resource requirement does that create?
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
CPDM provides the concurrency structure required before Resource Demand can be legitimately consolidated.
5. Governed Space
CPDM governs:
Concurrent & Parallel Resource Demand Governance
This space concerns temporal and operational relationships between multiple Resource Demand objects.
6. Governed Object
The primary Governed Object is:
The temporal and operational relationship between two or more governed Resource Demand objects.
The Governed Object may include:
simultaneous Demand; partially overlapping Demand; parallel Demand; sequential Demand; mutually exclusive Demand; coincident Peak Demand; non-coincident Peak Demand; shared Demand; interdependent Demand; conditional concurrent Demand.
7. Scope
CPDM applies wherever multiple Resource Demand objects may interact temporally or operationally and their combined Resource requirement must be determined.
Its Scope includes:
Demand temporal alignment; Demand overlap; simultaneous Demand; partial concurrency; full concurrency; parallel Demand; sequential Demand; mutually exclusive Demand; coincident Peaks; non-coincident Peaks; Demand overlap duration; Demand overlap magnitude; shared Resource Demand; conditional concurrency; event-driven concurrency; cross-function concurrency; cross-system concurrency; cross-location concurrency where relevant; cross-Resource functional concurrency;
concurrency evidence; concurrency uncertainty; concurrency conflict; concurrency reassessment; concurrency versioning.
CPDM does not independently determine:
final Demand consolidation; Resource Dependency; Criticality; Access authorization; Priority; Allocation; Consumption; Scarcity response; Resilience; Sustainability.
8. Entry Requirements
CPDM may receive:
Core Resource Demand Profiles
Functional Demand Profiles
Peak Demand Profiles
for two or more Demand objects.
9. Concurrent Demand
Concurrent Demand exists when two or more Resource requirements materially overlap within the same relevant temporal interval.
10. Simultaneous Demand
Simultaneous Demand represents Resource requirements active at the same relevant time.
11. Parallel Demand
Parallel Demand represents separate Resource-dependent activities operating concurrently.
Parallel operation may create additive, partially additive, shared, or otherwise related Resource Demand.
12. Concurrency vs Parallelism
Concurrency describes temporal overlap.
Parallelism describes operational activities proceeding alongside one another.
The two often coincide but are not methodologically identical.
13. Full Concurrency
Full Concurrency occurs when relevant Demand objects remain active together throughout the governed interval.
14. Partial Concurrency
Partial Concurrency occurs when Demand objects overlap for only part of their active intervals.
15. No Concurrency
Demand objects with no materially relevant temporal overlap should not be treated as simultaneous Demand.
16. Sequential Demand
Sequential Demand occurs when one Resource requirement follows another without material overlap.
17. Sequential Demand Principle
Sequential Demand ≠ Concurrent Demand.
18. Demand Timeline
CPDM should preserve the temporal position of each relevant Demand object.
Canonical representation:
Demand A: Start → Active → End
Demand B: Start → Active → End
Overlap: Intersection(A,B)
19. Temporal Intersection
Concurrency exists within the temporal intersection of Demand objects.
20. Overlap Window
The Overlap Window identifies the interval during which two or more Demand objects apply together.
21. Overlap Duration
Overlap Duration establishes how long concurrent Resource Demand persists.
22. Overlap Magnitude
Overlap Magnitude represents the Resource requirement existing during the concurrent interval.
23. Full Overlap
Two Demand objects may overlap throughout their entire active intervals.
24. Partial Overlap
Demand objects may overlap only partially.
The non-overlapping portions should remain distinct.
25. Overlap Fraction
Where useful, CPDM may represent the proportion of a Demand interval overlapping another Demand interval.
This is descriptive unless a specific governance interpretation is defined.
26. Temporal Granularity
Concurrency depends upon the temporal resolution used.
27. Granularity Integrity
Temporal resolution should be sufficiently precise to reveal materially relevant Demand overlap.
28. Coarse Granularity Risk
Daily Demand records may make two Resource requirements appear concurrent even when one occurs in the morning and another at night.
29. Excessive Granularity
Excessively fine resolution may add complexity without materially changing Resource governance.
30. Resource-Specific Concurrency Interval
Different Resource Systems may require different temporal resolution.
Examples:
Electricity — seconds/minutes
Compute — workload intervals
Water — minutes/hours/days
Materials — production cycles
Storage — capacity occupancy intervals
31. Same-Day ≠ Simultaneous
Two Demand objects occurring on the same day are not necessarily concurrent.
32. Same-Hour ≠ Simultaneous
Where Resource dynamics require finer resolution, two Demand objects occurring within the same hour may still be non- concurrent.
33. Coincident Demand
Coincident Demand occurs where Demand objects materially overlap during the same interval.
34. Coincident Peak Demand
Coincident Peak Demand occurs when materially high Demand states from multiple Demand objects overlap.
35. Individual Peak vs Coincident Peak
Individual Peak A + Individual Peak B ≠ Coincident Peak Demand unless the Peaks overlap.
36. Non-Coincident Peaks
Individual Demand objects may Peak at different times.
Their Peak values must remain temporally separated.
37. System Peak Formation
A System Peak may emerge from several moderate concurrent Demand objects rather than simultaneous individual maxima.
38. Peak Coincidence
CPDM should determine whether:
Peak A overlaps Peak B; Peak A overlaps normal Demand B; Peak B overlaps normal Demand A; neither Peak overlaps.
39. Peak Coincidence Window
The relevant Peak coincidence interval should remain explicit.
40. Peak Coincidence Duration
A short coincident Peak may have different Resource implications from a sustained coincident Peak.
41. Coincidence State
Possible states include:
Fully Coincident
Partially Coincident
Non-Coincident
Conditionally Coincident
Coincidence Unknown
42. Parallel Functional Demand
Different functions may operate simultaneously and require the same Resource.
43. Cross-Function Concurrency
Example:
AI computation + cooling + networking
may all require electricity concurrently.
CPDM determines the temporal relationship between their Resource requirements.
44. Supporting Function Concurrency
Supporting Resource Demand may be temporally linked to the Primary Function.
Example:
Compute operation → Cooling Demand
Cooling may overlap most or all of compute Demand.
45. Delayed Supporting Demand
Supporting Resource Demand may continue after the Primary Function reduces or stops.
Example:
Post-compute cooling
may continue after a workload ends.
46. Lead Demand
Some supporting systems require Resource before the Primary Function begins.
Example:
Pre-cooling
may create Resource Demand before compute operation.
47. Demand Lag
A Resource requirement may persist after the initiating function ends.
48. Functional Concurrency Chain
A functional Demand chain may therefore include:
Lead Demand → Primary Demand → Concurrent Supporting Demand → Lag Demand
49. Shared Demand
Multiple functions may share one Resource requirement.
Shared Demand must not automatically be counted once for every function.
50. Shared Infrastructure Demand
Examples include:
Shared cooling
Shared networking
Common pumps
Shared facility electricity
Common storage
51. Shared Demand Double-Counting
If one 10 MW cooling system supports two functions simultaneously:
10 MW shared cooling ≠ 20 MW merely because two functions use it.
52. Additive Demand
Demand objects are Additive where their Resource requirements are independent and simultaneously require separate Resource capacity.
53. Partially Additive Demand
Demand may be only partially additive where some Resource requirement is shared.
54. Non-Additive Demand
Demand objects may overlap temporally without requiring additive Resource capacity.
55. Additivity Test
Before summing concurrent Demand, CPDM should determine whether the Resource requirements are:
Independent
Shared
Overlapping
Substituting
Mutually exclusive
Already included within another Demand object
56. Additive ≠ Concurrent
Two Demand objects may be additive in principle but not concurrent in time.
Both conditions matter.
57. Concurrent ≠ Fully Additive
Two Demand objects may be concurrent while sharing Resource capacity.
58. Demand Inclusion
One Demand object may already include another Resource requirement.
The included Demand must not be added again.
59. Parent-Child Demand
A higher-level Demand may contain lower-level functional Demand components.
CPDM should preserve hierarchy to prevent double-counting.
60. Demand Hierarchy
Example:
Facility Electricity Demand
may already contain:
Compute Electricity
Cooling Electricity
Networking Electricity
Adding both facility total and all components would duplicate Demand.
61. Hierarchical Double-Counting
Aggregate Demand + Included Component Demand ≠ Valid Combined Demand.
62. Mutually Exclusive Demand
Two Demand states may be impossible to activate simultaneously.
63. Mutually Exclusive Operating Modes
Example:
A system may operate in:
Mode A
or:
Mode B
but not both.
Their maxima should not automatically be added.
64. Alternative Functional Paths
Two functions may represent alternative ways of producing the same outcome.
If only one path operates at a time, their Resource demands are not concurrent.
65. Conditional Concurrency
Demand objects may overlap only when defined conditions occur.
66. Event-Driven Concurrency
An event may activate several Resource requirements simultaneously.
Examples:
Emergency response
System recovery
Extreme weather
Production surge
67. Recurring Concurrency
Concurrency may repeat according to an operational cycle.
68. Seasonal Concurrency
Several Resource demands may become concurrent during seasonal conditions.
69. Demand Synchronization
Operational scheduling may intentionally synchronize Resource Demand.
70. Demand Desynchronization
Scheduling may intentionally separate Resource Demand in time.
CPDM represents the resulting Demand reality.
It does not independently decide whether desynchronization should occur.
71. Shifted Demand
A flexible Resource requirement may move to another time.
After the shift, concurrency must be reassessed.
72. Deferred Demand
Deferrable functions may reduce current concurrency by moving Resource Demand to a later interval.
73. Demand Rebound
Demand shifted away from one interval may create a new Peak or concurrent Demand condition later.
74. Temporal Demand Transfer
Demand management can move Resource requirement across time without reducing total Resource requirement.
Demand Shift ≠ Demand Elimination.
75. Cross-System Concurrency
Separate systems may demand the same Resource simultaneously.
76. Cross-Facility Concurrency
Facilities connected to the same Resource System may create concurrent Demand.
77. Cross-Location Concurrency
Demand at different locations may still be concurrent where they draw upon the same constrained Resource capacity.
78. Location-Concurrency Relationship
Spatial separation does not automatically eliminate Resource competition.
79. Common Resource Source
Demand at several locations may converge upon one Resource Source or infrastructure bottleneck.
CPDM may preserve this relationship as Demand context.
RACS retains Resource Availability & Capacity governance.
80. Local vs System Concurrency
Local Demand may be non-concurrent while aggregate system Demand remains concurrent across other locations.
81. Cross-Resource Concurrency
A function may require multiple Resources simultaneously.
Example:
Compute + electricity + cooling + network
This is cross-Resource functional concurrency.
82. Cross-Resource Physical Boundary
Different Resources remain physically distinct.
Their concurrent requirement does not make them additive into one physical Resource quantity.
83. Cross-Resource Concurrency Representation
Cross-Resource concurrency should preserve a Resource vector or relationship rather than false physical summation.
Example:
At Time T: Compute = X Electricity = Y Water = Z
not:
X + Y + Z = Total Resource.
84. Joint Resource Requirement
A function may fail if any one of several concurrently required Resources is unavailable.
CPDM records concurrency.
RDCS later governs Dependency and Criticality.
85. Concurrent Resource Bundle
A concurrent Resource bundle may represent multiple Resources required together.
Concurrent Resource Bundle ≠ Resource Equivalence.
86. Demand Synchronization with Availability
CPDM may compare Demand timing with RACS temporal Resource capacity as context.
It does not redefine either Demand or Availability.
87. Concurrent Demand vs Available Capacity
A relevant comparison may be:
Concurrent Demand at Time T ↔ Available Resource Capacity at Time T
The result becomes input to downstream governance.
88. Capacity Constraint Does Not Reduce Demand
If concurrent Demand is 100 and available capacity is 70:
Concurrent Demand remains 100 where evidence supports it.
89. Supply-Suppressed Concurrency
Observed Consumption may understate concurrent Demand when Resource capacity is constrained.
90. Concurrent Consumption vs Concurrent Demand
Concurrent Consumption ≠ Concurrent Demand by definition.
91. Concurrency Evidence
CPDM should preserve evidence establishing temporal overlap.
92. Temporal Evidence
Evidence may include:
timestamps; Resource measurements; workload schedules; system telemetry; production records; process logs; operating-state records.
93. Functional Evidence
FDIM outputs may establish which functions are active together.
94. Peak Evidence
PKDM outputs may establish whether Peak conditions overlap.
95. Scheduling Evidence
Operational schedules may support concurrency analysis.
Schedules must remain distinguishable from observed operation.
96. Observed Concurrency
Observed Concurrency is supported by operational evidence showing Demand overlap.
97. Planned Concurrency
Planned operation may imply future Demand overlap.
Planned Concurrency ≠ Observed Concurrency.
98. Predicted Concurrency
Prediction may estimate future Demand overlap.
Predicted Concurrency ≠ Current Concurrency.
PGA™ retains Prediction Governance.
99. Simulated Concurrency
Simulation may model Demand overlap under hypothetical conditions.
Simulated Concurrency ≠ Observed Concurrency.
SIMULOS® retains Simulation Governance.
100. Assumed Concurrency
Concurrency assumed without sufficient evidence should remain explicitly classified as assumed.
101. Concurrency Evidence Provenance
Evidence should preserve where relevant:
Demand IDs
Resource ID
Function IDs
Time
Measurement interval
Location
Evidence source
Operating state
Version:
102. Evidence Freshness
Concurrency patterns may change after scheduling, configuration, function, or system changes.
103. Concurrency Conflict
Concurrency Conflict exists where credible evidence supports materially different temporal relationships between Demand objects.
104. Conflict Example
One dataset may show:
Demand A and B overlapping
while another shows:
Demand B beginning only after A ends.
The conflict must remain visible until resolved.
105. Concurrency Conflict Resolution
Canonical logic:
**Concurrency Evidence A
Concurrency Evidence B → Demand Identity Check → Time Reference Check → Measurement Interval Check → Time-Zone / Clock Check where relevant → Function-State Check → Evidence Quality Check → Resolution or Preserved Conflict**
106. Time Synchronization
Evidence from separate systems may use different clocks.
Temporal alignment should account for material synchronization differences.
107. Clock Error
Clock drift or timestamp mismatch may create false concurrency or hide real concurrency.
108. Time-Zone Integrity
Distributed Resource systems should preserve a common temporal reference where necessary.
109. Missing Temporal Evidence
Demand objects without sufficient temporal evidence may not support reliable concurrency determination.
110. Concurrency Uncertainty
Uncertainty may concern:
Demand timing; overlap start;
overlap end; overlap magnitude; Demand additivity; shared Demand; functional state; future operation.
111. Concurrency Range
Where exact simultaneous Demand cannot be established, CPDM may represent a governed range.
112. Minimum Concurrent Demand
The lower bound may represent Resource Demand known to overlap.
113. Maximum Concurrent Demand
The upper bound may represent the highest simultaneous Demand reasonably supported by evidence.
It should not be confused with the sum of all theoretical maxima.
114. False Concurrency Precision
Exact-looking simultaneous Demand should not be produced where temporal evidence does not support it.
115. Concurrency Decision States
At minimum:
Fully Concurrent
Partially Concurrent
Conditionally Concurrent
Sequential
Mutually Exclusive
Non-Concurrent
Concurrency Evidence-Limited
Concurrency Conflicted
Concurrency Unknown
Concurrency Unresolved
116. Parallel Demand State
Parallel Demand may be represented separately where operational parallelism matters beyond simple temporal overlap.
117. Concurrent Demand Profile
The principal CPDM output is the:
Concurrent & Parallel Demand Profile
118. Minimum Profile Fields
At minimum:
Concurrency Profile ID
Resource ID
Demand IDs
CRDM Profile References
FDIM Profile References
PKDM Profile References where relevant
Demand Start / End References
Overlap Window
Overlap Duration
Concurrent Demand Quantity / Capacity / Rate
Native Measurement
Concurrency State
Additivity State
Peak Coincidence State
Shared Demand State
Relevant Location(s)
Evidence Basis
Evidence Time
Concurrency Uncertainty
Sufficiency State
Version:
119. Additivity State
Possible states include:
Fully Additive
Partially Additive
Shared
Non-Additive
Included / Hierarchical
Mutually Exclusive
Additivity Unknown
120. Peak Coincidence State
Possible states include:
Fully Coincident
Partially Coincident
Non-Coincident
Conditionally Coincident
Peak Coincidence Unknown
121. Concurrency Sufficiency
Concurrency is sufficiently governed when temporal and Resource relationships are adequately established for Demand consolidation.
122. Partially Established Concurrency
Some Demand relationships may be known while others remain unresolved.
123. Evidence-Limited Concurrency
Insufficient timing or additivity evidence may prevent reliable determination.
124. Concurrency Unknown
Where overlap cannot be established, CPDM should preserve Unknown rather than assuming full concurrency.
125. Conservative Concurrency Assumption
Where safety or continuity analysis requires a conservative assumption, full concurrency may be modeled.
The assumption must remain explicit.
Conservative Assumption ≠ Observed Concurrency.
126. Concurrency Matrix
Complex systems may represent pairwise Demand relationships through a Concurrency Matrix.
Example:
Demand A B C A Active Concurrent Sequential B Concurrent Active Shared C Sequential Shared Active
The matrix supports relationship analysis.
It does not itself determine Priority or Allocation.
127. Demand Timeline Model
A timeline model may represent:
Demand A: ███████
Demand B: ███████
Demand C: ████
The temporal intersection reveals changing simultaneous Resource requirements.
128. Concurrent Demand Curve
CPDM may produce a time-indexed concurrent Demand curve.
This curve can support DCMM consolidation.
129. Concurrent Peak
The maximum of the concurrent Demand curve may differ from the sum of individual Peaks.
130. Coincidence Factor
Where useful, CPDM may calculate a descriptive relationship between:
actual coincident Demand
and:
sum of individual Demand maxima.
The metric must preserve its defined methodology.
131. Coincidence Factor Boundary
A coincidence factor is descriptive.
It does not establish Priority, Resource entitlement, or Sustainability.
132. Diversity Effect
Temporal diversity among Demand objects may reduce the simultaneous Resource requirement.
133. Diversity ≠ Demand Reduction
The underlying individual Demand objects still exist.
Temporal diversity changes simultaneous Demand, not necessarily total Resource requirement.
134. Concurrency Change
Concurrency may change because of:
schedule changes; function activation; function deactivation; new Demand objects; Demand termination; Demand shifting; system reconfiguration; seasonal change; event activation.
135. New Demand Object
Addition of a new Resource Demand object should trigger concurrency reassessment where it may overlap existing Demand.
136. Demand Removal
Removal or termination of a Demand object may reduce concurrent Resource requirements.
137. Schedule Change
A scheduling change may create or remove Peak coincidence.
138. Functional Change
Changes identified by FDIM may alter concurrency relationships.
139. Peak Change
Changes identified by PKDM may alter coincident Peak conditions.
140. Concurrency Reassessment Trigger
CPDM reassessment should occur following material:
CRDM revision; FDIM revision; PKDM revision; schedule change; new Demand; Demand termination; time shift; operating-state change; system reconfiguration; new temporal evidence; evidence conflict; clock or timestamp correction.
141. Reassessment Logic
Canonical logic:
Existing Concurrent & Parallel Demand Profile → New Evidence / Material Change → Temporal Relationship Impact Test → Concurrency Retained or Revised → Concurrent Demand Recalculation → Version Update → DCMM Reassessment
142. Concurrency Versioning
Material changes should create a new governed profile version.
143. Historical Concurrency
Historical concurrency patterns may support analysis.
They must not automatically represent current concurrency.
144. Concurrency Trend
Concurrency may increase or decrease as systems change.
Trend analysis should preserve relevant operational conditions.
145. Concurrency vs Dependency
Simultaneous Resource Demand does not determine Dependency severity.
High Concurrent Demand ≠ High Dependency Severity.
146. Concurrency vs Criticality
Several concurrent Demand objects may all be low-criticality.
A small concurrent Demand may support a highly critical function.
Concurrent Demand Magnitude ≠ Criticality.
147. Concurrency vs Access
Concurrency does not establish Resource Access authorization.
148. Concurrency vs Priority
CPDM does not determine which concurrent Demand should receive Resource first.
Concurrent Demand ≠ Allocation Priority.
149. Concurrency vs Allocation
A concurrent Resource requirement is not an Allocation decision.
150. Concurrency vs Consumption
Observed concurrent Consumption may differ from concurrent Demand.
151. Concurrency vs Scarcity
Concurrent Demand exceeding available capacity may contribute to Scarcity governance.
CPDM does not establish Scarcity State.
152. Concurrency vs Resilience
High concurrency may affect Resource System resilience requirements.
RIRS retains Resource Interdependency & Resilience governance.
153. Concurrency vs Sustainability
A system may satisfy short-term concurrent Demand while remaining unsustainable over longer horizons.
154. Concurrency vs Value
High-Value functions may operate concurrently with lower-Value functions.
CPDM does not determine their Value or Priority.
VEGA™ retains relevant Value Governance.
155. Concurrency Integrity Principle
Resource Demand should be combined as simultaneous Demand only where the relevant Resource requirements actually overlap in time.
156. Additivity Integrity Principle
Temporal overlap alone does not prove that Resource Demand is fully additive.
157. Hierarchy Integrity Principle
A Demand component already included within an aggregate Demand must not be counted again merely because it is separately visible.
158. Peak Integrity Principle
Individual Demand Peaks must not be summed into a system Peak unless their relevant Peak conditions actually coincide.
159. Temporal Reality Principle
Resource systems experience Demand in time, not as a timeless sum of every requirement that may exist somewhere in the system.
160. Minimum Implementation Framework
A minimum operational CPDM implementation should contain eight governed layers.
Layer 1 — Demand Inputs
Receive:
CRDM Profiles FDIM Profiles PKDM Profiles
Layer 2 — Temporal Alignment
Establish:
Demand start Demand end Measurement interval Common temporal reference
Layer 3 — Overlap Detection
Determine:
Full overlap Partial overlap Sequential relationship No overlap Mutual exclusivity
Layer 4 — Additivity Analysis
Determine:
Independent Demand Shared Demand Included Demand Partially additive Demand Non-additive Demand
Layer 5 — Peak Coincidence
Determine:
Peak overlap Peak-to-normal overlap Non-coincident Peaks
Layer 6 — Integrity & Evidence
Assess:
Double-counting Hierarchy Time synchronization Evidence provenance Conflict
Layer 7 — Uncertainty & Sufficiency
Determine:
Concurrency uncertainty Concurrency State Additivity State Sufficiency State
Layer 8 — Governed Output
Produce:
Concurrent & Parallel Demand Profile Concurrent Demand Curve where relevant Version Known limitations Reassessment triggers DCMM handoff state
Minimum machine-readable logic:
Demand Profiles[] → Temporal Alignment → Overlap[] → Concurrency State[] → Additivity[] → Peak Coincidence[] → Shared / Included Demand[] → Integrity Checks[] → Evidence[] → Uncertainty[] → Concurrent Demand → Sufficiency → Concurrent & Parallel Demand Profile
161. Minimum Decision States
At minimum:
Fully Concurrent
Partially Concurrent
Conditionally Concurrent
Sequential
Mutually Exclusive
Non-Concurrent
Concurrency Evidence-Limited
Concurrency Conflicted
Concurrency Unknown
Concurrency Unresolved
162. Minimum Evidence Path
Where concurrency cannot be sufficiently established:
Concurrency Unresolved → Material Temporal / Additivity Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Concurrency Reassessment → Updated Concurrent & Parallel Demand Profile
The objective is sufficient evidence of simultaneous Resource requirement, not arbitrary assumption of full concurrency.
163. Minimum Reassessment Framework
At minimum:
Current Concurrent & Parallel Demand Profile → New Evidence / Material Change → Concurrency Impact Test → Relationship Retained or Revised → Concurrent Demand Recalculation → Profile Version Update → DCMM Reassessment
164. Governance Requirements
A conforming CPDM implementation must:
1. receive governed Demand profiles; 2. identify Demand objects being compared; 3. preserve Resource identity; 4. establish a common temporal reference; 5. establish relevant temporal granularity; 6. identify Demand start and end; 7. determine temporal overlap; 8. determine overlap duration; 9. determine overlap magnitude; 10. distinguish full from partial concurrency; 11. distinguish concurrent from sequential Demand; 12. identify mutually exclusive Demand; 13. identify conditional concurrency; 14. identify coincident Peak conditions; 15. distinguish individual Peaks from coincident Peaks; 16. assess Demand additivity; 17. identify shared Resource Demand; 18. identify included/hierarchical Demand; 19. prevent double-counting; 20. preserve cross-location concurrency where relevant; 21. preserve cross-Resource concurrency without false physical summation; 22. preserve evidence provenance; 23. assess time synchronization; 24. preserve material uncertainty; 25. preserve conflict; 26. support concurrency ranges where required; 27. support reassessment; 28. support versioning; 29. produce a Concurrent & Parallel Demand Profile; 30. preserve unresolved limitations for DCMM.
165. Governance Logic
Canonical CPDM logic:
Governed Demand Profiles → Temporal Alignment → Demand Interval Mapping → Overlap Detection → Concurrency Classification → Additivity Test → Shared / Included Demand Check → Peak Coincidence Analysis → Cross-Location / Cross-System Context → Evidence → Conflict → Uncertainty → Concurrent Demand Determination → Sufficiency → Concurrent & Parallel Demand Profile
Where concurrency is unresolved:
Demand Relationship → Temporal / Additivity Evidence Gap → Minimum Evidence Requirement → Evidence Acquisition → Concurrency Reassessment
Where concurrency changes:
Existing Concurrency Profile → Material Change → Concurrency Impact Test → Revised Relationship → Concurrent Demand Recalculation → Version Update → DCMM Reassessment
166. Governance Outputs
CPDM may produce:
Concurrent & Parallel Demand Profile
Concurrency State
Parallel Demand State
Overlap Window
Overlap Duration
Concurrent Demand Quantity
Concurrent Demand Capacity
Concurrent Demand Rate
Additivity State
Shared Demand State
Included Demand State
Mutual Exclusivity State
Peak Coincidence State
Concurrent Demand Curve
Concurrency Evidence State
Concurrency Conflict State
Concurrency Uncertainty State
Concurrency Sufficiency State
Concurrency Version
Reassessment Trigger
DCMM Handoff State
167. Downstream Release Condition
CPDM output may proceed into DCMM where concurrency and additivity relationships are sufficiently established for Demand consolidation or where remaining uncertainty can legitimately remain explicit.
Progression does not erase concurrency uncertainty.
168. Failure Conditions
CPDM should not be considered sufficiently completed where:
all Demand objects are automatically treated as simultaneous; Demand values from different times are added without temporal alignment; same-day Demand is automatically treated as concurrent; temporal resolution is insufficient for the Resource System; individual Peaks are summed without Peak coincidence analysis; shared Demand is counted once for every function; aggregate Demand is added to its own component Demand; mutually exclusive operating modes are summed; sequential Demand is represented as simultaneous Demand; parallel operation is assumed to mean full Resource additivity; cross-Resource Demand is physically summed into one meaningless quantity; time-zone or clock differences create false concurrency; planned concurrency is represented as observed concurrency; predicted concurrency is represented as current concurrency; simulated concurrency is represented as observed concurrency; material uncertainty is hidden; evidence conflict is suppressed; available capacity is used to artificially reduce concurrent Demand; concurrent Consumption is treated automatically as concurrent Demand; concurrency is treated as Priority; concurrency is treated as Allocation.
169. Use Case 1 — AI Data Center Concurrent Electricity Demand
FDIM identifies electricity Demand from:
AI compute → 41 MW
Cooling → 10 MW
Storage & networking → 3 MW
Shared infrastructure → 4 MW
A naive calculation gives:
58 MW.
CPDM examines temporal operation.
During one workload interval:
Compute = 41 MW
Cooling = 8 MW
Storage & networking = 3 MW
Shared infrastructure = 4 MW
Concurrent Demand:
56 MW
During another interval, compute drops to:
28 MW
while post-workload cooling rises to:
10 MW.
The system therefore does not automatically experience every functional maximum simultaneously.
PKDM may identify separate functional Peaks.
CPDM determines which of those Peaks actually coincide.
The sum of every functional maximum is not automatically the Resource capacity the system requires at one moment.
170. Use Case 2 — Regional Water Concurrent Demand
A regional water system contains:
Residential Demand
Industrial Demand
Agricultural Demand
Cooling Demand
Individual Peak values are:
Residential → 45,000 m³/day
Industrial → 38,000 m³/day
Agricultural → 55,000 m³/day
Cooling → 18,000 m³/day
A naive sum produces:
156,000 m³/day.
CPDM determines that:
residential Peak occurs primarily in morning/evening periods; industrial Demand is strongest during production hours; agricultural irrigation is concentrated in different intervals; cooling Demand follows temperature conditions.
Their individual Peaks do not necessarily coincide.
The governed concurrent Resource requirement must therefore be derived from their actual temporal overlap rather than from the sum of all individual maxima.
Four real Peaks do not automatically create one simultaneous system Peak.
171. Critical Distinctions
Demand A + Demand B ≠ Concurrent Demand unless they overlap
Sequential Demand ≠ Concurrent Demand
Same-Day ≠ Simultaneous
Individual Peak A + Individual Peak B ≠ Coincident Peak Demand unless Peaks overlap
10 MW Shared Demand ≠ 20 MW because two functions use it
Additive ≠ Concurrent
Concurrent ≠ Fully Additive
Aggregate Demand + Included Component Demand ≠ Valid Combined Demand
Demand Shift ≠ Demand Elimination
Concurrent Resource Bundle ≠ Resource Equivalence
Concurrent Consumption ≠ Concurrent Demand by definition
Planned Concurrency ≠ Observed Concurrency
Predicted Concurrency ≠ Current Concurrency
Simulated Concurrency ≠ Observed Concurrency
Conservative Assumption ≠ Observed Concurrency
Diversity ≠ Demand Reduction
High Concurrent Demand ≠ High Dependency Severity
Concurrent Demand Magnitude ≠ Criticality
Concurrent Demand ≠ Allocation Priority
172. Cross-Architecture Boundary
CPDM governs concurrent and parallel Resource Demand relationships within RDGS.
It may consume inputs from:
CRDM for Core Resource Demand; FDIM for Functional Demand; PKDM for Peak Demand; RACS for temporal and spatial Resource capacity context; PGA™ for predicted concurrency; SIMULOS® for simulated concurrency; ORA™ for observed operational timing; specialized Resource systems for Resource-specific temporal behaviour.
It does not absorb their governed mechanisms.
173. 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 determine when compute jobs operate.
A production scheduler may determine when material or electricity Demand occurs.
A building-management system may determine when cooling systems activate.
CPDM consumes these outputs to determine Demand concurrency.
It does not absorb the scheduling or operational mechanisms themselves.
174. Canonical Boundary
CPDM governs how multiple Resource Demand objects are temporally aligned and operationally related to determine which requirements actually occur together, how much they overlap, whether they are additive, shared, included, sequential, mutually exclusive, or conditionally concurrent, and what simultaneous Resource requirement results.
It does not determine final Demand consolidation, Resource Dependency, Criticality, Access authorization, Priority, Allocation, Consumption governance, Scarcity response, Resilience, or Sustainability.
Its principal governed output is the Concurrent & Parallel Demand Profile used by DCMM.
175. Canonical Closing Statement
Resource systems do not experience every Demand that exists somewhere in the system at the same moment.
CPDM establishes which Resource requirements actually meet in time — preventing sequential Demand, shared Demand, included Demand, and non-coincident Peaks from being falsely transformed into simultaneous Resource Demand.