Jira progress: loading…

MEID_STANDARD

Canonical Micro-Engine Identity (MEID) Standard

1. Purpose

The Canonical Micro-Engine Identity (MEID) Standard defines the stable, ZAR-governed identity model for executable micro-engines across ZAYAZ.

A MEID identifies the logical micro-engine independent of software version, implementation language, deployment environment, runtime instance, or tenant configuration.

The standard ensures that every micro-engine can be named consistently, discovered through ZAR, mapped to one or more versioned CMIs, referenced by architecture documents and Jira epics, and preserved in telemetry, replay, DAL anchors, and Pergamum Pulse.

---

2. Scope

MEIDs are mandatory for executable micro-engines and runtime processors in MICE, TrustGate, AAE, DAL, DSAIL, AII, ZSSR, EIF, EGFS, and shared ZAR/SIS services.

A MEID is not used for individual runtime executions, records, schemas, dashboards, UI components, datasets, policies, or standalone documents.

---

3. Identity Model

Every micro-engine has two primary identifiers:

Identifier	Purpose	Stable	Versioned	Example
MEID	Stable logical identity of the engine	Yes	No	MEID_GHG_CALC_INTENSITY
CMI	Versioned implementation artifact identity	No	Yes	comp.GHG-INT.ENGINE.CALCULATOR.1_0_0

The MEID answers: Which logical engine is this?

The CMI answers: Which versioned implementation executed?

Relationship:

MEID_GHG_CALC_INTENSITY
  ├── CMI: comp.GHG-INT.ENGINE.CALCULATOR.1_0_0
  ├── CMI: comp.GHG-INT.ENGINE.CALCULATOR.1_1_0
  └── CMI: comp.GHG-INT.ENGINE.CALCULATOR.2_0_0

---

4. Canonical MEID Structure

The canonical MEID structure is:

MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>

Part	Meaning	Registry Table
DOMAIN	Semantic or functional area of the engine	zar.meid_domain
CAPABILITY	Class of action performed by the engine	zar.meid_capability
FUNCTION	Concrete implementation role of the engine	zar.meid_function

Example:

MEID_TRUST_SCORE_CALCULATOR

Part	Value
Prefix	MEID
Domain	TRUST
Capability	SCORE
Function	CALCULATOR

---

5. DOMAIN, CAPABILITY, and FUNCTION

5.1. DOMAIN

DOMAIN identifies the stable semantic area in which the engine operates.

Examples include GHG, ENERGY, WATER, WASTE, TRUST, SIGNAL, FEDERATION, LINEAGE, AI, and RESOURCE.

DOMAIN is not necessarily the documentation module or CMI module prefix. For example, a TrustGate engine belongs to the Verification & Assurance module in CMI terms, but its MEID domain may be TRUST, SIGNAL, REPLAY, FEDERATION, or POLICY.

5.2. CAPABILITY

CAPABILITY identifies what the engine does.

Examples include CALC, VALIDATE, SCORE, NORMALIZE, REPLAY, ATTEST, ANCHOR, ROUTE, VERIFY, EXPORT, and SYNCHRONIZE.

5.3. FUNCTION

FUNCTION identifies the concrete executable role.

Examples include CALCULATOR, VALIDATOR, PARSER, ROUTER, GENERATOR, SYNCHRONIZER, REPLAYER, EVALUATOR, and NORMALIZER.

---

6. Valid and Invalid Examples

6.1. Valid Examples

MEID	Meaning
MEID_GHG_CALC_INTENSITY	GHG intensity calculation engine
MEID_GHG_AGGR_AGGREGATION	GHG aggregation engine
MEID_ENERGY_CALC_INTENSITY	Energy intensity calculation engine
MEID_WASTE_CLASSIFY_HAZARD	Waste hazard classification engine
MEID_SIGNAL_NORMALIZE_UNIT	Unit normalization engine for signals
MEID_TRUST_SCORE_CALCULATOR	Trust score calculation engine
MEID_TRUST_VALIDATE_VALIDATOR	Trust validation engine
MEID_FEDERATION_SYNCHRONIZE_SYNCHRONIZER	Federation synchronization engine

