Skip to main content

EU Sustainability Regulatory Architecture Integration - Introduction

Purpose​

This document defines the governed weekly process by which external EU sustainability regulatory developments are assessed for their architectural consequences in ZAYAZ.

The process deliberately separates:

  • regulatory intelligence — what changed externally; from
  • architecture integration — whether ZAYAZ should change because of it.

The objective is to prevent two opposite failure modes:

  1. under-reaction — material regulatory changes are observed but never propagated into forms, mappings, workflows, calculations, assurance, or implementation requirements; and
  2. over-reaction — draft proposals, consultations, commentary, or emerging technical material are prematurely encoded as production logic.

The process therefore treats regulatory change as a governed input into ZAYAZ architecture rather than as an automatic implementation trigger.

Weekly Operating Cycle​

Monday 07:00 — Regulatory Intelligence Intake​

The Monday brief identifies consequential developments across the monitored EU sustainability regimes.

The intelligence scan should:

  1. identify developments since the previous weekly cycle;
  2. distinguish binding law, adopted-but-not-effective acts, proposals, consultations, guidance, supervisory signals, technical taxonomies, implementation artefacts, and emerging signals;
  3. prioritise developments that may affect:
    • supplier forms;
    • taxonomy and ontology mappings;
    • compliance workflows;
    • reporting design;
    • calculation methods;
    • evidence requirements;
    • assurance;
    • submission formats;
    • product sustainability;
    • claims governance;
  4. explain what changed;
  5. explain why it matters;
  6. identify which ZAYAZ capabilities may be affected;
  7. identify items that deserve architecture review.

The Monday run is intentionally broad enough to capture meaningful change.

Tuesday — Architecture Integration​

The Tuesday integration cycle asks a different question:

Should anything discovered on Monday actually change ZAYAZ?

The integration cycle must be conservative.

A regulatory development does not create an architectural delta merely because it is new.

The Tuesday review should:

  1. read the latest Monday regulatory cohort and assign the ISO week tag, for example 2026-W38;
  2. re-check the authoritative primary sources;
  3. distinguish legal authority from guidance, technical support material, supervisory signals, consultation positions, and commentary;
  4. classify each development using the Regulatory Delta Classification;
  5. compare the development against the current canonical ZAYAZ architecture and relevant specifications;
  6. determine whether a genuine architectural delta exists;
  7. leave immaterial or premature items as WATCH or NO_ACTION;
  8. propagate material changes into the integration roadmap;
  9. identify affected canonical specifications requiring review;
  10. identify Hecate Needs where architecture is sufficiently determined to proceed toward implementation;
  11. record the weekly architectural delta in the evolution history;
  12. work on a branch only and never merge automatically to main.

Regulatory Scope

Core Regimes​

The weekly intelligence and architecture-integration cycle covers twelve core regimes.

1. CSRD / ESRS / ESRS-40a / Voluntary Standard​

Primary ZAYAZ concerns:

  • reporting scope;
  • materiality;
  • datapoints;
  • value-chain information;
  • supplier-request limitations;
  • disclosure architecture;
  • assurance;
  • implementation guidance;
  • digital tagging;
  • reporting-profile resolution;
  • historical version reproducibility.

2. Corporate Sustainability Due Diligence Directive — CSDDD​

Primary ZAYAZ concerns:

  • risk identification;
  • prioritisation;
  • evidence resolution;
  • supplier data requests;
  • prevention and mitigation;
  • remediation;
  • stakeholder engagement;
  • monitoring;
  • contractual measures;
  • due-diligence workflow provenance.

3. ESEF and ESRS XBRL / Digital Sustainability Reporting​

Primary ZAYAZ concerns:

  • XBRL taxonomy versions;
  • digital markup;
  • filing rules;
  • technical validation;
  • taxonomy mappings;
  • namespaces;
  • filing profiles;
  • machine-readable sustainability reporting.

4. EU Taxonomy Regulation and Delegated Acts​

