RCXM — Resource Context Module
Architecture: RSGA™ — Resource Sustainability Governance Architecture
Parent Standard: Resource Characterization Standard (RCHS)
Category: Governance & Enforcement
Subcategory: Resource Governance
Type: Core Module
Governed Space: Resource Context Governance
Module ID: RSGA-RCHS-RCXM-05
Origin ID: OOF-RSGA-RCHS-RCXM
Version: 1.0
Status: Draft Module
Effective Date: 4 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
RCXM — Resource Context Module governs how the materially relevant physical, spatial, temporal, technical, environmental, infrastructural, operational, dependency-related, recovery-related, and other Resource-specific conditions surrounding a Governed Resource are identified, structured, evidenced, maintained, and reassessed so that Resource Characterization reflects the conditions under which the Resource actually exists and carries governance significance.
RCXM consolidates the contextual conditions necessary to interpret the Governed Resource correctly.
The governance significance of a Resource cannot be determined from quantity alone.
2. Operational Role
A Resource may have the same nominal quantity while carrying fundamentally different governance significance under different conditions.
One million litres of water may represent very different Resource realities depending upon:
Location Season Source Quality Accessibility Local water stress Regeneration conditions Infrastructure Competing dependencies Recovery possibilities Time horizon
The same applies to electricity, compute, storage, network capacity, critical materials, land, cooling, regenerative Resources, and other constrained Resources.
RCXM therefore answers:
Under what conditions does this Resource exist? Where is the Resource relevant? When is the characterization valid? Which surrounding conditions materially affect its governance significance? Which contextual differences must remain visible? Which contextual information is evidence-based? Which context is uncertain or changing? When must the Resource Context be reassessed?
3. Governed Object
The primary Governed Object is:
The materially relevant Context surrounding a Governed Resource or Resource System.
RCXM governs Resource Context.
It does not independently determine:
Availability Capacity Demand Criticality Access Priority Allocation Scarcity Recovery execution Resilience Continuity Sustainability
Instead, it establishes contextual inputs upon which those later determinations may depend.
4. Position in Parent Standard Internal Module Flow
The Resource Characterization Standard (RCHS) internal module flow is:
RBDM — Resource Boundary Definition Module → RTCM — Resource Type & Constraint Module → RSDM — Resource State Definition Module
→ ROSM — Resource Origin & Source Module → RCXM — Resource Context Module
RCXM completes the initial Resource Characterization layer by integrating the material context surrounding the Resource already defined through the preceding modules.
5. Context Requirement
A Resource Characterization is not sufficiently complete merely because the Resource has:
Identity Boundary Type Constraint Profile State Origin Source
The conditions under which those characteristics matter must also be represented where material.
Resource Characterization without relevant Context may be technically correct yet governance- incomplete.
6. Context as a Governance Layer
Resource Context is the structured set of conditions necessary to interpret the Resource within the governed question.
Context may determine whether identical Resource measurements have different governance significance.
RCXM therefore treats Context as a first-class governance layer rather than supplementary descriptive metadata.
7. Context Materiality
Context is material when changing it could reasonably alter a downstream Resource Sustainability determination.
The materiality test is:
Would changing this contextual condition potentially change how the Resource should be interpreted for availability, dependency, access, allocation, scarcity, recovery, resilience, continuity, or sustainability governance?
If yes, the condition should remain visible.
8. Context Dimensions
Material Resource Context may include:
Physical Context Spatial Context Temporal Context Source Context State Context Quality Context Condition Context Technical Context Infrastructure Context Operational Context Environmental Context Regeneration Context
Recovery Context Dependency Context Substitution Context System Context
Not every Resource requires every dimension.
9. Physical Context
Physical Context describes materially relevant physical conditions surrounding the Resource.
This may include:
Form Physical condition Containment Storage condition Relevant physical environment Material configuration
Specialized physical determinations remain with the competent technical domain.
10. Spatial Context
Spatial Context establishes where the Resource and its relevant conditions apply.
Possible spatial levels include:
Asset Facility Site Local area Municipality Region Watershed Grid zone Network zone Country Cross-border system
Resource significance is location-dependent where Resource conditions vary spatially.
11. Local Context
A Resource may be abundant at a wider scale while constrained locally.
RCXM must therefore preserve local conditions where they materially affect Resource governance.
Global Resource abundance does not establish local Resource sufficiency.
12. Regional Context
Regional Resource conditions may affect:
Supply Infrastructure Scarcity Recovery Regeneration
Substitution Cross-system dependencies
Regional context should remain distinct from facility-level or global context.
13. Cross-Boundary Context
Resource conditions may be influenced by systems outside the immediate Resource boundary.
RCXM may represent relevant external context without expanding the Governed Resource boundary itself.
Relevant external Context ≠ Automatic boundary inclusion.
14. Temporal Context
Resource Context must preserve time where Resource significance changes materially through time.
Relevant horizons may include:
Current Immediate Peak Daily Seasonal Annual Planning horizon Recovery horizon Regeneration horizon Infrastructure lifecycle Long-term continuity horizon
15. Present Context
Present Context represents conditions applicable to the current governed Resource determination.
Present conditions must not automatically be projected into the future.
Present Resource Context ≠ Future Resource Context.
16. Historical Context
Historical Context may support understanding of:
Resource variability Prior constraints State transitions Source changes Regeneration patterns Recovery patterns
Historical conditions must remain distinguishable from current conditions.
17. Future Context
Future Resource Context may be relevant to planning.
Where future conditions depend upon Prediction, the predicted nature of the information must remain explicit.
Predicted Context ≠ Observed Context.
PGA™ retains Prediction Governance.
18. Seasonal Context
Some Resources vary materially by season.
Examples may include:
Water Hydropower Solar generation Wind conditions Biological Resources Heating or cooling capacity
Annual averages must not erase material seasonal constraints.
19. Peak Context
Resource governance may require understanding peak conditions.
A Resource System adequate under average conditions may become constrained during peaks.
Average Resource Condition ≠ Peak Resource Condition.
20. Quality Context
Resource quantity may be insufficient as a governance representation where Resource quality affects usability.
Quality Context may concern:
Purity Contamination Technical specification Energy characteristics Material grade Water characteristics Compute capability Network characteristics
RCXM preserves the contextual significance of quality.
21. Condition Context
Resource condition may affect governance even where quantity and Source remain unchanged.
Relevant conditions may include:
Degradation Damage Age Readiness Contamination Maintenance condition Storage condition
22. Technical Context
Technical Context identifies conditions arising from the technical systems through which the Resource is produced, processed, stored, transported, recovered, or used.
RCXM does not govern the underlying engineering mechanism.
It preserves the Resource-relevant context produced by it.
23. Infrastructure Context
Infrastructure may materially shape Resource significance.
Relevant infrastructure may include:
Generation Transmission Distribution Storage Processing Cooling Transport Recovery Network infrastructure
A Resource may exist while infrastructure materially limits its practical relevance.
24. Operational Context
Resource significance may differ under:
Normal operation Peak operation Reduced operation Maintenance Emergency operation Recovery operation Standby operation
Operational context must remain visible where material.
25. Environmental Context
Environmental conditions may materially affect Resource characteristics.
Examples include:
Temperature Precipitation Hydrological conditions Ecological conditions Weather conditions Habitat conditions
RCXM consumes competent environmental determinations without replacing environmental science.
26. Regeneration Context
For regenerative Resources, context may include:
Regeneration mechanism Regeneration horizon Regeneration conditions Regeneration dependencies Observed regeneration pressure
RCXM contextualizes regeneration.
It does not determine sustainable extraction.
27. Recovery Context
For recoverable Resources, relevant Context may include:
Recovery infrastructure Collection conditions Resource dispersion Material separation conditions Recovery pathway Secondary-use pathway
Recoverability depends upon Context as well as Resource characteristics.
28. Source Context
ROSM establishes Origin and Source.
RCXM establishes the contextual conditions under which that Source matters to the governed Resource.
Source Context may include:
Location Time Concentration Infrastructure dependency Transformation pathway Source variability
29. Resource-State Context
RSDM establishes Resource State.
RCXM may preserve contextual conditions necessary to interpret that state.
For example:
Stored Resource + emergency reserve context
differs from:
Stored Resource + normal commercial inventory context
even where the physical state is similar.
30. Dependency Context
A Resource may carry different governance significance depending upon what depends upon it.
RCXM may identify that dependency relationships exist and are contextually relevant.
RDCS later determines Dependency & Criticality.
Dependency Context ≠ Dependency Determination.
31. Criticality Context
Context may indicate conditions relevant to later Criticality assessment.
RCXM must not independently label a Resource critical merely because the context appears important.
Criticality-Relevant Context ≠ Criticality Determination.
32. Demand Context
Known demand conditions may influence how Resource Context is interpreted.
RCXM may preserve contextual demand information where necessary for characterization.
RDGS governs Demand.
33. Access Context
Physical or technical circumstances may affect practical accessibility.
RCXM may preserve these contextual conditions.
RAGS retains governance of access eligibility and authorization.
Access-Relevant Context ≠ Access Authority.
34. Allocation Context
Existing reservations, allocations, or distribution structures may form relevant context.
RCXM does not determine allocation.
It preserves context necessary for accurate downstream interpretation.
35. Scarcity Context
Known conditions may make Resource scarcity more or less plausible.
RCXM does not determine Scarcity State.
RSCS retains Scarcity & Constraint governance.
Scarcity-Relevant Context ≠ Scarcity Determination.
36. Substitution Context
The existence of potential substitutes may be contextually relevant.
RCXM may preserve:
Known alternative Resource Location-specific substitute
Time-dependent substitute Technical substitution condition
RSFS governs actual substitution.
37. Interdependency Context
Resource Context may include material relationships with other Resources.
Example:
Compute ↔ Electricity ↔ Cooling ↔ Water
RCXM records context necessary for characterization.
RIRS governs full Interdependency & Resilience.
38. Continuity Context
Resource characteristics may differ depending upon the continuity horizon being examined.
Immediate operational sufficiency does not establish long-term continuity.
Current adequacy ≠ Continuity.
39. Sustainability Context
Resource Context may include conditions relevant to later Sustainability determination.
RCXM does not determine sustainability.
Sustainability-Relevant Context ≠ Sustainability State.
40. Resource Context Profile
The principal RCXM output is the:
Resource Context Profile
The Profile integrates materially relevant contextual conditions surrounding the Governed Resource without collapsing them into a single score.
41. Contextual Independence
Contextual dimensions must remain independently interpretable where their distinction matters.
For example:
Location Time Quality Scarcity conditions Dependency
must not be compressed into one opaque classification if doing so prevents downstream reasoning.
42. Context Interaction
Context dimensions may interact.
Examples:
Location × Time
Quality × Use
Season × Regeneration
Infrastructure × Accessibility
Dependency × Scarcity
RCXM must permit relevant contextual relationships to remain visible.
43. Context Interaction Matrix
Where complexity requires it, RCXM may represent a Context Interaction Matrix identifying relationships as:
Independent Dependent Amplifying Limiting Conditional Unknown
This is contextual characterization, not a downstream decision.
44. Context Combination
Multiple individually moderate contextual conditions may combine into a materially significant Resource situation.
RCXM must therefore permit compound Context representation.
Contextual significance may emerge from combinations that are not material in isolation.
45. Context Dominance
One contextual condition may dominate the interpretation of a Resource at a particular time.
Examples:
Extreme local scarcity Infrastructure outage Severe quality degradation Critical seasonal condition
Dominant Context must not erase secondary material conditions.
46. Context Dependency
Some contextual conditions depend upon others.
Example:
Cooling Context may depend upon:
Ambient temperature Electricity
Water Infrastructure state
These relationships should remain visible where material.
47. Context Granularity
Context must be represented at sufficient granularity for the governed question.
Overly broad Context can hide material differences.
Excessive Context can create analytical noise.
Context granularity must follow governance relevance.
48. Context Scope
RCXM Context should extend only as far as necessary to interpret the Governed Resource correctly.
Context must not become an unlimited collection of everything surrounding the Resource.
Relevant Context ≠ Unlimited Context.
49. Context Inclusion Test
A contextual factor should be included where:
Its presence, absence, or change could materially alter interpretation of the Governed Resource or a downstream Resource Sustainability determination.
Otherwise, it may remain outside the governed Context.
50. Context Exclusion Test
Before excluding a potentially relevant contextual condition, ask:
Could exclusion cause a materially misleading representation of the Resource?
If yes, exclusion requires justification.
If unknown, uncertainty should remain visible.
51. Context Materiality Threshold
A Context implementation may establish domain-appropriate materiality thresholds.
Thresholds must be:
Defined Traceable Relevant to the governed Resource Reassessable
They must not be chosen merely to remove inconvenient Context.
52. Context Evidence
Material Context must be supported by evidence proportionate to governance significance.
Evidence may include:
Measurements Technical records Environmental observations Operational records Scientific determinations Infrastructure data Resource-system data Specialized-domain outputs
53. Context Evidence Provenance
Context evidence should remain traceable to:
Source Time Location Method Relevant Resource Version where applicable
This enables reassessment when Context changes.
54. Context Evidence Freshness
Context may change faster than Resource identity.
Evidence freshness requirements must therefore follow Context volatility.
Examples:
Weather-sensitive water conditions may change rapidly.
Geological Resource Origin may remain stable for long periods.
Evidence freshness must follow the rate at which the governed reality can materially change.
55. Context Observation
Observed Context should remain distinguishable from inferred, declared, predicted, or simulated Context.
Observation alone does not establish universal validity.
It applies to the relevant time and location.
56. Inferred Context
Context may be inferred from evidence.
The inference basis must remain traceable where material.
Inferred Context ≠ Directly Observed Context.
57. Declared Context
An operator, supplier, institution, or other actor may declare contextual conditions.
Declared Context must remain distinguishable from independently established Context.
Declared Context ≠ Verified Context.
58. Predicted Context
Predicted Context concerns future conditions.
Its predictive basis and uncertainty must remain visible.
PGA™ retains Prediction Governance.
59. Simulated Context
Simulation may establish possible contextual states.
Simulated Context must remain distinguishable from actual observed Context.
SIMULOS® retains simulation governance.
60. Context Assumption
A contextual assumption must remain visible where material.
Context Assumption ≠ Context Evidence.
Repeated operational use must not silently convert an assumption into fact.
61. Context Uncertainty
Context may be uncertain.
Possible states include:
Context Established Context Conditionally Established Context Partially Established Context Evidence-Limited Context Conflicted Context Unknown Context Unresolved
62. Context Conflict
Context Conflict exists where credible evidence supports materially incompatible contextual representations.
The conflict must remain visible until resolved or legitimately bounded.
63. Context Uncertainty Propagation
Material Context uncertainty must propagate into downstream governance where the unresolved Context could alter the result.
Uncertain Context must not produce falsely certain downstream governance.
64. Context Stability
Some contextual conditions are relatively stable.
Others are highly dynamic.
RCXM may classify Context as:
Stable Slow-Changing Periodic Variable Highly Dynamic Event-Driven Unknown
This classification informs reassessment frequency.
65. Dynamic Context
Highly dynamic Resource Context may require frequent or event-driven reassessment.
Examples may include:
Electricity grid conditions Network capacity Water stress Compute demand environment Weather-sensitive Resource conditions
Static characterization is insufficient where the Context materially changes faster than the governance cycle.
66. Context Change
Material Context may change through:
Season Weather Infrastructure state Source change Resource State change Demand conditions Regeneration conditions Recovery capability Dependency change Location change Operational configuration
67. Context Change Detection
RCXM should support detection of material contextual change.
Canonical logic:
Existing Context → New Evidence / Event → Context Change Test → Material / Immaterial → Context Update where required
68. Context Reassessment Trigger
Reassessment should occur when a change could materially affect Resource interpretation.
Triggers may include:
Location change Time-horizon change Season change Source change Resource-State change Quality change Infrastructure change Environmental change Regeneration change Recovery change Dependency change New evidence Evidence expiry Boundary revision
69. Context Reassessment Logic
Canonical logic:
Existing Resource Context Profile → New Evidence / Material Change → Context Impact Test → Context Retained or Revised → Profile Version Update → Downstream Reassessment Trigger where material
70. Context Versioning
Material changes in Context should produce distinguishable Context Profile versions where necessary.
A revised version should preserve:
Previous Context Changed condition Reason Effective time Evidence Affected Resource interpretation Potential downstream impact
71. Context History
Where Resource governance depends upon historical Context, RCXM may preserve Context History.
Historical Context must not be presented as current Context.
72. Context Comparability
Resource observations should not be treated as directly comparable where materially different Context is ignored.
For comparison, relevant alignment may include:
Boundary Location Time Quality Condition Source Resource State Infrastructure conditions
Same quantity under different Context may represent different Resource realities.
73. Cross-Location Comparability
Resources measured in different locations may require contextual alignment before comparison.
A litre of water remains physically a litre.
Its Resource governance significance may differ materially between locations.
Physical measurement equivalence does not establish governance-context equivalence.
74. Cross-Time Comparability
Resource conditions measured at different times may not be governance-equivalent.
Seasonality, degradation, regeneration, infrastructure change, Source change, or demand conditions may alter significance.
75. Cross-System Comparability
Two organizations may report identical Resource quantities while operating within fundamentally different Resource Systems.
RCXM preserves the Context necessary to prevent false comparison.
76. Context Equivalence
Two Context Profiles may be treated as equivalent only where their material differences do not affect the governed question.
Context similarity ≠ Context equivalence.
77. Native Measurement Context
Native Resource measurement must remain associated with relevant Context.
Examples:
Litres + location + time
MW + grid location + period
GPU capacity + hardware configuration + location + period
Tonnes of material + grade + state + Source
Measurement without material Context may be insufficient for governance.
78. Quantity Context
Quantity is one Resource characteristic.
Its significance depends upon relevant contextual conditions.
Quantity ≠ Governance Significance.
RCXM therefore prevents quantity from becoming a context-free proxy for sustainability.
79. Context and Normalization
RCXM provides essential inputs for future Resource normalization.
Any governed normalization may require Context such as:
Scarcity conditions Location Time Dependency Criticality Substitutability Recoverability Regeneration Interdependency Consequence
RCXM does not prescribe a universal normalization formula or unit.
80. Normalization Boundary
Native Context must remain recoverable after normalization.
Normalized Resource Significance must not erase the Resource Context that produced it.
This allows normalized outputs to remain explainable and auditable.
81. Context and WDU™
Water-specific normalization concepts such as WDU™ — Water Dependency Unit may use Resource Context as an input in a specialized Water Governance methodology.
RCXM does not define WDU™.
It supplies the generic Resource Context layer upon which specialized normalization may rely.
82. Resource-Specific Context
Different Resource types require different contextual information.
Water may require hydrological Context.
Energy may require grid and generation Context.
Critical materials may require geological, processing, and Source Context.
Compute may require hardware, electricity, cooling, network, and location Context.
Biological Resources may require regeneration and ecological Context.
Common governance structure does not require identical Resource Context.
83. Specialized Context Input
Specialized Resource domains may determine Context-specific facts.
Canonical relationship:
Specialized Domain Determination → Governed Context Input → RCXM Resource Context Profile
RCXM does not replace specialized expertise.
84. Context and Resource Boundaries
RBDM establishes what belongs within the Resource boundary.
RCXM may represent conditions outside that boundary where they materially affect the Resource.
Resource Boundary ≠ Context Boundary.
The Context boundary may legitimately extend beyond the physical Governed Resource.
85. Context and Resource Type
RTCM determines Resource Type and Constraint characteristics.
RCXM establishes the circumstances under which those characteristics become materially relevant.
Resource Type ≠ Resource Context.
86. Context and Resource State
RSDM determines Resource State.
RCXM contextualizes that state.
Same Resource State under different Context may carry different governance significance.
87. Context and Origin & Source
ROSM determines Origin and Source.
RCXM preserves conditions surrounding those Sources that materially affect interpretation.
Source Identity ≠ Source Context.
88. Context and Availability
RCXM provides contextual inputs relevant to Availability.
RACS determines actual Availability & Capacity.
Availability-Relevant Context ≠ Availability Determination.
89. Context and Demand
RCXM may preserve demand-related contextual conditions.
RDGS determines Resource Demand.
Demand Context ≠ Governed Demand State.
90. Context and Dependency
RCXM identifies dependency-relevant Context.
RDCS determines Dependency & Criticality.
Dependency-Relevant Context ≠ Dependency Determination.
91. Context and Access
RCXM may preserve physical, spatial, technical, or operational conditions affecting accessibility.
RAGS governs access eligibility, conditions, restriction, reservation governance, and withdrawal.
Accessibility Context ≠ Access Authorization.
92. Context and Allocation
RCXM may provide conditions relevant to later prioritization.
RPAS determines prioritization and allocation.
Allocation-Relevant Context ≠ Allocation Decision.
93. Context and Consumption
RCXM may preserve conditions necessary to interpret Resource use.
RCUS governs Consumption & Utilization.
Consumption Context ≠ Consumption Governance.
94. Context and Scarcity
RCXM may preserve contextual conditions contributing to scarcity.
RSCS determines Scarcity & Constraint governance.
Scarcity Context ≠ Scarcity State.
95. Context and Recovery
RCXM may preserve recovery-relevant Context.
RRCS governs Recovery & Circularity.
Recovery Context ≠ Recovery Determination.
96. Context and Substitution
RCXM may preserve substitute-relevant Context.
RSFS governs Substitution & Flexibility.
Substitution Context ≠ Substitution Decision.
97. Context and Resilience
RCXM may preserve cross-Resource and infrastructure Context.
RIRS governs Interdependency & Resilience.
Resilience-Relevant Context ≠ Resilience State.
98. Context and Sustainability
RCXM provides contextual inputs.
RCSS determines Continuity & Sustainability.
Contextual Favorability ≠ Sustainability.
99. Context and Value
A Resource Context may influence Value.
RCXM does not determine Value.
Resource Governance Significance ≠ Economic Value.
VEGA™ and VFM® retain their respective Value domains.
100. Context and Authority
Context may affect a governance decision.
It does not create authority to make that decision.
Context ≠ Governance Authority.
GOA™ retains Governance Authority.
101. Context and Evidence Governance
RCXM specifies which contextual evidence Resource Characterization requires.
ADIT® governs evidence governance itself.
Context Evidence Requirement ≠ Evidence Governance.
102. Context and Validation
RCXM may require validated Context where governance significance warrants it.
VALIDOS™ retains general Validation Governance.
Context Determination ≠ Validation Governance.
103. Context and Prediction
Future Context may be relevant.
Where future Context depends upon prediction, PGA™ governs the Prediction.
RCXM consumes the resulting governed Prediction as a Context input.
104. Context and Simulation
Simulation may test Resource Context under alternative scenarios.
SIMULOS® governs simulation methodology.
RCXM may consume governed simulation outputs.
105. Context Sufficiency
A Resource Context Profile is sufficient when it contains enough materially relevant Context for legitimate downstream Resource Sustainability governance.
Possible states:
Context Sufficient Context Conditionally Sufficient Context Partially Sufficient Context Evidence-Limited Context Conflicted Context Insufficient Context Unresolved
106. Context Completeness
Context completeness does not mean capturing every possible external condition.
It means capturing every known condition whose omission could materially distort the governed Resource representation.
Governance-relevant completeness ≠ Universal completeness.
107. Context Overload
Collecting excessive Context can reduce governance clarity.
RCXM therefore requires relevance discipline.
Context should be included because it changes interpretation, not merely because data exists.
Available Data ≠ Required Context.
108. Context Reduction
Context may be reduced where evidence establishes that a factor is immaterial to the governed question.
Reduction must not remove a condition merely because it complicates the desired result.
109. Context Conflict Resolution
Where materially different Context representations conflict:
**Context Claim A
Context Claim B → Evidence Comparison → Scope / Time / Location Check → Conflict Resolution or Preserved Uncertainty**
Conflicts must not be resolved solely through preferred narrative.
110. Context Dependency Graph
Where complexity requires it, RCXM may represent Context through a dependency graph.
Example:
Ambient Temperature → Cooling Requirement → Water / Electricity Dependency → Compute Resource Context
The graph identifies contextual relationships.
It does not independently govern downstream Resource Interdependency.
111. Context Change Graph
Dynamic Resource Systems may represent:
Context State A → Trigger → Context State B → Resource Interpretation Change → Downstream Reassessment
This supports event-driven Resource governance.
112. Context Profile Version
Each materially revised Resource Context Profile should preserve:
Profile ID Version Effective time Applicable Resource Applicable boundary Context changes Evidence changes Known limitations
113. Resource Characterization Integration
RCXM completes the RCHS characterization chain:
**Governed Resource Boundary
Resource Type & Constraint Profile Resource State Profile Resource Origin & Source Profile Resource Context Profile → Governed Resource Characterization**
This integrated characterization becomes the foundation for RACS.
114. Characterization Consistency Check
Before RCHS output is treated as sufficiently characterized, RCXM should support consistency checks between:
Boundary Type Constraint State Origin Source Context
Material contradictions require resolution or explicit uncertainty.
115. Characterization Conflict
Examples include:
State inconsistent with Source evidence Context inconsistent with Boundary Resource Type inconsistent with specialized evidence Origin inconsistent with Source pathway Temporal Context inconsistent with evidence time
Conflict must not be hidden merely to complete characterization.
116. Characterization Sufficiency Gate
RCXM may operate as the final sufficiency gate for RCHS.
Canonical logic:
**RBDM Output
RTCM Output RSDM Output ROSM Output RCXM Output → Cross-Module Consistency Test → Characterization Sufficiency Determination → Governed Resource Characterization**
Possible result:
Sufficiently Characterized Conditionally Characterized Partially Characterized Characterization Evidence-Limited Characterization Conflicted Characterization Unresolved
117. Downstream Release Condition
A Governed Resource Characterization may proceed to RACS when the characterization is sufficiently complete for Availability & Capacity governance.
Conditional release may occur where unresolved Context is explicitly preserved and does not invalidate the downstream question.
Downstream progression does not erase upstream uncertainty.
118. Re-Characterization Trigger
Material Context change may require full or partial Resource re-characterization.
Triggers may propagate to:
RBDM RTCM RSDM ROSM
where Context change reveals that boundary, Resource Type, State, Origin, or Source is no longer correctly represented.
119. Failure Conditions
RCXM should not be treated as sufficiently completed where:
Material location is omitted Material time context is omitted Seasonal conditions are hidden by annual averages Quality Context is ignored where it changes Resource usability Infrastructure Context is ignored where it materially shapes Resource reality Regeneration Context is omitted for a materially regenerative Resource Recovery Context is omitted where recovery materially affects Resource lifecycle External Context is excluded solely because it lies outside the Resource boundary Predicted Context is represented as observed Context Historical Context is represented as current Context Declared Context is represented as verified Context Context assumptions are represented as evidence Material uncertainty is hidden Quantity is treated as sufficient Resource significance Different Contexts are compared as equivalent without justification Context is expanded indefinitely without governance relevance Context is compressed into an opaque score that destroys material distinctions
120. Governance Requirements
A conforming RCXM implementation must:
1. receive the Governed Resource established by preceding RCHS modules; 2. identify materially relevant Context dimensions; 3. preserve spatial Context where material; 4. preserve temporal Context where material; 5. preserve quality and condition Context where material; 6. preserve technical and infrastructure Context where material; 7. preserve operational Context where material; 8. preserve environmental Context where material; 9. preserve regeneration Context for relevant Resources; 10. preserve recovery Context for relevant Resources; 11. preserve Source and State Context where material;
12. preserve dependency-relevant Context without performing Dependency determination; 13. preserve scarcity-relevant Context without performing Scarcity determination; 14. preserve substitution-relevant Context without performing Substitution governance; 15. support interacting Context dimensions; 16. apply Context materiality; 17. prevent unlimited irrelevant Context expansion; 18. preserve Context evidence and provenance; 19. preserve evidence freshness; 20. distinguish observed, inferred, declared, predicted, simulated, and assumed Context; 21. preserve material Context uncertainty; 22. support Context versioning; 23. support Context history where required; 24. support Context reassessment; 25. identify downstream reassessment triggers; 26. preserve native Resource measurement with relevant Context; 27. prevent normalization from erasing Context; 28. support cross-module consistency testing; 29. support final RCHS Characterization Sufficiency determination; 30. produce a governed Resource Context Profile.
121. Governance Logic
Canonical RCXM logic:
Governed Resource → Boundary → Type & Constraint Profile → Resource State Profile → Origin & Source Profile → Context Identification → Context Materiality Test → Context Dimensions → Context Relationships → Context Evidence → Context Freshness → Context Uncertainty → Context Sufficiency → Resource Context Profile
RCHS integration:
**RBDM
RTCM RSDM ROSM RCXM → Cross-Module Consistency → Characterization Sufficiency → Governed Resource Characterization**
122. Governance Outputs
RCXM may produce:
Resource Context Profile Spatial Context Temporal Context Physical Context Quality Context Condition Context Technical Context
Infrastructure Context Operational Context Environmental Context Regeneration Context Recovery Context Dependency-Relevant Context Substitution-Relevant Context Context Interaction Record Context Evidence Reference Context Evidence Freshness State Context Assumption Record Context Uncertainty State Context Conflict Record Context Sufficiency State Context Version Context History Context Reassessment Trigger Downstream Reassessment Trigger RCHS Characterization Sufficiency State Governed Resource Characterization
123. Minimum Implementation Framework
A minimum operational implementation of RCXM must contain at least eight governed layers.
Layer 1 — Characterization Inputs
Receive:
Resource ID Resource Boundary Resource Type & Constraint Profile Resource State Profile Resource Origin & Source Profile
Layer 2 — Context Identification
Identify materially relevant:
Spatial Temporal Physical Quality Condition Technical Infrastructure Operational Environmental Regeneration Recovery Dependency-related Substitution-related Context
Layer 3 — Materiality Filter
For each Context element determine:
Material Conditionally Material Immaterial Unresolved
Only governance-relevant Context should enter the canonical Profile.
Layer 4 — Context Relationship
Represent where material:
Independent Context Dependent Context Amplifying Context Limiting Context Conditional Context Unknown Relationship
Layer 5 — Evidence Classification
Each material Context element should identify whether it is:
Observed Inferred Declared Predicted Simulated Assumed
Layer 6 — Temporal Validity
Record:
Effective time Evidence time Freshness requirement Expiry or reassessment condition
where relevant.
Layer 7 — Sufficiency & Consistency
Determine:
Context Sufficiency Context Conflict Context Uncertainty Cross-Module Consistency
Layer 8 — Governed Output
Produce:
Resource Context Profile Context version Known limitations Reassessment triggers RCHS Characterization Sufficiency State Governed Resource Characterization
Minimum machine-readable logic:
Resource → Characterization Inputs → Context[] → Materiality[] → Relationships[] → Evidence[] → Temporal Validity → Uncertainty[] → Sufficiency → Consistency
→ Resource Context Profile → Governed Resource Characterization
124. Minimum Context Object
At minimum, a material Context object should support:
Context ID Resource ID Context Type Context Value / State Location where relevant Time where relevant Materiality State Evidence Basis Evidence Time Uncertainty Version
125. Minimum Decision States
At minimum, implementations must distinguish:
Context Established
Context Conditionally Established
Context Evidence-Limited
Context Conflicted
Context Unresolved
Context Material
Context Conditionally Material
Context Immaterial
Context Profile Sufficient
Context Profile Conditionally Sufficient
Context Profile Insufficient
126. Minimum Evidence Path
Where a materially relevant Context cannot be established:
Unresolved Context → Governance-Relevant Missing Evidence → Minimum Evidence Requirement → Evidence Acquisition → Context Reassessment → Updated Resource Context Profile
The goal is sufficient Context for legitimate Resource governance, not indiscriminate data accumulation.
127. Minimum Context Change Framework
At minimum:
Current Context → New Evidence / Event → Materiality Test → Context Change → Profile Update → Characterization Impact Test → Downstream Reassessment where required
This enables Resource Characterization to remain dynamic rather than permanently fixed at first assessment.
128. Minimum RCHS Integration Framework
A minimum implementation completing RCHS must combine:
RBDM — Governed Resource Boundary
RTCM — Resource Type & Constraint Profile
RSDM — Resource State Profile
ROSM — Resource Origin & Source Profile
RCXM — Resource Context Profile
into:
Governed Resource Characterization
The integrated output must preserve unresolved material uncertainty from every contributing module.
129. Use Case 1 — Water for AI Data Center Cooling
Two AI data centers each report consumption of the same annual volume of water.
Quantity alone could make the Resource use appear equivalent.
RCXM requires preservation of Context.
Data Center A may use water:
in a low-stress region; from a resilient Source; during periods of sufficient local supply; with significant recovery capability.
Data Center B may use the same physical quantity:
in a severely water-stressed region; during seasonal scarcity; from a Source supporting competing essential dependencies; with limited recovery capability.
The physical unit remains the same.
The Resource governance significance does not.
RCXM does not itself calculate WDU™, determine allocation priority, or declare one facility sustainable.
It establishes the contextual layer required for those later governance determinations.
Same litres. Different Resource reality.
130. Use Case 2 — Compute Capacity Across Two Locations
Two facilities each report the same nominal AI compute capacity.
Facility A operates with:
stable electricity infrastructure; sufficient cooling capacity; multiple relevant Source pathways; low infrastructure constraint; stable network capacity.
Facility B operates with:
constrained electricity; limited cooling; single-source infrastructure dependency; high peak-load exposure; limited network redundancy.
Nominal compute quantity alone suggests equivalence.
RCXM preserves the contextual differences.
The Module does not determine actual available compute capacity.
RACS performs that determination.
It ensures that RACS does not begin from context-free nominal capacity.
Same nominal compute capacity does not mean the same Governed Resource condition.
131. Critical Distinctions
Resource Quantity ≠ Resource Context
Resource Context ≠ Resource State
Resource Context ≠ Resource Type
Resource Boundary ≠ Context Boundary
Source Identity ≠ Source Context
Location ≠ Accessibility
Present Context ≠ Future Context
Historical Context ≠ Current Context
Average Condition ≠ Peak Condition
Physical Measurement Equivalence ≠ Governance-Context Equivalence
Global Abundance ≠ Local Sufficiency
Regeneration Context ≠ Sustainability
Recovery Context ≠ Recovery Determination
Dependency Context ≠ Dependency Determination
Criticality-Relevant Context ≠ Criticality Determination
Demand Context ≠ Demand State
Access-Relevant Context ≠ Access Authorization
Allocation-Relevant Context ≠ Allocation Decision
Scarcity Context ≠ Scarcity State
Substitution Context ≠ Substitution Decision
Resilience-Relevant Context ≠ Resilience State
Sustainability-Relevant Context ≠ Sustainability State
Contextual Favorability ≠ Sustainability
Observed Context ≠ Predicted Context
Simulated Context ≠ Observed Context
Declared Context ≠ Verified Context
Context Assumption ≠ Context Evidence
Context Uncertainty ≠ Context Absence
Available Data ≠ Required Context
Relevant Context ≠ Unlimited Context
Quantity ≠ Governance Significance
Native Resource Measurement ≠ Normalized Resource Significance
132. Cross-Architecture Boundary
RCXM may consume governed inputs from operational, scientific, technical, environmental, infrastructure, evidence, prediction, simulation, and specialized Resource domains.
It does not acquire ownership of those domains.
ORA™ governs general Operational Reality.
PGA™ governs Prediction.
SIMULOS® governs Simulation.
ADIT® governs Audit and Evidence Governance.
VALIDOS™ governs general Validation Governance.
GOA™ governs Governance Authority.
Specialized Resource architectures govern Resource-specific operational mechanisms.
RCXM governs only their materially relevant Context within Resource Characterization.
133. 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.
Hydrology may determine water conditions.
Grid engineering may determine electricity-system conditions.
Meteorology may determine weather conditions.
Ecology may determine regenerative conditions.
Infrastructure systems may determine technical conditions.
RCXM consumes the relevant governed outputs as Resource Context.
It does not absorb the originating mechanisms.
134. Canonical Boundary
RCXM governs the materially relevant Context required to interpret a Resource correctly within Resource Sustainability governance. It does not independently determine availability, demand, criticality, access, allocation, scarcity, recovery, substitution, resilience, continuity, or sustainability.
The Module ends when the Resource Context Profile and integrated Governed Resource Characterization are sufficiently established for downstream RSGA™ governance.
135. Canonical Closing Statement
A Resource quantity without Context can describe how much exists while still failing to describe what that quantity means.
RCXM preserves the conditions that turn Resource measurement into governable Resource reality.