Skip to main content

CMID

Canonical Metric Identifier System (CMID)

A Unified Tagging, Discovery, and Assurance Layer for Policies, Metrics, and Evidence

1. Purpose & Scope

The Canonical Metric Identifier System (CMID) is the universal standard for labeling, indexing, referencing, and verifying sustainability metrics across:

  • Policies
  • Procedures
  • Forms (FOGE)
  • Signals (SSSR)
  • Micro-Engines (MICE)
  • Reports & XBRL mappings
  • Agent workflows (ZARA, ZAAM)
  • Audit & evidence systems (ALTD, DAL, Assurance Cloud)

CMIDs ensure that every reference to a metric — in policy text, regulatory mappings, form fields, signals, or narrative sections — is traceable to a single authoritative definition.

CMIDs solve 4 systemic problems:

ProblemSolved By.
Inconsistent metric definitions across departments & policiesCMID → unified version in SSSR/ZAR
Hard for verifiers/auditors to locate a metric in ZAYAZCMID → deep link routing
Manual updates when ESRS/GRI/TCFD changesCMID → single point update
Lack of machine-readable tagging in documentationCMID → Docusaurus → SSSR → ZAR pipeline

CMIDs are the backbone enabling full automation, advanced search, and policy–metric interoperability.

2. CMID Generation Model​

2.1 Purpose​

The Canonical Metric Identifier System (CMID) provides a stable, global, immutable identity for every measurable unit used inside the ZAYAZ Platform. CMIDs allow:

  • unambiguous identification of metrics across all modules
  • cross-engine coordination (COSE → FIRM → REFS → AAE → RIF)
  • federated metric verification for auditors, authorities, and automated agents
  • machine-resolution of metrics during inference, simulation, or validation

Every CMID is globally unique, deterministic, and computationally generated.

2.2 Relationship to the Smart Searchable Signal Registry (SSSR)​

The SSSR is the authoritative source of metrics inside ZAYAZ.

Each row in the SSSR corresponds to:

  • a single semantic metric
  • a single data signal
  • a single CMID, automatically derived from its registry position

This ensures the entire platform uses the same canonical metric identity for:

  • emissions factors
  • governance indicators
  • supply chain metrics
  • risk thresholds
  • policy fields
  • micro-engine outputs
  • AI-generated enriched metrics

2.3 Canonical CMID Format​

The CMID follows this strict schema:

CMID-ZYZ-{ID padded to 6 digits}

Example mappings:

internal idsignal_idCMID.
sssr-000001sssr:countries.iso_cc_idCMID-ZYZ-000001
sssr-000002sssr:countries.iso_3166_1_alpha_3CMID-ZYZ-000002
sssr-000014sssr:energy.electricity.mwhCMID-ZYZ-000014
sssr-000432sssr:scope3.category1.upstreamCMID-ZYZ-000432

This creates a one-to-one, deterministic mapping:

CMID = canonical identity
SSSR row = canonical source of truth

2.4 Automated CMID Generation in SSSR​

CMIDs are generated and stored in Postgres:

ALTER TABLE signal_registry
ADD COLUMN cmid TEXT
GENERATED ALWAYS AS (
  'CMID-ZYZ-' || LPAD(id::text, 6, '0')
) STORED;

This ensures:

  • no manual assignment
  • no drift
  • no missing CMIDs
  • instant availability for search
  • guaranteed uniqueness

CMIDs become first-class members of:

  • verification workflows
  • RIF risk processes
  • COSE anomaly detection
  • AAE reasoning traces
  • ZARA query resolution
  • TLX/PAL provenance chains

2.5 CMIDs in Policy Templates​

Policy templates do not generate CMIDs.

They declare relationships to CMIDs via:

cmids:
  - CMID-ZYZ-000001
  - CMID-ZYZ-000014

This model is intentional:

  • metrics are anchored in SSSR
  • policies reference metrics
  • reasoning (AAE) and auditing (COSE/RIF) become deterministic

Below is a drop-in MDX section for your document and a corrected version of Sections 4.2 and 5 that reflect your rule:

SSSR is the authority. A row never mutates semantically. If the definition changes materially, a new SSSR row is issued → which creates a new CMID.

This aligns perfectly with ledger-style immutability and prevents silent metric drift.

2.6. Universal ESG Metric URI System (UMURI)​

While CMID provides a deterministic internal identifier for metrics, the Universal ESG Metric URI System (UMURI) provides a globally resolvable reference layer for humans, APIs, agents, auditors, and external systems.

UMURI enables ZAYAZ metrics to be cited and resolved in the same way scientific publications use persistent identifiers such as DOIs.