6.2. Invalid Examples

Invalid MEID	Reason
MEID_TG001	Non-semantic numeric identifier
MEID_CORE_NORM	Ambiguous domain and abbreviated function
MEID_CALC_GHG_INT	Does not follow <DOMAIN>_<CAPABILITY>_<FUNCTION> order
MEID_GHG_INTENSITY	Missing capability
MEID_TRUST_SCORE	Missing function
MEID_signal_normalize_unit	Lowercase not allowed
MEID_TRUST-SCORE-CALCULATOR	Hyphens not allowed
MEID_MICE_GHG_CALC_INTENSITY	Module encoded into MEID

---

7. Registry Architecture

The MEID registry is implemented under the zar schema.

zar.meid_status
zar.meid_domain
zar.meid_capability
zar.meid_function
zar.meid_registry
zar.meid_cmi_binding

Registry flow:

Domain Vocabulary
        │
Capability Vocabulary
        │
Function Vocabulary
        │
        ▼
Canonical MEID Registry
        │
        ▼
CMI Binding Registry

---

8. Registry Tables

8.1. zar.meid_status

Status	Meaning
proposed	Submitted but not approved
active	Approved and available
deprecated	Still recognized but not recommended
reserved	Reserved for future or protected use
blocked	Explicitly disallowed
retired	No longer valid for active runtime use
experimental	Sandbox or prototype use only

8.2. zar.meid_domain

Stores approved domain vocabulary.

Field	Description
domain_code	Uppercase domain code
canonical_name	Human-readable name
description	Meaning and scope
status	Lifecycle status
created_at	Creation timestamp
updated_at	Last update timestamp

8.3. zar.meid_capability

Stores approved capability vocabulary.

8.4. zar.meid_function

Stores approved function vocabulary.

8.5. zar.meid_registry

Stores canonical MEIDs.

Recommended fields include meid, domain_code, capability_code, function_code, canonical_name, description, owner_module, engine_class, tier, status, created_by, approved_by, approved_at, created_at, and updated_at.

The registry MUST enforce:

meid = 'MEID_' || domain_code || '_' || capability_code || '_' || function_code

8.6. zar.meid_cmi_binding

Stores bindings between a stable MEID and one or more versioned CMIs.

Only one CMI SHOULD be marked is_current = true per MEID unless an approved parallel runtime strategy exists.

---

9. Naming Rules

MEIDs MUST:

• start with MEID_;
• use uppercase ASCII letters, numbers, and underscores only;
• use exactly three vocabulary components after MEID_;
• use vocabulary values registered in ZAR;
• be globally unique.

MEIDs SHOULD NOT include:

• version numbers;
• programming language;
• cloud vendor;
• tenant;
• region;
• release date;
• temporary project names;
• implementation detail.

---

10. Lifecycle

proposed
   ↓
reserved
   ↓
active
   ↓
deprecated
   ↓
retired

Alternative branch:

proposed
   ↓
blocked

---

11. MEID Generation Workflow

The MEID Canonical Name Engine SHALL implement this workflow:

1. Select or propose a DOMAIN.
2. Select or propose a CAPABILITY.
3. Select or propose a FUNCTION.
4. Validate all three parts against ZAR vocabulary tables.
5. Generate the canonical MEID.
6. Check for duplicates in zar.meid_registry.
7. Return the existing MEID if one already exists.
8. Register the MEID as proposed, reserved, or active.
9. Bind one or more CMIs through zar.meid_cmi_binding.
10. Record creator, approver, timestamps, and lifecycle status.

---

12. API Requirements

12.1. Preview

POST /meid/preview

Request:

{
  "domain": "TRUST",
  "capability": "SCORE",
  "function": "CALCULATOR"
}

Response:

{
  "meid": "MEID_TRUST_SCORE_CALCULATOR",
  "exists": false,
  "valid": true
}

12.2. Register

POST /meid/register

Request:

{
  "domain": "TRUST",
  "capability": "SCORE",
  "function": "CALCULATOR",
  "canonical_name": "Trust Score Calculator",
  "description": "Calculates final TrustGate trust score from weighted evidence components.",
  "owner_module": "verification-assurance",
  "engine_class": "Assurance-Engine",
  "tier": "tier-0"
}

12.3. Bind CMI

POST /meid/bind-cmi

Request:

{
  "meid": "MEID_TRUST_SCORE_CALCULATOR",
  "cmi": "vera.TG-SCORE.ENGINE.CALCULATOR.1_0_0",
  "zar_code": "TGS05",
  "is_current": true
}

---

13. SQL Reference

The canonical generation function MAY be implemented as:

create or replace function zar.generate_meid(
    p_domain text,
    p_capability text,
    p_function text
)
returns text
language sql
immutable
as $$
    select 'MEID_' || upper(p_domain) || '_' || upper(p_capability) || '_' || upper(p_function);
$$;

---

14. Governance

MEID governance is owned by ZAR.

Governance requirements:

• New domain, capability, or function values require approval.
• Existing vocabulary values should be deprecated rather than deleted.
• Active MEIDs must not be renamed.
• If a MEID name is wrong, create a new MEID and deprecate the old one.
• CMI bindings must preserve historical auditability.
• Production MEIDs must be linked to at least one approved CMI before deployment.

---

15. Migration Guidance

Some existing MEIDs do not yet follow the canonical grammar.

Existing MEID	Recommended Canonical MEID
MEID_CALC_GHG_INT	MEID_GHG_CALC_INTENSITY
MEID_CALC_GHG_AGGR	MEID_GHG_AGGR_AGGREGATION
MEID_CALC_ENERGY_INT	MEID_ENERGY_CALC_INTENSITY
MEID_CORE_NORM	MEID_SIGNAL_NORMALIZE_UNIT or MEID_SIGNAL_NORMALIZE_NORMALIZER
MEID_UOM_001	MEID_RESOURCE_AGGR_AGGREGATION or MEID_SIGNAL_NORMALIZE_UNIT
MEID_ASRE_AAE	Candidate for AAE-specific governance review

Migration should use aliases and deprecation rather than destructive renaming.

---

16. Reference Vocabulary

16.1. Domains

Code	Canonical Name
GHG	Greenhouse Gas Emissions
ENERGY	Energy
WATER	Water
WASTE	Waste
FINANCE	Finance
TRUST	Trust and Assurance
SIGNAL	Signal Processing
SUPPLIER	Supplier Intelligence
PRODUCT	Product Sustainability
RISK	Risk Intelligence
GOVERNANCE	Governance
AI	Artificial Intelligence
REPLAY	Replay Verification
FEDERATION	Federation Services
LINEAGE	Lineage and Provenance
IDENTITY	Identity and Credentials
SECURITY	Security
POLICY	Policy Management
AUDIT	Audit and Compliance
RESOURCE	Resource Intelligence
POLLUTION	Pollution

16.2. Capabilities

Code	Canonical Name
CALC	Calculation
TRANS	Transformation
VALIDATE	Validation
SCORE	Scoring
NORMALIZE	Normalization
AGGR	Aggregation
CLASSIFY	Classification
ALLOCATE	Allocation
REPLAY	Replay
ATTEST	Attestation
ANCHOR	Ledger Anchoring
ROUTE	Routing
ENRICH	Enrichment
INGEST	Ingestion
DETECT	Detection
MONITOR	Monitoring
ORCHESTRATE	Orchestration
VERIFY	Verification
EXPLAIN	Explainability
PREDICT	Prediction
OPTIMIZE	Optimization
EXPORT	Export
IMPORT	Import
SYNCHRONIZE	Synchronization
RESOLVE	Resolution
GENERATE	Generation
PROJECT	Projection

