Jira progress: loading…

UOM

Universal Organizational Model

Purpose

The Universal Organizational Model (UOM) is the canonical organizational structure framework used throughout the ZAYAZ platform.

Its purpose is to provide a single, consistent representation of a client's organizational, operational, physical, and reporting structure regardless of industry, geography, ERP system, facility management system, or reporting framework.

The UOM acts as the foundational layer that enables:

• ESG reporting
• CSRD / ESRS compliance
• Facility-level analytics
• Organizational benchmarking
• AI-assisted querying through ZARA
• Carbon accounting
• Resource allocation
• Occupancy analysis
• Physical climate risk analysis
• Supply chain intelligence
• Digital Product Passports
• Future Digital Twin capabilities

The Universal Organizational Model follows the ZAYAZ design principle:

Precision Before Automation

All ESG data must be attached to a known organizational object before it can be interpreted, calculated, reported, or analyzed.

NOTE: To answer questions like:

• Which facilities consume the most electricity per employee?
• Which leased offices have the highest carbon intensity?
• Which manufacturing plants generate the most waste?
• Which sites are covered by ISO14001?
• Which facilities are located in flood-risk zones?
• Which facilities contribute most to ESRS E1 disclosures?

the system must understand the company’s structure.

---

Design Goals

The Universal Organizational Model must:

• Support organizations ranging from SMEs to multinational enterprises
• Support unlimited hierarchy depth
• Support multiple legal entities within a single client
• Support leased and owned facilities
• Support future acquisitions and divestitures
• Support ERP, HR, FM, IWMS, and IoT integrations
• Support cross-module interoperability
• Support AI-assisted navigation and querying
• Support auditability and traceability

---

Core Principle

The Universal Organizational Model separates:

Organizational Structure

Represents how the organization is structured.

Examples:

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

Physical Structure

Represents where operations occur.

Examples:

• Facility
• Building
• Floor
• Room
• Warehouse
• Retail Location
• Data Center

Resource Infrastructure

Represents where resources are consumed, produced, measured, or allocated.

Examples:

• Electricity Consumption Point
• Water Consumption Point
• Waste Collection Point
• Solar Generation Point
• Fuel Storage Point

Data Sources

Represents where information originates.

Examples:

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

These concepts must never be conflated.

---

Canonical Entity Hierarchy

The UOM is built around a generic entity structure.

Example:

Client
│
├── Legal Entity
│
├── Business Unit
│
├── Division
│
├── Department
│
├── Facility
│   │
│   ├── Building
│   │
│   ├── Floor
│   │
│   ├── Room
│   │
│   └── Resource Point
│
├── Project
│
├── Vehicle Fleet
│
└── Supplier

Actual implementations may use different levels depending on organizational complexity.

---

Entity Types

The following entity types are supported.

Organizational

LEGAL_ENTITY
BUSINESS_UNIT
DIVISION
DEPARTMENT
COST_CENTER
PROFIT_CENTER
PROJECT

Physical

FACILITY
BUILDING
FLOOR
ROOM
WAREHOUSE
DATA_CENTER
RETAIL_LOCATION
PORT
MINE
FARM
POWER_PLANT

Operational

VEHICLE
ASSET
LEASE
SUPPLIER

Additional entity types may be added through the governance process.

---

Resource Points

Overview

A Resource Point represents a logical ESG measurement boundary.

Resource Points are one of the most important concepts within the Universal Organizational Model.

A Resource Point represents the thing being measured.

It does not represent the device 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

---

Why Resource Points Exist

Organizations frequently receive the same information from multiple systems.

Example:

Utility API
Invoice OCR
Building Management System
Smart Meter
IoT Platform

All may describe the same electricity consumption.

Without Resource Points, duplicate counting can occur.

Resource Points establish a single canonical ESG measurement boundary.

All observations are linked to the same Resource Point.

---

Resource Point Types

Supported examples:

ELECTRICITY
GAS
WATER
HEAT
COOLING
STEAM
FUEL
SOLAR_GENERATION
EV_CHARGING
WASTE
REFRIGERANT
AIR_EMISSIONS

Additional types may be added as required.

---

Data Source Separation

The UOM explicitly separates measurement boundaries from observation sources.

Example:

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

