Regulatory Infrastructure
Governed by the integration rule document. This layer owns cross-domain authority/applicability integration, semantic/taxonomy bindings, evidence rights and transmission adapters. It does not replace the canonical Pergamum Pulse, Constitutional Runtime, SSSR/USO/ZAR or domain specifications.
2026-W38 authority register
| ID | Finding | Authority / disposition |
|---|---|---|
| RI-01 | ESMA continues to state that sustainability information need not be digitally marked up until the relevant marking rules are adopted through the ESEF delegated regulation. | LEGAL/TECHNICAL filing status; mandatory sustainability markup remains inactive. |
| RI-02 | EFRAG revised-ESRS datapoint mappings remain non-authoritative supporting material; final revised taxonomy resources remain a technical-release watch. | TECHNICAL_RESOURCE; AWAIT_TECHNICAL_SPEC. |
| RI-03 | Revised ESRS parliamentary scrutiny evidence exists, but legal activation remains separate from taxonomy registration or Runtime activation. | AWAIT_AUTHORITY. |
| RI-04 | EUDR, DPP, CBAM and future CSDDD reporting can introduce non-XBRL schema/API channels requiring independently versioned adapters. | WATCH / channel-specific AWAIT_TECHNICAL_SPEC. |
Canonical architecture reconciliation
XBRL activation architecture already exists
Pergamum Pulse — XBRL Taxonomy Runtime Activation already establishes the required constitutional distinction among:
- taxonomy custody/registration;
- projection release;
- Runtime activation authority;
- Runtime resolution;
- semantic-mapping authority;
- legal/methodological authority;
- FOGE definition publication;
- customer display;
- XBRL validation/tagging;
- regulatory filing;
- external publication;
- redistribution.
It explicitly prohibits a global mutable active flag and requires activation to be scoped by Runtime Context and temporal authority.
This is almost exactly the safety boundary the WSI seed proposed. Therefore:
Decision: do not build another WSI XBRL/taxonomy activation subsystem. Revised ESRS/ESEF integration must reuse the canonical PP release/activation chain.
Disposition: generic activation architecture NO_ACTION; revised taxonomy package AWAIT_TECHNICAL_SPEC.
Lifecycle architecture already exists
The canonical Pergamum Pulse Universal Lifecycle Registry already defines first-class lifecycle states and requires transition records to preserve source state, target state, reason, authority, effective time, transaction time, conditions and provenance. It also states that workflow, extraction, review, conflict, adoption, projection and activation states remain separate dimensions.
The WSI legal states such as SCRUTINY_CLEARED_PENDING_OJ are therefore specialised regulatory authority/applicability states, not replacements for canonical lifecycle_status.
Decision: unregistered candidate: regulatory authority/applicability profile must be reframed as a regulatory authority/applicability profile bound to canonical lifecycle/Runtime Context, not a new lifecycle registry.
Rights architecture already exists
The Pergamum Pulse rights vocabulary already provides governed processing operations and permission states: permitted, permitted-with-conditions, restricted, prohibited, unresolved, not-applicable, expired and revoked. It explicitly states that an omitted permission is not granted.
Regulatory evidence reuse, passport exposure, RAG/public generation and claim substantiation should compose with this canonical Rights Gate.
Decision: no WSI-specific evidence-permission vocabulary.
Required infrastructure extensions
RI-A1 — Regulatory authority/applicability profile
A bounded profile should capture regulatory instrument/provision identity, source authority, procedure events, publication/OJ evidence, national transposition where relevant, effective/applicable periods, entity/product scope and reporting-period applicability. It should bind to canonical Pergamum Pulse lifecycle, Temporal Profile, Runtime Context and provenance.
This may already be partly covered by Pergamum Pulse change-candidate/projection and constitutional registries. Full duplicate check is required before a Hecate Need.
Disposition: CANONICAL_REVIEW_REQUIRED; unregistered candidate: regulatory authority/applicability profile REFRAME.
RI-A2 — Semantic manifestation mappings
Canonical sustainability concepts should map to framework manifestations and taxonomy concepts with relation type, boundary/method/unit conditions, source version, authority and review state. Similar labels do not establish equivalence.
Disposition: CANONICAL_REVIEW_REQUIRED; inspect existing PP semantic-mapping contracts before extending.
RI-A3 — Non-XBRL regulatory submission adapters
Where EUDR, DPP, CBAM or future CSDDD channels expose schemas/APIs, adapters should preserve schema/code-list version, payload digest, authorisation context, idempotency/correlation, submission state, acknowledgement/rejection and correction history.
Do not equate HTTP success with legal acceptance.
Disposition: AWAIT_TECHNICAL_SPEC; unregistered candidate: non-XBRL regulatory submission/passport adapters reframed to non-XBRL/channel-specific adapters only.
Acceptance criteria
| Scenario | Expected behavior |
|---|---|
| Revised ESRS taxonomy package registers successfully | Registration creates no legal, filing, publication or semantic-mapping authority. |
| Parliament non-objection exists without resolved OJ applicability | Record event; block legal activation. |
| XBRL tag changes while semantic concept remains stable | Preserve canonical concept and historical report replay. |
| Two mappings have similar labels but different boundaries | Record conditional/non-equivalence; do not auto-reuse values. |
| Evidence is accessible but permission state is unresolved | Do not treat it as permitted for public generation/passport/claim use. |
| Non-XBRL submission times out after possible receipt | Reconcile using correlation/idempotency before retrying. |
| A regulatory authority profile changes | Preserve previous transaction-time knowledge and effective-time applicability for replay. |
Cross-domain ownership
| Domain | Uses common infrastructure | Retains ownership |
|---|---|---|
| Corporate Disclosure | authority/applicability, semantic mapping, XBRL activation | materiality, reporting profile, disclosure perimeter |
| Sustainable Finance | versioned criteria/evidence projections | alignment, KPI attribution, product category |
| Supply-Chain Due Diligence | identity, evidence rights, submission receipts | risk process, request entitlement, regime-specific sufficiency |
| Product Sustainability | dataset rights, identifiers, adapters | method selection, category rules, footprint/passport scope |
| Claims & Market Communication | evidence snapshots, rights, publication events | exact wording, jurisdiction, publication eligibility |
Canonical specs reviewed / follow-up
Reviewed:
- Pergamum Pulse XBRL Taxonomy Runtime Activation;
- Pergamum Pulse universal lifecycle registry;
- Pergamum Pulse rights vocabulary;
- Constitutional runtime/registry search results confirming temporal applicability and authority separation.
Follow-up:
- Pergamum Pulse Change Candidate and Projection Specification;
- semantic mapping/conflict specifications;
- regulatory applicability resolver, if already defined;
- EFRAG taxonomy release inventory;
- EUDR/DPP/CBAM concrete API/schema packages.
Weekly cohort history
| Cohort | Intelligence retained | Integration decision |
|---|---|---|
| 2026-W36 | Separate financial/sustainability ESEF tracks; draft mappings | Candidate semantic/filing separation. |
| 2026-W37 | Concept-centric interoperability | WATCH for public technical outputs. |
| 2026-W38 | ESRS procedure/OJ distinction; broader API/schema scope | Integrated 2026-09-15: canonical PP XBRL activation, lifecycle and rights already satisfy most proposed infrastructure architecture. Reframe work toward regulatory applicability profiles and channel-specific adapters; avoid duplicate registries. |
What changed in ZAYAZ? The integration cycle eliminated duplicate infrastructure proposals. Existing Pergamum Pulse contracts already provide the core activation, lifecycle and rights model. The remaining work is narrower: bind regulatory authority/applicability to those canonical mechanisms and add specific submission adapters only when authoritative technical packages exist.
2026-W39 Architecture Integration
New technical event — EFRAG revised-ESRS XBRL taxonomy
EFRAG's 17 September 2026 publication resolves the previous observation that the revised taxonomy had not yet been formally released.
This should trigger an observation → capture-candidate transition, not Runtime activation.
The repository already contains the relevant machinery:
- publisher-package source resolution and capture;
- rights gating before capture/registration;
- immutable XBRL taxonomy release identity;
- release observation records;
- release-diff workflow;
- semantic mapping/crosswalk governance;
- separate PP release and Runtime activation;
- distinct legal, filing, publication and redistribution authority.
Required W39 infrastructure action
- Preserve the prior “taxonomy not yet published” observation as historical evidence.
- Add the official 17 September EFRAG release as a new source object/capture candidate.
- Capture the exact package independently from the 2024 release.
- Register the new release only after rights and package validation.
- Diff it against the 2024 EFRAG taxonomy and the August 2026 datapoint resource.
- Route semantic changes through PP-MAP/semantic review.
- Keep legal authority, Runtime activation and filing authority false/unresolved unless separately granted.
Disposition: TAXONOMY_CHANGE, INTEROPERABILITY_DELTA; existing architecture NO_ACTION; release processing PROPOSED_DELTA; filing AWAIT_AUTHORITY.
New collision — X-11
Candidate taxonomy registration versus filing authority.
A release can be:
- officially published by EFRAG;
- captured;
- rights-cleared;
- registered;
- parsed;
- semantically mapped;
- technically valid;
and still not be legally authorised for ESEF filing.
The existing Pergamum Pulse activation architecture already models this distinction and SHALL remain authoritative.
Acceptance criteria
- Prior 2024 and new 2026 releases coexist immutably.
- Observation history is not overwritten when a previously anticipated release becomes official.
- Release diff output cannot grant semantic equivalence by itself.
- Semantic-mapping approval cannot grant filing authority.
- Internal technical activation cannot imply external filing/publication rights.
- Historical reports resolve the exact taxonomy release originally used.
- Rights failure blocks capture/registration as required by the canonical rights workflow.
Canonical review result
unregistered candidate: ESRS concept/reporting-profile migration is narrowed: no Hecate Need is required for generic XBRL capture/registration/diff architecture. The canonical stack already exists. A future Need is justified only if the 2026 taxonomy exposes a genuinely unsupported semantic/reporting-profile behavior.
W39 history
What changed in ZAYAZ? The revised ESRS taxonomy moved from an observation/wait state to a concrete governed release-processing candidate. The infrastructure architecture itself did not change; the existing Pergamum Pulse taxonomy pipeline should now be exercised against the official 17 September release.
W39 source/evidence register
All entries below were retrieved/rechecked 2026-09-22.
| Event | Authoritative source | Locator |
|---|---|---|
| Revised-ESRS draft XBRL taxonomy publication | EFRAG — Draft ESRS XBRL Taxonomy, 17 Sep 2026 | Official publication 17.09.2026; consultation to 11.11.2026; same datapoints as August list plus XBRL attributes; final submission planned by end-2026. |
| Taxonomy publication directory | EFRAG XBRL taxonomy directory | ESRS directory shows 17.09.2026 release presence; use only as technical package locator, not legal authority. |
| Sustainability ESEF filing status | ESMA — Electronic Reporting | Sustainability markup remains dependent on adoption of the relevant ESEF marking rules; technical readiness is separate from filing authority. |