How Canonical ESG Evolves

Overview

Canonical ESG maintains two independent and unrelated systems:

1. CDI/CEDM Semantic Infrastructure - For organization-level sustainability reporting standards
2. UPPS Product Passport Standards - For product-level disclosure requirements

These systems are completely separate. They serve different purposes, have different audiences, and evolve independently. This document is divided into two distinct parts to avoid confusion.

Part 1: CDI/CEDM Semantic Infrastructure

Purpose

The Canonical Disclosure Intent (CDI) ontology and Canonical ESG Data Model (CEDM) provide foundational data architecture for organization-level sustainability reporting standards such as GRI, ESRS, ISSB, TCFD, and CSRD.

This infrastructure is unrelated to UPPS product passport standards.

This section defines:

• How the semantic infrastructure evolves
• How CDI/CEDM components are versioned
• How stability is preserved across regulatory cycles
• How framework evolution is modelled without semantic drift

Semantic Infrastructure Stability Doctrine

CDI/CEDM evolution is governed by five stability doctrines:

1. Meaning Before Regulation

Semantic meaning (CDI layer) must remain stable across regulatory cycles.

2. Layer Isolation

Changes in one layer (CEDM, CDI, CMP, jurisdiction) do not implicitly modify other layers.

3. Explicit Version Boundaries

All structural changes are versioned. No silent modification is permitted.

4. Immutability of Frozen Artefacts

Once frozen, artefacts are never edited retroactively.

5. Reference Durability

Previously published versions remain referenceable indefinitely.

Semantic Infrastructure Components

The CDI/CEDM infrastructure consists of independently versioned components:

• CEDM - Canonical ESG Data Model (data structures and ontological architecture)
• CDI - Canonical Disclosure Intents (semantic concepts representing disclosure requirements)
• CMP - Canonical Mapping Packs (framework interpretation layers for GRI, ESRS, ISSB, etc.)
• Jurisdiction CMPs - Regulatory overlays for specific jurisdictions (EU, US, UK, etc.)
• Schemas - Machine-readable specifications (JSON-LD, RDF)
• APIs - Data exchange interfaces and protocols

Component Independence

Each component evolves independently:

• A change to a CMP does not alter CDI meaning
• A jurisdiction update does not redefine semantic concepts
• Schema refinements do not imply reinterpretation of disclosure requirements

Semantic Infrastructure Versioning

CDI/CEDM follows semantic versioning (MAJOR.MINOR.PATCH).

Major Version (X.0.0)

A major version introduces structural architectural change.

Examples:

• Redefinition of a core semantic boundary
• Incompatible restructuring of the CEDM data model
• Breaking schema modifications
• Fundamental change in CDI layering logic

Major versions are rare and deliberate.
Prior major versions remain published and referenceable.

Minor Version (X.Y.0)

A minor version introduces additive, backward-compatible evolution.

Examples:

• New CDIs added to the ontology
• New CMPs for additional frameworks (e.g., new ESRS standards)
• Additional jurisdiction mappings
• Extended schema properties
• Non-breaking API enhancements

Minor versions preserve semantic stability.

Patch Version (X.Y.Z)

A patch version corrects errors or clarifies documentation without altering meaning.

Examples:

• Typographical corrections
• Citation fixes
• Clarification of ambiguous explanatory text
• Non-semantic schema corrections
• Formatting improvements

Patch versions never alter semantic meaning.

Compatibility Classification

Each change is classified into one of the following categories:

• Non-breaking - No impact on prior semantic meaning or structure
• Additive - Expands scope without affecting prior definitions
• Clarificatory - Improves wording without changing meaning
• Breaking - Alters compatibility and requires major version increment

Compatibility classification is documented in changelogs.

Semantic Infrastructure Status Lifecycle

Each published CDI/CEDM component has a defined status:

Draft

• Subject to revision and refinement
• Intended for technical review
• Not recommended for production implementation
• Proposed CDIs or schema extensions under review

Active

• Stable within its version line
• Suitable for production implementation
• May receive minor or patch updates
• Production-ready CDI ontology and schemas

Frozen

• Immutable and permanently referenceable
• Will not be modified under any circumstances
• Historical CDI/CEDM versions preserved

Superseded

• Replaced by a newer version
• Retained for historical traceability
• Prior ontology versions

Deprecated

• Scheduled for phase-out with documented timeline
• Successor components identified
• CDIs being restructured or retired

Frozen artefacts are never retroactively edited.

Semantic Infrastructure Change Process

1. Proposal Submission

A written proposal must include:

• Description of the proposed change
• Rationale and use case justification
• Affected architectural layer(s) (CEDM, CDI, CMP, Schema)
• Compatibility impact assessment
• Migration considerations (if applicable)
• Alignment with existing ontology structure

2. Technical Assessment

Proposals are evaluated for:

• Alignment with governance principles
• Semantic stability impact
• Layer isolation compliance
• Compatibility classification
• Risk of regulatory overreach
• Ontological coherence

3. Decision

The Founding Steward may:

• Accept - Approve for implementation
• Accept with Modifications - Approve with specified revisions
• Request Revision - Return for further development
• Defer - Postpone pending additional information
• Reject - Decline with documented reasoning

4. Publication

Accepted changes are:

• Assigned a new version number
• Classified by compatibility type
• Documented in changelogs
• Published with explicit status
• Announced through standard channels

Semantic Infrastructure Backward Compatibility

CDI/CEDM prioritises backward compatibility.

Where compatibility cannot be preserved:

• A new major version is created
• Prior versions remain accessible
• Migration guidance is documented

No published version is invalidated.

Users are never forced to upgrade.

Handling External Framework Evolution

When external frameworks (GRI, ESRS, ISSB, TCFD, CSRD, etc.) update:

• A new CMP version is issued to reflect the updated framework
• Prior CMP versions remain frozen and referenceable
• Framework version numbers are explicitly referenced in CMP metadata
• CDI semantic meaning remains stable; only interpretation layers change
• Mapping documentation clearly identifies framework version applicability

Principle: Model, Don't Absorb

Framework evolution is modelled through interpretation layers (CMPs) - not absorbed into core semantic meaning.

This preserves:

• Stability across regulatory cycles
• Jurisdiction-agnostic applicability
• Clear separation between semantic concepts and framework-specific requirements

CDI/CEDM does not retroactively alter prior mappings to reflect new framework interpretations.

Semantic Infrastructure Deprecation Policy

CDI/CEDM elements may be deprecated but are not removed from frozen versions.

Deprecation:

• Is explicitly documented
• Includes rationale
• Identifies successor elements where applicable

Deprecated elements remain referenceable for historical consistency.

Schema and API Evolution

Machine-readable schemas and APIs evolve under the same versioning discipline.

Schema Evolution

• JSON-LD and RDF schemas evolve to support new use cases
• Schema changes maintain backward compatibility wherever possible
• Breaking schema changes trigger major version increments
• Schema version numbers correspond to architectural versioning

API Versioning

• API endpoints are versioned independently (e.g., /v1/, /v2/)
• Deprecated API versions remain operational during transition periods
• API documentation is version-specific

Ontological Stability

• CDI concepts are designed for long-term durability (10+ year horizon)
• New CDIs are added conservatively with rigorous justification
• Existing CDI definitions are rarely modified; new CDIs are preferred over redefinition

CDI/CEDM Governance

All semantic infrastructure evolution decisions operate under the Canonical ESG governance model.

Governance ensures:

• Architectural coherence across all semantic components
• Preservation of neutrality and independence from commercial influence
• Transparent change history with public changelogs and version documentation
• Non-authoritative positioning relative to regulatory frameworks
• Technical rigor in all changes and revisions

Governance does not assert interpretive authority over external standards or regulations.

See Governance for detailed governance framework.

Part 2: UPPS Product Passport Standards

Purpose

The Universal Product Passport Standards (UPPS) define disclosure requirements for product-level sustainability information.

UPPS is an independent standard unrelated to the CDI/CEDM semantic infrastructure.

This section defines:

• How UPPS standards evolve
• How UPPS components are versioned
• How stakeholder feedback shapes standard development
• How regulatory alignment is maintained

UPPS Standards Components

UPPS consists of independently versioned standards:

• UPPS Foundation - Core principles, scope, and governance framework
• UPPS 101 - General Product Disclosures (baseline requirements)
• UPPS 201 - Environmental Product Disclosures
• UPPS 301 - Circularity Product Disclosures
• UPPS 401 - Supply Chain and Traceability Disclosures
• UPPS 501 - Social and Ethical Product Disclosures
• Implementation Guidance - Sector-specific guidance and worked examples
• Technical Specifications - Data quality, assurance, and verification requirements

UPPS Versioning Model

UPPS follows semantic versioning (MAJOR.MINOR.PATCH).

Major Version (X.0.0)

A major version introduces substantive requirement modifications.

Examples:

• Substantive changes to disclosure requirements
• Redefinition of mandatory vs. optional disclosures
• Changes to calculation methodologies that affect comparability
• Restructuring of standard organization or scope

Major versions are rare and deliberate.
Prior major versions remain published and referenceable.
Transition periods (12-24 months) are provided for major revisions.

Minor Version (X.Y.0)

A minor version introduces additive, backward-compatible evolution.

Examples:

• New optional disclosure requirements
• Additional guidance or clarifications
• Expanded sector-specific guidance
• New worked examples or case studies
• Enhanced implementation resources

Minor versions do not impose new mandatory requirements.

Patch Version (X.Y.Z)

A patch version corrects errors or clarifies documentation.

Examples:

• Typographical corrections
• Citation fixes
• Clarification of ambiguous text
• Formatting improvements

