Skip to main content
Jira progress: loading…

UOM

Universal Organizational Model

Purpose​

The Universal Organizational Model (UOM) is the canonical organizational, physical, operational, and ESG context graph used throughout ZAYAZ.

Its purpose is to provide one consistent representation of a client's organizational scopes, facilities, buildings, assets, Resource Points, external mappings, and graph relationships regardless of industry, geography, ERP system, facility-management system, or reporting framework.

The UOM enables:

  • ESG reporting and CSRD / ESRS compliance;
  • facility-level analytics and benchmarking;
  • organizational and project attribution;
  • AI-assisted querying through ZARA;
  • carbon accounting and reporting-boundary analysis;
  • resource allocation and occupancy normalization;
  • physical climate-risk and geospatial analysis;
  • supply-chain intelligence;
  • Digital Product Passports and carbon-passport workflows;
  • future Digital Twin capabilities.

The governing principle is:

Precision Before Automation

All ESG data must resolve to a governed identity and context before it can be interpreted, calculated, reported, or analyzed.

Design Goals

The UOM must:

  • support SMEs through multinational enterprises;
  • support arbitrary graph depth without forcing a universal parent/child hierarchy;
  • support legal, organizational, project, physical, operational, and resource scopes;
  • support leased and owned facilities;
  • support acquisitions, divestitures, shared facilities, joint ventures, and matrix organizations;
  • support ERP, HR, FM, IWMS, BMS, IoT, utility, and other integrations;
  • support cross-module interoperability, auditability, traceability, and historical reconstruction;
  • provide deterministic context to ZARA, SSSR, ZSSR, Computation Hub, Reports Hub, RBAC, DaVE, DICE, and VTE.

Core Separation of Concerns

The UOM separates organizational identity, physical identity, Resource Point identity, graph topology, and observation sources.

Organizational structure​

Examples:

  • Legal Entity
  • Business Unit
  • Division
  • Department
  • Cost Center
  • Profit Center
  • Project

These scopes use governed E-C-O family identities rather than duplicate UOM Numbers.

Physical structure​

Examples:

  • Facility
  • Building
  • Floor
  • Room
  • Warehouse
  • Data Center
  • Retail Location
  • Port
  • Mine
  • Farm
  • Power Plant

These may use governed UOM Numbers.

Resource infrastructure​

Examples:

  • Electricity Resource Point
  • Water Resource Point
  • Waste Resource Point
  • Solar Generation Resource Point
  • Fuel Resource Point
  • Refrigerant Resource Point

These use governed UOM Numbers and represent measurement boundaries, not devices.

Data sources​

Examples:

  • Utility API
  • Utility Invoice
  • IoT Feed
  • Building Management System
  • ERP
  • CSV Import
  • Manual Entry

A data source is not a UOM object merely because it reports data about one.

Canonical Identity Model

UOM separates identity from classification.

E-C-O family identities​

Organizational and business scopes that already have a governed E-C-O family identity MUST retain that identity. UOM MUST NOT mint a duplicate UOM Number merely to place such an object in the graph.

ECO-...  legal / reporting / governed organization identity
EBU-...  Eco Business Unit identity
EBP-...  Eco Business Project identity

Canonical organizational classifications are:

uom_category_codeuom_typeGoverning identity family
ENTLEGAL_ENTITYECO
BUSBUSINESS_UNITEBU
DIVDIVISIONEBU
DEPDEPARTMENTEBU
CSTCOST_CENTEREBU
PFCPROFIT_CENTEREBU
PRJPROJECTEBP

These three-character values are classification codes on the E-C-O registration. They are not independent identities and are not UOM Number prefixes.

Example:

eco_number:         EBU-196-123-456-789-34
uom_type:           COST_CENTER
uom_category_code:  CST
name:               Manufacturing Cost Centre

EBU and EBP are attribution/context scopes by default. Their values MUST NOT automatically be added to an ECO inventory as if they were independently consolidatable inventories.

UOM Number identities​

Objects requiring an independent UOM-owned identity use uom_number.

uom_number:  POP-196-123-456-789-34
uom_type:    POWER_PLANT
uom_name:    Power Plant North

The three-character prefix and uom_type MUST resolve through config/system/uom-number-types.json and MUST agree.