PROJECT is conditional evaluation under a declared scenario or pathway (Scenario Engines, SCEN). It is distinct from PREDICT, which infers an outcome from data (Estimation & Forecasting Engines, ESTM).

16.3. Functions

Code	Canonical Name
INTENSITY	Intensity
AGGREGATION	Aggregation
SCOPE1	Scope 1
SCOPE2	Scope 2
SCOPE3	Scope 3
SHARE	Share or Composition
BUDGET	Budget
TARGET_GAP	Distance to Target
HAZARD	Hazard Classification
TREATMENT	Treatment Classification
UNIT	Unit Handling
FINAL	Final Score
DECISION	Decision
SIGNAL	Signal
PARSER	Parser
VALIDATOR	Validator
CALCULATOR	Calculator
ORCHESTRATOR	Orchestrator
COORDINATOR	Coordinator
ROUTER	Router
CLASSIFIER	Classifier
DETECTOR	Detector
GENERATOR	Generator
EXPORTER	Exporter
IMPORTER	Importer
SYNCHRONIZER	Synchronizer
RESOLVER	Resolver
MONITOR	Monitor
ANCHOR	Anchor
ATTESTATION	Attestation
REPLAYER	Replayer
EVALUATOR	Evaluator
ENRICHER	Enricher
TRANSFORMER	Transformer
NORMALIZER	Normalizer
ELECTRICITY	Electricity
FUEL	Fuel
RENEWABLE	Renewable Energy
AIR_TRANSPORT	Air Transport
FARM	Farm Operations
MACHINERY	Machinery
INVOICE	Invoice-based Emissions
SPEND	Spend-based Emissions
SCOPE2_ADJUSTMENT	Scope 2 Market Adjustment
SCOPE3_CATEGORY	Scope 3 Category
INDEX	Index
DELTA	Delta
SPLIT	Split Allocation
AGRIVISION	Agricultural Vision
CONSUMPTION	Consumption
DISCHARGE	Discharge
WITHDRAWAL	Withdrawal
STRESS	Water Stress
DIVERSION	Diversion Rate
CHEMICALS	Chemicals
MANAGEMENT	Management
TRANSITION_ROI	Transition Return on Investment
CARBON_FINANCE	Carbon Finance
CARBON_PRICE	Carbon Price
FOOTPRINT	Footprint
LIFECYCLE	Life Cycle
EPD	Environmental Product Declaration
EMISSION_FACTOR	Emission Factor
ACCOUNTS_PAYABLE	Accounts Payable
CRAWLER	Crawler
AIR_QUALITY	Air Quality
INTERPOLATOR	Interpolator
FORECASTER	Forecaster
INFERENCE	Inference
DEVICE	Device
DOCUMENT	Document
VECTORIZER	Vectorizer
ALIGNMENT	Alignment
OCCUPANCY	Occupancy
COVERAGE	Coverage
COMPLETENESS	Completeness
RECONCILIATION	Reconciliation
AUDIT	Audit
CONTEXT	Context
LEDGER	Ledger
FEDERATION	Federation
FEEDBACK	Feedback
RUNTIME	Runtime
SCHEDULER	Scheduler
STRUCTURE	Structure
RULES	Rules
POLICY	Policy
QUARANTINE	Quarantine
CONFIGURATION	Configuration
PURCHASED_GOODS	Purchased Goods and Services (Scope 3 cat. 1)
CAPITAL_GOODS	Capital Goods (Scope 3 cat. 2)
FUEL_ENERGY_ACTIVITIES	Fuel- and Energy-related Activities (Scope 3 cat. 3)
UPSTREAM_TRANSPORT	Upstream Transportation and Distribution (Scope 3 cat. 4)
OPERATIONAL_WASTE	Waste Generated in Operations (Scope 3 cat. 5)
BUSINESS_TRAVEL	Business Travel (Scope 3 cat. 6)
EMPLOYEE_COMMUTING	Employee Commuting (Scope 3 cat. 7)
UPSTREAM_LEASED_ASSETS	Upstream Leased Assets (Scope 3 cat. 8)
DOWNSTREAM_TRANSPORT	Downstream Transportation and Distribution (Scope 3 cat. 9)
PRODUCT_PROCESSING	Processing of Sold Products (Scope 3 cat. 10)
PRODUCT_USE	Use of Sold Products (Scope 3 cat. 11)
END_OF_LIFE	End-of-Life Treatment of Sold Products (Scope 3 cat. 12)
DOWNSTREAM_LEASED_ASSETS	Downstream Leased Assets (Scope 3 cat. 13)
FRANCHISES	Franchises (Scope 3 cat. 14)
INVESTMENTS	Investments (Scope 3 cat. 15)
ACTIVITY_FACTOR	Activity × Emission Factor (average-data method)
SUPPLIER_SPECIFIC	Supplier-specific Data
TRANSPORT	Transport, all modes (journey of air, road, rail, sea and inland-waterway legs)
WASTE_TREATMENT	Waste Treatment Emissions
USE_PHASE	Use-phase Emissions
FINANCED_EMISSIONS	Financed Emissions (PCAF attribution)