This system ensures that any sustainability metric referenced inside or outside ZAYAZ can be:

  • globally identifiable
  • machine resolvable
  • cryptographically traceable
  • stable over time

2.6.1. Identifier Layers​

ZAYAZ uses three complementary identifier forms for metric definitions:

IdentifierPurposeExample
CMIDInternal canonical metric identifierCMID-ZYZ-001288
URNTransport-safe permanent metric identifierurn:zayaz:metric:CMID-ZYZ-001288
HTTPS URIResolver endpoint for the metric definitionhttps://id.zayaz.io/metric/CMID-ZYZ-001288

These identifiers all refer to the same canonical metric definition.

2.6.2. Canonical URN Format​

Every metric MUST have a permanent URN identifier.

urn:zayaz:metric:{CMID}

Example:

urn:zayaz:metric:CMID-ZYZ-001288

Properties:

  • globally unique
  • immutable
  • storage-safe in ledgers
  • safe for signatures, hashes, and blockchain references
  • independent of network infrastructure

URNs are the recommended identifier for cryptographic provenance chains including:

  • DAL (Digital Assurance Ledger)
  • PAL (Planetary Assurance Ledger)
  • TLX (Transparency Ledger Exchange)

Example ledger reference:

{
  "metric_urn": "urn:zayaz:metric:CMID-ZYZ-001288",
  "timestamp": "2026-01-15T10:42:11Z",
  "verification_hash": "b9fae1a9e..."
}

2.6.3. Canonical HTTPS Metric URI​

Every metric MUST resolve through a canonical HTTPS URI.

https://id.zayaz.io/metric/{CMID}

Example:

https://id.zayaz.io/metric/CMID-ZYZ-001288

The URI resolver provides:

  • metric definition
  • SSSR linkage
  • framework mappings
  • dependency graph
  • calculation engines
  • validation engines
  • audit links
  • provenance data

The resolver supports content negotiation:

Request TypeResponse
BrowserHTML documentation
APIJSON
Graph / semantic systemsJSON-LD

2.6.4. Metric Definition Resolution​

Resolving a metric URI returns structured metadata.

Example:

{
  "cmid": "CMID-ZYZ-001288",
  "urn": "urn:zayaz:metric:CMID-ZYZ-001288",
  "uri": "https://id.zayaz.io/metric/CMID-ZYZ-001288",
  "sssr_id": "sssr-001288",
  "title": "Percentage Reduction in Total Greenhouse Gas Emissions",
  "unit": "percent",
  "data_type": "numeric_percentage",
  "framework_mappings": [
    {
      "framework": "ESRS",
      "concept": "ESRS_E1.EmissionsReductionPercentage"
    }
  ],
  "dependencies": [
    "CMID-ZYZ-000731",
    "CMID-ZYZ-000812"
  ],
  "engines": {
    "calculation": "MEID_CALC02_v1",
    "validation": "MEID_VALI04_v1"
  },
  "links": {
    "audit_view": "/ask?cmid=CMID-ZYZ-001288&mode=audit",
    "evidence": "/evidence/metric/CMID-ZYZ-001288"
  }
}

2.6.5. URI Stability Rules​

The following rules guarantee identifier stability.

RuleDescription
CMIDs are immutableA CMID never changes once issued
Metric URIs never changeMetric URIs must remain resolvable permanently
Metric URNs never changeMetric URNs are permanent identifiers
Deprecated metrics remain resolvableDeprecated metrics return a tombstone response
Replacement metrics must be linkedSuccessor CMIDs must be referenced

Example deprecation response:

{
  "cmid": "CMID-ZYZ-000731",
  "status": "deprecated",
  "replaced_by": "CMID-ZYZ-001288",
  "reason": "Metric consolidated following ESRS revision"
}

2.6.6. Relationship to CMID​

The relationship between identifiers is:

SSSR row → CMID → URN → HTTPS URI

Example:

SSSR ID: sssr-001288
CMID: CMID-ZYZ-001288
URN: urn:zayaz:metric:CMID-ZYZ-001288
URI: https://id.zayaz.io/metric/CMID-ZYZ-001288

CMID remains the canonical internal identity, while URN and URI provide global interoperability.

2.6.7. External Citation​

External systems can reference metrics using URIs or URNs.

Examples:

Policy reference

Metric: https://id.zayaz.io/metric/CMID-ZYZ-001288

API payload

{
  "metric": "urn:zayaz:metric:CMID-ZYZ-001288",
  "value": 14.2,
  "period": "2025"
}

Verifier evidence

Evidence linked to:
urn:zayaz:metric:CMID-ZYZ-001288

