RCTM — Resource Constraint Type Module
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Parent Standard: Resource Scarcity & Constraint Standard (RSCS)
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Core Module
Governed Space: Resource Constraint Type Governance
Module ID: RSGA-RSCS-RCTM-02
Origin ID: OOF-RSGA-RSCS-RCTM
Version: 1.0
Status: Draft Module
Effective Date: 7 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
RCTM — Resource Constraint Type Module governs how the specific type or combination of types of Resource Constraint affecting a defined Resource or Resource capacity is identified, distinguished, classified, evidenced, attributed to an operational constraint mechanism, related to other simultaneous constraints, monitored, and reassessed.
RCTM determines how a Resource is constrained .
It distinguishes constraints affecting:
quantity; capacity; rate; time; location; Source; accessibility; quality; delivery; infrastructure; regeneration; dependency; or multiple interacting Resource conditions.
Its foundational distinctions are:
Resource Constraint ≠ Resource Scarcity.
Constraint Type ≠ Constraint Severity.
Observed Resource Limitation ≠ Proven Constraint Mechanism.
One Scarcity State ≠ One Constraint Type by definition.
2. Operational Role
RSSM determines whether the governed Resource is in a Scarcity State relative to the applicable legitimate Resource requirement.
RCTM determines the form of Resource Constraint responsible for, contributing to, or otherwise materially affecting the Resource condition.
Its role is to transform:
**observed Resource limitation
Resource-state evidence operational context causal evidence**
into:
a governed Resource Constraint Type classification.
RCTM prevents different Resource problems from being collapsed into the generic statement:
“There is not enough Resource.”
The Resource may instead be constrained because:
not enough total quantity exists; capacity is saturated; the Resource cannot be delivered quickly enough; the Resource exists at the wrong time; the Resource exists at the wrong location; a required Source is unavailable; Access is restricted; Resource quality is inadequate; delivery infrastructure is constrained; regeneration is insufficient; another Resource dependency has failed; or several mechanisms operate simultaneously.
3. Operational Question
What type or combination of Resource Constraints is materially affecting the governed Resource, through which evidenced operational mechanisms, within which Source, location, time, capacity, quality, accessibility, delivery, infrastructure, regeneration, or dependency conditions, and with what confidence can those Constraint Types be established?
4. Position in RSCS Governance
Canonical progression:
Governed Resource State → Legitimate Resource Requirement → Applicable Resource Capacity → Resource Sufficiency Comparison → Resource Scarcity State → Constraint Type Identification → Constraint Mechanism Attribution → Constraint Interaction → Constraint Severity Evaluation → Scarcity Response / Monitoring → Resolution Assessment → Reassessment
RCTM governs:
Observed Resource Limitation → Resource Constraint Type
and:
Resource Constraint Evidence → Constraint Mechanism Classification
5. Governed Space
RCTM governs:
Resource Constraint Type Governance
This governed space concerns the identification, differentiation, classification, and evidence of the mechanisms through which Resource availability, usability, accessibility, capacity, quality, rate, location, timing, Source, delivery, regeneration, or dependent Resource conditions become constrained.
6. Governed Object
The primary Governed Object is:
A Resource Constraint Type classification associated with a defined Resource, Resource capacity, operational limitation, Source, location, time horizon, and evidenced Constraint mechanism.
Canonical relationship:
**Resource Limitation
Resource Context Constraint Evidence → Constraint Mechanism Identification → Constraint Type Classification → Constraint Interaction State**
7. Scope
RCTM governs:
Constraint Type identification; Constraint mechanism identification; quantity constraints; capacity constraints; rate constraints; temporal constraints; location constraints; Source constraints; accessibility constraints; quality constraints; delivery constraints; infrastructure constraints; regenerative constraints; dependency-induced constraints; cross-Resource constraints; single-mechanism constraints; multi-mechanism constraints; primary constraints; secondary constraints; direct constraints; indirect constraints; constraint interaction; constraint accumulation; constraint propagation relevance; constraint attribution; causal evidence; constraint-type evidence; constraint-type uncertainty;
constraint-type conflict; constraint-type transition; constraint-type monitoring; constraint-type reassessment; traceability; versioning.
RCTM does not independently:
determine Resource Demand; determine Resource Dependency or Criticality; grant Resource Access; determine Resource Priority; allocate Resources; measure actual Resource Consumption; determine the Scarcity State itself; determine complete Constraint Severity; authorize Resource intervention; govern Resource Recovery; authorize substitution; determine resilience; determine long-term Sustainability; determine Value; determine Harm; determine Liability.
8. Resource Constraint Type
A Resource Constraint Type represents the governed classification of the mechanism through which a Resource or Resource capacity is materially limited.
Constraint Type answers:
How is the Resource constrained?
It does not by itself answer:
How scarce is the Resource?
or:
How severe is the consequence?
9. Constraint-Type Principle
Constraint Type ≠ Scarcity State.
A Resource may experience an active constraint while remaining sufficient relative to legitimate Resource requirements.
10. Constraint-Type and Severity Principle
Constraint Type ≠ Constraint Severity.
The same Constraint Type may be minor in one context and critical in another.
11. Constraint Mechanism
A Constraint mechanism is the operational process or condition through which the Resource limitation arises.
Examples include:
reduced supply; capacity saturation; throughput limitation; Source interruption; transport failure; infrastructure failure; quality degradation; regenerative deficit; Access restriction; dependent Resource failure.
12. Mechanism Principle
Observed Resource Limitation ≠ Proven Constraint Mechanism.
Evidence must support the mechanism attribution.
13. Constraint Type Taxonomy
RCTM should support at minimum:
Quantity Constraint
Capacity Constraint
Rate Constraint
Temporal Constraint
Location Constraint
Source Constraint
Accessibility Constraint
Quality Constraint
Delivery Constraint
Infrastructure Constraint
Regenerative Constraint
Dependency-Induced Constraint
Cross-Resource Constraint
Combined Constraint
Constraint Type Unknown
Constraint Type Conflicted
14. Quantity Constraint
A Quantity Constraint exists where the amount of Resource relevant to the governed context is materially limited.
The limitation may concern:
physical quantity; energy quantity; material quantity;
data quantity; Resource stock; other Resource-specific quantity.
15. Quantity-Constraint Boundary
Low Resource Quantity ≠ Quantity Constraint by itself.
The quantity must be materially limited relative to the applicable Resource context or requirement.
16. Quantity Constraint and Scarcity
A Quantity Constraint may contribute to Scarcity.
However:
Quantity Constraint ≠ Scarcity automatically.
Remaining quantity may still be sufficient.
17. Capacity Constraint
A Capacity Constraint exists where the ability of a Resource system to provide, process, store, transmit, convert, or otherwise support Resource use is materially limited.
Examples include:
compute capacity; grid capacity; storage capacity; cooling capacity; processing capacity; transport capacity; treatment capacity.
18. Capacity Principle
Resource Existence ≠ Sufficient Resource Capacity.
19. Installed-Capacity Boundary
Installed or nominal capacity may exceed capacity actually usable under current conditions.
Installed Capacity ≠ Usable Capacity.
20. Capacity-Saturation Constraint
A Capacity-Saturation Constraint exists where applicable Resource-system capacity approaches or reaches its operational limit.
21. Saturation Principle
High Utilization ≠ Capacity Constraint by definition.
A Constraint exists only where the Resource condition becomes materially limiting.
22. Rate Constraint
A Rate Constraint exists where Resource quantity may be sufficient overall but cannot be supplied, processed, transmitted, withdrawn, consumed, or otherwise made available at the required rate.
23. Rate Principle
Sufficient Total Resource Quantity ≠ Sufficient Resource Rate.
24. Peak-Rate Constraint
A Resource may become constrained during peak intervals while remaining sufficient on average.
Average Resource Sufficiency ≠ Peak Resource Sufficiency.
25. Temporal Constraint
A Temporal Constraint exists where Resource availability or capacity is insufficient during the time interval in which it is required.
26. Temporal Principle
Resource Available Later ≠ Resource Available When Required.
27. Temporal-Mismatch Constraint
A Resource may exist in sufficient total quantity but be temporally misaligned with the relevant requirement.
28. Temporal Boundary
Long-Term Resource Sufficiency ≠ Short-Term Resource Sufficiency.
29. Location Constraint
A Location Constraint exists where Resource availability or capacity is insufficient at the location where it is required despite sufficient Resource conditions elsewhere.
30. Location Principle
Resource Availability Somewhere ≠ Resource Availability Where Required.
31. Spatial-Mismatch Constraint
A Spatial-Mismatch Constraint exists where the Resource and Resource requirement are geographically or operationally separated in a way that materially limits Resource use.
32. Source Constraint
A Source Constraint exists where a specific Resource Source becomes materially limited.
33. Source Principle
Constraint of Source A ≠ Constraint of Every Source of the Same Resource Type.
34. Source-Specific Scarcity Boundary
A Source may be constrained while alternative Sources remain available.
Whether those Sources can substitute for the constrained Source remains a separate governance question.
Alternative Source Availability ≠ Automatic Substitutability.
35. Accessibility Constraint
An Accessibility Constraint exists where Resource capacity exists but cannot be accessed by the relevant participant, system, function, or location.
36. Accessibility Principle
Available Resource ≠ Accessible Resource.
37. Access-Governance Boundary
An Accessibility Constraint may result from:
physical conditions; technical conditions; infrastructure conditions; governed Access conditions; other operational conditions.
RCTM identifies the Constraint Type.
RAGS governs Resource Access authority and rights.
38. Quality Constraint
A Quality Constraint exists where Resource quantity is available but fails the quality required for the relevant Resource use.
39. Quality Principle
Sufficient Resource Quantity ≠ Sufficient Resource Quality.
40. Quality-Degradation Constraint
A Resource may transition into a constrained state because its usable quality deteriorates even when physical quantity remains unchanged.
41. Quality Boundary
Resource Presence ≠ Functional Resource Suitability.
42. Delivery Constraint
A Delivery Constraint exists where Resource supply exists but cannot be delivered to the relevant requirement with sufficient quantity, rate, timing, reliability, or other required delivery condition.
43. Delivery Principle
Resource Availability ≠ Resource Deliverability.
44. Delivery and Location
Delivery Constraints may create Localized Scarcity even where upstream Resource supply remains sufficient.
45. Infrastructure Constraint
An Infrastructure Constraint exists where infrastructure required for Resource access, transport, transmission, processing, storage, conversion, cooling, treatment, or delivery becomes materially limiting.
46. Infrastructure Examples
Infrastructure Constraints may include:
electricity transmission congestion; pipeline capacity limitation; port congestion; water-treatment limitation; cooling-system capacity; data-network saturation; storage limitation; transport-system failure.
47. Infrastructure Principle
Resource Supply ≠ Infrastructure Capacity.
48. Infrastructure-Failure Constraint
Infrastructure failure may create a Resource Constraint even when the underlying Resource remains abundant.
49. Regenerative Constraint
A Regenerative Constraint exists where a Resource's effective regeneration cannot sustain the relevant withdrawal, Consumption, or depletion pattern over the applicable time horizon.
50. Regenerative Principle
Renewable Resource ≠ Unconstrained Resource.
51. Regeneration-Rate Constraint
A Resource may regenerate while remaining constrained because:
Consumption Rate > Effective Regeneration Rate
over a materially relevant period.
52. Regeneration Boundary
Resource Regeneration ≠ Immediate Resource Availability.
53. Dependency-Induced Constraint
A Dependency-Induced Constraint exists where a Resource becomes constrained because another Resource, system, infrastructure, or capability upon which its availability or use depends becomes constrained.
54. Dependency Principle
Constraint in a Dependency ≠ Automatic Constraint in the Dependent Resource.
The operational dependency and resulting limitation must be evidenced.
55. Cross-Resource Constraint
A Cross-Resource Constraint exists where the constrained state of one Resource materially limits the availability, usability, accessibility, capacity, or delivery of another Resource.
Example:
Water Constraint → Cooling Constraint → Compute Capacity Constraint
56. Cross-Resource Principle
Resource Correlation ≠ Cross-Resource Constraint.
A material dependency mechanism must exist.
57. Direct Constraint
A Direct Constraint acts directly upon the governed Resource or its immediate capacity.
Examples:
reduced water quantity; GPU failure;
pipeline capacity reduction.
58. Indirect Constraint
An Indirect Constraint affects the governed Resource through another dependency or enabling condition.
Examples:
electricity constraint reducing water-treatment capacity; water constraint reducing data-center cooling capacity.
59. Directness Principle
Indirect Constraint ≠ Secondary Importance.
An indirect constraint may become the dominant limitation.
60. Primary Constraint
A Primary Constraint is the Constraint mechanism that currently exerts the dominant limiting effect within the defined Resource context.
61. Primary-Constraint Boundary
Primary Constraint ≠ Root Cause by definition.
The dominant current limitation may itself result from another upstream mechanism.
62. Secondary Constraint
A Secondary Constraint materially contributes to the Resource limitation without being the dominant current constraint.
63. Secondary-Constraint Principle
Secondary Constraint ≠ Immaterial Constraint.
64. Combined Constraint
A Combined Constraint exists where multiple Constraint Types jointly produce or materially intensify the constrained Resource condition.
65. Combined-Constraint Principle
One Resource Constraint State ≠ One Constraint Type by default.
66. Constraint Interaction
RCTM should identify material interactions among simultaneous Constraint Types.
Possible interaction forms include:
independent; additive; amplifying; cascading; conditional; sequential; mutually reinforcing.
67. Independent Constraints
Two constraints may affect the same Resource without materially influencing one another.
68. Additive Constraints
Multiple constraints may independently reduce Resource sufficiency and collectively create a larger Resource limitation.
69. Amplifying Constraints
One Constraint Type may increase the effect of another.
For example:
high temperature → reduced cooling efficiency → increased water requirement → stronger water Constraint.
70. Cascading Constraints
One Constraint may trigger another Constraint through a dependency chain.
71. Conditional Constraint
A Constraint may become active only when another condition is present.
72. Interaction Principle
Coexisting Constraints ≠ Interacting Constraints by default.
Interaction must be evidenced.
73. Constraint Accumulation
Multiple individually manageable constraints may collectively become materially limiting.
Individually Non-Critical Constraints ≠ Collectively Non-Critical Constraint State.
74. Constraint Attribution
RCTM should preserve the evidentiary basis connecting the observed Resource limitation with the classified Constraint Type.
75. Attribution Evidence
Constraint attribution may use:
Resource measurements; capacity measurements; Source records; infrastructure telemetry; quality measurements; Access records; delivery records; regeneration evidence; dependency evidence; operational event records; other governed evidence.
76. Attribution Principle
Temporal Correlation ≠ Constraint Causation.
77. Multi-Causal Attribution
Where several mechanisms contribute to the Resource limitation, RCTM should preserve each material mechanism rather than forcing a single-cause classification.
78. Causal Confidence
Constraint mechanism attribution should preserve uncertainty or confidence where appropriate.
79. Confidence Principle
High Classification Confidence ≠ High Constraint Severity.
Confidence concerns evidence.
Severity concerns governance significance.
80. Constraint-Type Evidence
Every material Constraint Type should preserve evidence sufficient to support the classification.
81. Evidence Provenance
Material Constraint evidence should remain traceable to its origin, applicable period, Resource context, and relevant measurement or observation.
82. Evidence Sufficiency
RCTM should determine whether evidence is sufficient for the asserted Constraint Type.
Observed Resource Limitation Without Sufficient Causal Evidence ≠ Confirmed Constraint Type.
83. Constraint Type Unknown
Constraint Type Unknown applies where a Resource limitation is observed but the mechanism cannot yet be sufficiently identified.
84. Unknown-Type Principle
Unknown Constraint Type ≠ No Constraint.
85. Constraint Type Conflicted
Constraint Type Conflicted applies where material evidence supports incompatible Constraint-mechanism classifications.
86. Conflict Principle
Conflicting Constraint Evidence ≠ Permission to Select the Most Convenient Mechanism.
87. Multiple Constraint Types
Where evidence supports multiple simultaneous Constraint Types, each should remain independently identifiable.
88. Multi-Type Principle
Multiple Constraint Types ≠ Duplicate Classification.
Distinct mechanisms should remain distinct even when they contribute to the same Scarcity State.
89. Constraint-Type Transition
The mechanism constraining a Resource may change over time.
For example:
Source Constraint → Delivery Constraint → Infrastructure Constraint
or:
Rate Constraint → Quantity Constraint
as conditions evolve.
90. Transition Principle
Same Scarcity State ≠ Same Constraint Type Over Time.
91. Constraint-Type Persistence
A Constraint Type may persist even when its magnitude or severity changes.
92. Constraint-Type Resolution
A specific Constraint Type may resolve while other Constraint Types remain active.
93. Resolution Principle
Resolution of One Constraint Type ≠ Resolution of Resource Scarcity.
94. Constraint Substitution
Removing one Constraint may expose another previously non-binding Constraint.
For example:
grid capacity increased → cooling capacity becomes the new limiting constraint.
95. Binding Constraint
A Binding Constraint is the Constraint currently limiting Resource sufficiency or capacity within the applicable context.
96. Binding-Constraint Principle
Most Visible Constraint ≠ Binding Constraint by default.
97. Constraint Hierarchy
Where multiple constraints exist, RCTM may preserve relationships such as:
upstream; downstream; primary; secondary; binding; non-binding; enabling; dependent.
98. Hierarchy Boundary
Constraint Hierarchy ≠ Governance Priority Hierarchy.
RPAS governs Resource Priority.
99. Constraint Monitoring
Material Constraint Types should support monitoring appropriate to their operational characteristics.
100. Type-Specific Monitoring
Monitoring variables should reflect the Constraint Type.
Examples:
Quantity Constraint → Resource stock / flow
Capacity Constraint → usable capacity / occupancy
Rate Constraint → throughput / withdrawal / delivery rate
Temporal Constraint → availability window
Location Constraint → spatial availability
Source Constraint → Source condition
Quality Constraint → Resource quality indicators
Infrastructure Constraint → infrastructure capacity / state
Regenerative Constraint → withdrawal / regeneration relationship
101. Monitoring Principle
One Monitoring Variable ≠ Sufficient Evidence for Every Constraint Type.
102. Constraint-Type Reassessment
Constraint Type should be reassessed when materially relevant evidence changes.
Triggers may include:
Resource-state change; capacity change; Source change; infrastructure change; quality change; Access change; location change; regeneration change; dependency change; new operational evidence.
103. Historical Constraint Type
Historical Constraint Types may support recurrence and causal analysis.
However:
Historical Constraint Type ≠ Current Constraint Type.
104. Predicted Constraint Type
Prediction may identify a likely future Constraint Type.
However:
Predicted Constraint Type ≠ Observed Constraint Type.
PGA™ governs Prediction methodology where applicable.
105. Simulated Constraint Type
Simulation may test how Constraint Types could emerge under hypothetical conditions.
Simulated Constraint Type ≠ Operational Constraint Type.
SIMULOS® governs simulation.
106. Scarcity Boundary
RSSM determines the Resource Scarcity State.
RCTM determines the Constraint Type.
Constraint Type ≠ Scarcity State.
107. Severity Boundary
Constraint Type may provide an input to severity evaluation.
However:
Constraint Type ≠ Constraint Severity.
108. Demand Boundary
Demand may contribute to Resource constraint.
RCTM may identify Demand-related mechanisms where supported by evidence.
It does not govern Demand itself.
RDGS retains Resource Demand governance.
109. Dependency Boundary
Dependency evidence may explain a Dependency-Induced or Cross-Resource Constraint.
RDCS governs Resource Dependency and Criticality.
RCTM governs the Constraint mechanism affecting the Resource.
110. Access Boundary
Access conditions may create an Accessibility Constraint.
RAGS governs Access authority.
RCTM governs the resulting Constraint Type.
111. Allocation Boundary
Allocation may create or expose a localized Resource Constraint.
RCTM may classify the resulting mechanism.
It does not determine whether the Allocation should change.
112. Consumption Boundary
Consumption patterns may contribute to Quantity, Rate, Capacity, Regenerative, or other Constraint Types.
RCUS governs Consumption & Utilization.
RCTM governs the resulting Constraint classification.
113. Recovery Boundary
Recovery may reduce a Resource Constraint.
RCTM may observe the resulting Constraint-Type change.
It does not govern Recovery.
114. Substitution Boundary
An alternative Resource may bypass or reduce a Constraint.
RCTM does not determine whether substitution is acceptable.
RSFS governs substitution.
115. Resilience Boundary
Constraint Types may reveal vulnerabilities relevant to resilience.
RIRS governs Resource Interdependency & Resilience.
116. Sustainability Boundary
Persistent or regenerative Constraint Types may provide Sustainability evidence.
RCTM does not determine long-term Sustainability.
117. Value Boundary
The Value produced by Resource use does not determine Constraint Type.
High Value ≠ Different Constraint Mechanism.
118. Harm Boundary
A Constraint may contribute to Harm.
Resource Constraint ≠ Harm.
HAGA™ governs Harm.
119. Liability Boundary
A Constraint may become evidence relevant to Liability.
Resource Constraint ≠ Liability.
LIGA™ governs Liability.
120. Automation Boundary
Software may classify Resource Constraint Types.
However:
Automated Constraint Classification ≠ Governance Authority.
121. Intervention Boundary
Identification of a Constraint Type may support intervention analysis.
It does not authorize intervention.
Constraint Diagnosis ≠ Intervention Authority.
122. Resource Constraint Type Profile
The principal RCTM output is the:
Resource Constraint Type Profile
123. Minimum Resource Constraint Type Profile Fields
At minimum:
Constraint Type ID
Resource ID
Resource Type
Resource Source
Location
Applicable Time Horizon
Scarcity State Reference
Observed Resource Limitation
Primary Constraint Type
Secondary Constraint Types
Constraint Mechanism
Direct / Indirect State
Primary / Secondary State
Binding / Non-Binding State
Single / Combined Constraint State
Quantity Constraint State
Capacity Constraint State
Rate Constraint State
Temporal Constraint State
Location Constraint State
Source Constraint State
Accessibility Constraint State
Quality Constraint State
Delivery Constraint State
Infrastructure Constraint State
Regenerative Constraint State
Dependency-Induced Constraint State
Cross-Resource Constraint State
Constraint Interaction State
Constraint Hierarchy
Causal Evidence
Evidence Provenance
Evidence Sufficiency
Classification Confidence
Uncertainty State
Conflict State
Monitoring State
Constraint-Type Transition
Reassessment Trigger
Effective Time
Version:
124. Minimum Implementation Framework
A minimum operational RCTM implementation should contain eight governed layers.
Layer 1 — Resource Limitation
Establish:
Resource; observed limitation; Source; location; time horizon; operational context.
Layer 2 — Constraint Evidence
Collect:
quantity; capacity; rate; time; location; Source; Access; quality; delivery; infrastructure; regeneration; dependency evidence.
Layer 3 — Mechanism Identification
Determine the operational mechanism producing or contributing to the Resource limitation.
Layer 4 — Constraint Type Classification
Classify applicable Constraint Types.
Layer 5 — Constraint Relationship
Determine where applicable:
direct / indirect; primary / secondary; binding / non-binding; single / combined.
Layer 6 — Interaction & Causality
Determine:
interaction; accumulation; causal evidence; uncertainty; conflict.
Layer 7 — Monitoring & Reassessment
Establish:
type-specific monitoring; transition triggers; reassessment triggers.
Layer 8 — Governed Output
Produce:
Resource Constraint Type Profile
Canonical machine-readable logic:
**Observed Resource Limitation
Resource Context Constraint Evidence → Mechanism Identification
→ Constraint Type Classification → Constraint Relationship → Interaction / Causality → Evidence / Uncertainty / Conflict → Resource Constraint Type Profile**
125. Minimum Decision States
At minimum:
Quantity Constraint Identified
Capacity Constraint Identified
Rate Constraint Identified
Temporal Constraint Identified
Location Constraint Identified
Source Constraint Identified
Accessibility Constraint Identified
Quality Constraint Identified
Delivery Constraint Identified
Infrastructure Constraint Identified
Regenerative Constraint Identified
Dependency-Induced Constraint Identified
Cross-Resource Constraint Identified
Combined Constraint Identified
Binding Constraint Identified
Constraint Type Evidence-Limited
Constraint Type Conflicted
Constraint Type Unknown
Constraint Type Reassessment Required
126. Minimum Evidence Path
Where Constraint Type cannot be sufficiently determined:
Observed Resource Limitation → Constraint Type Unknown / Evidence-Limited / Conflicted → Missing Quantity / Capacity / Rate / Source / Location / Quality / Infrastructure / Dependency Evidence → Minimum Evidence Requirement → Evidence Acquisition → Mechanism Analysis → Constraint Type Classification → Causal Validation → Resource Constraint Type Profile Update
127. Minimum Reassessment Framework
At minimum:
Current Resource Constraint Type Profile → New Resource / Capacity / Source / Infrastructure / Quality / Access / Dependency Evidence → Materiality Test → Mechanism Reassessment → Constraint-Type Reclassification → Constraint-Relationship Review → Interaction / Causality Review → Monitoring Review → Profile Update → Version Update
128. Governance Requirements
A conforming RCTM implementation must:
1. identify the governed Resource; 2. preserve Resource type; 3. preserve Resource Source where material; 4. preserve location where material; 5. preserve the applicable time horizon; 6. identify the observed Resource limitation; 7. preserve relevant operational context; 8. distinguish Resource Constraint from Resource Scarcity; 9. distinguish Constraint Type from Scarcity State; 10. distinguish Constraint Type from Constraint Severity; 11. identify the applicable Constraint mechanism where evidence permits; 12. prevent observed limitation from becoming proven mechanism without evidence; 13. support Quantity Constraint classification; 14. distinguish low quantity from Quantity Constraint by itself; 15. prevent Quantity Constraint from becoming Scarcity automatically; 16. support Capacity Constraint classification; 17. distinguish Resource existence from Resource capacity; 18. distinguish installed from usable capacity; 19. support Capacity-Saturation Constraint; 20. prevent high Utilization from becoming Capacity Constraint automatically; 21. support Rate Constraint classification; 22. distinguish total quantity sufficiency from rate sufficiency; 23. support Peak-Rate Constraint; 24. distinguish average Resource sufficiency from peak sufficiency; 25. support Temporal Constraint classification; 26. distinguish later availability from availability when required; 27. support temporal-mismatch constraints; 28. distinguish long-term sufficiency from short-term sufficiency; 29. support Location Constraint classification; 30. distinguish availability somewhere from availability where required; 31. support spatial-mismatch constraints; 32. support Source Constraint classification; 33. distinguish Source-specific constraint from Resource-type-wide constraint; 34. distinguish alternative Source availability from automatic substitutability; 35. support Accessibility Constraint classification; 36. distinguish available Resource from accessible Resource; 37. preserve Access-related Constraint evidence; 38. preserve RAGS authority boundary; 39. support Quality Constraint classification; 40. distinguish Resource quantity from Resource quality; 41. support quality-degradation constraints; 42. distinguish Resource presence from functional suitability; 43. support Delivery Constraint classification; 44. distinguish Resource availability from Resource deliverability; 45. preserve delivery-related local constraints; 46. support Infrastructure Constraint classification;
47. preserve relevant infrastructure evidence; 48. distinguish Resource supply from infrastructure capacity; 49. support infrastructure-failure constraints; 50. support Regenerative Constraint classification; 51. distinguish renewable Resource from unconstrained Resource; 52. preserve regeneration-rate evidence; 53. distinguish regeneration from immediate Resource availability; 54. support Dependency-Induced Constraint classification; 55. require evidence of the dependency mechanism; 56. prevent dependency constraint from automatically becoming dependent-Resource constraint; 57. support Cross-Resource Constraint classification; 58. distinguish Resource correlation from Cross-Resource Constraint; 59. support Direct Constraint classification; 60. support Indirect Constraint classification; 61. prevent indirect constraints from becoming secondary importance automatically; 62. support Primary Constraint classification; 63. distinguish Primary Constraint from root cause; 64. support Secondary Constraint classification; 65. prevent Secondary Constraint from becoming immaterial automatically; 66. support Combined Constraint classification; 67. prevent one Resource Constraint State from being forced into one Constraint Type; 68. preserve Constraint interaction; 69. support independent interaction state; 70. support additive interaction state; 71. support amplifying interaction state; 72. support cascading interaction state; 73. support conditional interaction state; 74. support sequential interaction state where relevant; 75. support mutually reinforcing interaction state where relevant; 76. prevent coexisting constraints from becoming interacting constraints automatically; 77. identify Constraint accumulation; 78. prevent individually non-critical constraints from being assumed collectively non-critical; 79. preserve Constraint attribution; 80. preserve causal evidence; 81. distinguish temporal correlation from Constraint causation; 82. support multi-causal attribution; 83. preserve causal uncertainty; 84. preserve classification confidence where used; 85. distinguish classification confidence from Constraint Severity; 86. preserve Constraint-Type evidence; 87. preserve evidence provenance; 88. determine evidence sufficiency; 89. prevent observed limitation without causal evidence from becoming confirmed Constraint Type; 90. support Constraint Type Unknown; 91. prevent Unknown Constraint Type from becoming No Constraint; 92. support Constraint Type Conflicted; 93. preserve conflicting Constraint evidence; 94. prevent convenient mechanism selection under evidence conflict; 95. preserve multiple simultaneous Constraint Types; 96. prevent multiple Constraint Types from becoming duplicate classification; 97. preserve Constraint-Type transitions; 98. distinguish same Scarcity State from same Constraint Type over time; 99. preserve Constraint-Type persistence; 100. identify resolution of individual Constraint Types; 101. prevent resolution of one Constraint Type from becoming Scarcity Resolution; 102. identify emergence of newly binding constraints; 103. support Binding Constraint identification; 104. distinguish most visible Constraint from Binding Constraint; 105. preserve Constraint hierarchy where relevant; 106. distinguish Constraint hierarchy from governance Priority hierarchy; 107. support type-specific monitoring; 108. align monitoring variables with Constraint Type; 109. prevent one monitoring variable from becoming sufficient for every Constraint Type; 110. support Constraint-Type reassessment; 111. preserve reassessment triggers;
112. distinguish historical Constraint Type from current Constraint Type; 113. distinguish predicted Constraint Type from observed Constraint Type; 114. distinguish simulated Constraint Type from operational Constraint Type; 115. preserve RSSM Scarcity-State boundary; 116. preserve Constraint Severity boundary; 117. preserve RDGS Demand boundary; 118. preserve RDCS Dependency and Criticality boundary; 119. preserve RAGS Access boundary; 120. preserve RPAS Allocation boundary; 121. preserve RCUS Consumption & Utilization boundary; 122. preserve RRCS Recovery boundary; 123. preserve RSFS substitution boundary; 124. preserve RIRS resilience boundary; 125. preserve RCSS Sustainability boundary; 126. distinguish Resource Constraint from Harm; 127. distinguish Resource Constraint from Liability; 128. distinguish automated Constraint classification from governance authority; 129. distinguish Constraint diagnosis from intervention authority; 130. produce a Resource Constraint Type Profile.
129. Governance Logic
Canonical RCTM logic:
Governed Resource → Observed Resource Limitation → Resource Context → Quantity / Capacity / Rate / Time / Location / Source / Accessibility / Quality / Delivery / Infrastructure / Regeneration / Dependency Evidence → Constraint Mechanism Identification → Constraint Type Classification → Direct / Indirect Classification → Primary / Secondary Classification → Binding / Non-Binding Classification → Constraint Interaction → Causal Evidence → Evidence Sufficiency / Uncertainty / Conflict → Resource Constraint Type Profile → Monitoring → Reassessment
130. Governance Outputs
RCTM may produce:
Resource Constraint Type Profile
Primary Constraint Type
Secondary Constraint Type Set
Constraint Mechanism
Quantity Constraint State
Capacity Constraint State
Rate Constraint State
Temporal Constraint State
Location Constraint State
Source Constraint State
Accessibility Constraint State
Quality Constraint State
Delivery Constraint State
Infrastructure Constraint State
Regenerative Constraint State
Dependency-Induced Constraint State
Cross-Resource Constraint State
Combined Constraint State
Direct / Indirect Constraint State
Primary / Secondary Constraint State
Binding / Non-Binding Constraint State
Constraint Interaction State
Constraint Hierarchy
Causal Evidence State
Evidence Sufficiency State
Classification Confidence
Constraint Conflict State
Constraint-Type Transition
Monitoring State
Reassessment Trigger
Version:
131. Critical Distinctions
Resource Constraint ≠ Resource Scarcity
Constraint Type ≠ Scarcity State
Constraint Type ≠ Constraint Severity
Observed Resource Limitation ≠ Proven Constraint Mechanism
One Scarcity State ≠ One Constraint Type by definition
Low Resource Quantity ≠ Quantity Constraint by itself
Quantity Constraint ≠ Scarcity automatically
Resource Existence ≠ Sufficient Resource Capacity
Installed Capacity ≠ Usable Capacity
High Utilization ≠ Capacity Constraint by definition
Sufficient Total Resource Quantity ≠ Sufficient Resource Rate
Average Resource Sufficiency ≠ Peak Resource Sufficiency
Resource Available Later ≠ Resource Available When Required
Long-Term Resource Sufficiency ≠ Short-Term Resource Sufficiency
Resource Availability Somewhere ≠ Resource Availability Where Required
Constraint of Source A ≠ Constraint of Every Source of the Same Resource Type
Alternative Source Availability ≠ Automatic Substitutability
Available Resource ≠ Accessible Resource
Sufficient Resource Quantity ≠ Sufficient Resource Quality
Resource Presence ≠ Functional Resource Suitability
Resource Availability ≠ Resource Deliverability
Resource Supply ≠ Infrastructure Capacity
Renewable Resource ≠ Unconstrained Resource
Resource Regeneration ≠ Immediate Resource Availability
Constraint in a Dependency ≠ Automatic Constraint in the Dependent Resource
Resource Correlation ≠ Cross-Resource Constraint
Indirect Constraint ≠ Secondary Importance
Primary Constraint ≠ Root Cause by definition
Secondary Constraint ≠ Immaterial Constraint
One Resource Constraint State ≠ One Constraint Type by default
Coexisting Constraints ≠ Interacting Constraints by default
Individually Non-Critical Constraints ≠ Collectively Non-Critical Constraint State
Temporal Correlation ≠ Constraint Causation
High Classification Confidence ≠ High Constraint Severity
Observed Resource Limitation Without Sufficient Causal Evidence ≠ Confirmed Constraint Type
Unknown Constraint Type ≠ No Constraint
Conflicting Constraint Evidence ≠ Permission to Select the Most Convenient Mechanism
Multiple Constraint Types ≠ Duplicate Classification
Same Scarcity State ≠ Same Constraint Type Over Time
Resolution of One Constraint Type ≠ Resolution of Resource Scarcity
Most Visible Constraint ≠ Binding Constraint by default
Constraint Hierarchy ≠ Governance Priority Hierarchy
One Monitoring Variable ≠ Sufficient Evidence for Every Constraint Type
Historical Constraint Type ≠ Current Constraint Type
Predicted Constraint Type ≠ Observed Constraint Type
Simulated Constraint Type ≠ Operational Constraint Type
Scarcity State ≠ Complete Constraint Diagnosis
Resource Constraint ≠ Harm
Resource Constraint ≠ Liability
Automated Constraint Classification ≠ Governance Authority
Constraint Diagnosis ≠ Intervention Authority
132. Use Case 1 — AI Data Center Multi-Constraint Classification
An AI data center has sufficient installed GPU inventory for a planned workload.
Operational evidence shows:
GPU inventory — sufficient; electrical connection capacity — near maximum; cooling capacity — limited during peak temperature; water delivery rate — temporarily reduced; available annual water quantity — sufficient.
A generic shortage classification could incorrectly label the situation as a compute shortage or water shortage.
RCTM separates the mechanisms.
It identifies:
Compute Quantity Constraint — not established
Electrical Capacity Constraint — active
Cooling Infrastructure Constraint — active
Water Quantity Constraint — not established
Water Delivery / Rate Constraint — active
The cooling limitation is partly amplified by the reduced water-delivery rate.
RCTM therefore records a Combined Constraint with interacting Capacity, Infrastructure, and Rate Constraint Types.
It does not determine whether workloads should be stopped or reallocated.
Its output establishes how the Resource system is constrained , allowing the competent downstream governance mechanisms to act on the correct problem.
133. Use Case 2 — Regional Water Constraint Classification
A region reports declining water availability during a prolonged dry period.
Evidence shows:
reservoir quantity — reduced but still above minimum operational requirement; groundwater regeneration — materially below withdrawal rate; treatment capacity — sufficient; one municipality's pipeline — operating at maximum delivery capacity; another municipality retains sufficient supply.
RCTM does not classify the entire condition as a generic “water shortage.”
It identifies:
Regenerative Constraint — active
Delivery / Infrastructure Constraint — active in the affected municipality
Regional Quantity Constraint — not yet established
Location Constraint — active for the affected municipality
The Resource system therefore contains several distinct Constraint Types with different geographic and operational boundaries.
RCTM preserves those distinctions so that a regenerative Resource problem is not mistaken for a simple quantity shortage and a local delivery problem is not misrepresented as region-wide Resource absence.
134. Cross-Architecture Boundary
RCTM may consume:
RCHS — Resource identity, type, Source, state, and context.
RACS — Availability, usable capacity, temporal availability, location, accessibility, and capacity evidence.
RDGS — Demand evidence relevant to Demand-induced Resource constraints.
RDCS — Dependency and Criticality evidence relevant to Dependency-Induced and Cross-Resource constraints.
RAGS — Access evidence relevant to Accessibility Constraints.
RPAS — Allocation evidence relevant to Allocation-induced Resource conditions.
RCUS — Consumption and Utilization evidence relevant to Consumption-induced, Rate, Capacity, and Regenerative constraints.
RSSM — Resource Scarcity State evidence.
Other RSCS mechanisms may consume RCTM outputs for:
Constraint Severity; escalation; resolution; monitoring; Scarcity response.
RCTM may provide evidence to:
RRCS — Resource Recovery & Circularity.
RSFS — Resource Substitution & Flexibility.
RIRS — Resource Interdependency & Resilience.
RCSS — Resource Continuity & Sustainability.
ORA™ — operational reality evidence.
PGA™ — prediction relationships.
SIMULOS® — simulation relationships.
VEGA™ — Value and efficiency governance.
HAGA™ — Harm governance.
LIGA™ — Liability governance.
RCTM does not absorb these mechanisms.
135. 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.
RCTM governs the classification of how a Resource is constrained .
It does not govern the downstream decisions that the Constraint diagnosis may trigger.
136. Canonical Boundary
RCTM governs how the specific type or combination of types of Resource Constraint affecting a defined Resource or Resource capacity is identified, distinguished, classified, evidenced, attributed to an operational Constraint mechanism, related to simultaneous constraints, monitored, and reassessed across quantity, capacity, rate, time, location, Source, accessibility, quality, delivery, infrastructure, regeneration, dependency, and cross-Resource conditions.
It does not independently determine the Resource Scarcity State, complete Constraint Severity, Resource Demand, Resource Dependency or Criticality, Access authority, Priority or Allocation, Resource Consumption measurement, Recovery action, substitution authorization, resilience, long-term Sustainability, Value, Harm, Liability, or intervention authority.
Its principal governed output is the Resource Constraint Type Profile .
137. Canonical Closing Statement
A Resource shortage cannot be governed correctly until governance knows what is actually constrained. Insufficient quantity, saturated capacity, inadequate rate, wrong timing, wrong location, Source interruption, poor quality, inaccessible supply, infrastructure limitation, and regenerative deficit are not interchangeable problems.
RCTM turns the generic idea of Resource constraint into an evidenced operational diagnosis — identifying how the Resource is constrained, which mechanisms interact, which limitation is binding, and where uncertainty remains without converting diagnosis into Scarcity severity, Allocation authority, or intervention authority.