The Resource Point remains stable.

Data sources may change over time.

This enables future-proof integrations without affecting ESG calculations.

---

Observation Architecture

Every observation must contain:

Resource Point
Source
Timestamp
Value
Unit
Confidence
Validation Status

Multiple observations may exist for the same reporting period.

The system determines the accepted value using:

• Source Priority
• Trust Scores
• Validation Results
• Verifier Approval
• Governance Rules

---

Organizational Graph

The Universal Organizational Model uses graph-based relationships.

Examples:

Facility → Building

Building → Resource Point

Department → Facility

Department → Cost Center

Resource Point → Building

Relationships are stored separately from entity definitions.

This enables:

• Flexible hierarchies
• Cross-functional reporting
• Shared facilities
• Joint ventures
• Matrix organizations

---

Integration Philosophy

The Universal Organizational Model is system-agnostic.

Examples:

ERP Systems

• SAP
• Oracle
• Microsoft Dynamics
• NetSuite

HR Systems

• Workday
• BambooHR
• HiBob

Facility Management Systems

• Planon
• Archibus
• Maximo

Building Systems

• Siemens Desigo
• Schneider EcoStruxure
• Honeywell
• Johnson Controls

Utility Systems

• Electricity APIs
• Water APIs
• District Heating APIs

All imported structures are mapped into the UOM.

The UOM always remains the canonical source of truth.

---

AI Integration

ZARA uses the Universal Organizational Model as its primary organizational context layer.

Example user question:

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

Resolution process:

Question
↓
Facility Resolution
↓
Resource Point Resolution
↓
Occupancy Resolution
↓
Calculation Engine
↓
Trust Validation
↓
Response

Without the Universal Organizational Model, these queries cannot be reliably answered.

---

Governance

The Universal Organizational Model is governed through the Shared Intelligence Stack.

Changes to:

• Entity Types
• Resource Point Types
• Relationship Types
• Allocation Methods

must follow the standard ZAYAZ governance process.

All changes must be:

• Versioned
• Auditable
• Traceable

---

Relationship to Other ZAYAZ Components

The Universal Organizational Model integrates with:

• SSSR
• USO
• ZAR
• ZSSR
• ZARA
• DaVE
• DICE
• VTE
• Computation Hub
• Reporting Hub
• Input Hub

The UOM serves as the canonical organizational context layer for the entire platform.

---

Summary

The Universal Organizational Model provides a single, consistent, future-proof representation of organizational structures, physical assets, facilities, and ESG measurement boundaries.

It enables:

• Accurate ESG reporting
• Cross-system interoperability
• AI-assisted analytics
• Facility intelligence
• Resource tracking
• Compliance traceability
• Scalable enterprise onboarding

The Universal Organizational Model is the authoritative organizational graph for the ZAYAZ platform.

---

APPENDIX A - Table Details

The following tables can be found under the ZAYAZ database:

core_metadata.entity_registry
core_relations.entity_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

---
As soon as ZARA comparison questions become active, add:
core_data.occupancy_snapshots
core_metadata.lease_details
core_zara.entity_aliases
core_zara.resource_point_aliases
core_signals.resource_point_signal_map

---

core_metadata.entity_registry

NOTE:

RESOURCE_POINT is a first-class entity_type in entity_registry. Specialized Resource Point fields should go into: core_metadata.resource_point_registry

So later: core_metadata.resource_point_registry.resource_point_id

should also reference: core_metadata.entity_registry.entity_id

---

core_relations.entity_relationships

-- Facility contains building
-- parent = facility, child = building
relationship_type = 'PART_OF'

-- Building contains resource point
-- parent = building, child = resource point
relationship_type = 'MEASURES'

-- Department occupies building
-- parent = department, child = building
relationship_type = 'OCCUPIES'

-- Legal entity operates facility
-- parent = legal entity, child = facility
relationship_type = 'OPERATES'

Important naming note:

For strict graph semantics, interpret:

parent_entity_id = broader / controlling / containing object
child_entity_id  = narrower / contained / dependent object

Example:

Legal Entity → Facility
Facility → Building
Building → Resource Point
Department → Cost Center

This keeps graph traversal predictable for ZARA, reporting rollups, RBAC inheritance, and future facility intelligence.

---