2.6.8. Metric Definitions vs Facts​

A metric definition and a metric fact represent two different objects within ZAYAZ.

ObjectMeaningExample
Metric DefinitionDefines what the metric meansurn:zayaz:metric:CMID-ZYZ-001288
Metric FactA concrete observed, reported, calculated, or verified value for that metricurn:zayaz:fact:CMID-ZYZ-001288:004567

A metric URI identifies the definition, not a particular reported value.

Example:

https://id.zayaz.io/metric/CMID-ZYZ-001288

This resolves to the canonical metric definition stored in the SSSR registry and ZAR metadata layer.

However, real ESG disclosures consist of fact records, which represent concrete metric values linked to:

  • a reporting entity
  • a reporting period
  • a submission or calculation
  • evidence and verification records

Each fact must therefore have its own identifier.

2.6.9. Canonical Fact Identity​

The canonical identity of a metric fact follows this structure:

Fact identity = {CMID}:{fact_instance_id}

Example:

CMID-ZYZ-001288:004567

This identifier means:

  • the metric definition is CMID-ZYZ-001288
  • the specific fact instance is 004567

This creates a deterministic and scalable namespace where each metric manages its own fact instance sequence.

2.6.10. Canonical Fact URN​

Fact records MUST have a transport-safe URN identifier.

Format:

urn:zayaz:fact:{CMID}:{fact_instance_id}

Example:

urn:zayaz:fact:CMID-ZYZ-001288:004567

This URN is used for:

  • provenance chains
  • ledger references (DAL, PAL, TLX)
  • cryptographic signatures
  • audit logs
  • AI reasoning traces

Because the URN embeds the CMID, the fact is always linked to its metric definition.

2.6.11. Canonical Fact URI​

Each fact record must also be resolvable through an HTTPS resolver.

Format:

https://id.zayaz.io/fact/{CMID}/{fact_instance_id}

The resolver interprets the path parameters and retrieves the corresponding fact record.

Example resolver query:

SELECT *
FROM metric_facts
WHERE cmid = 'CMID-ZYZ-001288'
AND fact_instance_id = '004567';

The returned resource contains the complete disclosure record including context and provenance.

2.6.12. Example Fact Resource​

Resolving a fact URI may return a structure similar to:

{
  "fact_urn": "urn:zayaz:fact:CMID-ZYZ-001288:004567",
  "fact_uri": "https://id.zayaz.io/fact/CMID-ZYZ-001288/004567",
  "cmid": "CMID-ZYZ-001288",
  "metric_urn": "urn:zayaz:metric:CMID-ZYZ-001288",
  "fact_instance_id": "004567",
  "entity_id": "ECO-196-123-456-789",
  "reporting_period": "2025",
  "value": 14.2,
  "unit": "percent",
  "evidence_refs": [
    "ECO-ATTACHMENT-12321"
  ]
}

This structure preserves the full lineage between:

  • metric definition
  • fact observation
  • reporting entity
  • evidence records

2.6.13. Benefits​

The CMID-based fact identity model provides:

  • deterministic fact identification
  • guaranteed linkage to metric definitions
  • scalable metric namespaces
  • stable provenance references
  • efficient database resolution
  • clean separation between metric meaning and metric observations

3. CMID Schema (ZAR Artifact Format)​

CMID is generated directly from signal_registry.id

{
  "cmid": "CMID-ZYZ-001288",
  "title": "Percentage Reduction in Total Greenhouse Gas Emissions",
  "description": "Measures percentage reduction of combined Scope 1, 2, and 3 emissions relative to baseline year.",
  "domains": ["ESG", "Climate", "GHG"],
  "signal_ids": ["SIG.GHG.TOTAL", "SIG.GHG.BASELINE"],
  "sssr_mapping": "SSSR.GHG.TOTAL.REDUCTION_PCT",
  "xbrl_concepts": ["ESRS_E1.EmissionsReductionPercentage"],
  "micro_engines": ["MEID_CALC02_v1", "MEID_VALI04_v1"],
  "evidence_requirements": [
    "baseline_inventory",
    "current_inventory",
    "methodology_document",
    "verifier_statement"
  ],
  "version": 1,
  "status": "active"
}

4. SSSR Integration​

The SSSR (Smart Searchable Signal Registry) stores metadata for every signal. CMID becomes a required column.

4.1. Updated SSSR Schema​

