Architecture

1. Architectural Intent

The Canonical Disclosure Intent (CDI) architecture defines how disclosure meaning is represented, versioned, and reused independently of reporting frameworks.

The CDI architecture:

• bridges canonical data (CERM) and framework-specific interpretation (CMP),
• enables reuse of disclosure meaning across standards,
• preserves traceability from disclosed information to canonical assertions,
• supports controlled evolution as disclosure expectations change.

CDI does not define reporting workflows, submission formats, regulatory scope, or compliance logic.

2. Position Within Canonical ESG

CDI occupies the semantic layer between:

• canonical data assertions (CERM), and
• framework interpretation (CMP).

CDI does not replace data modelling or reporting standards.

It provides a stable semantic interface between them.

This separation ensures that:

• data truth remains independent of disclosure structure,
• disclosure meaning remains independent of regulatory obligation,
• framework interpretation remains independent of semantic definition.

3. Core Architectural Components

The CDI architecture consists of the following components:

1. Disclosure Intent
2. Intent Dependencies
3. Applicability Declarations
4. Fulfilment Contracts
5. Intent Identifiers and Versioning

Each component has a single responsibility and interacts through explicitly defined relationships.

4. Disclosure Intent

4.1 Definition

A Disclosure Intent represents a single, clearly defined disclosure concept that an organisation may communicate externally.

Examples include:

• Gross Scope 1 greenhouse gas emissions
• Existence of a climate transition plan
• Progress against emissions reduction targets

A Disclosure Intent is a semantic construct.
It is not a report section, template element, or regulatory requirement.

4.2 Characteristics

A Disclosure Intent:

• has a stable, globally unique identifier,
• has a precise semantic definition,
• is independent of reporting frameworks,
• may reference one or more canonical elements,
• may be quantitative, narrative, or hybrid.

Disclosure Intents define meaning only.
They do not encode format, obligation, or presentation structure.

5. Intent Dependencies

5.1 Purpose

Intent Dependencies declare the canonical elements required to meaningfully fulfil a Disclosure Intent.

Dependencies may reference:

• metrics,
• targets,
• trajectories,
• assertions,
• related intents,
• supporting narrative components.

5.2 Characteristics

Dependencies:

• are declarative rather than procedural,
• do not perform calculations,
• do not enforce completeness,
• do not determine adequacy.

They exist to ensure traceability between disclosure meaning and underlying canonical elements.

6. Applicability Declarations

6.1 Purpose

Applicability Declarations describe the contextual conditions under which a Disclosure Intent is semantically relevant.

They may declare:

• boundary relevance (e.g., organisational, value chain),
• temporal characteristics (historical, current, forward-looking),
• structural expectations (standalone vs contextual disclosure).

6.2 Non-Enforcement

Applicability declarations:

• do not determine whether disclosure is required,
• do not encode materiality logic,
• do not impose jurisdictional scope.

They clarify semantic context without asserting regulatory obligation.

7. Fulfilment Contracts

7.1 Purpose

A Fulfilment Contract defines the structural conditions under which a Disclosure Intent may be considered populated within a system.

It specifies:

• required canonical element types,
• acceptable assertion forms,
• optional supporting components.

7.2 Characteristics

Fulfilment Contracts:

• do not assess correctness,
• do not assess completeness,
• do not evaluate quality,
• do not imply compliance,
• do not imply assurance.

They define structural sufficiency for representing an intent — not regulatory sufficiency.

This distinction preserves separation between semantic modelling and compliance judgement.

8. Identifiers and Versioning

8.1 Stable Identification

Each Disclosure Intent has:

• a stable identifier,
• a versioned definition,
• a human-readable name and description.

Identifiers remain stable unless semantic meaning changes.

8.2 Version Evolution

Changes follow explicit rules:

• Editorial clarification does not change identifiers.
• Semantic modification requires a version increment.
• Deprecated intents remain referenceable.

Historical versions are preserved to support audit continuity and longitudinal analysis.

9. Interaction with Canonical Mapping Packs (CMP)

CDI does not contain:

• framework clause references,
• regulatory citations,
• jurisdictional applicability rules,
• compliance determinations.

Framework interpretation is handled exclusively through Canonical Mapping Packs (CMPs).

CMPs:

• reference CDI identifiers,
• document interpretation decisions,
• evolve independently of CDI.

This preserves neutrality and prevents semantic entanglement with regulatory change cycles.

10. Extensibility

The CDI architecture supports extension through:

• new disclosure intents,
• sector-specific intent collections,
• provisional or experimental intents.

Extensions must:

• not redefine existing intents,
• adhere to CDI design principles,
• be clearly distinguished from core taxonomy elements.

Extensibility shall not compromise semantic stability.

11. Architectural Non-Goals

The CDI architecture does not:

• automate disclosure decisions,
• replace professional judgement,
• encode regulatory logic,
• prescribe implementation technologies,
• validate compliance outcomes.

Its role is semantic clarity, structural consistency, and reuse.

12. Summary

The CDI architecture establishes a stable semantic layer between canonical data and framework interpretation.

By isolating disclosure meaning from regulatory obligation and presentation structure, CDI enables durable reuse, structured traceability, and resilience to evolving reporting regimes.

Version: v1.0.0