Primary ZAYAZ concerns:

  • eligibility;
  • alignment;
  • technical screening criteria;
  • substantial contribution;
  • DNSH;
  • minimum safeguards;
  • turnover, CapEx and OpEx KPIs;
  • activity classification;
  • versioned Taxonomy criteria.

5. Sustainable Finance Disclosure Regulation — SFDR​

Primary ZAYAZ concerns:

  • financial-product categories;
  • principal adverse impacts;
  • sustainable investment evidence;
  • transition evidence;
  • Taxonomy alignment;
  • downstream data demand from investors and lenders.

6. Product Environmental Footprint / Organisation Environmental Footprint​

Includes:

  • PEF;
  • OEF;
  • PEFCR;
  • OEFSR;
  • Environmental Footprint methods;
  • EF datasets;
  • transition rules.

Primary ZAYAZ concerns:

  • lifecycle calculations;
  • dataset selection;
  • factor resolution;
  • impact assessment;
  • uncertainty;
  • methodology profiles;
  • provenance;
  • product footprinting.

7. Ecodesign for Sustainable Products Regulation / Digital Product Passport​

Primary ZAYAZ concerns:

  • product sustainability requirements;
  • Digital Product Passports;
  • durability;
  • repairability;
  • recycled content;
  • substances of concern;
  • environmental footprints;
  • product data exchange;
  • product-level compliance.

8. EU Deforestation Regulation — EUDR​

Primary ZAYAZ concerns:

  • commodity and product scope;
  • CN/HS classification;
  • geolocation;
  • legality;
  • traceability;
  • risk assessment;
  • due-diligence statements;
  • supplier evidence;
  • EU information-system integration.

9. Forced Labour Regulation​

Primary ZAYAZ concerns:

  • forced-labour evidence;
  • supply-chain risk;
  • product-level prohibition;
  • investigation support;
  • cross-regime use of CSDDD evidence;
  • remediation and market-access controls.

10. Green Claims / Empowering Consumers for the Green Transition​

Primary ZAYAZ concerns:

  • claim substantiation;
  • verification;
  • environmental-performance evidence;
  • consumer-facing communication;
  • claims approval;
  • traceability between claims and underlying calculations.

11. Carbon Border Adjustment Mechanism — CBAM​

Primary ZAYAZ concerns:

  • product and installation data;
  • embedded emissions;
  • supplier emissions evidence;
  • default values;
  • verification;
  • declarant workflows;
  • customs-linked reporting;
  • carbon-price adjustments.

12. EU Batteries Regulation​

Primary ZAYAZ concerns:

  • battery carbon footprint;
  • recycled content;
  • due diligence;
  • battery passport;
  • product identifiers;
  • supply-chain evidence;
  • lifecycle and circularity data.

Regulatory Domains

The twelve core regimes are organised into five primary domains.

Domain A — Corporate Disclosure​

Includes:

  • CSRD;
  • ESRS;
  • ESRS-40a;
  • Voluntary Standard;
  • ESEF sustainability reporting.

Primary architectural concerns:

  • disclosure concepts;
  • reporting profiles;
  • materiality;
  • taxonomy;
  • assurance;
  • digital filing;
  • historical reproducibility.

Domain B — Sustainable Finance​

Includes:

  • EU Taxonomy;
  • SFDR.

Primary architectural concerns:

  • KPI attribution;
  • financial-product classifications;
  • sustainable-investment evidence;
  • PAI data;
  • alignment logic;
  • downstream data demand.

Domain C — Supply-Chain Due Diligence​

Includes:

  • CSDDD;
  • EUDR;
  • Forced Labour Regulation;
  • relevant supplier-data aspects of CBAM.

Primary architectural concerns:

  • supply-chain graph;
  • entity resolution;
  • product traceability;
  • risk assessment;
  • evidence resolution;
  • supplier requests;
  • mitigation and remediation;
  • due-diligence submissions.