{
  "signal_id": "SIG.GHG.TOTAL.REDUCTION_PCT",
  "name": "GHG Reduction Percentage (Scope 1+2+3)",
  "type": "numeric_percentage",
  "frameworks": ["CSRD", "ESRS", "GRI"],
  "cmid": "CMID-ZYZ-001288",
  "tags": ["policy-linked", "climate", "critical", "assurable"],
  "dependencies": ["SIG.GHG.TOTAL.CURRENT", "SIG.GHG.TOTAL.BASELINE"],
  "valuation_engine": "MEID_CALC02_v1",
  "validation_engine": "MEID_VALI04_v1"
}

4.2. Requirements​

The SSSR (Smart Searchable Signal Registry) is the authoritative registry of all signals and metrics used inside ZAYAZ.

The following invariants apply:

  • Every SSSR signal MUST map to exactly one CMID.
  • Metrics without CMIDs CANNOT appear in policies, forms, or reports.
  • An SSSR row represents a stable metric definition.
  • If a metric definition changes materially, a new SSSR row MUST be created.
  • Creating a new SSSR row automatically generates a new CMID.

This guarantees that:

  • historical metrics remain reproducible
  • audit trails remain stable
  • calculations remain deterministic

The SSSR → CMID link is used by:

  • ZARA reasoning engine
  • ZAAM assistants (Form Diagnostic, Verifier Concierge, Compliance Scout)
  • XBRL/iXBRL export
  • ALTD audit trails
  • SEEL stakeholder mapping

5. ZAR Integration (Canonical Identifier Architecture)​

ZAR stores authoritative metric definitions. SSSR stores operational signal mappings.

5.1. Binding Logic​

Metric lineage across ZAYAZ follows this deterministic chain:

SSSR.signal → CMID → ZAR.metric → FOGE.field → ALTD.entry

Where:

  • SSSR defines the canonical signal entry
  • CMID provides the universal metric identifier
  • ZAR stores semantic metadata and calculation logic
  • FOGE binds form fields to metrics
  • ALTD records evidence and audit actions

This architecture ensures complete traceability from data input to verified disclosure.

This provides complete metric lineage across the platform.

5.2 SSSR Authority Rules​

SSSR is the authoritative registry for metric signals.

The following rules govern registry behavior:

RuleDescription
SSSR rows are immutableThe semantic meaning of a row MUST NOT change
New definitions require new rowsMaterial metric definition changes create new SSSR entries
New SSSR rows generate new CMIDsCMIDs are derived directly from the SSSR row ID
Deprecated rows remain resolvableHistorical metrics must remain queryable
Lineage must be preservedReplacement relationships must be recorded

Example lifecycle:

Original metric: sssr-001288 → CMID-ZYZ-001288

Revised metric definition: sssr-001945 → CMID-ZYZ-001945

The previous metric remains accessible for:

  • historical calculations
  • audit replay
  • regulatory evidence
  • model explainability

Deprecation relationships are stored in ZAR metadata.

Example:

{
  "cmid": "CMID-ZYZ-001288",
  "status": "deprecated",
  "replaced_by": "CMID-ZYZ-001945"
}

This design ensures full reproducibility of historical ESG disclosures.

6. FOGE / Form Generator Integration​

FOGE needs CMIDs to bind form fields to canonical metric logic.

6.1. Field Schema​

{
  "field_id": "FIELD.GHG.TOTAL.REDUCTION_PCT",
  "label": "GHG Total Reduction (%)",
  "cmid": "CMID-ZYZ-001288",
  "signal_id": "SIG.GHG.TOTAL.REDUCTION_PCT",
  "required": true,
  "micro_engine": "MEID_CALC02_v1"
}

6.2. Dynamic Behavior​

  • Form hints come from ZARA.
  • Field-level help comes from ZAAM.
  • Validation comes from DICE/DaVE.
  • Assurance comes from VTE → Verifier workflows.

7. Integration With ZARA & ZAAM​

ZARA uses CMIDs as reasoning anchors.

7.1. Example​

Prompt:

“What’s missing from our Scope 3 disclosures?”

ZARA resolves:

CMID.GHG.SCOPE3.TOTAL.v1
  ↳ SSSR.GHG.S3.CATEGORIES (all 15 categories)
  ↳ Missing: SIG.GHG.S3.CAT4, SIG.GHG.S3.CAT9

7.2. ZAAM Agents​

  • Form Diagnostic Agent → preloads CMID → SSSR → help text
  • Verifier Concierge → deep-links to CMIDs for each disclosure
  • EcoWorld Academy Mentor → teaches the metric based on CMID

8 XBRL/iXBRL Binding​

8.1. Mapping Table​

{
  "cmid": "CMID-ZYZ-001288",
  "xbrl_reference": {
    "taxonomy": "EFRAG ESRS",
    "concept": "ESRS_E1.EmissionsReductionPercentage",
    "datatype": "xbrl:percentItemType",
    "period_type": "duration"
  }
}