The canonical rule is:

Do not mint a UOM identity where a governed E-C-O identity already appropriately expresses the object.

UOM-Owned Types

The governed machine-readable authority is:

config/system/uom-number-types.json

Current physical and operational examples include:

FACILITY
BUILDING
FLOOR
ROOM
WAREHOUSE
DATA_CENTER
RETAIL_LOCATION
PORT
MINE
FARM
POWER_PLANT
VEHICLE
ASSET
LEASE
SUPPLIER
RESOURCE_POINT

SUPPLIER uses a UOM Number only where no applicable governed E-C-O identity already provides the authoritative supplier identity.

Additional UOM types require governance and registry registration before use.

Resource Points

Overview​

A Resource Point is a stable logical ESG measurement boundary. It represents the thing or boundary being measured, not the device or source measuring it.

Examples:

Denver Building A Main Electricity Feed
Paris Office Water Consumption Point
Oslo Office District Heating Point
Solar Generation System #3
Waste Collection Point North Facility

Resource Points prevent duplicate counting when multiple systems report the same underlying consumption or generation.

Resource Point types​

Governed examples include:

RESOURCE_POINT
ELECTRICITY_RESOURCE_POINT
GAS_RESOURCE_POINT
WATER_RESOURCE_POINT
HEAT_RESOURCE_POINT
COOLING_RESOURCE_POINT
STEAM_RESOURCE_POINT
FUEL_RESOURCE_POINT
SOLAR_GENERATION_RESOURCE_POINT
EV_CHARGING_RESOURCE_POINT
WASTE_RESOURCE_POINT
REFRIGERANT_RESOURCE_POINT
AIR_EMISSIONS_RESOURCE_POINT

All observations describing the same governed measurement boundary resolve to the same Resource Point even when their sources differ.

Data Source Separation

A Resource Point remains stable while data sources may change over time.

Resource Point
└── Denver Main Electricity Feed
    ├── Utility API
    ├── Utility Invoice
    ├── BMS Integration
    ├── IoT Feed
    └── Manual Entry

This allows ZAYAZ to retain all source evidence while selecting or validating one accepted reporting value.

Observation Architecture

An observation should resolve at least:

Resource Point
Source
Observed timestamp / reporting period
Value
Unit
Confidence / trust context
Validation status

Multiple observations may exist for the same reporting period. Accepted-value selection can use source priority, trust scores, validation results, verifier approval, and governance rules.

Canonical Graph Model

The UOM is relationship-centric. Objects do not acquire universal parent/child, source/target, owner/owned, or container/contained roles merely because they participate in a graph edge.

A relationship assertion has two neutral endpoint positions and a governed predicate:

object_a | uom_relationship | object_b

Examples:

EBU-... | OPERATES     | FAC-...
EBU-... | OCCUPIES     | BLD-...
EBP-... | LOCATED_IN   | FAC-...
RSP-... | SERVES       | FAC-...
ROM-... | PART_OF      | FLR-...
POP-... | SUPPLIES     | DCE-...

object_a and object_b are neutral storage coordinates. The uom_relationship definition supplies semantics. Directed predicates define how A relates to B and may define an inverse. Symmetric predicates are invariant under endpoint swapping.

The canonical relationship vocabulary is:

config/system/uom-relationship-types.json

This supports shared facilities, joint ventures, matrix organizations, multi-purpose assets, physical assemblies, changing operational responsibility, and arbitrary graph traversal without brittle hierarchy assumptions.

Graph Participation Across Identity Namespaces

The UOM graph may contain governed identities from two authoritative namespaces:

eco_number
uom_number

A graph-node projection MAY provide an internal storage key for referential integrity and traversal performance, but that key is not a business identity and MUST NOT replace eco_number or uom_number in domain semantics.

Example:

ECO-...  OWNS      FAC-...
EBU-...  OPERATES  FAC-...
EBP-...  LOCATED_IN FAC-...
FAC-...  CONTAINS  BLD-...
BLD-...  CONTAINS  FLR-...
FLR-...  CONTAINS  ROM-...

Temporal Relationships

UOM relationships are temporal assertions. When reality changes, implementations SHOULD close the effective period and create a succeeding assertion rather than destroy history.