core_metadata.address_registry

Optional geospatial index if PostGIS is later enabled:

-- Future PostGIS enhancement:
-- Add a generated geometry/geography column and spatial index.
-- Useful for climate risk, flood exposure, biodiversity proximity,
-- commute analysis, and facility-level geospatial intelligence.

NOTE: We use PostGIS

Useful ZAYAZ examples:

-- Find facilities within 10 km of a point
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 addresses in meters
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 = '...';

Strategically, PostGIS is very valuable for ZAYAZ because it enables climate-risk overlays, facility proximity analysis, supply-chain geography, biodiversity exposure, flood/fire/heat-risk mapping, and location-aware ESG benchmarking.

---

core_metadata.facility_details

This is an extension table for entities where:

core_metadata.entity_registry.entity_type = 'FACILITY'

This table gives ZAYAZ the operational boundary needed for Scope 1, Scope 2, leased assets, facility benchmarking, climate-risk overlays, ZARA comparisons, and ESRS reporting.

---

core_metadata.building_details

core_metadata.entity_registry.entity_type = 'BUILDING'

This table gives ZAYAZ the building-level intelligence needed for energy intensity, leased-building reporting, floor-area allocation, occupancy normalization, climate-risk exposure, building performance analytics, and ZARA facility comparisons.

---

core_metadata.resource_point_registry

core_metadata.entity_registry.entity_type = 'RESOURCE_POINT'

Recommended examples

RESOURCE_POINT entity:
Denver Building A Main Electricity Feed

resource_type:
ELECTRICITY

measurement_boundary:
whole_building

unit_default:
kWh

measurement_direction:
consumption

scope_classification:
scope_2

RESOURCE_POINT entity:
Oslo Warehouse Diesel Tank

resource_type:
FUEL

measurement_boundary:
storage_tank

unit_default:
litre

measurement_direction:
consumption

scope_classification:
scope_1

RESOURCE_POINT entity:
Paris Office Waste Collection Point

resource_type:
WASTE

measurement_boundary:
waste_collection_area

unit_default:
kg

measurement_direction:
discharge

scope_classification:
non_ghg

This gives ZAYAZ an anti-duplication layer: all invoices, utility APIs, meters, IoT feeds, BMS integrations, and manual uploads can point to the same Resource Point, while ZARA, DaVE, DICE, Computation Hub, and Reports Hub use one canonical ESG measurement boundary.

---

core_relations.resource_point_relationships

This table links RESOURCE_POINT entities to facilities, buildings, departments, cost centers, assets, vehicles, or other entities, with allocation logic.

Example usage:

Denver Building A Main Electricity Feed
→ MEASURES
Denver Building A

Shared Campus Electricity Feed
→ ALLOCATED_TO
Building A, 55%
Building B, 45%

Paris Office Waste Collection Point
→ SERVES
Paris Office Facility

This table gives ZAYAZ the clean ESG allocation layer needed to prevent duplicate counting while still allowing one Resource Point to serve multiple buildings, departments, assets, cost centers, or reporting boundaries.

---

core_metadata.observation_source_registry

This table registers the source of observations. It does not represent the ESG measurement boundary. The measurement boundary is RESOURCE_POINT; the observation source is where the data came from.

Example records:

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
requires_manual_review: false

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

This table is the backbone for preventing duplicate counting because multiple observation sources can later bind to the same canonical RESOURCE_POINT, while DaVE/DICE can select, reconcile, or challenge the accepted value.

---

core_relations.resource_point_source_bindings

This table binds one canonical RESOURCE_POINT to one or more observation sources.

Example:

Resource Point:
Denver Building A Main Electricity Feed

Bound sources:
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 ensures ZAYAZ can store all available evidence while still selecting only one accepted value for reporting, preventing double counting across utility APIs, invoices, IoT feeds, BMS exports, and manual uploads.

---

core_data.resource_observations

This table stores all incoming observed values for Resource Points: utility API values, invoices, OCR results, IoT feeds, BMS exports, manual entries, CSV uploads, SEM estimates, verifier uploads, and other raw/near-raw observations.

It does not decide the final reporting value. That comes later in: core_data.accepted_resource_measurements

Examples:

Resource Point:
Denver Building A Main Electricity Feed