Domain D — Product Sustainability​

Includes:

  • ESPR;
  • Digital Product Passport;
  • PEF/OEF;
  • Batteries Regulation;
  • relevant CBAM product-emissions requirements.

Primary architectural concerns:

  • BOM and product graphs;
  • lifecycle data;
  • product footprints;
  • circularity;
  • product passports;
  • methodology profiles;
  • factor and dataset resolution.

Domain E — Claims and Market Communication​

Includes:

  • Green Claims;
  • Empowering Consumers for the Green Transition;
  • related substantiation and verification requirements.

Primary architectural concerns:

  • claims governance;
  • evidence lineage;
  • verification;
  • consumer-facing outputs;
  • prohibited or unsupported claims.

Regulatory Infrastructure Layer

In addition to the five substantive domains, ZAYAZ must monitor a cross-cutting regulatory infrastructure layer.

This includes:

  • XBRL taxonomies;
  • XML schemas;
  • JSON schemas;
  • controlled vocabularies;
  • classification code lists;
  • EU submission portals;
  • technical APIs;
  • due-diligence statement formats;
  • filing validation rules;
  • digital product-passport schemas;
  • taxonomy release packages;
  • implementation conformance suites;
  • regulatory data-exchange specifications.

A technical artefact may create a material ZAYAZ delta even where the underlying legislation has not changed.

Second-Tier Watchlist

The following regimes are monitored continuously but are elevated into the weekly core brief only when a material ZAYAZ consequence arises.

Chemicals and Materials​

  • REACH;
  • CLP;
  • substances-of-concern rules;
  • chemicals restrictions relevant to ESPR, DPP, Batteries, or product claims.

Packaging and Circularity​

  • Packaging and Packaging Waste Regulation — PPWR;
  • waste-framework developments;
  • recycled-content methodologies;
  • extended producer responsibility where relevant to ZAYAZ data models.

Product-Specific Ecodesign​

  • ESPR delegated acts;
  • product-group requirements;
  • repairability rules;
  • durability criteria;
  • product-specific DPP requirements.

Climate and Emissions​

  • EU ETS;
  • ETS2;
  • Methane Regulation;
  • EU Climate Law and target revisions;
  • sector-specific emissions methodologies.

Industrial and Environmental Regulation​

  • Industrial Emissions Directive;
  • environmental-permitting data;
  • pollution reporting;
  • relevant environmental data portals.

Raw Materials and Strategic Supply Chains​

  • Critical Raw Materials Act;
  • sourcing and resilience requirements;
  • strategic-material traceability.

Sector-Specific Sustainability Regulation​

Examples include:

  • financial services;
  • textiles;
  • chemicals;
  • electronics;
  • construction;
  • transport;
  • food and agriculture;
  • mining;
  • energy;
  • batteries;
  • automotive.

Public Reporting and Digital Taxonomy Infrastructure​

  • public country-by-country reporting taxonomy;
  • EU digital filing standards;
  • cross-regulatory taxonomy infrastructure;
  • machine-readable corporate reporting developments.

Regulatory Authority Classification

Every item in the weekly cohort must be assigned an authority state.

Recommended states:

  • BINDING_EFFECTIVE
  • ADOPTED_PENDING_EFFECTIVENESS
  • SCRUTINY_PENDING
  • LEGISLATIVE_PROPOSAL
  • TRILOGUE_OR_NEGOTIATION
  • CONSULTATION
  • OFFICIAL_GUIDANCE
  • SUPERVISORY_SIGNAL
  • TECHNICAL_TAXONOMY
  • TECHNICAL_IMPLEMENTATION_ARTEFACT
  • RESEARCH_OR_EMERGING_SIGNAL
  • WITHDRAWN_OR_SUPERSEDED

Authority state must be stored independently from architecture impact.

A high-impact proposal is still a proposal.

A low-impact binding amendment is still binding.

Regulatory Delta Classification

