Chapter 24 — Constitutional Publication Framework
Part I — Publication Foundations and Architecture
The Constitutional Publication Framework, abbreviated CPF, is the governed constitutional architecture through which eligible ZAYAZ knowledge, evidence, Runtime Outcomes, reports, disclosures, statements, passports, filings, public records and assurance materials become authorised publications for defined audiences and channels.
The CPF SHALL govern the transition from internal constitutional state to externally or internally disclosed representation.
A Runtime Outcome SHALL NOT become a Publication merely because it:
- exists;
- is technically renderable;
- passed a calculation;
- passed HECATE validation;
- appears in a user interface;
- was exported;
- was generated by an agent;
- was approved for another purpose;
- was previously published in another context;
- is available through an API;
- is stored in a public-facing system.
Publication is a distinct constitutional transition.
It requires explicit resolution of:
- publication purpose;
- publication subject;
- intended audience;
- publication authority;
- disclosure permissions;
- applicable reporting and legal obligations;
- validation status;
- assurance status;
- evidence sufficiency;
- confidentiality and security;
- temporal applicability;
- publication format;
- channel;
- language;
- accessibility;
- version;
- corrections and restatements;
- retention;
- provenance.
The governing principle is:
A Runtime Outcome is not a Publication Object. A Publication Object becomes publishable only through a governed Publication Profile, Publication Decision and Publication Release.
The CPF SHALL support publication through:
- regulatory filings;
- CSRD and ESRS sustainability statements;
- EU Taxonomy disclosures;
- management reports;
- assurance packages;
- product and carbon passports;
- supplier disclosures;
- stakeholder reports;
- financial-impact disclosures;
- public transparency portals;
- EcoWorld publications;
- e-c-o.com articles and reference content;
- E-C-O Number lookup records;
- APIs;
- machine-readable datasets;
- structured data packages;
- downloadable reports;
- evidence packages;
- verifier and regulator workspaces;
- internal governance publications;
- public corrections and restatements.
Conceptually:
Constitutional Knowledge and Evidence
│
▼
Constitutional Runtime Outcomes
│
├── Validation Outcomes
├── Computation Outcomes
├── Reasoning Outcomes
├── Governance Decisions
├── Assurance Evidence
├── Workflow Outcomes
└── Explanations
│
▼
Publication Eligibility Evaluation
│
├── Publication Profile
├── Audience Profile
├── Disclosure Profile
├── Temporal Profile
├── Security Profile
├── Assurance Profile
└── Channel Profile
│
▼
Publication Object Assembly
│
▼
Publication Package and Manifest
│
▼
Validation, Approval and Assurance Gates
│
▼
Publication Decision
│
▼
Publication Release
│
├── Regulatory Filing
├── Public Portal
├── Report
├── API
├── Passport
├── Dataset
└── Evidence Package
│
▼
Publication Receipt, Monitoring and Provenance
The CPF SHALL remain independent of any single content-management system, reporting engine, document renderer, filing portal, API gateway, public website, database, graph platform, assurance platform, cloud provider or distribution channel.
24.1. Purpose
The purpose of the Constitutional Publication Framework is to establish the authoritative architecture through which constitutional knowledge and Runtime Outcomes become controlled representations for defined recipients.
The CPF SHALL provide a common publication model for:
- internal publications;
- external publications;
- regulatory disclosures;
- public disclosures;
- stakeholder disclosures;
- assurance deliverables;
- machine-readable publications;
- human-readable publications;
- periodic publications;
- event-triggered publications;
- product and entity passports;
- public registry entries;
- evidence packages;
- corrections;
- restatements;
- withdrawals;
- superseding releases;
- historical publication reconstruction.
The CPF SHALL ensure that every material Publication can answer:
- what was published;
- why it was published;
- for whom it was published;
- under which authority it was published;
- which source knowledge and Runtime Outcomes it represents;
- which Publication Profile applied;
- which validation and assurance requirements were satisfied;
- which limitations and qualifications were disclosed;
- which version was released;
- when it became effective;
- where it was distributed;
- whether it was corrected, superseded or withdrawn;
- which Module and Components produced it;
- whether the recipient received the intended version;
- how the publication can be independently reconstructed.
24.1.1. Publication Question
The governing question of the CPF is:
How does constitutionally governed knowledge become an authorised, audience-specific, versioned, assured and provenance-preserving publication?
This question is distinct from:
| Constitutional Layer | Governing Question |
|---|---|
| Constitution | What is authoritative? |
| Constitutional Knowledge Graph | How is constitutional knowledge interconnected? |
| Constitutional Compiler Framework | How is knowledge transformed into governed implementation artefacts? |
| Constitutional Runtime Framework | How is knowledge interpreted and executed in context? |
| Constitutional Publication Framework | How are eligible outcomes transformed into authorised disclosures and releases? |
| Delivery Infrastructure | How are publication bytes transported, hosted or displayed? |
24.1.2. Publication Responsibilities
The CPF SHALL be responsible for:
- publication eligibility;
- Publication Profile resolution;
- audience resolution;
- disclosure control;
- Publication Object assembly;
- package construction;
- publication validation;
- approval and assurance Gates;
- release identity;
- publication versioning;
- channel binding;
- distribution evidence;
- corrections and restatements;
- withdrawal;
- publication monitoring;
- retention;
- publication provenance;
- replay and historical reconstruction.
The CPF SHALL NOT silently:
- convert internal knowledge into public knowledge;
- reinterpret a Runtime Outcome;
- weaken an assurance qualification;
- omit material uncertainty;
- remove adverse findings;
- change the reporting boundary;
- change the reporting period;
- change units or methodologies;
- replace source evidence;
- infer publication authority from technical access;
- use branding to conceal the publishing legal entity;
- treat rendering success as publication approval;
- treat publication delivery as recipient comprehension;
- replace historical Publications after correction.
24.1.3. Publication Boundary
The Publication Boundary is the constitutional boundary between:
- governed internal state; and
- a representation intentionally made available to a defined audience.
The boundary exists even where the audience is internal.
Examples include:
- a board report;
- an auditor evidence package;
- a regulator filing;
- a supplier scorecard;
- a public API response;
- an E-C-O Number lookup record;
- an EcoWorld article;
- a carbon passport;
- a report downloaded by a tenant user.
A user-interface view MAY be a Publication where it is intentionally presented as an authoritative or governed representation.
24.1.4. Publication Is Not Export
An export is a technical extraction.
A Publication is a governed disclosure.
An export becomes a Publication only where it satisfies the applicable:
- Publication Profile;
- authority;
- disclosure;
- validation;
- assurance;
- security;
- versioning;
- delivery;
- provenance requirements.
24.1.5. Publication Is Not Activation
Activation makes constitutional or runtime artefacts operative.
Publication makes governed representations available to an audience.
An activated object MAY remain unpublished.
A published object SHALL NOT automatically become active constitutional knowledge.
24.1.6. Publication Is Not Assurance
Assurance provides a conclusion regarding defined subject matter and criteria.
Publication communicates a governed representation.
A Publication MAY:
- be unassured;
- be internally reviewed;
- have limited assurance;
- have reasonable assurance;
- include multiple assurance scopes;
- contain assured and unassured sections.
The assurance state SHALL be explicit.
24.1.7. Publication Is Not Publicity
A Publication MAY be:
- private;
- restricted;
- tenant-internal;
- management-only;
- auditor-only;
- regulator-only;
- supplier-specific;
- stakeholder-specific;
- publicly accessible.
Publication classification SHALL not be inferred from the word “publication.”
24.2. Scope and Applicability
The CPF SHALL apply to every ZAYAZ-controlled representation that is intended to communicate material constitutional, ESG, sustainability, governance, financial-impact, assurance or operational information to an audience.
24.2.1. In-Scope Publication Subjects
Publication Subjects MAY include:
- organisation;
- legal entity;
- reporting undertaking;
- group;
- value chain;
- supplier;
- customer;
- facility;
- site;
- product;
- service;
- project;
- activity;
- financial product;
- portfolio;
- asset;
- emission source;
- impact;
- risk;
- opportunity;
- policy;
- action;
- target;
- metric;
- disclosure requirement;
- data point;
- assurance engagement;
- audit;
- incident;
- methodology;
- model;
- scenario;
- transition plan;
- carbon footprint;
- lifecycle result;
- E-C-O Number;
- public registry record.
24.2.2. In-Scope Publication Forms
Publication Forms MAY include:
- sustainability statement;
- management report section;
- regulatory filing;
- structured filing package;
- annual report;
- integrated report;
- thematic report;
- disclosure table;
- taxonomy table;
- dashboard;
- public webpage;
- lookup record;
- API response;
- dataset;
- graph projection;
- product passport;
- carbon passport;
- supplier passport;
- certificate;
- assurance statement;
- audit report;
- evidence package;
- notification;
- correction notice;
- withdrawal notice.
24.2.3. Out-of-Scope Technical Artefacts
The following are not Publications unless used as intentional audience-facing representations:
- internal cache;
- temporary file;
- build artefact;
- runtime log;
- raw trace;
- queue message;
- unapproved draft;
- test fixture;
- simulation output;
- developer preview;
- agent scratchpad;
- private model context;
- intermediate calculation;
- unvalidated export;
- backup.
Their use in a publication process SHALL remain provenance-visible.
24.2.4. Applicability Sources
Publication obligations MAY arise from:
- Constitution;
- Publication Profile;
- reporting framework;
- law or regulation;
- regulatory filing rule;
- assurance engagement;
- contract;
- tenant policy;
- white-label policy;
- stakeholder commitment;
- governance decision;
- public transparency policy;
- incident policy;
- correction policy;
- product-passport requirement.
24.2.5. Jurisdictional Applicability
The CPF SHALL resolve jurisdictional publication requirements by reference to:
- publishing legal entity;
- reporting entity;
- recipient;
- place of establishment;
- place of offering;
- regulated market;
- product market;
- data location;
- publication channel;
- reporting period;
- applicable legal framework.
Jurisdiction SHALL not be inferred solely from interface language or server location.
24.2.6. Framework Applicability
Applicable frameworks MAY include:
- CSRD;
- ESRS;
- EU Taxonomy;
- SFDR;
- ISSB standards;
- GRI standards;
- national reporting requirements;
- product-passport rules;
- carbon-accounting frameworks;
- lifecycle methods;
- assurance standards;
- sector standards;
- tenant-specific frameworks.
Framework applicability SHALL be resolved through governed Constitutional Resolution Policies.
24.2.7. Publication Materiality
Publication materiality SHALL determine whether information is:
- required;
- material;
- optional;
- prohibited;
- subject to aggregation;
- subject to omission;
- subject to explanation;
- subject to assurance;
- subject to correction.
Materiality SHALL be evaluated under the applicable framework and Publication Profile.
24.2.8. Multi-Framework Publication
A Publication MAY satisfy multiple frameworks.
The Runtime SHALL preserve:
- each framework;
- each requirement;
- each mapping;
- each criterion;
- each assurance scope;
- conflicts;
- omissions;
- provenance.
A shared disclosure SHALL not erase framework-specific meaning.
24.3. Publication Domain Model
The CPF SHALL define publication through distinct constitutional objects.
These objects SHALL NOT be collapsed into one generic document record.
24.3.1. Publication Subject
A Publication Subject is the entity, activity, product, period, assertion, outcome or body of knowledge represented by a Publication.
Every Publication Subject SHALL possess a stable identity or governed composite identity.
24.3.2. Publication Object
A Publication Object is the governed semantic representation approved for potential inclusion in one or more Publication Packages.
A Publication Object MAY represent:
- narrative;
- metric;
- table;
- graph;
- image;
- assertion;
- disclosure;
- footnote;
- methodology statement;
- assurance statement;
- evidence reference;
- machine-readable record;
- public lookup record;
- correction notice.
Every Publication Object SHALL preserve:
- Publication Object Identifier;
- object type;
- subject;
- semantic content;
- source Runtime Outcomes;
- source evidence;
- reporting boundary;
- reporting period;
- units;
- methodology;
- uncertainty;
- limitations;
- confidentiality;
- validation state;
- assurance state;
- lifecycle;
- version;
- provenance.
24.3.3. Publication Package
A Publication Package is the governed collection of Publication Objects assembled for a defined purpose, audience, framework, channel or release.
A package MAY contain:
- human-readable renderings;
- machine-readable data;
- metadata;
- signatures;
- evidence references;
- assurance materials;
- manifest;
- schemas;
- styles;
- translations;
- attachments.
24.3.4. Publication Manifest
A Publication Manifest is the integrity-protected record describing the exact contents and governing state of a Publication Package.
It SHALL identify:
- Publication Package Identifier;
- Publication Profile;
- Publication Objects and versions;
- source Runtime Outcomes;
- reporting boundary;
- reporting period;
- audience;
- channel;
- languages;
- formats;
- validation results;
- approvals;
- assurance;
- security classification;
- signatures;
- content digests;
- Runtime Bundle;
- generating Modules and Components;
- release eligibility;
- provenance.
24.3.5. Publication Decision
A Publication Decision determines whether a Publication Package may be released for a defined purpose, audience, channel and time.
Decision classes MAY include:
- Approved for Release;
- Approved with Conditions;
- Approved for Restricted Release;
- Approved for Regulatory Submission;
- Approved for Public Release;
- Approval Pending;
- Assurance Pending;
- Correction Required;
- Blocked;
- Rejected;
- Withdrawn;
- Indeterminate.
Indeterminate SHALL NOT be treated as approval.
24.3.6. Publication Release
A Publication Release is the immutable governed version authorised for distribution.
It SHALL identify:
- Publication Release Identifier;
- Publication Package;
- release version;
- publication authority;
- approval;
- assurance state;
- effective time;
- release time;
- audience;
- channel permissions;
- distribution constraints;
- retention;
- correction policy;
- withdrawal policy;
- signatures;
- provenance.
24.3.7. Publication Instance
A Publication Instance is a specific rendering or delivery of a Publication Release.
Examples include:
- one PDF;
- one XHTML filing;
- one API representation;
- one webpage;
- one JSON package;
- one regulator upload;
- one passport payload;
- one email attachment.
A Publication Release MAY produce multiple Publication Instances.
24.3.8. Publication Receipt
A Publication Receipt records that a Publication Instance was delivered, accepted, exposed or made available through a defined channel.
It SHOULD preserve:
- Receipt Identifier;
- Publication Release;
- Publication Instance;
- recipient or audience class;
- channel;
- delivery endpoint;
- delivery time;
- acceptance state;
- external reference;
- response;
- content digest;
- retry history;
- provenance.
Delivery does not necessarily establish legal receipt unless the applicable channel profile defines it.
24.3.9. Publication Record
A Publication Record is the complete historical record of a Publication Release and its lifecycle.
It includes:
- preparation;
- validation;
- approval;
- assurance;
- release;
- distribution;
- access where governed;
- correction;
- restatement;
- supersession;
- withdrawal;
- archival state.
24.3.10. Publication Series
A Publication Series groups related releases over time.
Examples include:
- annual sustainability statements;
- quarterly taxonomy reports;
- product-passport versions;
- supplier disclosures;
- recurring public registry records.
A series SHALL not replace individual release identity.
24.3.11. Draft Publication
A Draft Publication is a non-authoritative package under preparation.
Every draft SHALL be visibly distinguishable from an authorised release.
Draft distribution SHALL be restricted by policy.
24.3.12. Publication Assertion
A Publication Assertion is a claim intentionally communicated within a Publication.
It SHALL preserve links to:
- source Constitutional Assertion;
- evidence;
- validation;
- methodology;
- uncertainty;
- assurance;
- reporting boundary;
- period;
- provenance.
24.3.13. Publication Status
Publication Status MAY include:
- Proposed;
- Draft;
- In Assembly;
- In Validation;
- Validation Failed;
- In Review;
- Approval Pending;
- Assurance Pending;
- Release Ready;
- Released;
- Corrected;
- Restated;
- Superseded;
- Withdrawn;
- Archived;
- Rejected.
Status transitions SHALL be evented and provenance-preserving.
24.4. Publication Architecture
The CPF architecture SHALL separate semantic publication responsibilities from rendering, hosting and delivery technologies.
24.4.1. Architectural Layers
A reference architecture is:
Constitutional Source Layer
│
▼
Runtime Outcome Layer
│
▼
Publication Eligibility Layer
│
▼
Publication Assembly Layer
│
▼
Validation, Governance and Assurance Layer
│
▼
Release Management Layer
│
▼
Rendering and Serialization Layer
│
▼
Channel and Distribution Layer
│
▼
Monitoring, Correction and Archive Layer
24.4.2. Constitutional Source Layer
The source layer MAY include:
- Constitutional Objects;
- Constitutional Relationships;
- Constitutional Assertions;
- evidence;
- Runtime Outcomes;
- Decision Receipts;
- Validation Results;
- Governance Decisions;
- Assurance Evidence;
- audit findings;
- operational evidence.
The source layer remains authoritative for its own domain.
24.4.3. Publication Eligibility Layer
The eligibility layer SHALL determine whether source material is eligible for publication under the applicable:
- Publication Profile;
- framework;
- audience;
- disclosure policy;
- security policy;
- temporal state;
- validation state;
- assurance state;
- authority;
- retention policy.
Eligibility SHALL not itself release content.
24.4.4. Publication Assembly Layer
The assembly layer SHALL:
- select eligible source material;
- map source material to Publication Objects;
- resolve templates;
- resolve language;
- resolve units and formats;
- preserve cross-references;
- include required metadata;
- include qualifications;
- construct Publication Packages;
- generate Publication Manifests.
24.4.5. Validation, Governance and Assurance Layer
This layer SHALL coordinate:
- HECATE validation;
- content review;
- publication authority;
- approval;
- assurance;
- legal review where applicable;
- security review;
- accessibility review;
- filing validation;
- final release Gate.
These responsibilities SHALL remain distinguishable.
24.4.6. Release Management Layer
The release layer SHALL govern:
- release identity;
- version;
- release candidate;
- approval state;
- effective time;
- publication time;
- signatures;
- release notes;
- channel eligibility;
- correction relationship;
- supersession relationship;
- withdrawal state.
24.4.7. Rendering and Serialization Layer
Rendering and serialization MAY produce:
- PDF;
- HTML;
- XHTML;
- MDX;
- Markdown;
- JSON;
- JSON-LD;
- XML;
- XBRL or Inline XBRL;
- CSV;
- spreadsheet;
- graph serialization;
- image;
- signed package;
- API representation.
Rendering SHALL not change constitutional meaning.
24.4.8. Channel and Distribution Layer
Channels MAY include:
- regulatory portal;
- tenant portal;
- public website;
- EcoWorld;
- e-c-o.com;
- E-C-O Number lookup;
- API;
- secure data room;
- verifier workspace;
- assurance workspace;
- email;
- document exchange;
- public registry;
- distributed ledger;
- product-passport network.
24.4.9. Monitoring, Correction and Archive Layer
This layer SHALL monitor:
- delivery;
- publication accessibility;
- channel integrity;
- version exposure;
- broken references;
- correction requirements;
- supersession;
- withdrawal;
- retention;
- archive integrity;
- historical availability.
24.4.10. Publication Control Plane
The Publication Control Plane SHALL govern:
- Publication Profiles;
- templates;
- schemas;
- channels;
- authorities;
- approval routes;
- assurance requirements;
- language requirements;
- accessibility requirements;
- release policies;
- correction policies;
- retention policies.
24.4.11. Publication Data Plane
The Publication Data Plane MAY contain:
- Publication Objects;
- Publication Packages;
- Publication Manifests;
- Publication Releases;
- Publication Instances;
- Publication Receipts;
- renderings;
- distribution state.
24.4.12. Publication Evidence Plane
The Publication Evidence Plane SHALL preserve:
- source lineage;
- eligibility evidence;
- validation evidence;
- approval evidence;
- assurance evidence;
- signatures;
- release evidence;
- delivery receipts;
- correction evidence;
- withdrawal evidence;
- archive evidence.
24.5. Publication Lifecycle
The Publication Lifecycle SHALL be explicit and governed.
A reference lifecycle is:
Publication Need Identified
│
▼
Publication Request
│
▼
Profile and Applicability Resolution
│
▼
Eligibility Evaluation
│
▼
Publication Object Assembly
│
▼
Publication Package Construction
│
▼
HECATE Validation
│
▼
Review and Approval
│
▼
Assurance Gate
│
▼
Release Decision
│
▼
Publication Release
│
▼
Rendering and Distribution
│
▼
Monitoring
│
├──► Correction
├──► Restatement
├──► Supersession
├──► Withdrawal
└──► Archive
24.5.1. Publication Request
Every governed publication process SHALL begin with a Publication Request or an automatic publication obligation.
A Publication Request SHALL identify:
- Publication Request Identifier;
- requester;
- purpose;
- subject;
- intended audience;
- framework;
- reporting period;
- requested channel;
- requested language;
- requested release time;
- authority;
- confidentiality;
- provenance.
24.5.2. Publication Obligation
A Publication Obligation MAY arise automatically from:
- reporting calendar;
- regulatory deadline;
- Governance Decision;
- assurance engagement;
- contract;
- incident;
- correction requirement;
- data change;
- product-passport update;
- public transparency commitment.
24.5.3. Applicability Resolution
CRP SHALL resolve:
- applicable Publication Profile;
- applicable frameworks;
- applicable Audience Profiles;
- applicable Disclosure Profiles;
- required assurance;
- required approvals;
- required channels;
- required formats;
- required languages;
- required accessibility;
- retention;
- correction rules.
24.5.4. Eligibility Evaluation
Eligibility SHALL evaluate:
- source identity;
- source lifecycle;
- validation status;
- authority;
- reporting boundary;
- reporting period;
- materiality;
- completeness;
- evidence;
- uncertainty;
- assurance readiness;
- security classification;
- disclosure permission;
- temporal validity;
- unresolved findings;
- unresolved contradictions.
24.5.5. Assembly
Assembly SHALL preserve the relationship between each Publication Object and its source material.
Assembly SHALL NOT:
- silently rewrite metrics;
- change units without governed conversion;
- omit qualifications;
- alter assurance scope;
- change reporting boundaries;
- merge incompatible methodologies;
- erase uncertainty;
- conceal unresolved findings.
24.5.6. Validation
HECATE SHALL validate the Publication Package against:
- Publication Profile;
- schema;
- framework requirements;
- content requirements;
- source lineage;
- validation state;
- assurance state;
- disclosure policy;
- security;
- accessibility;
- channel requirements;
- manifest completeness;
- provenance.
24.5.7. Review
Review MAY include:
- content-owner review;
- data-owner review;
- methodology review;
- legal review;
- security review;
- accessibility review;
- executive review;
- assurance-provider review;
- tenant review;
- white-label review.
Review SHALL not create publication authority unless the reviewer possesses the required Role and Authority Assignment.
24.5.8. Approval
Approval SHALL identify:
- approving actor;
- Role;
- authority;
- scope;
- conditions;
- approved package digest;
- approved version;
- effective period;
- time;
- provenance.
Approval of one version SHALL not automatically approve a later version.
24.5.9. Assurance Gate
Where assurance is required, the Gate SHALL validate:
- assurance subject;
- criteria;
- scope;
- assurance level;
- assurance conclusion;
- limitations;
- exceptions;
- opinion version;
- signer;
- validity;
- linkage to the Publication Package.
24.5.10. Release Decision
The release decision SHALL be based on the exact Publication Manifest and content digests.
A content change after approval or assurance SHALL invalidate the prior release decision unless the change is classified as non-material under an explicit policy.
24.5.11. Release
Release SHALL:
- assign immutable release identity;
- seal the Publication Manifest;
- record signatures;
- establish effective and publication time;
- establish channel permissions;
- create release events;
- preserve provenance.
24.5.12. Distribution
Distribution SHALL:
- use authorised channels;
- preserve the approved release;
- validate destination;
- preserve content integrity;
- produce a Publication Receipt where required;
- preserve recipient and channel state;
- record failures and retries.
24.5.13. Monitoring
Monitoring SHALL detect:
- wrong version exposure;
- unauthorised publication;
- broken access;
- channel corruption;
- missing attachments;
- stale public record;
- failed regulator acceptance;
- language inconsistency;
- signature failure;
- correction trigger;
- withdrawal trigger.
24.5.14. Archive
Archive SHALL preserve:
- released content;
- manifest;
- signatures;
- renderings;
- receipts;
- corrections;
- supersession;
- withdrawal;
- access policy;
- retention;
- historical provenance.
24.6. Publication Classes
Publication Classes SHALL establish the constitutional treatment of different disclosure purposes and audiences.
24.6.1. Regulatory Publication
A Regulatory Publication is submitted to or made available under a regulatory requirement.
It SHALL preserve:
- regulated entity;
- legal basis;
- filing period;
- filing authority;
- filing format;
- filing taxonomy;
- validation;
- assurance;
- submission channel;
- regulator receipt;
- correction and restatement state;
- provenance.
24.6.2. Public Publication
A Public Publication is available without recipient-specific authorisation.
Public classification SHALL require explicit approval.
Public availability SHALL not imply that all source evidence is public.
24.6.3. Restricted Publication
A Restricted Publication is available only to authorised audience classes.
Restriction MAY be based on:
- tenant;
- Role;
- organisation;
- contract;
- assurance engagement;
- regulator relationship;
- supplier relationship;
- investigation;
- legal privilege;
- confidentiality.
24.6.4. Internal Publication
An Internal Publication is communicated within a tenant, organisation or defined internal audience.
Internal status SHALL not eliminate publication governance.
24.6.5. Assurance Publication
An Assurance Publication communicates:
- assurance conclusion;
- subject matter;
- criteria;
- scope;
- level;
- limitations;
- findings;
- signer;
- date;
- provenance.
24.6.6. Machine Publication
A Machine Publication is designed for automated consumption.
It SHALL preserve:
- schema;
- semantic identifiers;
- version;
- units;
- null semantics;
- temporal semantics;
- tenant scope;
- security;
- content digest;
- provenance.
24.6.7. Human Publication
A Human Publication SHALL preserve meaning through:
- readable structure;
- terminology;
- tables;
- visualisations;
- notes;
- qualifications;
- accessibility;
- language;
- source references.
24.6.8. Hybrid Publication
A Hybrid Publication contains human-readable and machine-readable representations.
The representations SHALL be reconciled.
Where they conflict, the Publication Profile SHALL identify the authoritative representation or require correction.
24.6.9. Dynamic Publication
A Dynamic Publication is generated at request time from governed source state.
It SHALL still preserve:
- Publication Profile;
- source versions;
- Runtime Context;
- decision;
- rendering version;
- audience;
- publication time;
- receipt;
- provenance.
24.6.10. Static Publication
A Static Publication is released as an immutable content instance.
Later changes SHALL create a new release, correction, restatement or supersession.
24.6.11. Periodic Publication
A Periodic Publication SHALL identify:
- reporting frequency;
- period;
- comparative periods;
- publication deadline;
- series;
- prior release;
- consistency treatment;
- provenance.
24.6.12. Event-Triggered Publication
An Event-Triggered Publication MAY arise from:
- threshold breach;
- incident;
- material change;
- target update;
- product update;
- supplier change;
- correction;
- regulatory event;
- assurance event.
The triggering event SHALL remain identifiable.
24.7. Publication Context
A Publication Context is the immutable governed set of facts under which publication eligibility, assembly, approval, release and distribution occur.
It SHALL be derived from Runtime Context but MAY include publication-specific dimensions.
24.7.1. Publication Context Dimensions
Publication Context MAY include:
- tenant;
- white-label deployment;
- publishing organisation;
- publishing legal entity;
- reporting entity;
- publication subject;
- publication purpose;
- audience;
- framework;
- jurisdiction;
- reporting period;
- publication date;
- effective date;
- language;
- channel;
- format;
- assurance level;
- security classification;
- confidentiality;
- materiality;
- correction state;
- release state.
24.7.2. Context Sources
Sources MAY include:
- Runtime Context;
- tenant registry;
- organisation registry;
- legal-entity registry;
- reporting-boundary registry;
- framework registry;
- Publication Profile;
- Audience Profile;
- Disclosure Profile;
- Governance Decision;
- Security Profile;
- assurance engagement;
- reporting calendar;
- approved defaults.
24.7.3. Publication Context Assembly
Assembly SHALL:
- resolve identities;
- validate sources;
- resolve conflicts;
- apply jurisdiction;
- apply framework;
- apply audience;
- apply disclosure;
- apply temporal scope;
- apply tenant and white-label scope;
- apply assurance;
- apply security;
- produce a Publication Context Fingerprint.
24.7.4. Publication Context Fingerprint
The fingerprint SHALL support:
- approval binding;
- assurance binding;
- package validation;
- release integrity;
- caching;
- replay;
- historical reconstruction;
- audit;
- correction impact analysis.
24.7.5. Context Change
A material Publication Context change SHALL invalidate prior eligibility, approval or release readiness.
Material changes MAY include:
- publishing entity;
- reporting boundary;
- period;
- audience;
- framework;
- jurisdiction;
- assurance level;
- security classification;
- channel;
- Publication Profile;
- source Runtime Bundle.
24.7.6. Multi-Audience Context
One Publication Package MAY support multiple audiences only where the applicable Disclosure Profiles are compatible.
Otherwise, separate packages or audience-specific projections SHALL be produced.
24.7.7. Multi-Channel Context
A Publication Release MAY be rendered to multiple channels where each channel:
- is authorised;
- preserves meaning;
- satisfies format requirements;
- satisfies accessibility;
- preserves version identity;
- produces appropriate receipts.
24.7.8. Context Validation
HECATE SHALL validate:
- source trust;
- entity identity;
- tenant;
- audience;
- framework;
- jurisdiction;
- reporting period;
- assurance;
- security;
- channel;
- fingerprint reproducibility;
- provenance.
24.8. Publication Authority and Separation of Duties
Publication SHALL occur only under explicit constitutional authority.
Technical ability to publish SHALL not establish publication authority.
24.8.1. Publication Authority
Publication Authority SHALL define:
- authority holder;
- authority type;
- subject scope;
- audience scope;
- channel scope;
- framework scope;
- tenant scope;
- jurisdiction;
- effective period;
- delegation;
- conditions;
- provenance.
24.8.2. Publication Roles
Publication Roles MAY include:
- Publication Requester;
- Publication Owner;
- Content Owner;
- Data Owner;
- Data Steward;
- Disclosure Owner;
- Publication Assembler;
- Validator;
- Reviewer;
- Approver;
- Assurance Provider;
- Legal Reviewer;
- Security Reviewer;
- Accessibility Reviewer;
- Release Manager;
- Channel Operator;
- Publication Archivist;
- Correction Authority;
- Withdrawal Authority.
Roles SHALL be resolved through the Constitutional Role Registry.
24.8.3. Separation of Duties
Separation of duties MAY require distinct actors or Components for:
- preparation and approval;
- calculation and validation;
- publication assembly and assurance;
- approval and release;
- release and channel operation;
- correction proposal and correction approval;
- audit and operational ownership.
24.8.4. Self-Approval
Self-approval SHALL be prohibited where the applicable Publication Profile requires independence.
An agent SHALL not approve its own Publication Package.
A Component SHALL not infer approval from its own successful validation.
24.8.5. Delegated Authority
Delegation SHALL preserve:
- delegator;
- delegate;
- authority type;
- scope;
- purpose;
- effective time;
- expiration;
- revocation;
- provenance.
24.8.6. Emergency Publication Authority
Emergency publication MAY be permitted for:
- urgent safety information;
- material incident communication;
- regulator-directed notice;
- security advisory;
- critical correction.
Emergency authority SHALL be:
- explicit;
- bounded;
- time-limited;
- purpose-limited;
- retrospectively reviewed;
- provenance-preserving.
24.8.7. White-Label Authority
A white-label operator MAY possess authority over:
- branding;
- tenant onboarding;
- approved public channels;
- operator-level publications;
- tenant publication administration.
White-label authority SHALL not automatically permit publication of tenant content.
24.8.8. Tenant Authority
Tenant publication authority SHALL remain scoped to the tenant unless explicit cross-tenant authority exists.
24.8.9. External Authority
External assurance providers, auditors, regulators and filing agents SHALL possess explicitly mapped authority.
External system access SHALL not create constitutional authority.
24.8.10. Authority Validation
HECATE SHALL validate:
- actor identity;
- Role;
- Authority Assignment;
- scope;
- tenant;
- subject;
- audience;
- channel;
- framework;
- time;
- delegation;
- conflicts of interest;
- provenance.
24.9. Publication Runtime Components
The CPF MAY be implemented through modular Components.
Each Component SHALL belong to a Module and preserve Component lineage.
24.9.1. Reference Components
| Component | Constitutional Responsibility |
|---|---|
| Publication Gateway | Accepts Publication Requests and obligations |
| Publication Context Assembler | Builds and seals Publication Context |
| Publication Profile Resolver | Resolves applicable publication requirements |
| Eligibility Engine | Evaluates publication eligibility |
| Disclosure Resolver | Determines permitted disclosure by audience |
| Publication Object Factory | Creates governed Publication Objects |
| Package Assembler | Constructs Publication Packages |
| Manifest Service | Creates integrity-protected Publication Manifests |
| Publication Validator | Coordinates HECATE publication validation |
| Approval Orchestrator | Coordinates review and approval Gates |
| Assurance Binder | Binds assurance scope and conclusions |
| Release Manager | Creates immutable Publication Releases |
| Rendering Service | Produces channel-specific representations |
| Channel Router | Delivers authorised Publication Instances |
| Receipt Service | Captures delivery and acceptance evidence |
| Correction Manager | Governs corrections, restatements and withdrawal |
| Publication Archive | Preserves historical releases and evidence |
| Publication Explanation Service | Produces publication explanations |
| Publication Audit Service | Supports independent audit and reconstruction |
24.9.2. Component Authority
Each Component SHALL possess explicit Component Authority.
No Component SHALL:
- expand its publication scope;
- bypass a Gate;
- modify assurance state;
- change audience;
- alter tenant;
- suppress findings;
- release an unapproved version;
- substitute an unauthorised channel;
- erase historical releases.
24.9.3. Component Contracts
Component interactions SHALL use governed Runtime Integration Contracts defining:
- inputs;
- outputs;
- identity;
- tenant;
- Publication Context;
- authority;
- security;
- temporal semantics;
- idempotency;
- transaction boundaries;
- error treatment;
- provenance.
24.9.4. Publication Gateway
The Publication Gateway SHALL validate:
- request identity;
- requester;
- tenant;
- purpose;
- subject;
- authority;
- requested audience;
- requested channel;
- request integrity.
24.9.5. Eligibility Engine
The Eligibility Engine SHALL produce an Eligibility Outcome containing:
- eligible;
- conditionally eligible;
- ineligible;
- indeterminate;
- required actions;
- blocking findings;
- missing evidence;
- missing authority;
- assurance requirement;
- explanation;
- provenance.
24.9.6. Package Assembler
The Package Assembler SHALL operate only upon eligible or conditionally eligible source material.
Conditional eligibility SHALL remain visible.
24.9.7. Release Manager
The Release Manager SHALL:
- bind approval to package digest;
- bind assurance to package scope;
- assign immutable release identity;
- seal manifest;
- validate channel permissions;
- create release event;
- prevent post-release mutation.
24.9.8. Channel Router
The Channel Router SHALL independently validate:
- release identity;
- destination;
- channel authority;
- tenant;
- audience;
- format;
- security;
- effective time;
- withdrawal state.
24.9.9. Publication Archive
The archive SHALL preserve immutable historical states while applying lawful access restrictions, retention and redaction.
24.9.10. Component Substitution
A Component MAY be substituted only where:
- constitutional capability is equivalent;
- contracts are compatible;
- authority is equivalent;
- security is equivalent or stronger;
- reliability is sufficient;
- validation passes;
- provenance records the substitution.
24.10. Runtime Integration
The CPF SHALL integrate with the Constitutional Runtime Framework without duplicating its responsibilities.
24.10.1. Context Runtime Integration
The CPF SHALL consume validated Runtime Context and assemble Publication Context.
Publication-specific context SHALL not contradict the source Runtime Context.
24.10.2. CRP Integration
CRP SHALL resolve:
- Publication Profile;
- Audience Profile;
- Disclosure Profile;
- Assurance Profile;
- Channel Profile;
- language requirements;
- accessibility requirements;
- correction policy;
- retention policy.
24.10.3. HECATE Integration
HECATE SHALL validate:
- source eligibility;
- Publication Objects;
- packages;
- manifests;
- framework conformance;
- audience disclosure;
- security;
- assurance binding;
- release readiness;
- corrections;
- provenance.
HECATE SHALL not grant publication authority.
24.10.4. Governance Runtime Integration
Governance Runtime SHALL resolve:
- publication authority;
- approvals;
- delegations;
- assurance requirements;
- separation of duties;
- emergency authority;
- escalation;
- withdrawal authority.
24.10.5. Temporal Runtime Integration
Temporal Runtime SHALL govern:
- reporting period;
- publication deadline;
- effective date;
- release date;
- embargo;
- expiry;
- correction date;
- restatement date;
- supersession;
- withdrawal;
- archive period.
24.10.6. Event Runtime Integration
Publication events MAY include:
- PublicationRequested;
- PublicationObligationCreated;
- PublicationEligibilityEvaluated;
- PublicationPackageAssembled;
- PublicationValidationCompleted;
- PublicationApprovalGranted;
- PublicationApprovalRejected;
- AssuranceBound;
- PublicationReleaseCreated;
- PublicationDistributed;
- PublicationAccepted;
- PublicationDeliveryFailed;
- PublicationCorrected;
- PublicationRestated;
- PublicationSuperseded;
- PublicationWithdrawn;
- PublicationArchived.
24.10.7. Workflow Runtime Integration
Workflow Runtime MAY coordinate:
- content preparation;
- data collection;
- review;
- validation;
- approval;
- assurance;
- translation;
- accessibility review;
- regulatory filing;
- correction;
- withdrawal.
Workflow completion SHALL not itself establish release approval.
24.10.8. Agent Runtime Integration
Agents MAY assist with:
- drafting;
- summarisation;
- cross-reference generation;
- translation proposals;
- tagging;
- format conversion;
- consistency checks;
- evidence indexing;
- accessibility checks;
- publication monitoring.
Agent outputs SHALL remain proposals until governed validation and approval.
24.10.9. Security Runtime Integration
Security Runtime SHALL enforce:
- tenant isolation;
- audience access;
- disclosure restrictions;
- embargo;
- legal privilege;
- personal-data controls;
- trade-secret protection;
- regulator-only access;
- channel security;
- export restrictions.
24.10.10. Reliability Runtime Integration
Reliability Runtime SHALL govern:
- publication deadlines;
- rendering reliability;
- channel availability;
- regulator submission retries;
- public availability;
- receipt capture;
- archive availability;
- recovery;
- publication SLOs.
24.10.11. Explainability Runtime Integration
Every material Publication SHALL support explanation of:
- source;
- purpose;
- audience;
- framework;
- methodology;
- boundary;
- period;
- validation;
- approval;
- assurance;
- limitations;
- corrections;
- provenance.
24.10.12. Audit Runtime Integration
Audit Runtime SHALL be able to examine:
- Publication Request;
- Publication Context;
- Profile resolution;
- eligibility;
- source evidence;
- assembly;
- validation;
- approvals;
- assurance;
- release;
- distribution;
- corrections;
- archive;
- provenance.
24.10.13. Runtime Bundle Integration
Publication Profiles, schemas, templates, rules, channel definitions and conformance fixtures SHOULD be included in or referenced by governed Runtime Bundles.
24.10.14. Pergamum Pulse Integration
Pergamum Pulse MAY derive intelligence including:
- publication-readiness risk;
- disclosure coverage gaps;
- validation bottlenecks;
- assurance gaps;
- deadline risk;
- recurring corrections;
- stale public records;
- cross-channel inconsistency;
- tenant publication divergence;
- publication-control weakness;
- public-transparency gaps;
- Module-level publication risk;
- Component-level publication risk.
Pergamum Pulse SHALL preserve:
- Module lineage;
- Component lineage;
- Publication Profile lineage;
- Publication Object lineage;
- Publication Release lineage;
- audience lineage;
- channel lineage;
- tenant lineage;
- framework lineage;
- assurance lineage;
- temporal validity;
- provenance.
Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.
24.11. Foundational Non-Functional Requirements
The CPF SHALL satisfy constitutional non-functional requirements in addition to content correctness.
24.11.1. Determinism
Equivalent source state, Publication Context, Runtime Bundle, Publication Profile and rendering configuration SHALL produce semantically equivalent Publication Packages.
24.11.2. Reproducibility
An authorised reviewer SHALL be able to reconstruct a Publication Release from:
- source versions;
- Runtime Outcomes;
- Publication Context;
- Publication Profile;
- templates;
- schemas;
- rendering Components;
- Runtime Bundle;
- approvals;
- assurance;
- manifest.
24.11.3. Immutability
A released Publication SHALL be immutable.
Correction SHALL create a new governed state rather than mutate the historical release.
24.11.4. Idempotency
Repeated release or distribution requests SHALL not create uncontrolled duplicate releases or side effects.
24.11.5. Tenant Isolation
Tenant isolation SHALL apply to:
- source selection;
- Publication Objects;
- packages;
- manifests;
- drafts;
- approvals;
- assurance materials;
- renderings;
- channels;
- receipts;
- archives;
- corrections.
24.11.6. Security
Security SHALL apply before, during and after publication.
Public release SHALL not expose protected source evidence unless explicitly approved.
24.11.7. Accessibility
Applicable Publications SHALL satisfy governed accessibility requirements.
Accessibility transformations SHALL preserve semantic content.
24.11.8. Internationalisation
Language and locale handling SHALL preserve:
- identifiers;
- metrics;
- units;
- dates;
- numbers;
- legal names;
- qualifications;
- uncertainty;
- assurance wording;
- provenance.
24.11.9. Integrity
Publication integrity MAY be protected through:
- content digests;
- digital signatures;
- trusted timestamps;
- signed manifests;
- transparency logs;
- immutable archives;
- regulator receipts.
24.11.10. Availability
Publication availability SHALL match the applicable Reliability Profile.
Public availability SHALL not supersede withdrawal or embargo controls.
24.11.11. Scalability
The CPF SHALL support:
- multi-tenant operation;
- multiple white-label deployments;
- large reporting packages;
- multilingual publication;
- machine and human channels;
- high-volume public lookup;
- event-triggered updates;
- global distribution;
- jurisdiction-specific releases.
Scale SHALL not weaken approval, security, assurance or provenance.
24.11.12. Observability
The CPF SHALL expose governed telemetry for:
- publication pipeline state;
- validation;
- approval;
- assurance;
- rendering;
- distribution;
- receipt;
- availability;
- correction;
- withdrawal;
- archive.
Telemetry SHALL not become an uncontrolled copy of publication content.
24.11.13. Replay
The CPF SHALL support replay of:
- eligibility;
- profile resolution;
- package assembly;
- validation;
- approval path;
- assurance binding;
- rendering;
- distribution;
- correction impact.
24.11.14. Publication Diff
A Publication Diff SHOULD identify changes in:
- source;
- subject;
- period;
- boundary;
- metric;
- narrative;
- methodology;
- evidence;
- validation;
- assurance;
- audience;
- channel;
- rendering;
- limitations;
- provenance.
24.11.15. Impact Analysis
A proposed change SHALL support impact analysis over:
- Publication Objects;
- packages;
- releases;
- channels;
- recipients;
- reports;
- regulatory filings;
- passports;
- public records;
- assurance conclusions;
- tenants;
- Modules;
- Components.
24.12. Part I Conformance
An implementation conforms to Part I of the Constitutional Publication Framework where it:
- treats publication as a distinct constitutional transition;
- distinguishes Runtime Outcomes from Publication Objects;
- distinguishes Publication Objects, Packages, Manifests, Decisions, Releases, Instances and Receipts;
- assigns stable identity and version to every material publication artefact;
- resolves applicability through governed Publication Profiles and Constitutional Resolution Policies;
- requires explicit Publication Context;
- preserves publishing entity, reporting boundary, reporting period, audience, framework and channel;
- requires publication authority separate from technical publishing capability;
- preserves separation of preparation, validation, approval, assurance and release;
- prevents HECATE validation from being treated as publication approval;
- prevents approval from being treated as assurance;
- binds approval and assurance to exact package identity and content digest;
- prevents post-approval content mutation;
- produces immutable Publication Releases;
- governs rendering independently from semantic content;
- governs distribution through authorised channels;
- captures Publication Receipts where required;
- preserves tenant and white-label isolation;
- protects confidential source evidence during public disclosure;
- supports regulatory, public, restricted, internal, human, machine and hybrid Publications;
- supports periodic and event-triggered Publications;
- preserves corrections, restatements, supersession and withdrawal without erasing history;
- supports deterministic reconstruction, replay, diff and impact analysis;
- preserves Runtime Bundle, Module and Component lineage;
- integrates with Context, CRP, HECATE, Governance, Temporal, Event, Workflow, Agent, Security, Reliability, Explainability and Audit runtimes;
- prevents agent-generated content from becoming authoritative without governed validation and approval;
- prevents public-channel availability from overriding embargo, withdrawal or access controls;
- preserves complete publication evidence and provenance;
- allows Pergamum Pulse to derive publication intelligence without granting it publication authority;
- remains independent of any single renderer, CMS, filing portal, website or delivery technology.
Part I Foundational Principle
The Constitutional Publication Framework is the governed boundary through which ZAYAZ transforms eligible constitutional knowledge and Runtime Outcomes into authorised representations for defined audiences.
Publication SHALL not occur merely because content exists, is technically renderable, passed validation, was generated by an agent or can be reached through a public interface. Every Publication SHALL possess an explicit purpose, subject, audience, publishing entity, Publication Context, Publication Profile, authority, validation state, assurance state, release identity, channel permission and complete provenance.
A Publication Object SHALL remain distinct from its source Runtime Outcomes. A Publication Package SHALL remain distinct from its renderings. A Publication Release SHALL remain distinct from its delivery instances. A correction, restatement, supersession or withdrawal SHALL create a new governed historical state rather than rewrite the past.
By making publication profile-driven, authority-bound, assurance-aware, audience-specific, channel-governed, immutable, replayable and provenance-preserving, ZAYAZ can support regulator-grade sustainability reporting, public transparency, product and carbon passports, assurance, white-label distribution and stakeholder communication without sacrificing constitutional integrity, tenant isolation or accountable governance.