Jira progress: loading…

UOM-TYPE

UOM Engines

1. Identity

Attribute	Value
Type code	`UOM-TYPE`
Canonical name	UOM Engines
Parent type	—
Type status	deprecated
Tier scope	tier-1, tier-2
Invocation	service
Payload effect	derive
Lineage role	stamps-cmi

UOM-TYPE is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: UOM-TYPE. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary

UOM Engines are Micro Engines responsible for computing intelligence from the Universal Organizational Model.

They operate across ZAYAZ’s canonical organizational and physical graph:

Legal Entity
  → Facility
  → Building
  → Resource Point
  → Accepted Measurement

UOM engines transform Resource Points, relationships, facilities, buildings, leases, occupancy snapshots, and accepted measurements into reusable operational and ESG intelligence.

Design rationale

UOM engines make the organizational graph computational.

They allow ZAYAZ to answer questions such as:

How much electricity did the Denver office use?
Which facilities have no water data?
What is kWh per employee for each office?
Which buildings are resource outliers?

By separating UOM computations into dedicated Micro Engines, ZAYAZ avoids monolithic ESG logic and creates reusable, auditable, graph-aware computation services.

3. Membership criteria

3.1 Inclusion tests

A micro engine is a member of UOM-TYPE when its specification satisfies the following:

UOM engines perform computations over organizational, physical, and resource structures.

Supported responsibility areas include:

Resource aggregation
Intensity calculations
Occupancy resolution
Resource coverage analysis
Measurement completeness checks
Resource reconciliation
Facility-level intelligence
Building-level intelligence
Entity-level resource rollups

3.2 Exclusions

A micro engine is not a member of UOM-TYPE when any of the following is its responsibility; each belongs to the type named:

❌ OCR
❌ Raw invoice extraction
❌ AI narrative generation
❌ Framework interpretation
❌ Final assurance approval
❌ Unit normalization where MEID_CORE_NORM is available
❌ Product carbon allocation unless part of PCF engines

3.3 Boundary cases

UOM-TYPE versus AGGR and CALC: UOM-TYPE is bound to the organizational graph and to Resource Points as measurement boundaries; an aggregation or intensity over an explicit input hierarchy without that binding is AGGR or CALC. MEID_STANDARD section 15 already maps MEID_UOM_001 to domain RESOURCE with capability AGGR, so whether UOM-TYPE remains a type is an open decision.
UOM-TYPE versus TRFM: UOM engines never convert units; they call the central normalizer.
Deprecated 2026-10-11: UOM is a domain (RESOURCE), not an operation. Members migrate to AGGR (resource aggregation), NORM (intensity), VALI (coverage, completeness) and RSLU (occupancy resolution, reconciliation); the Resource Point and tenant-scoping constraints move to the UOM document as domain rules.

4. Design rules

RULE-UOM-TYPE-001 — Graph-Aware

UOM engines SHALL understand entity relationships and Resource Point relationships.

RULE-UOM-TYPE-002 — Accepted Values Only

UOM engines consume accepted measurements, not raw observations, unless explicitly designed for reconciliation or completeness checks.

RULE-UOM-TYPE-003 — Tenant-Scoped

Every execution SHALL be strictly scoped by client_id.

RULE-UOM-TYPE-004 — No Duplicate Counting

UOM engines SHALL use Resource Points as canonical measurement boundaries.

RULE-UOM-TYPE-005 — Reusable by ZARA

Outputs SHALL be structured, explainable, and suitable for natural-language responses.

5. Contract

5.1 Inputs

UOM engines consume:

UOM graph nodes
UOM graph edges
Resource Point definitions
Resource Point relationships
Accepted Resource Measurements
Occupancy snapshots
Lease and facility metadata
Observation source bindings where needed

Typical tables:

core_metadata.entity_registry
core_relations.entity_relationships
core_metadata.resource_point_registry
core_relations.resource_point_relationships
core_data.accepted_resource_measurements
core_data.occupancy_snapshots
core_metadata.lease_details

5.2 Outputs

UOM engines produce:

Aggregated resource values
Facility-level metrics
Building-level metrics
Entity-level rollups
Resource coverage results
Measurement completeness results
Reconciliation findings
ZARA-ready evidence payloads

All outputs SHALL preserve provenance.

6. Position in the computation chain

6.1 Placement

UOM Graph Infrastructure
  → Accepted Measurements
  → UOM Engines
  → ESG Engines
  → Graph-Aware ESG Intelligence
  → ZARA / Reports Hub

UOM engines sit above the physical/resource graph and below higher-order ESG interpretation.

6.2 Relationship to NORM

UOM engines SHALL NOT implement independent unit conversion logic.

When unit conversion is required, they call:

MEID_CORE_NORM

This ensures that all unit normalization is centralized, versioned, and auditable.

6.3 Relationship to Graph-Aware ESG Intelligence

UOM engines perform deterministic computations.

Graph-Aware ESG Intelligence orchestrates:

graph traversal
entity discovery
context resolution
MICE selection
result synthesis

The intelligence layer calls UOM engines rather than duplicating their logic.

7. Identity rules for members

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

mice.category SHALL be UOM-TYPE.
The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of AGGR, CALC, RESOLVE, VALIDATE.
The DOMAIN segment SHALL be RESOURCE.
Typical FUNCTION segments: AGGREGATION, INTENSITY, RESOLVER, VALIDATOR.
CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE.
Lineage: members append their CMI stamp to the USO lineage tail.
Tier scope: tier-1, tier-2; invocation: service; payload effect: derive.

9. Governance and audit

9.1 Audit & Provenance

Every UOM execution SHALL record:

engine ID
engine version
client ID
entity IDs used
Resource Points used
measurement IDs used
allocation logic
warnings
confidence score
trust score

UOM engines are integrated with ALTD / DAL logging.

10. Members

Initial UOM engines:

MEID_UOM_001 Resource Aggregation Engine
MEID_UOM_002 Intensity Calculation Engine
MEID_UOM_003 Occupancy Engine
MEID_UOM_004 Resource Coverage Engine
MEID_UOM_005 Measurement Completeness Engine
MEID_UOM_006 Resource Reconciliation Engine

Loading micro engines…

CALC — Calculation Engines
NORM — Normalization Engines
META — Metadata Enrichment Engines
EXTR — Extraction Engines
TRFM — Transformation Engines
AME — Assurance / Meta engines

SEM — Stochastic Extrapolation Module
ESG — ESG attribution and boundary engines (no registered document id)
ZARA — Explainability and orchestration

GitHub Repo Request for Change (RFC)

1. Identity​

2. Purpose and boundary​

Design rationale​

3. Membership criteria​

3.1 Inclusion tests​

3.2 Exclusions​

3.3 Boundary cases​

4. Design rules​

5. Contract​

5.1 Inputs​

5.2 Outputs​

6. Position in the computation chain​

6.1 Placement​

6.2 Relationship to NORM​

6.3 Relationship to Graph-Aware ESG Intelligence​

7. Identity rules for members​

9. Governance and audit​

9.1 Audit & Provenance​

10. Members​

11. Related types​

Other related documents​