A -- LOCATED_IN --> B
effective_from: 2025-01-01
effective_to:   2026-06-30

A -- LOCATED_IN --> C
effective_from: 2026-07-01
effective_to:   null

This permits historical reconstruction for CSRD/ESRS reporting boundaries, audit, replay, acquisitions/divestitures, leases, operational responsibility, and facility intelligence.

Integration Philosophy

The UOM is system-agnostic. ERP, HR, FM, IWMS, BMS, utility, and IoT structures map into governed E-C-O or UOM identities.

Examples:

SAP Company / legal reporting scope   → ECO
SAP Cost Center / Profit Center       → EBU
SAP WBS / governed project            → EBP
SAP Plant / physical facility         → FAC-...
Workday Location                      → FAC-...
Planon Building                       → BLD-...
Archibus Room                         → ROM-...
Utility Meter boundary                → Resource Point UOM Number

External identifiers remain mappings; they do not become canonical UOM identities merely because an external system uses them as primary keys.

AI Integration

ZARA uses UOM as a primary organizational-context layer.

Example question:

How much electricity does the Denver office use per employee compared with our Paris office?

Resolution path:

Question
↓
Identity / alias resolution
↓
Facility resolution
↓
Resource Point resolution
↓
Accepted measurement resolution
↓
Occupancy resolution
↓
Calculation Engine
↓
Trust validation
↓
Response

The LLM should not perform the authoritative calculation itself; deterministic engines and governed data provide the result.

Governance

Changes to UOM Number types, E-C-O-backed UOM classifications, Resource Point types, and relationship types require governed registry changes and standard ZAYAZ review.

Machine-readable authorities:

config/system/uom-number-types.json
config/system/uom-relationship-types.json

All changes must be versioned, auditable, traceable, and reflected in this specification.

Persistence Model

The associated physical-model proposal is:

code/associated-files/shared-intelligence/universal-organizational-model/uom-core-tables.sql

Core responsibilities:

core_metadata.uom_registry
  issued UOM-owned identities and metadata

core_metadata.uom_graph_nodes
  internal projection of E-C-O and UOM identities participating in the graph

core_relations.uom_relationships
  temporal relationship assertions between neutral graph endpoints

The graph-node projection MUST preserve identity_namespace and identity_value. graph_node_id is an internal referential key, not a replacement business identifier.

Legacy concepts such as generic entity_id, generic entity_type, parent_entity_id, and child_entity_id are not canonical UOM domain semantics. Forward migrations should map them by actual meaning:

  • UOM-owned object identity → uom_number;
  • E-C-O-owned organizational/business identity → eco_number;
  • classification → uom_type and, where applicable, uom_category_code;
  • graph structure → neutral endpoints plus governed uom_relationship.

Applied historical migrations MUST NOT be rewritten solely to adopt this vocabulary.

APPENDIX A — Detailed UOM Data Domains​

The original UOM design defined a broad implementation surface. The following domains remain part of the UOM architecture; table names shown below are logical responsibilities and may be migrated to the governed UOM naming model as physical schemas evolve.

core_metadata.uom_registry
core_metadata.uom_graph_nodes
core_relations.uom_relationships
core_metadata.address_registry
core_metadata.facility_details
core_metadata.building_details
core_metadata.resource_point_registry
core_relations.resource_point_relationships
core_metadata.observation_source_registry
core_relations.resource_point_source_bindings
core_data.resource_observations
core_data.accepted_resource_measurements
core_relations.external_object_mappings
core_data.occupancy_snapshots
core_metadata.lease_details
core_zara.entity_aliases
core_zara.resource_point_aliases
core_zara.alias_resolution_history
core_signals.resource_point_signal_map

Address registry and PostGIS​

PostGIS is strategically valuable for facility proximity, climate-risk overlays, biodiversity exposure, flood/fire/heat-risk mapping, commute analysis, supply-chain geography, and location-aware ESG benchmarking.

Example:

SELECT *
FROM core_metadata.address_registry
WHERE ST_DWithin(
    geom::geography,
    ST_SetSRID(ST_MakePoint(-104.9903, 39.7392), 4326)::geography,
    10000
);

Distance between two governed locations:

SELECT ST_Distance(a.geom::geography, b.geom::geography) AS distance_m
FROM core_metadata.address_registry a
JOIN core_metadata.address_registry b
  ON a.address_id <> b.address_id