Each development should receive one or more delta classifications.

Core Delta Classes​

  • SCOPE_DELTA
  • THRESHOLD_DELTA
  • DEFINITION_DELTA
  • EFFECTIVE_DATE_DELTA
  • FORM_DELTA
  • DATAPOINT_DELTA
  • SUPPLIER_DATA_DELTA
  • EVIDENCE_DELTA
  • DUE_DILIGENCE_DELTA
  • WORKFLOW_DELTA
  • TAXONOMY_DELTA
  • ONTOLOGY_DELTA
  • CLASSIFICATION_DELTA
  • CALCULATION_DELTA
  • FACTOR_DATA_DELTA
  • METHODOLOGY_DELTA
  • UNCERTAINTY_DELTA
  • ASSURANCE_DELTA
  • VERIFICATION_DELTA
  • SUBMISSION_DELTA
  • API_DELTA
  • REPORTING_DELTA
  • CLAIMS_DELTA
  • PRODUCT_PASSPORT_DELTA
  • RIGHTS_DELTA
  • INTEROPERABILITY_DELTA
  • ENFORCEMENT_DELTA
  • PRODUCT_STRATEGY_DELTA

Non-Action States​

  • WATCH
  • NO_ACTION
  • AWAIT_AUTHORITY
  • AWAIT_TECHNICAL_SPEC
  • AWAIT_GUIDANCE
  • SUPERSEDED

Architecture Impact Assessment

Each Monday item should be assessed against the current canonical ZAYAZ architecture.

The Tuesday review asks:

  1. Does the development alter a legal obligation?
  2. Does it alter the meaning of a canonical sustainability concept?
  3. Does it alter the permissible or required evidence?
  4. Does it alter who may be asked for information?
  5. Does it alter a calculation or methodology?
  6. Does it alter a taxonomy or code mapping?
  7. Does it alter a reporting or submission format?
  8. Does it alter assurance or verification?
  9. Does it alter product-level compliance?
  10. Does it alter claims or communications?
  11. Does it alter effective-date logic?
  12. Does it create a cross-regime conflict or precedence rule?

If none apply materially, the item should normally remain WATCH or NO_ACTION.

ZAYAZ Capability Impact Map

Potential affected capabilities include, but are not limited to:

Pergamum Pulse​

Potential impacts:

  • regulatory-source ingestion;
  • lifecycle state;
  • effective dates;
  • legal hierarchy;
  • jurisdiction;
  • delegated and implementing acts;
  • technical artefacts;
  • source hashing;
  • provenance.

COSE​

Potential impacts:

  • compliance rules;
  • obligation resolution;
  • threshold logic;
  • jurisdictional applicability;
  • policy execution;
  • enforcement state.

FOGE / FFG​

Potential impacts:

  • supplier forms;
  • reporting questionnaires;
  • conditional fields;
  • evidence requests;
  • value-chain request ceilings;
  • due-diligence escalation questions.

RIF​

Potential impacts:

  • risk models;
  • supply-chain risk;
  • regulatory risk;
  • severity and likelihood;
  • escalation logic.

EKG / CIS​

Potential impacts:

  • canonical concepts;
  • framework mappings;
  • causal relationships;
  • cross-regime dependencies;
  • semantic equivalence and non-equivalence.

MICE and Computation​

Potential impacts:

  • calculation methods;
  • methodology profiles;
  • datasets;
  • factors;
  • uncertainty;
  • allocation;
  • validation.

DSAIL / Regulatory Submission​

Potential impacts:

  • external schemas;
  • APIs;
  • filing packages;
  • regulatory portals;
  • submission validation.

AAE / Assurance​

Potential impacts:

  • assurance tests;
  • evidence sufficiency;
  • verification requirements;
  • audit lineage.

ZARA / AI Intelligence Layer​

Potential impacts:

  • authoritative legal explanation;
  • source-grounded answers;
  • applicability reasoning;
  • cross-regime interpretation;
  • compliance recommendations.