Observation 1:
source = Utility API
period = 2026-03-01 to 2026-03-31
value = 100023
unit = kWh
quality_status = valid
confidence_score = 0.98

Observation 2:
source = Invoice OCR
period = 2026-03-01 to 2026-03-31
value = 99950
unit = kWh
quality_status = valid
confidence_score = 0.91

Observation 3:
source = BMS Feed
period = 2026-03-01 to 2026-03-31
value = 100018
unit = kWh
quality_status = valid
confidence_score = 0.82

All three observations are stored. Only one final reporting value should later be selected into:

core_data.accepted_resource_measurements

This gives DaVE/DICE the raw evidence needed for trust scoring, duplicate detection, variance analysis, source reconciliation, and verifier-ready audit trails.

---

core_data.accepted_resource_measurements

This table stores the single accepted reporting/calculation value for a Resource Point and period.

It is downstream of: core_data.resource_observations

and upstream of:

Computation Hub
DaVE / DICE / VTE
Reports Hub
ZARA
ESRS / CSRD outputs

Examples:

Resource Point:
Denver Building A Main Electricity Feed

Accepted Measurement:
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

Resource Point:
Paris Office Electricity Feed

Accepted Measurement:
period = March 2026
accepted_value = 12400
unit = kWh
selected_source = Invoice OCR
selection_method = MANUAL_APPROVAL
confidence_score = 0.91
validation_status = passed
approval_status = approved

This table is what ZARA and the Computation Hub should use for normal ESG calculations, unless the user explicitly asks to inspect raw observations or source conflicts.

---

core_relations.external_object_mappings

This table maps objects from external systems into the ZAYAZ Universal Organizational Model.

Examples:

SAP Plant            → ZAYAZ Facility
Workday Location     → ZAYAZ Facility
Planon Building      → ZAYAZ Building
Archibus Room        → ZAYAZ Room
Utility Meter ID     → ZAYAZ Resource Point
BMS Data Point       → ZAYAZ Resource Point
HR Department        → ZAYAZ Department
ERP Cost Center      → ZAYAZ Cost Center

Example records:

source_system: SAP
external_object_type: PLANT
external_object_id: 1000-DEN
external_object_name: Denver Plant
mapping_type: entity
target_entity_type: FACILITY
zayaz_entity_id: <Denver Facility>
match_method: exact_id
match_status: confirmed

source_system: Workday
external_object_type: LOCATION
external_object_id: PAR-OFFICE-01
external_object_name: Paris Office
mapping_type: entity
target_entity_type: FACILITY
zayaz_entity_id: <Paris Office>
match_method: fuzzy_name
match_confidence: 0.91
match_status: matched

source_system: Schneider EcoStruxure
external_object_type: DATA_POINT
external_object_id: BLDG-A-MAIN-KWH
mapping_type: resource_point
target_entity_type: RESOURCE_POINT
zayaz_resource_point_id: <Denver Building A Main Electricity Feed>
match_method: hierarchy_match
match_confidence: 0.96
match_status: confirmed

This table is essential for onboarding companies with hundreds or thousands of facilities, buildings, cost centers, resource points, meters, and departments across ERP, HR, FM, IWMS, BMS, and utility systems.

---

core_data.occupancy_snapshots

This table supports questions like:

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

Example:

entity_id:
Denver Office Facility

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

This table is what allows ZARA to compute:

Denver electricity per employee =
accepted electricity measurement / occupancy snapshot FTE

---

core_metadata.lease_details

Leases are modelled as:

ENTITY_REGISTRY
    entity_type = LEASE

with the lease-specific attributes stored in:

core_metadata.lease_details

Example:

Lease:
Paris Office Lease

Lease Type:
operating

Lessor:
Paris Property Holdings

Lease Start:
2024-01-01

Lease End:
2034-12-31

Leased Area:
2,450 m²

Landlord Reports Energy:
true

Utility Allocation:
LANDLORD_STATEMENT

Rent Includes Electricity:
true

This table becomes extremely valuable later because ZARA can answer questions like:

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?

and Computation Hub can correctly determine Scope 1, Scope 2, IFRS16, leased asset treatment, and ESRS reporting boundaries.

---

core_zara.entity_aliases

With aliases we can ask questions like:

"How much electricity did the Denver office consume?"
"How much power does Denver use?"
"What is the energy consumption at Colorado HQ?"

where all can resolve to the same canonical entity.

Instead of just:

"How much electricity did DEN-FAC-001 consume?"

The auto-normalization trigger we use is extremely useful for ZARA.

Examples

Entity:

FACILITY
Denver Office

Aliases:

Denver Office
Denver HQ
Colorado HQ
DEN-01
Denver Site
US Denver Office

Entity:

BUILDING
Paris Building A

Aliases:

Paris HQ
Building A
Paris Main Building
FR-PAR-A

---

pgvector

First enable pgvector in the database:

CREATE EXTENSION IF NOT EXISTS vector;

Then add the embedding column:

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

vector(1536) is valid because pgvector supports the vector type up to 2,000 dimensions. 

For ZARA alias search, I recommend HNSW first:

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

Use cosine search like this:

SELECT
    alias_id,
    entity_id,
    alias_text,
    1 - (embedding <=> '[/* query embedding values */]'::vector) AS similarity
FROM core_zara.entity_aliases
WHERE client_id = '00000000-0000-0000-0000-000000000000'
  AND status = 'active'
  AND embedding IS NOT NULL
ORDER BY embedding <=> '[/* query embedding values */]'::vector
LIMIT 10;

HNSW generally gives better query performance than IVFFlat but uses more memory and builds more slowly; IVFFlat builds faster and uses less memory, but should be created after the table has data. 

Alternative IVFFlat index:

CREATE INDEX IF NOT EXISTS idx_entity_aliases_embedding_ivfflat
ON core_zara.entity_aliases
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

For IVFFlat, pgvector recommends choosing lists based on row count: roughly rows / 1000 up to 1M rows, and sqrt(rows) above 1M rows. 

For ZAYAZ v1, use this:

CREATE EXTENSION IF NOT EXISTS vector;
ALTER TABLE core_zara.entity_aliases
ADD COLUMN IF NOT EXISTS embedding vector(1536);
CREATE INDEX IF NOT EXISTS idx_entity_aliases_embedding_hnsw
ON core_zara.entity_aliases
USING hnsw (embedding vector_cosine_ops);

Later, tune query recall per request:

BEGIN;
SET LOCAL hnsw.ef_search = 100;
SELECT alias_id, entity_id, alias_text
FROM core_zara.entity_aliases
WHERE client_id = '...'
  AND status = 'active'
  AND embedding IS NOT NULL
ORDER BY embedding <=> '[/* query embedding */]'::vector
LIMIT 10;
COMMIT;

---

core_zara.resource_point_aliases

While entity_aliases helps ZARA resolve:

Denver Office
Colorado HQ
Paris Building A

resource_point_aliases helps resolve:

electricity
power
energy use
grid consumption
water usage
diesel tank
waste collection
solar production

to the correct canonical RESOURCE_POINT.

This table will be heavily used by ZARA when answering questions such as:

How much electricity does Denver use?

because the user rarely knows:

RP-DENVER-BLDG-A-MAIN-ELECTRICITY

Example

Canonical Resource Point:

Denver Building A Main Electricity Feed

Aliases:

Electricity
Power
Grid Electricity
Building Power
Main Power Feed
Energy Consumption
Electricity Usage
kWh Consumption
Denver Power

Canonical Resource Point:

Paris Office Water Consumption Point

Aliases:

Water
Water Use
Water Consumption
Office Water
Freshwater Usage
m³ Water

---

core_zara.alias_resolution_history

This table stores:

User Prompt
Resolved Alias
Resolved Resource Point
Confidence
Selected Resolution
Timestamp

This gives ZARA a learning loop so that if users repeatedly ask for:

"power"

and choose:

Denver Main Electricity Feed

the system automatically boosts that alias resolution score over time. This becomes extremely powerful once you have thousands of facilities and tens of thousands of resource points across large enterprise tenants.

This gives ZARA a learning trail for alias resolution and lets us later boost aliases based on confirmed user behavior.

---

core_signals.resource_point_signal_map

This table connects the Universal Organizational Model to the ESG signal layer.

It tells ZAYAZ: This Resource Point produces data for this Signal / USO path / framework disclosure.

Example:

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

