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:

Select or propose a DOMAIN.
Select or propose a CAPABILITY.
Select or propose a FUNCTION.
Validate all three parts against ZAR vocabulary tables.
Generate the canonical MEID.
Check for duplicates in zar.meid_registry.
Return the existing MEID if one already exists.
Register the MEID as proposed, reserved, or active.
Bind one or more CMIs through zar.meid_cmi_binding.
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

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

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

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.

GitHub Repo Request for Change (RFC)

1. Purpose​

2. Scope​

3. Identity Model​

4. Canonical MEID Structure​

5. DOMAIN, CAPABILITY, and FUNCTION​

5.1. DOMAIN​

5.2. CAPABILITY​

5.3. FUNCTION​

6. Valid and Invalid Examples​

6.1. Valid Examples​

6.2. Invalid Examples​

7. Registry Architecture​

8. Registry Tables​

8.1. zar.meid_status​

8.2. zar.meid_domain​

8.3. zar.meid_capability​

8.4. zar.meid_function​

8.5. zar.meid_registry​

8.6. zar.meid_cmi_binding​

9. Naming Rules​

10. Lifecycle​

11. MEID Generation Workflow​

12. API Requirements​

12.1. Preview​

12.2. Register​

12.3. Bind CMI​

13. SQL Reference​

14. Governance​

15. Migration Guidance​

16. Reference Vocabulary​

16.1. Domains​

16.2. Capabilities​

16.3. Functions​

17. Summary​

1. Purpose

2. Scope

3. Identity Model

4. Canonical MEID Structure

5. DOMAIN, CAPABILITY, and FUNCTION

5.1. DOMAIN

5.2. CAPABILITY

5.3. FUNCTION

6. Valid and Invalid Examples

6.1. Valid Examples

6.2. Invalid Examples

7. Registry Architecture

8. Registry Tables

8.1. `zar.meid_status`

8.2. `zar.meid_domain`

8.3. `zar.meid_capability`

8.4. `zar.meid_function`

8.5. `zar.meid_registry`

8.6. `zar.meid_cmi_binding`

9. Naming Rules

10. Lifecycle

11. MEID Generation Workflow

12. API Requirements

12.1. Preview

12.2. Register

12.3. Bind CMI

13. SQL Reference

14. Governance

15. Migration Guidance

16. Reference Vocabulary

16.1. Domains

16.2. Capabilities

16.3. Functions

17. Summary