WHERE a.address_id = '...'
  AND b.address_id = '...';

Facility details​

core_metadata.facility_details is the facility-specific extension domain for UOM objects where:

core_metadata.uom_registry.uom_type = 'FACILITY'

It provides operational boundaries for Scope 1, Scope 2, leased assets, benchmarking, climate-risk overlays, ZARA comparisons, and ESRS reporting.

Building details​

core_metadata.building_details is the building-specific extension domain for UOM objects where:

core_metadata.uom_registry.uom_type = 'BUILDING'

It supports energy intensity, floor-area allocation, occupancy normalization, climate-risk exposure, leased-building reporting, and building-performance analytics.

Resource Point registry​

core_metadata.resource_point_registry stores Resource Point-specific metadata for UOM objects classified as Resource Points.

Examples:

uom_name: Denver Building A Main Electricity Feed
uom_type: ELECTRICITY_RESOURCE_POINT
measurement_boundary: whole_building
unit_default: kWh
measurement_direction: consumption
scope_classification: scope_2
uom_name: Oslo Warehouse Diesel Tank
uom_type: FUEL_RESOURCE_POINT
measurement_boundary: storage_tank
unit_default: litre
measurement_direction: consumption
scope_classification: scope_1
uom_name: Paris Office Waste Collection Point
uom_type: WASTE_RESOURCE_POINT
measurement_boundary: waste_collection_area
unit_default: kg
measurement_direction: discharge
scope_classification: non_ghg

This gives ZAYAZ an anti-duplication layer: invoices, utility APIs, meters, IoT feeds, BMS integrations, and manual uploads can point to the same canonical Resource Point.

Resource Point relationships​

Resource Points can be linked through governed UOM relationships to facilities, buildings, EBU scopes, cost centers, assets, vehicles, or other graph objects.

Examples:

Denver Building A Main Electricity Feed
→ SERVES
Denver Building A
Shared Campus Electricity Feed
→ ALLOCATED_TO
Building A, 55%
Building B, 45%
Paris Office Waste Collection Point
→ SERVES
Paris Office Facility

Allocation percentages and methods belong to the allocation semantics of the relationship or associated allocation records; they do not change endpoint identity.

Observation source registry​

This domain registers where observations came from. It does not represent the ESG measurement boundary.

Examples:

source_type: UTILITY_API
source_name: Fortum Electricity API
source_priority: 100
default_trust_score: 0.98
expected_frequency: monthly
source_type: UTILITY_INVOICE
source_name: Fortum Invoice OCR
source_priority: 90
default_trust_score: 0.90
source_type: IOT_FEED
source_name: Schneider EcoStruxure Feed
source_priority: 70
default_trust_score: 0.80
expected_frequency: real_time
source_type: MANUAL_ENTRY
source_name: Manual Facility Upload
source_priority: 20
default_trust_score: 0.50
requires_manual_review: true

Resource Point source bindings​

One canonical Resource Point may bind to multiple observation sources with different roles and priorities.

Denver Building A Main Electricity Feed
1. Fortum Utility API       primary_observation     priority 100
2. Fortum Invoice OCR       validation_source       priority 90
3. Schneider BMS Feed       secondary_observation   priority 70
4. Manual Upload            backup_source           priority 20

This lets ZAYAZ retain all evidence while selecting only one accepted value for ordinary reporting/calculation.

Resource observations​

core_data.resource_observations stores incoming observed values from utility APIs, invoices, OCR, IoT, BMS, manual entry, CSV, estimates, verifier uploads, and other raw/near-raw sources.

Example:

Resource Point: Denver Building A Main Electricity Feed
period: 2026-03-01 to 2026-03-31
value: 100023
unit: kWh
source: Utility API
quality_status: valid
confidence_score: 0.98

A second source may report a slightly different value for the same period. Both observations are retained for reconciliation and audit.

Accepted resource measurements​

core_data.accepted_resource_measurements stores the accepted reporting/calculation value for a Resource Point and period.

It is downstream of raw observations and upstream of Computation Hub, DaVE, DICE, VTE, Reports Hub, ZARA, and ESRS/CSRD outputs.

Example:

Resource Point: Denver Building A Main Electricity Feed
period: March 2026
accepted_value: 100023
unit: kWh
selected_source: Fortum Utility API
selection_method: SOURCE_PRIORITY
confidence_score: 0.98
validation_status: passed
approval_status: system_selected

ZARA and Computation Hub should normally consume accepted measurements unless the user explicitly asks to inspect source conflicts or raw observations.

External object mappings​

External systems map into the UOM rather than redefining it.

Examples:

SAP Plant            → FAC-... / FACILITY
Workday Location     → FAC-... / FACILITY
Planon Building      → BLD-... / BUILDING
Archibus Room        → ROM-... / ROOM
Utility Meter ID     → Resource Point UOM Number
HR Department        → EBU-... / DEPARTMENT
ERP Cost Center      → EBU-... / COST_CENTER
ERP Project / WBS    → EBP-... / PROJECT

Mappings should retain source system, external object type, external object identifier, matching method, confidence, status, and the canonical target identity.

Occupancy snapshots​

Occupancy data supports questions such as:

electricity per employee
water per FTE
waste per occupant
emissions per department
energy intensity per office

Example:

scope_identity: FAC-...
period: 2026-03-01 → 2026-03-31
fte_count: 84.5
headcount: 91
occupancy_basis: hr_system
source: Workday Location Export
confidence_score: 0.94

Lease details​

Leases are UOM-owned operational objects with uom_type = 'LEASE' and lease-specific attributes stored in the lease domain.

Examples include lessor, lease type, lease start/end, leased area, utility-allocation basis, landlord energy reporting, and whether utilities are included in rent.

This enables questions such as:

Which leased facilities do not provide landlord energy data?

Which leases expire within the next 24 months?

Which leased sites use floor-area allocation instead of direct metering?

ZARA aliases and pgvector​

Alias resolution allows natural-language names such as Denver Office, Colorado HQ, Paris Building A, power, or water use to resolve to canonical identities.

Where pgvector is used:

CREATE EXTENSION IF NOT EXISTS vector;

Embeddings may be stored on alias records:

ALTER TABLE core_zara.entity_aliases
ADD COLUMN IF NOT EXISTS embedding vector(1536);

HNSW is a suitable first index for semantic alias search:

CREATE INDEX IF NOT EXISTS idx_entity_aliases_embedding_hnsw
ON core_zara.entity_aliases
USING hnsw (embedding vector_cosine_ops);

Alias records MUST resolve to canonical eco_number or uom_number identities, not revive generic entity_id as a domain identity.

Alias resolution history​

core_zara.alias_resolution_history may store prompt, candidate alias, canonical resolved identity, confidence, selected resolution, and timestamp. This creates a governed learning trail for repeated natural-language resolution behavior.

Resource Point signal map​

core_signals.resource_point_signal_map connects physical/operational measurement boundaries to the ESG signal layer.

Example:

Denver Building A Main Electricity Feed
→ electricity_consumption_kwh
→ ESRS E1-5
→ Scope 2 location-based emissions
→ Scope 2 market-based emissions

This bridge allows Computation Hub to route accepted measurements into the correct engines and allows ZARA to understand which UOM objects contribute to which disclosures.

APPENDIX B — Physical-to-ESG Digital Twin and MICE​

The UOM plus Resource Intelligence layer provides the physical-to-ESG bridge used by reusable MICE and ZARA.

B.1 Resource Aggregation Engine — MEID_UOM_001​

Aggregates accepted Resource Point measurements across the UOM graph.

Questions:

How much electricity did this facility use?
What was total water consumption across all German sites?
What is total Scope 2 electricity consumption for this ECO reporting organization?

Core inputs include the UOM graph, Resource Point metadata, accepted resource measurements, and allocation relationships.

B.2 Intensity Calculation Engine — MEID_UOM_002​

Combines accepted measurements with occupancy, floor area, revenue, or other governed denominators.

Examples:

kWh / employee
kWh / FTE
kWh / m²
Water / employee
Waste / employee
Scope 2 / employee
Scope 2 / revenue

B.3 Occupancy Engine — MEID_UOM_003​

Resolves and normalizes FTE, headcount, average occupancy, peak occupancy, desk count, and occupancy rate for selected UOM/E-C-O scopes and reporting periods.