Cross-Regime Collision Detection

A core function of the Tuesday review is to detect interactions where more than one regime governs the same underlying object, activity, supplier, product, metric, or evidence item.

Examples:

  • CSDDD due diligence vs EUDR commodity-specific due diligence;
  • CSRD supplier information requests vs CSDDD evidence requests;
  • PEF product-footprint methodology vs ESPR product-specific requirements;
  • EU Taxonomy environmental criteria vs ESRS disclosure requirements;
  • SFDR downstream data demand vs CSRD corporate disclosures;
  • Batteries Regulation carbon-footprint rules vs PEF methodology;
  • Green Claims substantiation vs PEF environmental-performance evidence;
  • CBAM embedded emissions vs corporate Scope 1/2/3 emissions accounting.

The review must determine whether the relationship is:

  • GENERAL_RULE
  • SPECIFIC_RULE
  • SUPPLEMENTARY_RULE
  • PRECEDENCE_RULE
  • SHARED_EVIDENCE
  • SHARED_CALCULATION
  • NON_EQUIVALENT_CONCEPT
  • CONFLICT
  • DUPLICATIVE_REQUEST_RISK

The existence of two requirements affecting similar information must not automatically cause duplicate data collection.

Canonical-Spec Review

Where a genuine architectural delta exists, the Tuesday process should identify which canonical ZAYAZ artefacts require review.

Examples include:

  • constitutions;
  • domain architecture;
  • ontology specifications;
  • SSSR;
  • USO;
  • ZAR;
  • regulatory schemas;
  • FOGE specifications;
  • supplier evidence contracts;
  • MICE method specifications;
  • dataset registries;
  • taxonomy registries;
  • reporting-profile specifications;
  • assurance specifications;
  • API contracts;
  • Digital Product Passport specifications;
  • PEF/LCA architecture;
  • Hecate Needs.

The integration cycle should identify affected specifications before modifying them.

A weekly regulatory development should never casually rewrite multiple canonical documents merely because an external proposal changed.

Hecate Need Gate

Where architecture is sufficiently determined, the integration cycle should propose the next Hecate Need.

A Hecate Need is appropriate when:

  1. the regulatory requirement or technical requirement is sufficiently authoritative;
  2. the architecture decision is stable enough to implement;
  3. affected canonical specifications are understood;
  4. acceptance criteria can be stated;
  5. provenance and authority can be linked;
  6. implementation would not outrun unresolved governance.

The Hecate Need should include:

  • regulatory trigger;
  • authority state;
  • affected regime;
  • affected ZAYAZ capability;
  • architectural delta;
  • implementation objective;
  • acceptance criteria;
  • validation requirements;
  • source references;
  • effective-date requirements;
  • rollback or supersession conditions where applicable.

Weekly Cohort Model

Each Monday/Tuesday cycle should be assigned an ISO week cohort.

Example:

2026-W38

The cohort acts as a stable grouping for:

  • intelligence items;
  • source references;
  • regulatory authority states;
  • delta classifications;
  • architecture decisions;
  • WATCH decisions;
  • canonical-spec impacts;
  • Hecate Needs;
  • validation requirements.

Weekly Architecture Integration Record

Each weekly cohort should record:

Executive Delta Summary​

A concise statement:

What changed in ZAYAZ this week because of external regulatory developments?

Possible answer:

No production architecture changes. Revised ESRS cleared parliamentary scrutiny but remained pending OJ publication. Migration preparation advanced; activation remained blocked.

or:

EUDR implementing guidance introduced a new mandatory geolocation validation rule. The supplier evidence contract and EUDR submission validator were updated; Hecate Need HN-xxxx was created.

Item-Level Record​

Recommended fields:

  • cohort_id
  • regime
  • domain
  • source_id
  • source_authority
  • authority_state
  • publication_date
  • effective_date
  • delta_class
  • materiality
  • affected_capabilities
  • cross_regime_links
  • architecture_decision
  • canonical_specs_to_review
  • hecate_need
  • implementation_status
  • validation_status
  • notes

