FDIM — Functional Demand Identification 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: Functional Resource Demand Governance
Module ID: RSGA-RDGS-FDIM-02
Origin ID: OOF-RSGA-RDGS-FDIM
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
FDIM — Functional Demand Identification Module governs how an established Core Resource Demand is associated with the specific operational function, process, capability, service, output, or Resource-dependent activity that creates the Resource requirement, and how the portion of Resource Demand attributable to that function is identified, evidenced, bounded, decomposed, and reassessed.
FDIM transforms a Core Resource Demand from:
Resource required
into:
Resource required for a defined function.
Resource Demand ≠ Functional Resource Demand until the function creating the requirement is sufficiently established.
2. Operational Role
CRDM establishes the foundational Resource Demand object.
FDIM determines why that Resource is operationally required.
Its role is to establish:
which function generates Demand; what operational result that function performs; which Resource requirement belongs to that function; whether several functions share the same Resource Demand; whether one function creates several Resource demands; whether supporting Resource requirements exist; whether Demand is direct or derived; whether the functional relationship is sufficiently evidenced.
FDIM prevents Resource Demand from remaining detached from the operational activity that creates it.
3. Core Question
Which specific function, process, capability, service, output, or operational activity requires the Resource, and what portion of the Resource Demand is actually attributable to that function?
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
FDIM receives the Core Resource Demand Profile and establishes the functional structure required for later Peak, Concurrent, Parallel, and Consolidated Demand governance.
5. Governed Space
FDIM governs:
Functional Resource Demand Governance
This space concerns the relationship between Resource Demand and the operational function that creates or requires it.
6. Governed Object
The primary Governed Object is:
The functional relationship between a Resource Demand and the function, process, capability, service, output, or activity that generates that Demand.
The Governed Object may include:
Primary function; supporting function; shared function; dependent process; functional Resource requirement; functional Demand component; supporting Resource Demand; functional Demand chain.
7. Scope
FDIM applies wherever Resource Demand must be associated with one or more identifiable functions before downstream Demand governance can reliably proceed.
Its Scope includes:
function identification; function boundary; function-to-Resource relationship; Resource-to-function relationship; functional Demand attribution; functional Demand decomposition; functional Demand aggregation; primary and supporting functions; direct and derived Demand; shared Demand; multi-function Demand; cross-Resource functional requirements; supporting Resource requirements; functional Demand evidence; functional uncertainty; functional conflict; functional change; functional reassessment; functional Demand versioning.
FDIM does not independently determine:
Peak Demand; Demand concurrency; final Demand consolidation; Resource Dependency severity; Resource Criticality; Access authorization; Priority; Allocation; Consumption; Scarcity;
Resilience; Sustainability.
8. Entry Requirement
FDIM receives the:
Core Resource Demand Profile
from CRDM.
At minimum, the input should identify:
Demand ID; Resource ID; Demand Source; Demand Boundary; Demand Quantity / Capacity / Rate; Native Measurement; Evidence Basis; Uncertainty; Demand State.
9. Functional Demand
Functional Demand is the Resource requirement attributable to a defined operational function under specified conditions.
Canonical relationship:
**Resource Demand
Identified Function Functional Evidence → Functional Resource Demand**
10. Function Definition
A Function is an identifiable activity, capability, process, service, output, or operational role that requires Resource to operate or produce a relevant result.
11. Function Identification
FDIM should identify the function at a level sufficiently precise to explain why the Resource is required.
12. Functional Specificity
Function identification should avoid descriptions that are so broad that materially different Resource requirements become indistinguishable.
Example:
“Data center operation”
may be insufficient where Demand actually arises from:
AI computation; cooling; storage;
networking; support infrastructure.
13. Excessive Functional Fragmentation
FDIM should also avoid unnecessary decomposition into trivial subfunctions that do not materially improve Resource governance.
More Functions ≠ Better Functional Governance.
14. Functional Boundary
The Functional Boundary defines which operational activity belongs to the governed function.
15. Boundary Integrity
Functional boundaries should follow operational Resource reality rather than organizational labels or preferred analytical outcomes.
16. Function vs Organization
An organizational department is not automatically a function.
One department may perform several Resource-dependent functions.
Several departments may contribute to one function.
17. Function vs System
A system may perform multiple functions.
A function may also span multiple systems.
System Boundary ≠ Functional Boundary.
18. Function vs Process
A process may constitute:
the function itself; a subfunction; a supporting function; one stage within a larger function.
The relationship should remain explicit.
19. Primary Function
A Primary Function is the principal operational activity directly responsible for the relevant Resource Demand.
20. Supporting Function
A Supporting Function enables or sustains another function.
Examples:
Cooling supporting computation
Pumping supporting water delivery
Networking supporting distributed computation
Material handling supporting production
21. Primary vs Supporting Demand
Resource Demand associated with supporting functions should not be silently merged into the Primary Function where the distinction materially affects governance.
22. Direct Functional Demand
Direct Functional Demand arises directly from operation of the identified function.
Example:
Compute workload → Compute capacity Demand
23. Supporting Resource Demand
A function may create Demand for Resources required to support its operation.
Example:
Compute workload → Electricity Demand → Cooling Demand
24. Derived Functional Demand
Derived Functional Demand is calculated from the operation of another function or Resource requirement.
The derivation relationship must remain traceable.
25. Direct vs Derived Demand
Direct Resource Demand ≠ Derived Supporting Resource Demand.
Both may be valid.
Their causal relationship should remain visible.
26. Functional Demand Chain
A function may create a chain of Resource requirements.
Example:
AI inference → Compute Demand
→ Electricity Demand → Cooling Demand → Water Demand
FDIM may preserve this functional Demand chain.
27. Demand Chain Integrity
Each step in a functional Demand chain should identify:
originating function; resulting Resource requirement; derivation basis; evidence.
28. Demand Cascade
One Resource-dependent function may generate several downstream Resource requirements.
FDIM should preserve material cascades where they affect Resource governance.
29. Cascade Boundary
FDIM governs the Resource Demand relationships created by the function.
It does not absorb the underlying physics or engineering mechanisms that generate them.
30. One Function, One Resource
A function may depend primarily on one governed Resource.
This is the simplest functional Demand relationship.
31. One Function, Multiple Resources
Many functions require several Resources simultaneously.
Example:
AI training
may require:
Compute Electricity Cooling Water Network capacity Storage
Each remains a separate Resource Demand object.
32. Resource Bundle
FDIM may represent several Resources as a functional Resource bundle where they jointly support the same function.
33. Resource Bundle Integrity
A Resource bundle preserves Resource relationships without creating physical equivalence.
Joint Functional Requirement ≠ Resource Equivalence.
34. One Resource, Multiple Functions
The same Resource may support several functions.
Example:
Electricity may support:
Computation Cooling Lighting Pumping Storage systems Safety infrastructure
35. Functional Demand Decomposition
Where one Resource Demand supports multiple functions, FDIM should decompose the Demand where materially possible and useful.
36. Decomposed Demand
Canonical representation:
**Total Resource Demand → Function A Demand
Function B Demand Function C Demand**
only where the functional components are legitimately additive.
37. Non-Additive Functional Demand
Functional Demand components must not be added where:
they overlap; share capacity; occur at different times; represent alternative operating states; use the same underlying Resource requirement.
38. Functional Double-Counting
FDIM must prevent the same Resource Demand from being attributed fully to several functions when those functions share the same underlying requirement.
39. Shared Functional Demand
A Resource requirement may support multiple functions simultaneously.
Where exact attribution is impossible or artificial, FDIM may preserve a Shared Functional Demand state.
40. Shared Demand Attribution
Shared Resource Demand should be attributed only where a defensible method exists.
False allocation between functions should not be introduced merely to force numerical completeness.
41. Functional Attribution
Functional Attribution identifies the relationship between Resource Demand and the function responsible for it.
Possible states may include:
Directly Attributed
Derived
Shared
Conditionally Attributed
Partially Attributed
Unattributed
42. Attribution Basis
Functional attribution may be based on:
direct measurement; technical architecture; process measurement; workload data; Resource metering; engineering model; operational evidence; validated derivation.
43. Direct Functional Measurement
Where Resource Demand can be directly measured for one function, FDIM should preserve that direct measurement.
44. Submetered Functional Demand
Dedicated Resource metering may provide strong functional attribution.
Example:
Cooling electricity measured independently from compute electricity.
45. Derived Functional Attribution
Where direct measurement is unavailable, Demand may be attributed through a governed derivation method.
46. Attribution Assumption
Where attribution depends upon assumptions, those assumptions must remain explicit.
Attribution Assumption ≠ Direct Functional Evidence.
47. Functional Evidence
FDIM should preserve evidence supporting the relationship between:
Resource Demand
and:
Function.
48. Functional Evidence Types
Evidence may include:
Operational telemetry
Process records
System architecture
Technical specifications
Resource meters
Workload records
Production records
Engineering models
Validated operational observations
49. Evidence Relevance
Evidence should establish the functional relationship, not merely prove that Resource was consumed somewhere within the larger system.
50. Evidence Provenance
Functional evidence should preserve where relevant:
Demand ID
Function ID
Resource ID
Evidence Source
Measurement / derivation method
Time
Location
Version:
51. Evidence Time
Functional Demand evidence should correspond sufficiently to the operating state being governed.
52. Functional Evidence Freshness
System reconfiguration may invalidate previously valid functional attribution.
53. Functional Change
A Resource Demand may remain numerically unchanged while its functional purpose changes.
This is a material governance change.
54. Same Quantity, Different Function
Same Resource Quantity ≠ Same Functional Demand.
100 units supporting one function are not methodologically identical to 100 units supporting another function.
55. Functional Demand Context
Relevant context may include:
operating mode; workload; production state; environmental condition; technical configuration; supporting infrastructure; time; location.
56. Functional Operating State
The Resource requirement may change depending on the operating state of the function.
57. Normal Operation
A function may have a normal operating Resource requirement.
58. Reduced Operation
Reduced operation may create a lower functional Resource requirement.
59. High-Load Operation
A function may require more Resource under high-load conditions.
PKDM governs detailed Peak Demand downstream.
60. Standby Function
A function may remain inactive while requiring standby Resource capacity.
61. Emergency Function
An emergency operating function may create a Resource requirement different from normal operation.
FDIM identifies the function.
It does not establish Criticality or Priority.
62. Recovery Function
System recovery may create temporary Resource Demand.
This Demand should remain distinguishable from steady-state operational Demand.
63. Maintenance Function
Maintenance may itself require Resource.
Maintenance Demand should not automatically be attributed to normal operation.
64. Temporary Function
A temporary operational activity may create temporary Resource Demand.
65. Function Activation
A previously inactive function may become active and create Resource Demand.
66. Function Deactivation
When a function ceases operation, its Resource Demand may terminate or move to standby.
67. Functional Transition
Resource Demand may change during transition between operating states.
68. Function Substitution
One function or technical method may replace another while producing the same operational outcome.
This may change Resource Demand.
FDIM records the functional change.
RSFS governs Resource substitution where applicable.
69. Alternative Functional Path
A system may achieve the same operational result through different functions or processes.
Their Resource requirements may differ.
70. Functional Equivalence Boundary
Two functions producing similar outputs are not automatically equivalent for Resource Demand purposes.
Same Output ≠ Same Resource Demand.
71. Functional Efficiency
Two implementations of the same function may require different Resource quantities.
FDIM may preserve the Resource requirement difference.
VEGA™ retains relevant efficiency and Value governance for intelligent systems.
72. Efficiency vs Functional Demand
Efficiency may change the amount of Resource required to perform a function.
Where the requirement changes, FDIM should update the functional Demand representation.
73. Functional Demand Reduction
A function may require less Resource after:
technical improvement; process redesign; configuration change; efficiency improvement; workload reduction.
74. Functional Demand Increase
Demand may increase because of:
higher workload; lower efficiency; expanded function; degraded infrastructure; changed operating conditions.
75. Function Expansion
A function may expand in scope.
The resulting Resource Demand should be reassessed rather than extrapolated automatically.
76. Function Contraction
A function may contract without terminating.
Resource Demand should reflect the changed functional reality.
77. Functional Requirement Minimum
Where evidence supports it, FDIM may identify the minimum Resource requirement needed for a function to operate.
This does not determine the function's Criticality.
78. Functional Operating Range
Some functions can operate across a range of Resource inputs.
Example:
Minimum viable compute: 5,000 units
Normal compute: 7,500 units
High-performance operation: 9,000 units
FDIM may preserve the functional range.
79. Minimum vs Preferred Resource Level
A function may have:
minimum Resource requirement
and:
preferred Resource level.
These are not equivalent.
80. Functional Requirement vs Preference
Preferred Resource Level ≠ Functional Resource Requirement.
81. Functional Requirement vs Optimization
Additional Resource may improve:
speed; quality; throughput; convenience; redundancy.
This does not automatically make the additional Resource part of minimum functional Demand.
82. Service-Level Demand
A function may have different Resource requirements at different service levels.
The service-level basis should remain explicit.
83. Quality-Dependent Functional Demand
A Resource function may require a minimum Resource quality.
84. Performance-Dependent Functional Demand
A function may require Resource performance above a defined threshold.
85. Functional Continuity Requirement
A function may require Resource continuously or tolerate interruption.
FDIM may identify this functional property.
It does not determine broader Resource Continuity governance.
86. Interruptible Function
Some functions can tolerate Resource interruption.
87. Non-Interruptible Functional Requirement
Some functions may require continuous Resource support.
FDIM identifies the functional condition.
RDCS later determines Dependency and Criticality.
88. Deferrable Function
A function may be capable of operating later rather than immediately.
This property may materially affect downstream governance.
89. Shiftable Functional Demand
A function may allow Resource Demand to move to another time.
FDIM may preserve this functional property.
Detailed temporal concurrency and Demand management remain downstream.
90. Flexible Functional Demand
A function may tolerate a range of Resource quantities or operating times.
Functional flexibility should not automatically be interpreted as Resource substitution.
91. Inflexible Functional Demand
A function may have narrow Resource requirements.
This does not automatically establish Criticality.
92. Functional Demand Dependency Boundary
FDIM identifies that a function requires Resource.
RDCS determines how strongly the function depends on it.
Functional Requirement ≠ Dependency Severity.
93. Functional Demand Criticality Boundary
A function requiring Resource does not automatically make that Resource Demand critical.
Functional Requirement ≠ Criticality.
94. Functional Demand Priority Boundary
A function's importance does not automatically determine Resource Priority within FDIM.
Functional Importance ≠ Resource Allocation Priority.
95. Functional Demand Access Boundary
A function may require Resource without being authorized to access it.
Functional Demand ≠ Resource Access Authorization.
96. Functional Demand Allocation Boundary
FDIM does not decide how much Resource the function receives.
Functional Demand ≠ Resource Allocation.
97. Functional Demand Consumption Boundary
The Resource requirement of a function is not identical to its actual Resource Consumption.
Functional Demand ≠ Functional Consumption.
98. Functional Demand Scarcity Boundary
A function may have unmet Resource Demand.
FDIM does not determine whether Scarcity exists.
99. Functional Demand Sustainability Boundary
A function may legitimately require Resource while its continued operation at that Resource level is unsustainable.
Functional Requirement ≠ Sustainable Resource Use.
100. Functional Demand Value Boundary
A function may create Value.
FDIM does not determine that Value.
VEGA™ retains relevant Value governance.
101. Functional Demand Harm Boundary
A function may create or prevent Harm.
HAGA™ retains Harm Governance.
FDIM does not alter Demand merely because the function has positive or negative consequences.
102. Functional Demand Liability Boundary
Resource Demand associated with a function does not establish Liability.
LIGA™ retains Liability Governance.
103. Functional Demand Authority Boundary
A function's Resource requirement does not establish Governance Authority.
Capability ≠ Authority.
104. Multi-Function Resource System
A Resource System may contain many functions sharing one Resource supply.
FDIM should preserve function-specific Demand where materially possible.
105. Functional Demand Matrix
For complex systems, FDIM may represent:
Function × Resource → Functional Demand
Example:
Function Resource Demand AI Compute Compute 8,000 units AI Compute Electricity 40 MW Cooling Electricity 8 MW Cooling Water 12,000 m³/day
The matrix represents relationships, not Priority.
106. Function-to-Resource Mapping
A function may map to one or many Resources.
Canonical representation:
Function → Resource A Demand → Resource B Demand → Resource C Demand
107. Resource-to-Function Mapping
A Resource may support one or many functions.
Canonical representation:
Resource → Function A → Function B → Function C
108. Many-to-Many Functional Demand
Complex Resource systems may require many-to-many mappings.
FDIM should preserve them without unnecessary collapse.
109. Functional Demand Graph
Where useful, Resource-function relationships may be represented as a graph.
Nodes may include:
Functions
Resources
Supporting functions
Edges represent governed Demand relationships.
110. Functional Demand Traceability
Every material Functional Demand should remain traceable to:
Core Demand
Resource
Function
Demand Source
Evidence
111. Functional Demand Profile
The principal FDIM output is the:
Functional Demand Profile
It describes how the Core Resource Demand relates to the function or functions creating it.
112. Minimum Functional Demand Profile Fields
At minimum:
Demand ID
CRDM Profile Reference
Resource ID
Demand Source
Function ID
Function Name / Description
Function Type
Functional Boundary
Functional Demand Quantity / Capacity / Rate
Native Measurement
Direct / Derived / Shared Attribution
Operating State
Supporting Resource Relationship where relevant
Evidence Basis
Evidence Time
Functional Uncertainty
Functional Sufficiency State
Version:
113. Functional Demand State
At minimum, FDIM may represent:
Functionally Attributed
Partially Functionally Attributed
Shared Functional Demand
Conditionally Attributed
Functionally Evidence-Limited
Functionally Conflicted
Function Unknown
Functional Attribution Unresolved
114. Functional Sufficiency
Functional Demand is sufficiently established when the relationship between Resource requirement and operational function is adequate for downstream RDGS governance.
115. Partial Functional Attribution
Part of a Resource Demand may be attributable while another part remains unresolved.
FDIM should preserve the distinction.
116. Unknown Functional Attribution
Resource Demand may be measured without knowing which function created it.
Measured Resource Consumption ≠ Known Functional Demand.
117. Functional Conflict
Functional Conflict exists where credible evidence supports incompatible explanations of which function creates Resource Demand.
118. Functional Conflict Resolution
Canonical logic:
**Functional Claim A
Functional Claim B → Resource Check → Demand Boundary Check → Function Boundary Check → Time Check → Operating-State Check → Evidence Comparison → Attribution Resolution or Preserved Conflict**
119. Functional Uncertainty
Uncertainty may concern:
function identity; function boundary; Resource attribution; shared Demand; derived Demand; operating state; measurement basis.
120. Uncertainty Propagation
Material functional uncertainty must remain visible downstream.
Uncertain Functional Attribution ≠ Certain Peak or Consolidated Demand Attribution.
121. Functional Change Event
Material change may include:
Function activation
Function deactivation
Function expansion
Function contraction
Process redesign
Technical replacement
Resource relationship change
Operating-mode change
Supporting-function change
122. Functional Reassessment Trigger
FDIM reassessment should occur following material:
CRDM Demand revision; function change; system reconfiguration; Resource change; new measurement; new attribution evidence; evidence expiry; functional conflict; operating-state change.
123. Reassessment Logic
Canonical logic:
Existing Functional Demand Profile → New Evidence / Material Functional Change → Functional Impact Test → Attribution Retained or Revised → Demand Quantity Reassessment where required → Version Update → Downstream RDGS Reassessment
124. Functional Versioning
Material changes to functional attribution should create a new profile version.
125. Historical Functional Attribution
Previous functional attribution may remain relevant for audit or analysis.
It must not automatically represent current functional Demand.
126. Functional Demand Comparison
Functional Demand may be compared across:
functions; systems; locations; time periods; operating states
only where the Resource and measurement basis are sufficiently compatible.
127. Same Function Across Systems
The same named function may have different Resource requirements across systems.
Same Function Name ≠ Same Resource Demand.
128. Same Function Across Time
A function's Resource Demand may change after:
technology change; configuration change; efficiency change; workload change; environmental change.
129. Functional Demand Baseline
FDIM may establish a functional Demand baseline where useful.
The baseline conditions must remain explicit.
130. Baseline Boundary
A historical or nominal baseline must not replace current functional Demand where conditions have materially changed.
131. Functional Demand Anomaly
A Resource requirement materially inconsistent with the established functional relationship may trigger reassessment.
An anomaly is not automatically an error.
132. Unexplained Demand
Resource Demand not attributable to an identified function should remain visible as unexplained Demand rather than being arbitrarily distributed.
133. Residual Functional Demand
After attributable Demand components are identified, a residual may remain.
The residual should be preserved where material.
134. Residual Demand Investigation
Residual Demand may indicate:
unidentified function; measurement error; shared overhead; system loss; boundary mismatch; unrecorded process.
FDIM should not assume which explanation is correct without evidence.
135. Supporting Overhead
A system may have Resource Demand that supports several functions collectively.
Examples:
Shared cooling
Shared networking
Facility infrastructure
Common control systems
Such Demand may remain a governed shared overhead where precise attribution is unjustified.
136. Attribution Integrity Principle
Functional attribution must follow the Resource-dependent operational reality, not the preferred accounting distribution.
137. Functional Demand Reality Principle
A Resource quantity becomes functionally meaningful only when the system can explain what operational activity requires it.
138. Minimum Implementation Framework
A minimum operational FDIM implementation should contain eight governed layers.
Layer 1 — Core Demand Input
Receive:
Core Resource Demand Profile
Layer 2 — Function Identification
Establish:
Function ID Function description
Function boundary Operating state
Layer 3 — Resource-Function Mapping
Determine:
Resource → Function
and where relevant:
Function → Resource(s)
Layer 4 — Functional Attribution
Determine:
Direct Derived Shared Partial Conditional Unattributed
Demand relationships.
Layer 5 — Functional Decomposition
Where valid, separate:
Primary Demand Supporting Demand Shared Demand Residual Demand
Layer 6 — Evidence & Integrity
Assess:
Functional evidence Provenance Double-counting Attribution overlap Residual Demand Conflict
Layer 7 — Uncertainty & Sufficiency
Determine:
Functional uncertainty Functional Demand State Functional Sufficiency
Layer 8 — Governed Output
Produce:
Functional Demand Profile Version Known limitations Reassessment triggers PKDM handoff state
Minimum machine-readable logic:
Core Resource Demand Profile → Function[] → Functional Boundary[] → Resource-Function Relationship[] → Attribution[] → Functional Demand[] → Supporting Demand[] → Shared / Residual Demand[] → Evidence[] → Uncertainty[] → Functional Sufficiency → Functional Demand Profile
139. Minimum Decision States
At minimum:
Functionally Attributed
Partially Functionally Attributed
Shared Functional Demand
Conditionally Attributed
Functionally Evidence-Limited
Functionally Conflicted
Function Unknown
Functional Attribution Unresolved
140. Minimum Evidence Path
Where Functional Demand cannot be sufficiently established:
Functional Attribution Unresolved → Missing Functional Evidence → Minimum Evidence Requirement → Evidence Acquisition → Functional Attribution Reassessment → Updated Functional Demand Profile
The objective is sufficient functional attribution for governance, not arbitrary numerical decomposition.
141. Minimum Reassessment Framework
At minimum:
Current Functional Demand Profile → New Evidence / Material Functional Change → Functional Impact Test → Attribution Retained or Revised → Profile Version Update → Downstream RDGS Reassessment
142. Governance Requirements
A conforming FDIM implementation must:
1. receive a governed Core Resource Demand Profile; 2. identify the relevant function; 3. define the functional boundary; 4. distinguish function from organization; 5. distinguish function from system where necessary; 6. identify primary and supporting functions; 7. distinguish direct from derived Demand; 8. preserve functional Demand chains where material; 9. preserve cross-Resource functional relationships; 10. preserve Resource identity; 11. support one-function/multiple-Resource relationships; 12. support one-Resource/multiple-function relationships; 13. prevent functional double-counting; 14. support shared Functional Demand; 15. support residual/unexplained Demand; 16. preserve functional Demand measurement; 17. preserve attribution basis; 18. preserve evidence provenance; 19. preserve evidence freshness; 20. preserve operating state; 21. support functional Resource ranges where relevant; 22. distinguish minimum Resource requirement from preferred Resource level; 23. distinguish Functional Demand from Dependency; 24. distinguish Functional Demand from Criticality; 25. distinguish Functional Demand from Priority; 26. preserve uncertainty; 27. preserve conflict; 28. support reassessment; 29. support versioning; 30. produce a governed Functional Demand Profile.
143. Governance Logic
Canonical FDIM logic:
Core Resource Demand Profile → Function Identification → Functional Boundary → Operating State → Resource-Function Mapping → Direct / Derived / Shared Attribution → Functional Demand Decomposition → Supporting Resource Relationship → Double-Counting Check → Residual Demand Check → Functional Evidence → Conflict → Uncertainty → Sufficiency → Functional Demand Profile
Where functional attribution is unresolved:
Resource Demand → Functional Evidence Gap → Minimum Functional Evidence Requirement → Evidence Acquisition → Attribution Reassessment
Where function changes:
Existing Functional Demand Profile → Material Functional Change → Functional Impact Test
→ Revised Functional Demand → Version Update → Downstream Reassessment
144. Governance Outputs
FDIM may produce:
Functional Demand Profile
Function Identity
Functional Boundary
Function Operating State
Resource-Function Relationship
Functional Demand Quantity
Direct Functional Demand State
Derived Functional Demand State
Supporting Resource Demand State
Shared Functional Demand State
Residual Demand State
Functional Attribution State
Functional Evidence State
Functional Conflict State
Functional Uncertainty State
Functional Sufficiency State
Functional Demand Version
Reassessment Trigger
PKDM Handoff State
145. Downstream Release Condition
FDIM output may proceed into PKDM where Resource Demand is sufficiently associated with its operational function or where remaining functional uncertainty can legitimately remain explicit.
Progression does not erase functional uncertainty.
146. Failure Conditions
FDIM should not be considered sufficiently completed where:
Resource Demand has no materially identifiable function; organizational labels are substituted for functional analysis; one system is assumed to perform only one function; supporting Resource Demand is hidden inside Primary Demand where distinction matters; derived Demand hides its origin; shared Demand is double-counted;
Resource bundles are treated as physically equivalent; functional Demand is arbitrarily decomposed without evidence; unexplained Demand is silently distributed; preferred Resource levels are represented as minimum functional requirements; maximum performance Resource levels are treated automatically as functional Demand; historical functional attribution is treated automatically as current; material operating-state changes are ignored; functional evidence conflict is suppressed; functional uncertainty is hidden; Functional Demand is confused with Dependency; Functional Demand is confused with Criticality; Functional Demand is treated as Priority; Functional Demand is treated as Allocation.
147. Use Case 1 — AI Data Center Functional Demand
CRDM establishes:
Core electricity Demand: 58 MW
for an AI data center.
A single 58 MW number does not explain what creates that Demand.
FDIM identifies:
AI compute → 41 MW
Cooling → 10 MW
Storage & networking → 3 MW
Shared facility infrastructure → 4 MW
The functional structure shows that the Resource Demand does not arise from one homogeneous activity.
It also preserves the relationship:
AI computation → electricity Demand
and:
AI computation → cooling requirement → additional electricity and potentially water Demand.
FDIM does not determine which function has higher Priority if electricity becomes constrained.
It establishes what the Resource is functionally supporting.
Knowing that a data center requires 58 MW is not the same as knowing what the 58 MW is required to do.
148. Use Case 2 — Regional Water Functional Demand
CRDM establishes:
Core regional water Demand: 120,000 m³/day.
FDIM identifies the functional structure:
Residential essential use → 35,000 m³/day
Industrial processing → 32,000 m³/day
Agricultural irrigation → 38,000 m³/day
Cooling and infrastructure → 10,000 m³/day
Shared / unresolved system Demand → 5,000 m³/day
The 120,000 m³/day total remains unchanged.
Its governance meaning becomes materially clearer because the Resource requirement is now connected to the functions creating it.
FDIM does not determine which function is more critical or should receive Resource first.
The same total Resource Demand can represent fundamentally different Resource realities depending on the functions behind it.
149. Critical Distinctions
Resource Demand ≠ Functional Resource Demand until function is established
More Functions ≠ Better Functional Governance
System Boundary ≠ Functional Boundary
Direct Resource Demand ≠ Derived Supporting Resource Demand
Joint Functional Requirement ≠ Resource Equivalence
Same Resource Quantity ≠ Same Functional Demand
Same Output ≠ Same Resource Demand
Preferred Resource Level ≠ Functional Resource Requirement
Functional Requirement ≠ Dependency Severity
Functional Requirement ≠ Criticality
Functional Importance ≠ Resource Allocation Priority
Functional Demand ≠ Resource Access Authorization
Functional Demand ≠ Resource Allocation
Functional Demand ≠ Functional Consumption
Functional Requirement ≠ Sustainable Resource Use
Measured Resource Consumption ≠ Known Functional Demand
Uncertain Functional Attribution ≠ Certain Peak or Consolidated Demand Attribution
Same Function Name ≠ Same Resource Demand
Capability ≠ Authority
150. Cross-Architecture Boundary
FDIM governs functional Resource Demand relationships within RDGS.
It may consume evidence from:
RCHS for Resource characterization; RACS for Resource capacity context; CRDM for Core Resource Demand;
ORA™ for operational evidence; PGA™ for predicted functional Demand; SIMULOS® for simulated functional Demand; VEGA™ for relevant efficiency and Value information; specialized Resource systems for technical functional requirements.
It does not absorb their governed mechanisms.
151. 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 engine may determine compute requirements.
A cooling model may determine cooling Resource requirements.
A production process may determine material requirements.
A building system may determine electricity requirements.
FDIM consumes those outputs to establish the Resource-to-function relationship.
It does not absorb the mechanisms that produced them.
152. Canonical Boundary
FDIM governs how Core Resource Demand is associated with the specific function, process, capability, service, output, or operational activity that creates the Resource requirement, including direct, derived, shared, supporting, and residual Functional Demand relationships.
It does not determine Peak Demand, Demand concurrency, final Demand consolidation, Dependency severity, Criticality, Access authorization, Priority, Allocation, Consumption, Scarcity, Resilience, or Sustainability.
Its principal governed output is the Functional Demand Profile used by subsequent RDGS Core Modules.
153. Canonical Closing Statement
A Resource Demand number explains how much Resource appears to be required; it does not by itself explain what that Resource is required to do.
FDIM connects Resource Demand to operational function, making visible which activities create the requirement, which Resources support them, and which Demand relationships must remain distinct before Peak, Concurrent, and Consolidated Demand can be governed.