Function codes are the specific segment of a MEID. The list grows with the engine inventory and is reference vocabulary rather than a closed enumeration, but every value SHALL be registered here (and in zar.meid_function) before it is used in a MEID. A function code MAY contain _ (TARGET_GAP, SCOPE2_ADJUSTMENT); validators SHALL resolve the three MEID segments by vocabulary lookup, not by splitting on _.

16.4. MICE Types

mice.category on an engine document SHALL be the type_code of a registered MICE Type document (see MTPS-001). The MICE Type bounds which §16.2 capabilities an engine's MEID may carry. The registry projection config/system/mice-types.json is generated from the type documents and is the authority for this table; it is reproduced here for reference.

Type code	MICE Type	Allowed capabilities
AGGR	Aggregation Engines	AGGR
ALERT	Alert Engines	DETECT, MONITOR
AME	Assurance / Meta engines	VERIFY, ATTEST, SCORE, DETECT
CALC	Calculation Engines	CALC, ALLOCATE
CONN	Connector Engines	IMPORT, EXPORT, SYNCHRONIZE
CTRL	Control & Governance Engines	ATTEST, ANCHOR, REPLAY, ROUTE, ORCHESTRATE, MONITOR, RESOLVE, EXPORT
ESTM	Estimation & Forecasting Engines	PREDICT, CLASSIFY
EXTR	Extraction Engines	INGEST
GEOX	Geospatial Engines	RESOLVE, CLASSIFY
META	Metadata Enrichment Engines	ENRICH, CLASSIFY
NORM	Normalization Engines	NORMALIZE
RMAP	Risk Mapping Engines	CLASSIFY
RSLU	Resolution Engines	RESOLVE, CLASSIFY
SCEN	Scenario Engines	PROJECT, OPTIMIZE
SCORE	Scoring Engines	SCORE
SENS	Sensor Logic Units	VALIDATE, TRANS, DETECT
TRFM	Transformation Engines	TRANS, CLASSIFY, NORMALIZE
TSER	Time-Series Engines	TRANS, VALIDATE, SYNCHRONIZE
UOM-TYPE	UOM Engines	AGGR, CALC, RESOLVE, VALIDATE
VALI	Validator Engines	VALIDATE

UOM-TYPE is deprecated: its members migrate to NORM, RSLU and VALI. GEOX is a sub-type of RSLU.

---

17. Summary

MEID gives ZAYAZ a stable identity layer for executable micro-engines.

CMI identifies versioned implementation artifacts.

MEID identifies stable logical engines.

Together they provide runtime traceability, deterministic replay, DAL auditability, ZAR governance, architecture graph consistency, and scalable developer naming discipline.