8.2. Workflow​

  1. Exporter reads CMID
  2. Maps to XBRL concept
  3. Checks SSSR signal values
  4. Runs validation engines
  5. Produces ESEF/iXBRL-ready file

9 ALTD Audit Trail Integration​

Every metric-related action must store CMID.

9.1. Audit Log Example​

{
  "event": "metric_update",
  "cmid": "CMID-ZYZ-001288",
  "metric_urn": "urn:zayaz:metric:CMID-ZYZ-001288",
  "fact_id": "CMID-ZYZ-001288:004567",
  "fact_urn": "urn:zayaz:fact:CMID-ZYZ-001288:004567",
  "fact_uri": "https://id.zayaz.io/fact/CMID-ZYZ-001288/004567",
  "signal_id": "SIG.GHG.TOTAL.REDUCTION_PCT",
  "user_id": "eco196xxxxxxx000023",
  "timestamp": "2025-03-04T12:41:00Z",
  "old_value": "12%",
  "new_value": "14%",
  "evidence_reference": "ECO-ATTACHMENT-12321"
}

10. CMIDs in the ZAYAZ Verification, Assurance & Evidence Pipeline​

The CMID is the universal reference key that binds together:

  • metric definitions
  • policy fields
  • calculation engines
  • telemetry signals
  • evidence sources
  • auditor workflows
  • AI reasoning traces
  • lineage and provenance logs

This section describes how CMIDs propagate through the ZAYAZ Governance Stack.

10.0. CMID Badge Component​

Create a component: /src/components/CMIDBadge.js

import * as React from 'react';

export default function CMIDBadge({ cmid }: { cmid: string }) {
  return (
    <span
      style={{
        padding: '4px 8px',
        backgroundColor: 'var(--zyz-color-brand-tint, #E0F2FF)',
        borderRadius: '6px',
        fontSize: '0.8rem',
        color: 'var(--zyz-color-brand-strong, #0369A1)',
        border: '1px solid var(--zyz-color-border-subtle)',
        marginLeft: '0.25rem',
      }}
    >
      {cmid}
    </span>
  );
}

Expose it in MDXComponents.js:

import CMIDBadge from '@site/src/components/CMIDBadge';

export default {
  ...OriginalMDXComponents,
  CMIDBadge,
};

We can now use:

<CMIDBadge cmid="CMID-ZYZ-000001" />

10.1 CMID → Evidence Linking​

Every CMID automatically synthesizes:

10.1.1 Ask ZARA Audit View​

A dedicated audit context:

/ask?cmid=CMID-ZYZ-000014&mode=audit

This enables:

  • auditor-focused responses
  • deterministic grounding
  • stricter hallucination controls
  • traceable evidence pathways
  • reference to all policies and calculations involving that CMID

Access is wrapped in:

<AudienceBlock audience={['external-auditor','external-verifier','external-authority']}>
  <AuditEvidenceLink cmid="CMID-ZYZ-000014" />
</AudienceBlock>

Only authorized audiences see the link.

10.2 CMIDs in Search Indexing​

The indexer injects CMIDs into semantic search metadata.

Example search document:

{
  "id": "doc:/policies/env/climate-change#metrics",
  "slug": "/policies/env/climate-change",
  "title": "Climate Change Policy",
  "heading": "Metrics",
  "content": "...",
  "metadata": {
    "hub": "policies",
    "module": "env",
    "cmid": ["CMID-ZYZ-000001", "CMID-ZYZ-000014"]
  }
}

This enables ZARA to answer:

  • “Which documents define CMID-ZYZ-000432?”
  • “Which policies reference CMID-ZYZ-000114?”
  • “Show me all evidence related to CMID-ZYZ-000058.”

10.3 CMIDs in COSE (Compliance Surveillance Engine)​

COSE uses CMIDs to:

  • align anomaly detection with metric semantics
  • identify regulatory thresholds linked to specific signals
  • consolidate evidence trails from multiple sources
  • power cross-framework compliance mapping (CSRD ↔ ESRS ↔ IPCC ↔ ISO)

CMIDs provide the anchoring identity that ensures the correct regulatory rule is applied to the correct metric.

10.4 CMIDs in RIF (Risk Intelligence Framework)​

RIF uses CMIDs as dimension keys for:

  • dynamic risk filters
  • threshold retrieval
  • sector-adjusted baselines
  • overconfidence index detection
  • fraud/irregularity signals
  • probability-based noncompliance scoring

This transforms CMIDs into a risk-aware ontology entry.

