Back to CEDM OverviewImplementation Guide

Implementing CEDM in Your Organization

A comprehensive guide to integrating the Canonical ESG Data Model into your sustainability reporting infrastructure.

This guide covers database architecture, CDI integration, CMP mapping strategies, and migration pathways for organizations transitioning from existing ESG data systems.

Implementation Approach

CEDM implementation follows a layered architecture approach where semantic infrastructure (CDI), framework interpretation (CMP), and presentation logic (SSS) are implemented as distinct, loosely-coupled layers.

1

CDI Layer

Implement canonical semantic structures for sustainability data storage and modeling.

2

CMP Layer

Map framework requirements to CDIs using versioned interpretation packs.

3

SSS Layer

Generate framework-compliant reports using structured presentation templates.

Layer 1: CDI Implementation

Database Architecture

CDI implementation requires a semantic data layer that stores sustainability metrics, targets, trajectories, and evidence using canonical structures independent of any specific reporting framework.

Core Database Tables

cdi_metrics

Stores quantitative sustainability metrics mapped to CDI identifiers.

id: UUID (PK)
cdi_id: VARCHAR (e.g., CDI-CLIM-01)
value: DECIMAL
unit: VARCHAR
reporting_period: DATE_RANGE
scope: JSONB
methodology: TEXT
version: VARCHAR
cdi_targets

Stores sustainability targets and commitments.

id: UUID (PK)
cdi_id: VARCHAR
target_value: DECIMAL
baseline_value: DECIMAL
baseline_year: INTEGER
target_year: INTEGER
status: ENUM
scope: JSONB
cdi_evidence

Links metrics to supporting evidence and data lineage.

id: UUID (PK)
metric_id: UUID (FK)
evidence_type: ENUM
source_system: VARCHAR
document_uri: TEXT
calculation_logic: TEXT
audit_trail: JSONB
verified: BOOLEAN
cdi_metadata

Stores CDI definitions and versioning information.

cdi_id: VARCHAR (PK)
domain: VARCHAR
name: TEXT
definition: TEXT
version: VARCHAR
status: ENUM
schema: JSONB
deprecated_date: DATE

Implementation Note

Use JSONB columns for scope, methodology, and audit trail fields to accommodate flexible, evolving data structures without schema migrations. This enables forward compatibility as CDI schemas evolve.

CDI Integration Patterns

Pattern 1: Direct CDI Storage

Store all sustainability data directly using CDI identifiers as primary keys. Best for greenfield implementations or complete data architecture rewrites.

INSERT INTO cdi_metrics (cdi_id, value, unit, reporting_period)
VALUES ('CDI-CLIM-01', 125000.50, 'tCO2e', '[2024-01-01, 2024-12-31]');

Pattern 2: CDI Mapping Layer

Maintain existing data structures and create a mapping table that links legacy fields to CDI identifiers. Best for incremental adoption with existing systems.

CREATE TABLE cdi_mapping (
  legacy_table VARCHAR,
  legacy_column VARCHAR,
  cdi_id VARCHAR,
  transformation_logic TEXT
);

Pattern 3: Hybrid Approach

Store new data using CDI structures while maintaining legacy data in existing tables. Use views or ETL processes to present unified CDI-compliant interface.

CREATE VIEW cdi_unified AS
SELECT cdi_id, value, unit FROM cdi_metrics
UNION ALL
SELECT mapped_cdi_id, legacy_value, legacy_unit FROM legacy_emissions;

Layer 2: CMP Implementation

Framework Mapping Architecture

CMPs (Canonical Mapping Packs) establish explicit, versioned mappings between CDIs and framework-specific disclosure requirements. This layer enables multi-framework reporting without data duplication.

CMP Database Tables

cmp_packs

Stores CMP pack metadata and versioning.

id: VARCHAR (e.g., CMP-PACK-GRI)
framework_name: VARCHAR
jurisdiction: VARCHAR
version: VARCHAR
status: ENUM (active, frozen)
authority_note: TEXT
published_date: DATE
frozen_date: DATE
cmp_mappings

Stores individual framework-to-CDI mappings.

id: VARCHAR (e.g., CMP-GRI-305-1)
pack_id: VARCHAR (FK)
framework_reference: VARCHAR
mapped_cdi: VARCHAR
disclosure_summary: TEXT
interpretive_rationale: TEXT
scope_conditions: TEXT
version: VARCHAR

CMP Loading Strategy

Load CMP packs as JSON configuration files that are versioned and frozen. Do not store CMP mappings in mutable database tables—treat them as immutable reference data.

// Load CMP pack from JSON
const gri_cmp = await loadCmpPack('CMP-PACK-GRI', '1.0');

// Query mappings
const scope1_mapping = gri_cmp.mappings.find(
  m => m.frameworkReference === 'GRI 305-1'
);

Multi-Framework Reporting Query Pattern

-- Generate GRI 305-1 disclosure from CDI data
SELECT
  cm.framework_reference AS disclosure_id,
  cm.disclosure_summary,
  m.value,
  m.unit,
  m.reporting_period,
  m.methodology
FROM cmp_mappings cm
JOIN cdi_metrics m ON cm.mapped_cdi = m.cdi_id
WHERE cm.pack_id = 'CMP-PACK-GRI'
  AND cm.framework_reference = 'GRI 305-1'
  AND m.reporting_period @> '2024-01-01'::date;
-- Same CDI data, different framework (ESRS E1-6)
SELECT
  cm.framework_reference,
  m.value,
  m.unit
FROM cmp_mappings cm
JOIN cdi_metrics m ON cm.mapped_cdi = m.cdi_id
WHERE cm.pack_id = 'CMP-PACK-ESRS-E1'
  AND cm.framework_reference = 'ESRS E1-6';