Example records:

Resource Point:
Denver Building A Main Electricity Feed

Signal:
electricity_consumption_kwh

Framework:
ESRS

Framework Reference:
E1-5

Signal Category:
energy

GHG Scope:
scope_2

Calculation Method:
direct_value

Default Unit:
kWh

Resource Point:
Denver Building A Main Electricity Feed

Signal:
scope2_location_based_emissions

Framework:
GHG_PROTOCOL

Signal Category:
emissions

GHG Scope:
scope_2

Calculation Method:
emission_factor

Emission Factor Source:
IEA / national grid factor / supplier factor

Resource Point:
Oslo Warehouse Diesel Tank

Signal:
stationary_combustion_fuel_use

Framework:
ESRS

Framework Reference:
E1-6

Signal Category:
emissions

GHG Scope:
scope_1

Calculation Method:
emission_factor

This table is the bridge between the physical/operational world and the ESG reporting world. ZARA should use it to understand which Resource Points contribute to which disclosures, and Computation Hub should use it to route accepted measurements into the correct calculation engines.

---

APPENDIX B - A Physical-to-ESG Digital Twin Layer for ZAYAZ

The Universal Organizational Model is the beginning of a Physical-to-ESG Digital Twin Layer for ZAYAZ.

Here's some examples of what MICE can do because these tables exist.

---

B.1. Resource Aggregation Engine — MEID_UOM_001

Aggregates accepted Resource Point measurements across the UOM graph.

It answers questions like:

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 legal entity?

Core inputs:

entity_registry
entity_relationships
resource_point_relationships
accepted_resource_measurements
resource_point_registry

Core output:

Aggregated resource value by entity, period, resource type, and unit.

---

B.2. Intensity Calculation Engine - MEID_UOM_002

Previously:

Electricity Consumption = 1,200,000 kWh

Not very useful.

Now:

resource_observations
+
occupancy_snapshots
+
facility_details

allows automatic generation of:

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

No additional modeling required.

The MICE simply traverses:

RESOURCE_POINT
 → FACILITY
 → OCCUPANCY

---

B.3. Occupancy Engine - MEID_UOM_003

Resolves and normalizes occupancy data for entities such as facilities, buildings, floors, departments, and leased spaces.

It supports:

FTE
headcount
average occupancy
peak occupancy
desk count
occupancy rate

Used by intensity calculations such as:

kWh/FTE
water/FTE
waste/FTE
emissions/employee

Core inputs:

occupancy_snapshots
entity_registry
entity_relationships
facility_details
building_details

Core output:

Validated occupancy denominator for a selected entity and reporting period.

---

B.4. Resource Coverage Engine - MEID_UOM_004

Example:

Client:
500 facilities

Questions:

How many have:
- electricity
- water
- waste
- natural gas
- refrigerants

The engine simply traverses:

FACILITY
   → RESOURCE_POINTS

and calculates coverage.

---

B.5. Measurement Completeness Engine - MEID_UOM_005

Now possible because we have:

resource_point_registry
resource_point_signal_map
accepted_resource_measurements

The engine can ask:

Which facilities should have electricity data
but have no accepted measurements?

or

Which buildings have water points
but no readings for > 90 days?

This becomes a very powerful QA engine.

---

B.6. Resource Reconciliation Engine - MEID_UOM_006

Large enterprises often have:

10,000+
meters

Many are duplicates.

Using:

resource_point_aliases
external_object_mappings
observation_source_registry

the engine can detect:

same utility
same building
same unit
same measurements

and propose:

possible duplicate resource points

---

B.7. Scope Attribution Engine - MEID_ESG_001

Because:

resource_point_signal_map

already links:

Resource Point
→ Signal
→ Scope
→ Framework

the engine can automatically route:

Natural Gas
→ Scope 1
Grid Electricity
→ Scope 2
District Heating
→ Scope 2
Business Travel
→ Scope 3

without manual mapping.

---

B.8. ESG Boundary Engine - MEID_ESG_002

This becomes extremely valuable for CSRD.

Example:

Facility A

belongs to:

Subsidiary X

but:

Lease says:
landlord controls utilities

Now the engine can determine:

Included in reporting boundary?
Partially included?
Excluded?

using:

entity_relationships
lease_details
resource_point_signal_map

---

B.9. Facility Benchmark Engine - MEID_ESG_003

One of the first ZARA superpowers.

Question:

Which facilities are outliers?

Engine:

Find all facilities
with same type
same climate zone
same size

Then calculate:

kWh/m²
kWh/FTE
water/FTE
waste/FTE

and identify:

Top 10%
Bottom 10%
Anomalies

---

B.10. Carbon Passport Engine - MEID_PCF_001

Other ZAYAZ capabilities.

Trace:

Product
→ Facility
→ Resource Points
→ Electricity
→ Emissions
→ Emission Factors

to automatically generate:

facility-level embodied energy
facility-level operational emissions
product allocation basis

---

B.11. AI Facility Assistant in ZARA

Classification: ZARA Capability

The one described in the examples (Denver vs Paris).

User asks:

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

ZARA executes:

Denver Office
    ↓
Facility Entity
Find electricity resource points
    ↓
Aggregate accepted measurements
    ↓
Find occupancy snapshots
    ↓
Calculate kWh/FTE
    ↓
Repeat for Paris
    ↓
Compare

No LLM calculations required.

The LLM only generates the answer.

---

B.12. UOM Graph Infrastructure

Classification: Infrastructure

UOM Graph Infrastructure is the canonical organizational and physical graph layer of ZAYAZ. It models how legal entities, facilities, buildings, departments, leases, assets, and Resource Points relate to each other, enabling graph traversal, facility intelligence, ESG boundary analysis, resource aggregation, and ZARA reasoning.

It consists of:

entity_registry
entity_relationships
facility_details
building_details
resource_point_registry
resource_point_relationships
lease_details
address_registry

It enables ZAYAZ to understand:

Company → Legal Entity → Facility → Building → Resource Point → Signal → Disclosure

Its purpose is to provide the structural backbone for Graph-Aware ESG Intelligence, ZARA, MICE, RBAC, reporting, facility management, and future digital twin capabilities.

This is a major ZARA differentiator.

Because every object is now:

entity_registry

and every connection is:

entity_relationships

ZARA can traverse:

Company
  → Division
      → Facility
          → Building
              → Floor
                  → Room
                      → Resource Point
                          → Observation
                              → Signal
                                  → Disclosure

as a graph.

This means MICE can answer:

Which facilities in Europe have leased buildings where electricity is landlord-supplied and contribute more than 5% of Scope 2 emissions?

That query becomes a graph traversal rather than a hardcoded ESG report.

---

B.13. Graph-Aware ESG Intelligence Layer

Classification: Intelligence Layer

Purpose:

The Graph-Aware ESG Intelligence Layer is the semantic reasoning and orchestration layer that traverses the Universal Organizational Model (UOM) graph, discovers relationships between organizational, operational, and ESG objects, and dynamically invokes the appropriate MICE to answer complex sustainability, compliance, facility, and operational intelligence questions.

Unlike individual MICE, which perform specific calculations, the Graph-Aware ESG Intelligence Layer coordinates graph traversal, context discovery, dependency resolution, and multi-engine execution to produce business-level insights. It serves as the primary intelligence bridge between the UOM Graph Infrastructure, Computation Hub, and ZARA.

Responsibilities

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

Example Traversal

Question:

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

The layer performs:

Germany
 ↓
Facilities
 ↓
Lease Relationships
 ↓
Resource Points
 ↓
Accepted Measurements
 ↓
Signal Mapping
 ↓
Scope Attribution Engine
 ↓
Resource Aggregation Engine
 ↓
Boundary Engine
 ↓
Final Result

Core Inputs

entity_registry
entity_relationships
resource_point_registry
resource_point_relationships
lease_details
accepted_resource_measurements
resource_point_signal_map

All available MICE

Core Outputs

Multi-dimensional ESG insights
Cross-facility intelligence
Boundary-aware analysis
Root-cause analysis
Comparative analytics
AI-ready context packages
Explainable reasoning chains

Relationship to MICE

MICE
    perform calculations

Graph-Aware ESG Intelligence
    decides which calculations are required
    discovers relevant graph paths
    orchestrates engine execution
    combines and explains results

Relationship to ZARA

User
 ↓
ZARA
 ↓