10.5 CMIDs in AAE (Autonomous Assurance Engine)​

AAE uses CMIDs to:

  • fetch metric definitions
  • build assurance chains
  • provide step-by-step reasoning
  • explain extrapolation or simulation behavior
  • verify consistency between calculators and policy expectations
  • produce transparent validation narratives for auditors

Every reasoning trace is anchored by CMID.

10.6 CMIDs in Lineage, Provenance & TLX → PAL​

CMIDs feed directly into:

  • TLX (Transparency Ledger Exchange)
  • PAL (Planetary Assurance Ledger)
  • DAL (Digital Assurance Ledger)

This ensures traceability:

  • from input → calculation → evidence → reporting → verification → blockchain proof

A CMID-based lineage model is:

Input Source → Metric Signal → Calculation → Assurance → Disclosure → Ledger

Each hop is cryptographically resolvable.

Chapter 10 Summary

CMIDs are the connective tissue of the entire assurance ecosystem:

LayerRole of CMID
SSSRcanonical metric identity
Policiessemantic link to regulatory expectations
Enginesconsistent computation across modules
COSEcompliance anomaly mapping
RIFrisk filters & sector adjustments
AAEtransparent reasoning & verification
TLX/PALend-to-end traceability & auditability

CMIDs turn ZAYAZ into a provable, self-auditing sustainability system.

11. CMID Lifecycle Management​

Versioning Rules

ChangeVersion Change
Metadata clarificationsPATCH (v1.0 → v1.1)
Additional variantsMINOR (v1 → v1.1)
Breaking definition changeMAJOR (v1 → v2)

12. End-to-End Flow (Technical)​

Docusaurus Policy → CMID → ZAR
                       ↓
                 SSSR Signal
                       ↓
               FOGE Field Generation
                       ↓
              ZARA + ZAAM Assistants
                       ↓
              Validation (DICE/DaVE)
                       ↓
              Assurance & Verifier Workflow
                       ↓
                  XBRL/iXBRL Export
                       ↓
                 ALTD Audit Logging

13. Summary - CMID​

Introducing CMIDs enables:

  • Searchable, structured policy-metric linkage
  • Auditor/verifier deep linking
  • Automated consistency across the entire ZAYAZ ecosystem
  • Policy interoperability with regulatory frameworks
  • Accurate XBRL generation
  • Smarter agent behavior (ZARA, ZAAM)
  • Full lifecycle traceability in ALTD

CMIDs are now a core layer in the Shared Intelligence Stack (SIS) and ZAR framework.

14. Cryptographic Integrity & Ledger Anchoring​

ZAYAZ provides cryptographic integrity guarantees for both metric definitions and metric facts.

This capability ensures that:

  • metric definitions cannot be silently modified
  • reported facts cannot be altered without detection
  • historical disclosures remain reproducible
  • audit trails can be independently verified

The system achieves this using two mechanisms:

  1. Cryptographic fingerprints (hashes)
  2. Merkle audit trees anchored in Hyperledger Fabric

Together these provide a provable ESG data infrastructure suitable for regulatory-grade reporting and assurance.

14.1. Cryptographic Metric Fingerprints​

Each metric definition stored in SSSR/ZAR is converted into a canonical JSON representation.

Example metric definition:

{
  "cmid": "CMID-ZYZ-001288",
  "title": "Percentage Reduction in Total Greenhouse Gas Emissions",
  "unit": "percent",
  "data_type": "numeric_percentage",
  "dependencies": [
    "CMID-ZYZ-000731",
    "CMID-ZYZ-000812"
  ],
  "calculation_engine": "MEID_CALC02_v1",
  "validation_engine": "MEID_VALI04_v1"
}

A cryptographic fingerprint is calculated using SHA-256.

metric_fingerprint = SHA256(canonical_metric_json)

Example result:

b7d19c7b77e1b7a3e0a3d0a6f9a2f6e7b53c0f5e5c45a4d90d91cbe9b5e1c2a6

The fingerprint uniquely represents the exact metric definition.

If any part of the definition changes, the fingerprint changes.

14.2. Metric Fingerprint Ledger Anchoring​

Metric fingerprints are anchored in the Hyperledger Fabric internal ledger.

Example ledger record:

{
  "record_type": "metric_definition",
  "cmid": "CMID-ZYZ-001288",
  "metric_urn": "urn:zayaz:metric:CMID-ZYZ-001288",
  "definition_fingerprint": "b7d19c7b77e1b7a3e0a3d0a6f9a2f6e7b53c0f5e5c45a4d90d91cbe9b5e1c2a6",
  "registry": "SSSR",
  "created_at": "2026-01-15T10:42:11Z"
}