Patch versions never alter compliance requirements.

UPPS Status Lifecycle

Each published UPPS standard has a defined status:

Draft

• Subject to revision and refinement
• Intended for stakeholder review and public consultation
• Not recommended for implementation
• Standards in public consultation phase

Active

• Stable within its version line
• Suitable for implementation
• May receive minor or patch updates
• Published standards available for implementation

Frozen

• Immutable and permanently referenceable
• Will not be modified
• Superseded standard versions retained for reference

Superseded

• Replaced by a newer version
• Retained for historical traceability
• Organizations may continue using during transition periods

Deprecated

• Scheduled for phase-out with documented timeline
• Successor standards identified
• Migration guidance provided

UPPS Change Process

1. Proposal Submission

A written proposal must include:

• Description of proposed requirement modification
• Rationale (regulatory alignment, stakeholder feedback, implementation experience)
• Affected standard(s) and disclosure section(s)
• Impact on existing implementations
• Transition timeline and migration guidance
• Stakeholder consultation summary

2. Technical Assessment

Proposals are evaluated for:

• Technical feasibility and implementability
• Alignment with international best practices (ISO, GRI, ESRS)
• Stakeholder value and materiality
• Reporting burden implications
• Data availability and quality considerations
• Verification and assurance feasibility

3. Public Consultation

For substantive UPPS changes:

• Minimum 60-day public consultation period
• Consultation materials published (draft text, rationale, impact assessment)
• Stakeholder comments documented and addressed
• Revision notes published with comment resolution

4. Decision

The Founding Steward may:

• Accept - Approve for implementation
• Accept with Modifications - Approve with specified revisions
• Request Revision - Return for further development
• Defer - Postpone pending additional stakeholder input
• Reject - Decline with documented reasoning

5. Publication

Accepted changes are:

• Assigned a new version number
• Classified by compatibility type
• Documented in detailed changelogs
• Published with explicit status
• Accompanied by migration guidance (for breaking changes)
• Announced through standard channels

UPPS Backward Compatibility

UPPS prioritises backward compatibility.

Where compatibility cannot be preserved:

• A new major version is created
• Prior versions remain accessible
• Migration guidance is documented
• Transition periods (12-24 months) are provided

No published version is invalidated.

Organizations are never forced to upgrade.

Handling Regulatory Evolution

When regulations (EU DPP, ESPR, CSRD, etc.) or international standards evolve:

• UPPS standards are reviewed for alignment requirements
• Minor revisions may add guidance on regulatory compliance
• Major regulatory shifts may trigger UPPS standard revisions
• Regulatory alignment is documented in implementation guidance
• UPPS requirements remain independent; regulatory compliance is mapped, not absorbed
• Sector-specific guidance may be updated to reflect new regulations

Principle: Map, Don't Absorb

Regulatory requirements are mapped to UPPS disclosures through implementation guidance - not absorbed into baseline requirements.

This preserves:

• Global applicability across jurisdictions
• Stability for organizations in multiple markets
• Clear separation between universal standards and local compliance

Stakeholder-Driven Evolution

• UPPS standards evolve based on implementation experience and stakeholder feedback
• Annual review cycles assess standard relevance and effectiveness
• Pilot implementations inform practical refinements
• Industry working groups may propose sector-specific guidance

Assurance and Verification Evolution

• Data quality requirements and verification protocols evolve as assurance practices mature
• Assurance guidance is versioned independently from disclosure requirements
• Auditor training materials are updated to reflect standard changes

Sector-Specific Guidance

• Sector guidance documents evolve independently from core standards
• New sectors may be added without modifying baseline requirements
• Sector guidance versions are tied to specific UPPS standard versions

UPPS Governance

All UPPS evolution decisions operate under the Canonical ESG governance model.

Governance ensures:

• Stakeholder engagement through mandatory public consultation
• Technical rigor in all requirement changes
• Transparent change history with public changelogs
• Independence from commercial influence
• Regulatory alignment without compromising global applicability

See Governance for detailed governance framework.

Summary

Canonical ESG maintains two independent and unrelated systems:

CDI/CEDM Semantic Infrastructure

• For organization-level sustainability reporting standards (GRI, ESRS, ISSB, TCFD, CSRD)
• Emphasizes long-term ontological stability (10+ year horizon)
• Evolves through additive expansion
• Maintains strict backward compatibility
• Models framework evolution through interpretation layers (CMPs)
• Serves as durable foundation beneath evolving reporting regimes

UPPS Product Passport Standards

• For product-level disclosure requirements
• Evolves based on stakeholder feedback and regulatory developments
• Balances stability with responsiveness to emerging requirements
• Maintains backward compatibility with 12-24 month transition periods
• Maps regulatory requirements without absorbing them into baseline standards
• Provides actionable, implementable standards for product transparency

These systems are completely separate and serve different purposes.