Evolution History

The integration process creates a permanent research- and regulation-derived architectural changelog.

Illustrative entries:

2026-W38 — Revised ESRS cleared Parliament. Regulatory lifecycle expanded to distinguish scrutiny-cleared from legally effective. No production activation pending OJ publication.

2026-W40 — Final EU Taxonomy technical advice changed OpEx treatment. Taxonomy KPI methodology profile updated; core activity classification unchanged.

2026-W44 — EFRAG revised-ESRS XBRL taxonomy published. Sustainability taxonomy mappings staged; mandatory ESEF filing remained inactive.

2027-W03 — New ESPR delegated act introduced product-group DPP fields. Product Passport schema and supplier evidence contract reviewed.

This becomes the architecture's regulatory evolution history.

Governance Rules

1. Branch-Only Operation​

All integration-document changes and proposed architecture updates must be made on a dedicated branch.

Never merge automatically to main.

2. No Automatic Promotion from Intelligence to Production​

A development being included in the Monday brief does not authorise a production change.

The Tuesday architecture review is the governance gate.

3. Primary Sources First​

Wherever possible, rely on:

  • EUR-Lex;
  • European Commission;
  • European Parliament;
  • Council of the European Union;
  • ESMA;
  • EFRAG;
  • EBA;
  • EIOPA;
  • JRC;
  • competent EU agencies;
  • official technical repositories.

Secondary sources may support discovery but must not silently replace normative authority.

4. Authority Must Be Explicit​

Every change must retain the authority state of its source.

A consultation must never be represented as binding law.

An adopted act pending entry into force must never be represented as currently applicable.

5. Effective-Date Safety​

Production logic must resolve:

  • publication date;
  • adoption date;
  • entry into force;
  • application date;
  • transitional periods;
  • reporting-period applicability;
  • early-adoption rights;
  • grandfathering;
  • supersession.

6. Historical Reproducibility​

A regulatory update must not destroy the ability to reproduce:

  • previous reports;
  • previous calculations;
  • previous assurance decisions;
  • previous supplier requests;
  • previous regulatory submissions.

7. Conservative Canonical Change​

External change should modify canonical architecture only where a genuine architectural delta exists.

Where uncertainty remains, prefer:

  • configuration;
  • versioning;
  • policy profiles;
  • staging;
  • WATCH state.

8. Cross-Regime Reuse Before Duplicate Collection​

Where multiple regimes require overlapping evidence, ZAYAZ should prefer reusable canonical evidence objects rather than duplicate supplier requests.

9. Human-Governed Architecture​

The integration cycle may propose:

  • architecture changes;
  • canonical-spec reviews;
  • Hecate Needs;
  • implementation work.

It must not automatically merge or activate material production changes.

Operating Flow

EU / EEA REGULATORY ENVIRONMENT
             ↓
 Monday regulatory intelligence
             ↓
          2026-Wxx
             ↓
 Tuesday architecture review
             ↓
      Is there a real delta?
          ↙         ↘
        NO           YES
        ↓             ↓
   WATCH / NO_ACTION  Delta classification
                      ↓
              Cross-regime analysis
                      ↓
             Canonical-spec impact
                      ↓
                Hecate Need
                      ↓
               Implementation
                      ↓
                 Validation
                      ↓
                   ZAYAZ

Design Principle

The purpose of the process is not to make ZAYAZ react faster to every regulatory publication.

The purpose is to make ZAYAZ change correctly.

The governing principle is:

Regulatory intelligence discovers change. Architecture integration determines whether that change belongs in ZAYAZ.

Over time, this process should create a traceable chain from:

external authority → regulatory interpretation → architecture decision → implementation → validation → operational compliance

That chain is itself a strategic ZAYAZ asset.

GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