This guarantees:

  • metric definition integrity
  • historical version traceability
  • tamper detection

Auditors can independently recompute the fingerprint from the published metric definition.

14.3. Fact Fingerprints​

Metric facts are also cryptographically fingerprinted.

Example fact record:

{
  "cmid": "CMID-ZYZ-001288",
  "fact_instance_id": "004567",
  "entity_id": "ECO-196-123-456-789",
  "reporting_period": "2025",
  "value": 14.2,
  "unit": "percent"
}

Fingerprint calculation:

fact_fingerprint = SHA256(canonical_fact_json)

Example result:

af91d7a1e4f9f40b56f47f05a48c45e3a1e13d29c33c58f4a5d5a87e8c15c70d

Fact identity:

CMID-ZYZ-001288:004567

Fact URN:

urn:zayaz:fact:CMID-ZYZ-001288:004567

Ledger entry:

{
  "record_type": "metric_fact",
  "fact_urn": "urn:zayaz:fact:CMID-ZYZ-001288:004567",
  "cmid": "CMID-ZYZ-001288",
  "fact_fingerprint": "af91d7a1e4f9f40b56f47f05a48c45e3a1e13d29c33c58f4a5d5a87e8c15c70d",
  "timestamp": "2026-01-15T10:42:11Z"
}

This guarantees that reported values cannot be altered undetected.

14.4. Canonical JSON Serialization​

To ensure deterministic hashing, JSON must be canonicalized.

Example rules:

  • fields sorted alphabetically
  • UTF-8 encoding
  • no whitespace differences
  • normalized number formats

Example canonical serialization pseudocode:

import json
import hashlib

def fingerprint(data):
    canonical = json.dumps(data, sort_keys=True, separators=(',', ':'))
    return hashlib.sha256(canonical.encode("utf-8")).hexdigest()

This ensures identical fingerprints across systems.

14.5. Merkle Audit Trees​

To efficiently verify large ESG datasets, ZAYAZ constructs Merkle audit trees.

A Merkle tree aggregates thousands or millions of fact fingerprints into a single Merkle root hash.

Structure:

Fact Hash 1
Fact Hash 2
Fact Hash 3
Fact Hash 4
      ↓
Hash Pair 1
Hash Pair 2
      ↓
Merkle Root

Example:

H1 = SHA256(fact1)
H2 = SHA256(fact2)
H3 = SHA256(fact3)
H4 = SHA256(fact4)

P1 = SHA256(H1 + H2)
P2 = SHA256(H3 + H4)

MERKLE_ROOT = SHA256(P1 + P2)

The Merkle root becomes the cryptographic fingerprint of an entire ESG dataset.

14.6. Ledger Anchoring of Merkle Roots​

Instead of storing millions of fact hashes in the ledger, ZAYAZ stores the Merkle root.

Example ledger entry:

{
  "record_type": "report_merkle_root",
  "entity_id": "ECO-196-123-456-789",
  "reporting_period": "2025",
  "merkle_root": "b8e12a67e3c5c7f1d2e8d61fbe0a4b73a0c9c77cda9a3c8b1e6c7f5d2b1c9a3f",
  "facts_count": 48213,
  "timestamp": "2026-03-10T14:22:09Z"
}

Auditors can verify any individual fact by recomputing the path to the root.

14.7. Audit Verification Workflow​

An auditor can independently verify any reported ESG value.

Verification steps:

  1. Retrieve the fact record
  2. Recompute the fact fingerprint
  3. Verify inclusion in the Merkle tree
  4. Verify Merkle root stored in the ledger
  5. Verify ledger integrity

Verification pseudocode:

if sha256(fact_json) == fact_fingerprint:
    verify_merkle_path()
    verify_merkle_root_in_ledger()

If all checks pass, the auditor has cryptographic proof that the value has not been altered.

14.8. Benefits for ESG Assurance​

This architecture provides:

  • tamper-evident ESG reporting
  • deterministic audit replay
  • independent verification capability
  • long-term regulatory traceability
  • cryptographic assurance of disclosures
  • scalable verification for millions of facts

These properties significantly strengthen ZAYAZ as a regulatory-grade ESG infrastructure platform.

14.9. Verifiable ESG Reports​

ZAYAZ enables the creation of cryptographically verifiable ESG reports.

A verifiable ESG report is a sustainability disclosure package where the entire dataset can be independently verified using cryptographic proofs.

This is achieved by aggregating all report facts into a Merkle audit tree, whose root hash is anchored in the internal Hyperledger Fabric ledger.