B.4 Resource Coverage Engine — MEID_UOM_004​

Determines which facilities have expected Resource Points for electricity, water, waste, gas, refrigerants, fuel, and other governed resource classes.

B.5 Measurement Completeness Engine — MEID_UOM_005​

Detects expected Resource Points with missing readings, missing periods, stale sources, or missing accepted values.

B.6 Resource Reconciliation Engine — MEID_UOM_006​

Detects possible duplicate or conflicting Resource Points using aliases, external mappings, source metadata, units, location, and measurement similarity.

B.7 Scope Attribution Engine — MEID_ESG_001​

Uses the Resource Point signal map and governed signal semantics to route resource activity into Scope 1, 2, or 3 calculations without hardcoding source-specific mappings.

B.8 ESG Boundary Engine — MEID_ESG_002​

Combines ECO/EBU/EBP scope identities, UOM relationships, lease attributes, ownership/control semantics, and reporting rules to decide whether a physical or operational scope is included, partially included, or excluded from a reporting boundary.

B.9 Facility Benchmark Engine — MEID_ESG_003​

Benchmarks facilities by governed characteristics such as facility type, country, climate zone, floor area, FTE, NACE context, and other comparable features.

B.10 Carbon Passport Engine — MEID_PCF_001​

Supports traversal such as:

Product
→ Facility
→ Resource Points
→ Energy / Material Activity
→ Accepted Measurements
→ Emission Factors
→ Allocation Model
→ Product footprint

B.11 AI Facility Assistant in ZARA​

Example:

How much electricity does the Denver office use per employee and how does it compare to Paris?

ZARA resolves identities and aliases, traverses UOM, invokes the appropriate MICE, and generates the explanation. Deterministic engines perform authoritative calculations.

B.12 UOM Graph Infrastructure​

The UOM Graph Infrastructure is the canonical organizational/physical graph layer supporting graph traversal, facility intelligence, ESG boundary analysis, resource aggregation, RBAC inheritance, and ZARA reasoning.

Canonical graph identities are eco_number or uom_number; graph relationships are governed predicates between neutral endpoints.

B.13 Graph-Aware ESG Intelligence Layer​

This orchestration/reasoning layer traverses the UOM graph, discovers relevant relationships, resolves context, and invokes MICE to answer business-level questions.

Responsibilities include:

Graph traversal
Identity discovery
Relationship resolution
Context enrichment
Cross-domain reasoning
MICE orchestration
Result synthesis
Explanation generation

Example query:

Which leased facilities in Germany contribute more than 10% of Scope 2 emissions?

Conceptual resolution:

Germany
↓
Relevant ECO/EBU scopes
↓
Facilities
↓
Lease relationships
↓
Resource Points
↓
Accepted measurements
↓
Signal mapping
↓
Scope Attribution Engine
↓
Resource Aggregation Engine
↓
Boundary Engine
↓
Final result

This creates the bridge between:

Identity / Context World
(ECO / EBU / EBP / UOM Numbers)
↓
Operational World
(Resource Points / Utilities / Occupancy)
↓
Signal World
(Signals / Metrics / ESRS)
↓
Computation World
(MICE / Computation Hub)
↓
AI World
(ZARA)

APPENDIX C — SSSR Registry Alignment​

Register the UOM/Resource Intelligence physical domains under the UOM component lineage while preserving table-level and field-level semantics in SSSR.

Primary responsibilities include:

UOM object identities:
core_metadata.uom_registry

UOM graph projection:
core_metadata.uom_graph_nodes

UOM graph edges:
core_relations.uom_relationships

Facility / building context:
core_metadata.facility_details
core_metadata.building_details
core_metadata.address_registry

Resource measurement boundary:
core_metadata.resource_point_registry
core_relations.resource_point_relationships

Observation source governance:
core_metadata.observation_source_registry
core_relations.resource_point_source_bindings

Measurement evidence:
core_data.resource_observations
core_data.accepted_resource_measurements

External onboarding and mapping:
core_relations.external_object_mappings

Occupancy normalization:
core_data.occupancy_snapshots

Lease / landlord logic:
core_metadata.lease_details

ZARA natural-language resolution:
core_zara.entity_aliases
core_zara.resource_point_aliases
core_zara.alias_resolution_history