Layer 3: SSS Implementation

Structured Sustainability Statements

SSS (Structured Sustainability Statements) provide presentation templates that transform CDI data into framework-compliant disclosure formats. This layer handles formatting, narrative generation, and regulatory presentation requirements.

SSS Template Structure

SSS templates are JSON-based presentation specifications that define how CDI data should be formatted, aggregated, and presented for specific framework disclosures.

{ "id": "SSS-GRI-305-1", "framework": "GRI", "disclosure": "305-1", "title": "Direct (Scope 1) GHG emissions", "presentation": { "format": "table", "columns": ["Gas Type", "Emissions (tCO2e)", "Methodology"], "data_source": { "cdi": "CDI-CLIM-01", "aggregation": "sum", "breakdown": ["gas_type"] } }, "narrative_template": "Total Scope 1 emissions for {{period}} were {{value}} {{unit}}, calculated using {{methodology}}." }

Report Generation Workflow

  1. 1Load SSS template for target framework disclosure
  2. 2Query CDI data using CMP mappings to identify required metrics
  3. 3Apply presentation logic (aggregation, formatting, unit conversion)
  4. 4Generate narrative using template placeholders and CDI metadata
  5. 5Render output in framework-compliant format (PDF, XBRL, JSON)

Migration Strategies for Existing Systems

Most organizations already have existing ESG data architectures—whether custom databases, vendor platforms, or spreadsheet-based systems. CEDM provides multiple migration pathways depending on your current state and strategic objectives.

Scenario 1: Framework-Specific Data Silos

You maintain separate databases/tables for GRI, ESRS, TCFD, etc.

Current State

  • Separate tables: gri_emissions, esrs_climate, tcfd_metrics
  • Data duplication across frameworks
  • Manual reconciliation required

Migration Path

  1. Step 1:Create cdi_metrics table alongside existing tables
  2. Step 2:Build ETL process to extract data from framework-specific tables and load into CDI structure
  3. Step 3:Implement CMP mappings to enable querying CDI data for each framework
  4. Step 4:Gradually shift data entry to CDI layer; deprecate framework-specific tables

Scenario 2: Vendor Platform Lock-In

You use a third-party ESG software platform with proprietary data structures

Current State

  • Data locked in vendor platform (e.g., Workiva, Diligent, Sphera)
  • Limited API access or export capabilities
  • Framework updates require vendor releases

Migration Path

  1. Step 1:Implement CDI layer as semantic overlay using vendor API or data exports
  2. Step 2:Build integration layer that maps vendor data model to CDI identifiers
  3. Step 3:Use CDI layer for new frameworks/jurisdictions not supported by vendor
  4. Step 4:Gradually migrate data entry to CDI-native system; phase out vendor platform

Scenario 3: Spreadsheet-Based Reporting

You manage ESG data primarily in Excel/Google Sheets

Current State

  • Data scattered across multiple spreadsheets
  • Manual data aggregation and reconciliation
  • Version control and audit trail challenges

Migration Path

  1. Step 1:Implement lightweight CDI database (PostgreSQL, MySQL, or cloud database)
  2. Step 2:Build CSV import tool to load spreadsheet data into CDI tables
  3. Step 3:Create web-based data entry forms mapped to CDI structure
  4. Step 4:Generate framework reports using CMP mappings and SSS templates

Scenario 4: ERP/Source System Integration

You extract ESG data from operational systems (ERP, HRIS, energy management)

Current State

  • Data sourced from SAP, Oracle, Workday, building management systems
  • Custom ETL processes for each framework
  • Transformation logic embedded in reporting scripts

Migration Path

  1. Step 1:Implement CDI layer as data warehouse/lake for sustainability metrics
  2. Step 2:Refactor ETL pipelines to load source data into CDI structure (not framework-specific tables)
  3. Step 3:Store calculation logic and transformations in cdi_evidence table
  4. Step 4:Use CMP layer to generate framework-specific views from canonical data

Implementation Checklist

Phase 1: Foundation (Months 1-3)

  • Design CDI database schema
  • Load CDI metadata (283 CDIs)
  • Implement core tables (metrics, targets, evidence)
  • Build data validation layer
  • Create API endpoints for CDI data access

Phase 2: Integration (Months 4-6)

  • Load CMP packs for target frameworks
  • Build ETL pipelines from source systems
  • Implement legacy data mapping layer
  • Migrate historical data to CDI structure
  • Validate data completeness and accuracy

Phase 3: Reporting (Months 7-9)

  • Implement SSS template engine
  • Build framework-specific report generators
  • Create audit trail and evidence linking
  • Test multi-framework reporting workflows
  • User acceptance testing with reporting team

Phase 4: Production (Months 10-12)

  • Deploy to production environment
  • Train users on CDI data entry workflows
  • Establish data governance procedures
  • Monitor system performance and data quality
  • Decommission legacy framework-specific systems

Technical Resources

Architecture Explorer

Browse all 283 CDIs, CMP mappings, and SSS templates with interactive documentation.

Explore →

CDI Registry

Complete CDI taxonomy with definitions, schemas, and domain classifications.

View Registry →

CMP Documentation

Framework mapping specifications for GRI, ESRS, ISSB, TCFD, CDP, and TNFD.

Read Docs →

Contribute

Join the community, propose new CDIs, or contribute CMP mappings for emerging frameworks.

Get Involved →

Questions About CEDM Implementation?

Canonical ESG maintains the CEDM standard and semantic infrastructure. For implementation questions, technical clarifications, or to contribute to the standard's evolution, reach out to the community.

Join the Community