14.9.1. Report Integrity Model​

Each ESG report contains thousands of metric facts.

Example:

Fact 1 → CMID-ZYZ-001288:004567
Fact 2 → CMID-ZYZ-000731:000128
Fact 3 → CMID-ZYZ-004211:000933
Fact 4 → CMID-ZYZ-002511:000102

Each fact is fingerprinted:

H1 = SHA256(fact1)
H2 = SHA256(fact2)
H3 = SHA256(fact3)
H4 = SHA256(fact4)

These hashes are aggregated into a Merkle tree.

P1 = SHA256(H1 + H2)
P2 = SHA256(H3 + H4)

MERKLE_ROOT = SHA256(P1 + P2)

The resulting Merkle root represents the entire ESG dataset for that report.

14.9.2. Ledger Anchoring​

The Merkle root is anchored in the Hyperledger Fabric ledger.

Example ledger record:

{
  "record_type": "verifiable_esg_report",
  "entity_id": "ECO-196-123-456-789",
  "reporting_period": "2025",
  "facts_count": 48213,
  "merkle_root": "b8e12a67e3c5c7f1d2e8d61fbe0a4b73a0c9c77cda9a3c8b1e6c7f5d2b1c9a3f",
  "report_uri": "urn:zayaz:report:ECO-196-123-456-789:2025",
  "timestamp": "2026-03-10T14:22:09Z"
}

Because the ledger is immutable, this Merkle root becomes the permanent cryptographic fingerprint of the report.

14.9.3. Independent Verification​

Auditors or regulators can verify any ESG disclosure using the following steps:

  1. Retrieve the fact record
  2. Recompute the fact fingerprint
  3. Verify its inclusion path within the Merkle tree
  4. Confirm the Merkle root stored in the ledger

Verification pseudocode:

fact_hash = sha256(fact_json)

verify_merkle_path(fact_hash, merkle_root)

verify_merkle_root_in_ledger(merkle_root)

If verification succeeds, the fact is provably identical to the value originally reported.

14.9.4. Benefits of Verifiable ESG Reports​

Verifiable ESG reports provide:

  • cryptographic proof of report integrity
  • tamper-evident sustainability disclosures
  • deterministic audit replay
  • scalable verification for large datasets
  • long-term regulatory traceability

This capability allows ZAYAZ to deliver audit-grade ESG reporting infrastructure where sustainability disclosures become provably trustworthy digital records.

14.10. Architectural Diagram — Verifiable ESG Reporting Flow​

The following diagram illustrates how ZAYAZ transforms raw ESG facts into a cryptographically verifiable report.


How a single ESG number gets verified:


Architectural Diagram — Assurance-Grade Verifiable ESG Reporting

14.10.1. Simplified Verification Path​

An auditor verifying a single disclosure follows this path:

These diagrams show how ZAYAZ separates:

  • metric identity
  • fact identity
  • cryptographic integrity
  • report-level verification
  • ledger anchoring

This means a single ESG value can be independently tested against the cryptographic record of the full report.

14.10.2. Component Roles​

ComponentRole
SSSRAuthoritative source of metric definitions
CMIDCanonical metric identity
Fact IDCanonical fact identity in the form {CMID}:{fact_instance_id}
SHA-256 FingerprintTamper-evident fingerprint of metric definitions and facts
Merkle Audit TreeAggregates fact fingerprints into one report-level proof
Hyperledger FabricAnchors fingerprints and Merkle roots in an immutable ledger
Verifiable ESG ReportFinal report package whose integrity can be independently proven

14.10.3. Example Fact Chain​

Metric Definition:
CMID-ZYZ-001288
urn:zayaz:metric:CMID-ZYZ-001288

Fact Record:
CMID-ZYZ-001288:004567
urn:zayaz:fact:CMID-ZYZ-001288:004567
https://id.zayaz.io/fact/CMID-ZYZ-001288/004567

Fact Fingerprint:
SHA256(canonical_fact_json)

Merkle Root:
SHA256(aggregated fact hashes)

Ledger Anchor:
Hyperledger Fabric transaction storing Merkle root

This creates a complete, traceable path from:

metric definition → reported fact → cryptographic proof → immutable ledger anchor

14.10.4. Why This Matters​

This architecture allows ZAYAZ to provide:

  • mathematically verifiable ESG disclosures
  • tamper-evident audit trails
  • deterministic replay of historical reports
  • cryptographic proof of integrity at both metric and report level

For auditors, regulators, and accounting firms, this means that trust is no longer based only on process documentation — it is reinforced by cryptographic verification.



GitHub RepoRequest for Change (RFC)