Signal / framework routing:
core_signals.resource_point_signal_map

ZPDV governs recurring common fields such as eco_number, uom_number, uom_type, uom_category_code, relationship_id, object_a, object_b, uom_relationship, effective_from, effective_to, timestamps, provenance, evidence, units, and uncertainty fields.

SSSR should reference those ZPDV semantic identities rather than redefine them independently.

APPENDIX D — Component Classification and Development Plan​

MICE = executable micro-engines
Graph-Aware ESG Intelligence = orchestration / reasoning layer
Registries = governed data domains, not engines
#Final NameTypeNotes
1Resource Aggregation EngineMICEAggregates accepted measurements across graph scopes.
2Intensity Calculation EngineMICECalculates kWh/FTE, kWh/m², water/FTE, emissions/FTE, etc.
3Occupancy EngineMICEResolves FTE, headcount, utilization, and occupancy.
4Resource Coverage EngineMICEChecks Resource Point coverage by facility/scope.
5Measurement Completeness EngineMICEDetects missing periods, sources, or accepted values.
6Resource Reconciliation EngineMICEDetects duplicate/conflicting Resource Points and sources.
7Scope Attribution EngineMICEMaps Resource Points to Scope 1/2/3 via governed signals.
8ESG Boundary EngineMICEUses identity, leases, relationships, ownership/control, and rules.
9Facility Benchmark EngineMICEBenchmarks by facility type, climate zone, size, FTE, country, NACE, etc.
10Carbon Passport EngineMICEDepends on product/BOM/routing/allocation domains.
11Graph-Aware ESG Intelligence LayerOrchestration LayerTraverses UOM and orchestrates MICE.
12AI Facility AssistantZARA capabilityUser-facing assistant using Graph Layer + MICE.
13Facility Intelligence GraphData/graph capabilityUOM graph plus traversal services.
14Product RegistryRegistry / moduleProduct master data.
15Bill of MaterialsRegistry / moduleProduct/component relationships.
16Manufacturing RoutingRegistry / moduleProcess/facility routing.
17Allocation ModelsEngine + rule registryGoverned allocation definitions and execution.

Phase 1 — Foundational UOM MICE

  1. Resource Aggregation Engine
  2. Intensity Calculation Engine
  3. Occupancy Engine
  4. Resource Coverage Engine
  5. Measurement Completeness Engine
  6. Resource Reconciliation Engine

Phase 2 — ESG Logic MICE

  1. Scope Attribution Engine
  2. ESG Boundary Engine
  3. Facility Benchmark Engine

Phase 3 — Intelligence Layer

  1. Graph-Aware ESG Intelligence Layer
  2. AI Facility Assistant in ZARA

Phase 4 — Product / Carbon Passport Domain

  1. Product Registry
  2. Bill of Materials
  3. Manufacturing Routing
  4. Allocation Model Registry
  5. Carbon Passport Engine

Implementation Invariants

  1. Every graph participant resolves to an authoritative eco_number or uom_number.
  2. Do not create a duplicate UOM Number for an object already appropriately identified by the E-C-O family.
  3. Classification is not identity: ENT, BUS, DIV, DEP, CST, PFC, and PRJ classify E-C-O registrations; they do not identify objects.
  4. A UOM Number prefix and persisted uom_type must resolve to the same governed type.
  5. Relationship semantics live in the predicate, not in endpoint column names.
  6. Parent/child and source/target are prohibited as universal UOM endpoint roles.
  7. Historical relationships are preserved through effective periods rather than destructive replacement.
  8. External identifiers remain mappings unless explicitly promoted through a governed identity process.
  9. Runtime implementations consume governed registries; they do not invent UOM types or relationship codes.
  10. UOM provides context and topology; computation, routing, signal semantics, and trust remain responsibilities of their owning components.

Summary

The Universal Organizational Model is ZAYAZ's governed organizational, physical, operational, and Resource Point context graph. It combines authoritative E-C-O identities with UOM-owned identities, classifies them through governed vocabularies, connects them through temporal relationship semantics, and preserves the implementation detail required for facility intelligence, ESG calculation, ZARA reasoning, SSSR alignment, and future digital-twin capabilities.



GitHub RepoRequest for Change (RFC)