Graph-Aware ESG Intelligence Layer
 ↓
MICE
 ↓
UOM Graph Infrastructure
 ↓
Results
 ↓
ZARA Response

---

From a ZAYAZ architecture perspective, what this Universal Organizational Model (UOM) + Resource Intelligence Layer provides the missing bridge between:

Entity World
(Company / Facility / Building)
↓
Operational World
(Resource Points / Utilities / Occupancy)
↓
Signal World
(Signals / Metrics / ESRS)
↓
Computation World
(MICE / Computation Hub)
↓
AI World
(ZARA)

That bridge is what will allow many MICE to be generic and reusable across every client, regardless of whether they have 1 office or 20,000 facilities.

---

APPENDIX C - SSSR Registry Info

C.1 Registery

Register this group of tables as:

Universal Organizational Model / Resource Intelligence Layer

with these primary responsibilities:

UOM graph nodes:
core_metadata.entity_registry

UOM graph edges:
core_relations.entity_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 / leased asset 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

A useful inspection query:

SELECT
    n.nspname AS schema_name,
    c.relname AS table_name,
    obj_description(c.oid) AS table_description
FROM pg_class c
JOIN pg_namespace n
    ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND n.nspname IN (
      'core_metadata',
      'core_relations',
      'core_data',
      'core_zara',
      'core_signals'
  )
ORDER BY
    n.nspname,
    c.relname;

---

APPENDIX D - Classification of the UOM Components & Develoment Plan

MICE = executable micro-engines
Graph-Aware ESG Intelligence = orchestration / reasoning layer
Registries = data domains, not engines

Classification

#	Final Name	Type	Notes
1	Resource Aggregation Engine	MICE	Aggregates accepted measurements across facilities, buildings, departments, countries, etc.
2	Intensity Calculation Engine	MICE	Calculates kWh/FTE, kWh/m², water/FTE, emissions/FTE, etc.
3	Occupancy Engine	MICE	Resolves FTE, headcount, utilization, average occupancy.
4	Resource Coverage Engine	MICE	Checks which facilities have electricity, water, waste, fuel, etc.
5	Measurement Completeness Engine	MICE	Detects missing months, missing sources, missing accepted values.
6	Resource Reconciliation Engine	MICE	Replaces “Meter Rationalization”; detects duplicate/ conflicting sources for same Resource Point.
7	Scope Attribution Engine	MICE	Maps Resource Points to Scope 1/2/3 using resource_point_signal_map.
8	ESG Boundary Engine	MICE	Uses leases, entity relationships, control boundaries, ownership, inclusion/exclusion.
9	Facility Benchmark Engine	MICE	Benchmarks facilities by type, climate zone, size, FTE, country, NACE, etc.
10	Carbon Passport Engine	MICE	Later depends on Product Registry, BOM, routing, allocation models.
11	Graph-Aware ESG Intelligence Layer	Orchestration Layer	Traverses UOM graph and calls MICE. Not itself a calculation engine.
12	AI Facility Assistant	ZARA capability	User-facing assistant using Graph Layer + MICE.
13	Facility Intelligence Graph	Data/graph capability	The UOM graph itself plus traversal services.
14	Product Registry	Registry / module	Not MICE. Product master data.
15	Bill of Materials	Registry / module	Not MICE. Product/component relationships.
16	Manufacturing Routing	Registry / module	Not MICE. Process/facility routing.
17	Allocation Models	Engine + rule registry	Can include MICE for allocation execution, but needs a model registry.

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 7. Scope Attribution Engine 8. ESG Boundary Engine 9. Facility Benchmark Engine

Phase 3 — Intelligence Layer 10. Graph-Aware ESG Intelligence Layer 11. AI Facility Assistant in ZARA

Phase 4 — Product / Carbon Passport Domain 12. Product Registry 13. Bill of Materials 14. Manufacturing Routing 15. Allocation Model Registry 16. Carbon Passport Engine

Infrastructure: UOM Graph Infrastructure

Intelligence Layer: Graph-Aware ESG Intelligence Layer

ZARA Capability: AI Facility Assistant

• MICE = executable computation engines
• Infrastructure = graph/storage layer
• Intelligence Layer = orchestration and reasoning
• ZARA Capability = user-facing AI experience

---