Skip to main content

Chapter 24 — Constitutional Publication Framework

Part II — Publication Profiles, Audience, Disclosure and Eligibility​

Part II defines the governed profile system through which ZAYAZ determines:

  • what may or must be published;
  • to whom it may be published;
  • for which purpose;
  • under which reporting framework;
  • through which channel;
  • in which format and language;
  • with which accessibility, confidentiality and assurance requirements;
  • under which conditions;
  • with which omissions, qualifications and limitations;
  • at which time;
  • under which publication authority.

Part I established that a Runtime Outcome is not a Publication Object and that publication is a distinct constitutional transition.

Part II defines the profile and eligibility architecture controlling that transition.

The governing principle is:

Publication eligibility SHALL be resolved from explicit, versioned and provenance-preserving profiles. It SHALL NOT be inferred from technical availability, user-interface visibility, prior publication, model judgement or implementation convention.

The publication-control stack is:

Publication Request or Obligation
        │
        ▼
Publication Context
        │
        ▼
Profile Resolution
        │
        ├── Publication Profile
        ├── Framework Publication Profile
        ├── Audience Profile
        ├── Disclosure Profile
        ├── Channel Profile
        ├── Format and Rendering Profile
        ├── Language Profile
        ├── Accessibility Profile
        ├── Assurance Profile
        ├── Temporal Profile
        └── Retention Profile
        │
        ▼
Eligibility Evaluation
        │
        ├── Source Eligibility
        ├── Materiality
        ├── Completeness
        ├── Evidence Sufficiency
        ├── Validation State
        ├── Assurance Readiness
        ├── Authority
        ├── Security
        ├── Omission Rules
        └── Qualification Rules
        │
        ▼
Publication Eligibility Outcome
        │
        ├── Eligible
        ├── Eligible with Conditions
        ├── Restricted
        ├── Remediation Required
        ├── Ineligible
        └── Indeterminate

Profiles SHALL remain independent from:

  • user-interface configuration;
  • static templates;
  • application feature flags;
  • database access rights;
  • content-management permissions;
  • channel-specific code;
  • agent prompts;
  • manually maintained spreadsheets;
  • undocumented legal interpretation;
  • unversioned assurance instructions.

24.13. Publication Profile​

A Publication Profile is the governed Constitutional Object defining the complete publication requirements applicable to a publication purpose, subject, audience, framework, jurisdiction, period and channel.

The Publication Profile SHALL act as the primary constitutional control object for publication.

24.13.1. Publication Profile Identity​

Every Publication Profile SHALL possess:

  • Publication Profile Identifier;
  • canonical name;
  • semantic definition;
  • profile type;
  • governing authority;
  • purpose;
  • applicable Publication Subjects;
  • applicable Publication Object Types;
  • audience scope;
  • framework scope;
  • jurisdictional scope;
  • tenant scope;
  • white-label scope;
  • temporal applicability;
  • required source states;
  • required validation;
  • required evidence;
  • required approval;
  • required assurance;
  • permitted channels;
  • permitted formats;
  • language requirements;
  • accessibility requirements;
  • disclosure controls;
  • omission controls;
  • correction controls;
  • retention;
  • lifecycle;
  • version;
  • provenance.

24.13.2. Publication Profile Types​

Publication Profile Types MAY include:

  • regulatory filing;
  • sustainability statement;
  • annual report;
  • management report;
  • public transparency report;
  • assurance package;
  • audit report;
  • product passport;
  • carbon passport;
  • supplier passport;
  • stakeholder report;
  • public lookup record;
  • API publication;
  • machine-readable dataset;
  • internal board publication;
  • regulator workspace publication;
  • verifier workspace publication;
  • incident publication;
  • correction notice;
  • restatement;
  • withdrawal notice.

Profile Types SHALL originate from governed Constitutional Value Providers.

24.13.3. Profile Purpose​

A Publication Profile SHALL define one or more permitted purposes, including:

  • statutory compliance;
  • regulatory submission;
  • public transparency;
  • stakeholder information;
  • investor information;
  • assurance;
  • audit;
  • supplier engagement;
  • customer communication;
  • product transparency;
  • governance oversight;
  • internal decision support;
  • incident communication;
  • correction;
  • historical archive.

A Publication created for one purpose SHALL not be reused for another purpose without re-evaluating profile applicability.

24.13.4. Profile Applicability​

Applicability SHALL evaluate:

  • Publication Subject Type;
  • publishing legal entity;
  • reporting entity;
  • tenant;
  • white-label deployment;
  • organisation;
  • framework;
  • jurisdiction;
  • reporting period;
  • materiality;
  • audience;
  • channel;
  • assurance scope;
  • correction state;
  • incident state;
  • effective time.

24.13.5. Profile Requirements​

Profile requirements SHALL be represented as explicit obligations.

Requirement classes MAY include:

  • mandatory content;
  • conditional content;
  • prohibited content;
  • mandatory metadata;
  • mandatory evidence;
  • required explanation;
  • required validation;
  • required review;
  • required approval;
  • required assurance;
  • required signature;
  • required format;
  • required language;
  • required accessibility;
  • required channel;
  • required retention;
  • required correction behaviour.

24.13.6. Profile Constraints​

Constraints MAY include:

  • maximum disclosure scope;
  • minimum aggregation;
  • prohibited recipients;
  • embargo;
  • jurisdictional restrictions;
  • data residency;
  • restricted evidence;
  • assurance limitations;
  • publication deadlines;
  • permitted translations;
  • file-size limits;
  • machine-schema requirements;
  • channel-specific signing.

24.13.7. Profile Defaults​

Defaults MAY be used only where:

  • the default is constitutionally approved;
  • its scope is explicit;
  • it does not weaken a mandatory requirement;
  • it is versioned;
  • it is included in the Publication Context;
  • it is provenance-preserving.

A missing value SHALL not silently inherit a permissive default.

24.13.8. Profile Inheritance​

Publication Profiles MAY inherit from:

  • Core Publication Profile;
  • framework profile;
  • jurisdictional profile;
  • white-label profile;
  • tenant profile;
  • organisation profile;
  • subject-specific profile;
  • channel profile.

Inheritance SHALL preserve source identity and override rules.

24.13.9. Profile Composition​

A reference composition order is:

ZAYAZ Core Publication Profile
        │
        ▼
Framework Publication Profile
        │
        ▼
Jurisdictional Publication Profile
        │
        ▼
White-label Publication Profile
        │
        ▼
Tenant Publication Profile
        │
        ▼
Organisation Publication Profile
        │
        ▼
Subject-Specific Publication Profile
        │
        ▼
Audience and Channel Profiles
        │
        ▼
Publication Context

No lower-order profile SHALL weaken a non-overrideable Core, legal, security or assurance control.

24.13.10. Profile Conflict​

A profile conflict exists where two applicable profile requirements cannot both be satisfied.

Conflicts MAY include:

  • mandatory disclosure versus prohibited disclosure;
  • public access versus confidentiality;
  • incompatible formats;
  • conflicting deadlines;
  • conflicting assurance scopes;
  • incompatible language requirements;
  • inconsistent retention;
  • incompatible correction obligations.

Unresolved conflict SHALL block publication eligibility.

24.13.11. Profile Precedence​

Precedence SHALL consider:

  • constitutional authority;
  • legal authority;
  • mandatory framework requirement;
  • non-overrideable security control;
  • regulator instruction;
  • assurance requirement;
  • tenant restriction;
  • contractual requirement;
  • publication purpose;
  • specific-over-general rule;
  • temporal applicability.

Implementation order SHALL not determine precedence.

24.13.12. Profile Override​

An override SHALL require:

  • explicit override authority;
  • overrideable requirement;
  • reason;
  • scope;
  • effective time;
  • expiration;
  • affected publication;
  • risk assessment;
  • approval;
  • provenance.

An override SHALL not modify the source profile.

24.13.13. Non-Overrideable Controls​

Non-overrideable controls MAY include:

  • cross-tenant disclosure prohibition;
  • unauthorised personal-data publication;
  • prohibited trade-secret disclosure;
  • publication without required legal authority;
  • publication without required assurance;
  • concealment of material limitation;
  • publication of withdrawn content;
  • deletion of historical publication lineage;
  • unapproved use of a regulator filing identity;
  • agent self-approval.

24.13.14. Profile Lifecycle​

Profile lifecycle MAY include:

  • Proposed;
  • Draft;
  • Under Review;
  • Approved;
  • Active;
  • Suspended;
  • Deprecated;
  • Superseded;
  • Withdrawn;
  • Archived.

Only approved and active profiles SHALL govern authoritative publication.

24.13.15. Profile Versioning​

A new version SHALL be created where changes affect:

  • applicability;
  • required content;
  • audience;
  • disclosure;
  • assurance;
  • validation;
  • format;
  • channel;
  • language;
  • accessibility;
  • deadlines;
  • correction;
  • retention;
  • authority.

Historical releases SHALL retain their historical profile versions.

24.13.16. Profile Validation​

HECATE SHALL validate:

  • identity;
  • authority;
  • applicability;
  • completeness;
  • inheritance;
  • composition;
  • precedence;
  • overrides;
  • temporal validity;
  • non-overrideable controls;
  • provenance.

24.14. Framework Publication Profiles​

A Framework Publication Profile defines publication requirements originating from a reporting, disclosure, assurance, passport or regulatory framework.

It SHALL preserve the original framework identity and version.

24.14.1. Framework Profile Identity​

Every Framework Publication Profile SHALL identify:

  • Framework Profile Identifier;
  • framework;
  • framework version;
  • issuing authority;
  • effective date;
  • jurisdiction;
  • applicable entities;
  • applicable subjects;
  • publication obligations;
  • data-point obligations;
  • narrative obligations;
  • presentation requirements;
  • filing requirements;
  • assurance requirements;
  • omission rules;
  • transition rules;
  • provenance.

24.14.2. Framework Requirement​

Every framework requirement SHALL possess:

  • Requirement Identifier;
  • source reference;
  • semantic meaning;
  • applicability;
  • content requirement;
  • format requirement;
  • evidence requirement;
  • assurance requirement;
  • omission treatment;
  • effective time;
  • provenance.

24.14.3. Disclosure Requirement Mapping​

A Publication Object MAY satisfy one or more framework requirements.

The mapping SHALL identify:

  • Publication Object;
  • framework requirement;
  • mapping type;
  • satisfaction status;
  • evidence;
  • limitations;
  • assurance;
  • provenance.

24.14.4. Mapping Types​

Mapping Types MAY include:

  • exact satisfaction;
  • partial satisfaction;
  • conditional satisfaction;
  • aggregated satisfaction;
  • decomposed satisfaction;
  • reference satisfaction;
  • narrative satisfaction;
  • machine-data satisfaction;
  • no satisfaction.

24.14.5. Multi-Framework Mapping​

Where one Publication Object supports multiple frameworks, each mapping SHALL remain independent.

A shared label SHALL not imply identical meaning.

24.14.6. Framework Conflict​

Framework conflict SHALL preserve:

  • conflicting requirements;
  • affected Publication Objects;
  • authority;
  • resolution;
  • unresolved limitations;
  • audience impact;
  • assurance impact;
  • provenance.

24.14.7. Framework Transition​

A framework transition SHALL define:

  • prior version;
  • new version;
  • effective period;
  • transition relief;
  • comparative treatment;
  • mapping changes;
  • assurance impact;
  • migration;
  • provenance.

24.14.8. Framework-Specific Formats​

Framework-specific formats MAY include:

  • structured regulatory templates;
  • XBRL;
  • Inline XBRL;
  • XHTML;
  • XML;
  • prescribed tables;
  • regulator APIs;
  • passport schemas;
  • signed filing packages.

Format conformance SHALL not establish semantic completeness by itself.

24.14.9. CSRD and ESRS Publication Profile​

A CSRD and ESRS Publication Profile SHOULD identify:

  • reporting undertaking;
  • consolidation boundary;
  • sustainability statement structure;
  • reporting period;
  • ESRS version;
  • material matters;
  • disclosure requirements;
  • datapoints;
  • policies, actions, targets and metrics;
  • value-chain treatment;
  • phase-in provisions;
  • omission and non-applicability treatment;
  • assurance scope;
  • digital tagging requirements;
  • provenance.

24.14.10. EU Taxonomy Publication Profile​

An EU Taxonomy Publication Profile SHOULD identify:

  • reporting entity;
  • economic activities;
  • eligibility;
  • alignment;
  • technical screening criteria;
  • substantial contribution;
  • DNSH;
  • minimum safeguards;
  • turnover, CapEx and OpEx KPIs;
  • allocation methodology;
  • double-counting controls;
  • tables;
  • evidence;
  • assurance;
  • provenance.

24.14.11. Product and Carbon Passport Profile​

A passport profile SHOULD identify:

  • passport subject;
  • product or asset identity;
  • manufacturer or responsible operator;
  • lifecycle version;
  • data fields;
  • units;
  • carbon and lifecycle methodology;
  • supply-chain evidence;
  • verification;
  • update triggers;
  • public and restricted fields;
  • machine schema;
  • signature;
  • revocation;
  • provenance.

24.14.12. Framework Profile Validation​

HECATE SHALL validate:

  • framework identity;
  • source authority;
  • version;
  • requirement mappings;
  • transition rules;
  • omission treatment;
  • format requirements;
  • assurance;
  • provenance.

24.15. Audience Profiles​

An Audience Profile defines the intended recipient class, information needs, access entitlement, disclosure depth, language, accessibility and interaction requirements for a Publication.

Audience SHALL be explicit.

“Public,” “customer,” “investor,” “regulator” and “internal” SHALL not be treated as equivalent or interchangeable audiences.

24.15.1. Audience Profile Identity​

Every Audience Profile SHALL possess:

  • Audience Profile Identifier;
  • canonical name;
  • audience class;
  • purpose;
  • eligibility criteria;
  • identity requirements;
  • access requirements;
  • disclosure entitlement;
  • required detail;
  • prohibited detail;
  • language;
  • accessibility;
  • jurisdiction;
  • channel permissions;
  • retention;
  • lifecycle;
  • version;
  • provenance.

24.15.2. Audience Classes​

Audience Classes MAY include:

  • public;
  • investor;
  • lender;
  • customer;
  • consumer;
  • employee;
  • worker representative;
  • supplier;
  • business partner;
  • affected community;
  • NGO;
  • academic;
  • regulator;
  • public authority;
  • auditor;
  • assurance provider;
  • verifier;
  • board;
  • executive management;
  • tenant user;
  • tenant administrator;
  • white-label operator;
  • legal counsel;
  • security investigator;
  • data subject;
  • product user.

24.15.3. Audience Identity​

An audience MAY be:

  • anonymous class;
  • authenticated class;
  • named organisation;
  • named natural person;
  • Role-based group;
  • tenant;
  • regulator;
  • verifier network;
  • contractual recipient;
  • public registry user.

24.15.4. Audience Entitlement​

Entitlement SHALL be resolved from:

  • identity;
  • Role;
  • relationship;
  • tenant;
  • contract;
  • legal basis;
  • regulator authority;
  • assurance engagement;
  • disclosure policy;
  • public classification.

24.15.5. Audience Purpose​

Audience purpose MAY include:

  • statutory review;
  • investment decision;
  • purchasing decision;
  • assurance;
  • audit;
  • supplier improvement;
  • governance;
  • public transparency;
  • research;
  • incident response;
  • product use;
  • due diligence.

24.15.6. Audience Detail Level​

Detail levels MAY include:

  • summary;
  • standard;
  • detailed;
  • technical;
  • evidence-supported;
  • forensic;
  • machine-complete.

Detail level SHALL not override disclosure restrictions.

24.15.7. Audience-Specific Representation​

The same Publication Subject MAY require separate representations for:

  • public audience;
  • regulator;
  • assurer;
  • board;
  • tenant operator;
  • supplier.

Each representation SHALL preserve its relationship to the same underlying Publication Objects where applicable.

24.15.8. Public Audience​

A Public Audience Profile SHALL require explicit public-release authority.

It SHALL define:

  • anonymous access;
  • indexing;
  • caching;
  • reuse;
  • download;
  • machine access;
  • licence;
  • personal-data treatment;
  • trade-secret treatment;
  • public correction;
  • archive.

24.15.9. Regulator Audience​

A Regulator Audience Profile MAY require:

  • regulator identity;
  • legal basis;
  • filing mandate;
  • prescribed format;
  • secure channel;
  • acknowledgement;
  • correction protocol;
  • confidential annex;
  • assurance package;
  • retention.

24.15.10. Assurance Audience​

An Assurance Audience Profile MAY permit access to:

  • evidence;
  • methodology;
  • controls;
  • workpapers;
  • management representations;
  • limitations;
  • unresolved findings.

Access SHALL remain engagement-bound.

24.15.11. Stakeholder Audience​

A Stakeholder Audience Profile SHOULD identify:

  • stakeholder category;
  • information need;
  • material matter;
  • appropriate level of detail;
  • accessibility;
  • language;
  • feedback channel;
  • confidentiality.

24.15.12. Audience Collision​

An Audience Collision exists where one package combines audiences with incompatible disclosure entitlements.

The Runtime SHALL:

  • split the package;
  • produce redacted projections;
  • use restricted annexes;
  • deny combined publication;
  • require separate releases.

24.15.13. Audience Change​

A change in audience SHALL trigger re-evaluation of:

  • disclosure;
  • security;
  • language;
  • accessibility;
  • channel;
  • approval;
  • assurance;
  • retention;
  • publication eligibility.

24.15.14. Audience Validation​

HECATE SHALL validate:

  • profile identity;
  • audience class;
  • entitlement;
  • purpose;
  • detail level;
  • disclosure compatibility;
  • channel compatibility;
  • language;
  • accessibility;
  • provenance.

24.16. Disclosure Profiles​

A Disclosure Profile defines which content may, must or must not be disclosed to an audience for a defined purpose.

Disclosure SHALL be evaluated independently from data access.

An actor may be permitted to access source data while lacking authority to publish it.

24.16.1. Disclosure Profile Identity​

Every Disclosure Profile SHALL possess:

  • Disclosure Profile Identifier;
  • audience;
  • purpose;
  • subject scope;
  • content scope;
  • permitted content;
  • mandatory content;
  • prohibited content;
  • masking;
  • redaction;
  • aggregation;
  • minimisation;
  • legal basis;
  • tenant;
  • jurisdiction;
  • export policy;
  • retention;
  • approval;
  • lifecycle;
  • version;
  • provenance.

24.16.2. Disclosure Decisions​

Disclosure Decision classes MAY include:

  • Disclose;
  • Disclose with Conditions;
  • Disclose in Aggregated Form;
  • Disclose with Redaction;
  • Disclose to Restricted Audience;
  • Embargo;
  • Do Not Disclose;
  • Indeterminate.

24.16.3. Content-Level Disclosure​

Disclosure SHALL be applicable to:

  • Publication Object;
  • property;
  • metric;
  • narrative;
  • evidence reference;
  • assurance statement;
  • footnote;
  • annex;
  • graph node;
  • graph relationship;
  • source identity;
  • methodology;
  • uncertainty;
  • limitation.

24.16.4. Mandatory Disclosure​

Mandatory disclosure SHALL identify:

  • requirement source;
  • affected content;
  • audience;
  • deadline;
  • format;
  • assurance;
  • permitted omission;
  • provenance.

Mandatory disclosure does not automatically authorise disclosure of supporting confidential evidence.

24.16.5. Prohibited Disclosure​

Prohibition MAY arise from:

  • personal-data law;
  • legal privilege;
  • trade-secret protection;
  • tenant restriction;
  • national security;
  • regulator confidentiality;
  • assurance confidentiality;
  • contractual restriction;
  • active investigation;
  • embargo;
  • source licence.

24.16.6. Minimisation​

Disclosure minimisation SHALL limit:

  • properties;
  • subjects;
  • records;
  • granularity;
  • time period;
  • geography;
  • evidence detail;
  • identifiers;
  • personal data;
  • supply-chain detail.

Minimisation SHALL not make a Publication misleading.

24.16.7. Aggregation​

Aggregation SHALL define:

  • population;
  • grouping;
  • threshold;
  • methodology;
  • suppressed groups;
  • inference risk;
  • uncertainty;
  • provenance.

24.16.8. Redaction​

Redaction SHALL preserve:

  • redacted element identity;
  • reason;
  • authority;
  • legal or policy basis;
  • audience;
  • duration;
  • effect on interpretation;
  • controlled-access path;
  • provenance.

24.16.9. Masking​

Masking MAY include:

  • full suppression;
  • partial masking;
  • pseudonymisation;
  • generalisation;
  • range;
  • tokenisation;
  • category substitution.

Masking SHALL not alter the underlying authoritative value.

24.16.10. Restricted Annex​

A Publication Package MAY contain a Restricted Annex with a different Audience and Disclosure Profile.

The package SHALL preserve:

  • annex identity;
  • permitted audience;
  • relationship to main publication;
  • security;
  • assurance;
  • distribution;
  • provenance.

24.16.11. Embargo​

An embargo SHALL identify:

  • protected content;
  • start;
  • end;
  • authorised pre-release audience;
  • release trigger;
  • breach treatment;
  • provenance.

24.16.12. Public-Domain Source​

The public availability of a source SHALL not automatically authorise republication.

The Runtime SHALL preserve:

  • source licence;
  • attribution;
  • jurisdiction;
  • permitted use;
  • modification rights;
  • expiry;
  • provenance.

24.16.13. Disclosure Explanation​

Every restricted, redacted or omitted material disclosure SHOULD support an explanation identifying:

  • affected content;
  • governing reason;
  • effect on understanding;
  • whether alternate access exists;
  • review or expiry;
  • provenance.

24.16.14. Disclosure Validation​

HECATE SHALL validate:

  • audience;
  • purpose;
  • legal basis;
  • content scope;
  • prohibited content;
  • redaction;
  • aggregation;
  • minimisation;
  • annex separation;
  • embargo;
  • provenance.

24.17. Channel Profiles​

A Channel Profile defines the constitutional and technical requirements for distributing a Publication Release through a delivery channel.

Channel availability SHALL not establish channel eligibility.

24.17.1. Channel Profile Identity​

Every Channel Profile SHALL possess:

  • Channel Profile Identifier;
  • canonical name;
  • channel type;
  • operator;
  • destination class;
  • supported audiences;
  • supported publication classes;
  • supported formats;
  • identity requirements;
  • security;
  • availability;
  • acceptance protocol;
  • receipt protocol;
  • correction protocol;
  • withdrawal protocol;
  • retention;
  • lifecycle;
  • version;
  • provenance.

24.17.2. Channel Types​

Channel Types MAY include:

  • regulatory filing portal;
  • public website;
  • tenant portal;
  • secure workspace;
  • verifier portal;
  • assurance data room;
  • API;
  • webhook;
  • email;
  • managed file transfer;
  • document exchange;
  • public registry;
  • product-passport network;
  • distributed ledger;
  • print;
  • physical delivery.

24.17.3. Channel Authority​

Channel operation SHALL require:

  • Component Authority;
  • destination authority;
  • tenant scope;
  • publication-class permission;
  • effective time;
  • security state;
  • channel readiness.

24.17.4. Regulatory Channel​

A Regulatory Channel Profile SHOULD define:

  • regulator;
  • regulated entity identity;
  • filing credentials;
  • filing taxonomy;
  • submission format;
  • endpoint;
  • acceptance status;
  • validation messages;
  • correction process;
  • filing receipt;
  • filing deadline;
  • provenance.

24.17.5. Public Website Channel​

A Public Website Channel Profile SHALL define:

  • public domain;
  • publication path;
  • caching;
  • indexing;
  • accessibility;
  • language;
  • download;
  • machine metadata;
  • correction banner;
  • supersession;
  • withdrawal;
  • archive.

24.17.6. EcoWorld Channel​

An EcoWorld Channel Profile MAY define publication of:

  • educational content;
  • public ESG records;
  • methodological explanations;
  • Academy materials;
  • public sustainability intelligence;
  • stakeholder guidance.

EcoWorld publication SHALL not expose protected ZAYAZ tenant data.

24.17.7. E-C-O Number Lookup Channel​

An E-C-O Number lookup profile SHOULD define:

  • public identifier;
  • subject identity;
  • public status;
  • verified public properties;
  • provenance summary;
  • correction state;
  • restricted-property exclusions;
  • cache state;
  • API representation;
  • availability.

24.17.8. API Channel​

An API Channel Profile SHALL define:

  • endpoint;
  • authentication;
  • audience;
  • schema;
  • version;
  • rate;
  • caching;
  • pagination;
  • error model;
  • content negotiation;
  • tenant isolation;
  • receipt or access event;
  • deprecation.

24.17.9. Email Channel​

Email publication SHALL define:

  • recipient;
  • recipient validation;
  • encryption where required;
  • attachment policy;
  • link policy;
  • expiry;
  • recall limitations;
  • delivery evidence;
  • bounce handling;
  • confidentiality warning.

24.17.10. Secure Workspace Channel​

A secure workspace SHALL define:

  • membership;
  • Role;
  • engagement;
  • tenant;
  • document access;
  • download;
  • watermarking;
  • expiry;
  • activity logging;
  • revocation.

24.17.11. Channel Failure​

Channel failure MAY include:

  • authentication failure;
  • validation rejection;
  • endpoint unavailable;
  • wrong destination;
  • partial upload;
  • receipt missing;
  • checksum mismatch;
  • format rejection;
  • deadline breach.

Failure SHALL preserve retry and escalation state.

24.17.12. Channel Substitution​

A channel MAY be substituted only where:

  • the Publication Profile permits it;
  • audience remains equivalent;
  • security is equivalent or stronger;
  • legal requirements remain satisfied;
  • format remains valid;
  • approval remains applicable;
  • provenance records the substitution.

24.17.13. Channel Validation​

HECATE SHALL validate:

  • profile identity;
  • operator;
  • destination;
  • audience;
  • format;
  • security;
  • acceptance protocol;
  • correction and withdrawal support;
  • effective state;
  • provenance.

24.18. Format and Rendering Profiles​

A Format and Rendering Profile defines how Publication Objects and Packages are represented without changing their constitutional meaning.

Rendering SHALL be a governed transformation.

24.18.1. Format Profile Identity​

Every Format Profile SHALL possess:

  • Format Profile Identifier;
  • format;
  • media type;
  • schema;
  • version;
  • encoding;
  • layout rules;
  • semantic mapping;
  • accessibility;
  • signature support;
  • metadata;
  • validation;
  • lifecycle;
  • provenance.

24.18.2. Supported Formats​

Formats MAY include:

  • PDF;
  • PDF/A;
  • HTML;
  • XHTML;
  • MDX;
  • Markdown;
  • JSON;
  • JSON-LD;
  • XML;
  • XBRL;
  • Inline XBRL;
  • CSV;
  • spreadsheet;
  • RDF;
  • graph serialization;
  • image;
  • signed archive;
  • printed document.

24.18.3. Semantic Equivalence​

Multiple renderings of one Publication Release SHALL be semantically equivalent within declared format limitations.

Differences SHALL be identified and explained.

24.18.4. Authoritative Representation​

Where multiple formats exist, the Publication Profile SHALL identify:

  • authoritative representation;
  • equivalent representations;
  • convenience representations;
  • machine-authoritative representation;
  • human-authoritative representation;
  • conflict treatment.

24.18.5. Template Object​

A Publication Template SHALL possess:

  • Template Identifier;
  • intended Publication Profile;
  • format;
  • structure;
  • mandatory sections;
  • optional sections;
  • placeholders;
  • rendering rules;
  • styles;
  • accessibility;
  • version;
  • provenance.

A template SHALL not contain hidden constitutional logic.

24.18.6. Layout Rule​

Layout rules MAY govern:

  • section order;
  • headings;
  • table placement;
  • footnotes;
  • page numbering;
  • cross-references;
  • annexes;
  • labels;
  • units;
  • legends;
  • assurance markers;
  • correction markers.

24.18.7. Table Rendering​

Tables SHALL preserve:

  • row and column semantics;
  • units;
  • totals;
  • subtotals;
  • rounding;
  • missing values;
  • suppressed values;
  • comparative periods;
  • footnotes;
  • source linkage.

24.18.8. Visualisation Rendering​

A visualisation SHALL preserve:

  • metric identity;
  • axes;
  • units;
  • scale;
  • period;
  • data source;
  • aggregation;
  • uncertainty;
  • omitted values;
  • accessibility alternative;
  • provenance.

Visualisation design SHALL not materially distort interpretation.

24.18.9. Rounding​

Rounding SHALL define:

  • source precision;
  • display precision;
  • rounding mode;
  • aggregation order;
  • reconciliation tolerance;
  • disclosure of approximation;
  • provenance.

24.18.10. Null and Missing Values​

Formats SHALL distinguish:

  • zero;
  • not applicable;
  • not available;
  • not collected;
  • withheld;
  • confidential;
  • not assured;
  • estimated;
  • indeterminate.

Blank cells SHALL not be used where meaning would be ambiguous.

24.18.11. Machine Schema​

Machine-readable Publications SHALL expose:

  • semantic identifiers;
  • schema version;
  • units;
  • datatypes;
  • enumerations;
  • null semantics;
  • temporal semantics;
  • provenance references;
  • validation status.

24.18.12. Digital Signature​

A rendering MAY be signed.

Signature validation SHALL establish:

  • signer identity;
  • signer authority;
  • signed content digest;
  • signed scope;
  • signing time;
  • certificate;
  • revocation;
  • provenance.

24.18.13. Rendering Component​

The rendering Component SHALL preserve:

  • Component identity;
  • Module;
  • version;
  • template version;
  • format profile;
  • input digest;
  • output digest;
  • warnings;
  • provenance.

24.18.14. Rendering Validation​

HECATE SHALL validate:

  • format profile;
  • template;
  • semantic equivalence;
  • structure;
  • units;
  • rounding;
  • null semantics;
  • accessibility;
  • signatures;
  • output digest;
  • provenance.

24.19. Language, Localisation and Accessibility Profiles​

Language and accessibility SHALL be governed publication properties.

Translation and localisation SHALL not create independent constitutional meaning.

24.19.1. Language Profile​

A Language Profile SHALL identify:

  • canonical language;
  • permitted target languages;
  • jurisdictional language;
  • translation method;
  • review requirement;
  • terminology source;
  • legal-name treatment;
  • unit and number formatting;
  • date formatting;
  • assurance wording;
  • correction treatment;
  • provenance.

24.19.2. Canonical Language​

Every Publication Object SHOULD identify its canonical language.

A translation SHALL reference the canonical source version.

24.19.3. Translation Object​

A Translation Object SHALL possess:

  • Translation Identifier;
  • source Publication Object;
  • source language;
  • target language;
  • translator or Component;
  • translation method;
  • terminology profile;
  • review;
  • approval;
  • limitations;
  • version;
  • provenance.

24.19.4. Machine Translation​

Machine translation MAY be used where permitted.

It SHALL preserve:

  • model identity;
  • model version;
  • instructions;
  • source content;
  • glossary;
  • confidence or review state;
  • human review where required;
  • provenance.

Machine translation SHALL not be treated as approved legal translation without governed authority.

24.19.5. Terminology Profile​

A Terminology Profile SHOULD define:

  • constitutional terms;
  • framework terms;
  • approved translations;
  • prohibited substitutions;
  • abbreviations;
  • legal names;
  • unit names;
  • provenance.

24.19.6. Localisation​

Localisation MAY adapt:

  • date format;
  • number format;
  • currency presentation;
  • units;
  • address format;
  • examples;
  • jurisdictional notices;
  • contact details.

Localisation SHALL not alter the underlying metric or legal meaning.

24.19.7. Accessibility Profile​

An Accessibility Profile SHALL define:

  • applicable audience;
  • applicable channel;
  • semantic structure;
  • keyboard access;
  • screen-reader compatibility;
  • alternative text;
  • colour-independent meaning;
  • contrast;
  • captions;
  • transcript;
  • table semantics;
  • plain-language layer;
  • downloadable alternative;
  • validation;
  • provenance.

24.19.8. Alternative Representation​

Where one format cannot satisfy accessibility requirements, an equivalent accessible representation SHALL be provided where required.

24.19.9. Plain-Language Layer​

A plain-language representation MAY accompany a technical Publication.

It SHALL preserve:

  • material facts;
  • limitations;
  • uncertainty;
  • assurance;
  • correction state;
  • provenance.

It SHALL not replace the authoritative technical representation where the profile requires one.

24.19.10. Accessibility Exception​

An exception SHALL require:

  • reason;
  • affected content;
  • audience impact;
  • alternative access;
  • remediation;
  • authority;
  • expiration;
  • provenance.

24.19.11. Language and Accessibility Validation​

HECATE SHALL validate:

  • language profile;
  • source-target linkage;
  • terminology;
  • required review;
  • legal names;
  • accessibility structure;
  • alternate representations;
  • exceptions;
  • provenance.

24.20. Publication Eligibility​

Publication Eligibility determines whether source knowledge and Runtime Outcomes are constitutionally eligible to enter a Publication Package under resolved profiles.

Eligibility is not release approval.

24.20.1. Eligibility Request​

Every eligibility evaluation SHALL identify:

  • Eligibility Request Identifier;
  • Publication Request or Obligation;
  • source subjects;
  • Publication Context;
  • resolved profiles;
  • requested audience;
  • requested channel;
  • requested period;
  • authority;
  • provenance.

24.20.2. Eligibility Dimensions​

Eligibility SHALL evaluate:

  • source identity;
  • source authority;
  • source lifecycle;
  • tenant;
  • reporting boundary;
  • reporting period;
  • temporal validity;
  • materiality;
  • completeness;
  • validation;
  • evidence;
  • methodology;
  • uncertainty;
  • contradiction;
  • assurance readiness;
  • disclosure permission;
  • security;
  • legal hold;
  • unresolved findings;
  • correction state;
  • provenance.

24.20.3. Source Eligibility​

A source MAY be:

  • eligible;
  • eligible with qualification;
  • eligible only for restricted audience;
  • eligible only for internal use;
  • eligible after remediation;
  • ineligible;
  • indeterminate.

24.20.4. Eligible Source Types​

Eligible source types MAY include:

  • validated Constitutional Object;
  • validated Constitutional Assertion;
  • validated Relationship;
  • Computation Outcome;
  • Validation Outcome;
  • Governance Decision;
  • Reasoning Outcome;
  • Workflow Outcome;
  • approved agent output;
  • assurance evidence;
  • audit conclusion;
  • external source accepted under policy.

24.20.5. Provisional Source​

A provisional source MAY be publishable only where the Publication Profile permits provisional disclosure and requires explicit qualification.

24.20.6. Derived Assertion​

A Derived Assertion SHALL preserve:

  • premise lineage;
  • reasoning profile;
  • confidence;
  • contradiction state;
  • validation;
  • activation state;
  • publication permission.

Derived status SHALL be disclosed where material.

24.20.7. AI-Generated Source​

AI-generated content SHALL be ineligible for authoritative publication unless:

  • source and purpose are identified;
  • model and instructions are preserved;
  • evidence is linked;
  • hallucination and unsupported-claim controls are applied;
  • validation is complete;
  • human or governed authority approves;
  • provenance is complete.

24.20.8. External Source​

An external source SHALL preserve:

  • source identity;
  • publisher;
  • acquisition time;
  • licence;
  • authority;
  • quality;
  • temporal validity;
  • integrity;
  • permitted use;
  • provenance.

External publication shall not establish constitutional truth automatically.

24.20.9. Validation Requirement​

The Publication Profile SHALL define required validation status.

Possible requirements MAY include:

  • structurally valid;
  • semantically valid;
  • governance valid;
  • temporally valid;
  • provenance valid;
  • evidence valid;
  • cross-object valid;
  • fully valid.

24.20.10. Evidence Sufficiency​

Evidence sufficiency SHALL consider:

  • claim;
  • evidence quantity;
  • relevance;
  • reliability;
  • completeness;
  • temporal applicability;
  • assurance;
  • contradiction;
  • chain of custody.

24.20.11. Assurance Readiness​

Assurance readiness SHALL identify whether:

  • assurance is not required;
  • source is ready for assurance;
  • assurance is in progress;
  • assurance is complete;
  • assurance contains limitations;
  • assurance failed;
  • assurance scope does not cover the source.

24.20.12. Unresolved Findings​

A finding MAY:

  • block publication;
  • require qualification;
  • require restricted audience;
  • require remediation;
  • be immaterial to the publication;
  • require explicit disclosure.

Treatment SHALL be profile-governed.

24.20.13. Contradiction​

Unresolved contradiction SHALL not be concealed.

The profile SHALL determine whether contradiction:

  • blocks publication;
  • requires qualification;
  • permits separate views;
  • requires further evidence;
  • permits restricted publication only.

24.20.14. Staleness​

A source SHALL be evaluated against freshness requirements.

Stale sources MAY be:

  • prohibited;
  • permitted with qualification;
  • permitted for historical reporting;
  • permitted pending update;
  • accepted under transition rule.

24.20.15. Eligibility Outcome​

A Publication Eligibility Outcome SHALL possess:

  • Eligibility Outcome Identifier;
  • Publication Request;
  • Publication Context;
  • resolved profiles;
  • evaluated sources;
  • eligible sources;
  • restricted sources;
  • ineligible sources;
  • missing requirements;
  • required remediation;
  • required qualifications;
  • blocking findings;
  • assurance state;
  • authority state;
  • decision;
  • explanation;
  • provenance.

24.20.16. Eligibility Decision Classes​

Decision classes SHALL include:

  • Eligible;
  • Eligible with Conditions;
  • Eligible for Restricted Publication;
  • Remediation Required;
  • Ineligible;
  • Indeterminate;
  • Not Applicable;
  • Not Evaluated.

Not Evaluated and Indeterminate SHALL NOT be treated as Eligible.

24.20.17. Eligibility Expiration​

Eligibility SHALL expire upon material change to:

  • source;
  • Publication Context;
  • profile;
  • authority;
  • assurance;
  • evidence;
  • validation;
  • audience;
  • channel;
  • reporting period;
  • security;
  • correction state.

24.20.18. Eligibility Reuse​

A prior outcome MAY be reused only where:

  • source versions match;
  • Publication Context Fingerprint matches;
  • profile versions match;
  • authority remains valid;
  • evidence remains valid;
  • assurance remains valid;
  • no correction or revocation applies;
  • reuse policy permits.

24.20.19. Eligibility Explanation​

The Runtime SHALL explain:

  • which sources were evaluated;
  • which profiles applied;
  • which requirements were met;
  • which were not met;
  • which conditions apply;
  • which findings block release;
  • whether assurance is required;
  • whether restricted publication is possible;
  • provenance.

24.20.20. Eligibility Validation​

HECATE SHALL validate:

  • request;
  • context;
  • profiles;
  • source versions;
  • materiality;
  • validation;
  • evidence;
  • assurance readiness;
  • security;
  • decision consistency;
  • explanation;
  • provenance.

24.21. Materiality, Completeness and Coverage​

Publication eligibility SHALL evaluate whether the Publication Package adequately covers the information required by the applicable profile.

Completeness SHALL not be inferred from document length or field population alone.

24.21.1. Publication Materiality Object​

A Publication Materiality Object SHALL identify:

  • Materiality Identifier;
  • subject;
  • framework;
  • audience;
  • period;
  • threshold;
  • qualitative factors;
  • decision;
  • authority;
  • evidence;
  • version;
  • provenance.

24.21.2. Quantitative Materiality​

Quantitative materiality MAY use:

  • absolute threshold;
  • relative threshold;
  • percentage;
  • financial threshold;
  • emissions threshold;
  • workforce threshold;
  • affected-person threshold;
  • product threshold;
  • risk threshold.

24.21.3. Qualitative Materiality​

Qualitative materiality MAY consider:

  • regulatory sensitivity;
  • human-rights severity;
  • environmental irreversibility;
  • stakeholder significance;
  • governance failure;
  • fraud;
  • controversy;
  • strategic importance;
  • public-interest impact;
  • assurance significance.

24.21.4. Double Materiality​

Where applicable, double materiality SHALL distinguish:

  • impact materiality;
  • financial materiality;
  • combined materiality;
  • assessment period;
  • value-chain scope;
  • affected stakeholders;
  • evidence;
  • decision;
  • provenance.

24.21.5. Coverage Matrix​

A Publication Coverage Matrix SHOULD map:

  • profile requirement;
  • framework requirement;
  • Publication Object;
  • coverage state;
  • source;
  • evidence;
  • assurance;
  • omission;
  • limitation;
  • provenance.

24.21.6. Coverage States​

Coverage MAY be:

  • complete;
  • complete with qualification;
  • partial;
  • omitted with basis;
  • not applicable;
  • prohibited;
  • missing;
  • indeterminate.

24.21.7. Completeness Evaluation​

Completeness SHALL evaluate:

  • required sections;
  • required metrics;
  • required narratives;
  • required periods;
  • required entities;
  • required value-chain scope;
  • required methodologies;
  • required evidence;
  • required assurance;
  • required explanations.

24.21.8. Comparative Information​

Comparative information SHALL preserve:

  • comparative period;
  • methodology consistency;
  • restatement;
  • boundary change;
  • unit change;
  • unavailable comparison;
  • explanation;
  • provenance.

24.21.9. Boundary Completeness​

Boundary completeness SHALL evaluate:

  • legal entities;
  • operations;
  • facilities;
  • products;
  • value-chain stages;
  • geographies;
  • activities;
  • excluded subjects;
  • joint operations;
  • acquisitions and disposals;
  • provenance.

24.21.10. Coverage Gap​

A Coverage Gap SHALL identify:

  • requirement;
  • missing subject;
  • missing period;
  • missing source;
  • reason;
  • materiality;
  • remediation;
  • publication effect;
  • provenance.

24.21.11. Coverage Qualification​

A qualification SHALL identify:

  • affected requirement;
  • limitation;
  • reason;
  • effect;
  • expected resolution;
  • assurance effect;
  • audience effect;
  • provenance.

24.21.12. Completeness Validation​

HECATE SHALL validate:

  • materiality;
  • Coverage Matrix;
  • required subjects;
  • required periods;
  • boundary;
  • comparative information;
  • gaps;
  • qualifications;
  • provenance.

24.22. Omission, Non-Applicability and Confidentiality Treatment​

The Runtime SHALL distinguish omission, non-applicability, unavailability, confidentiality and prohibition.

These states SHALL not be collapsed into a blank field.

24.22.1. Omission Object​

Every material omission SHALL possess:

  • Omission Identifier;
  • omitted requirement;
  • omitted content;
  • omission type;
  • reason;
  • authority;
  • legal or framework basis;
  • materiality;
  • expected duration;
  • remediation;
  • audience effect;
  • assurance effect;
  • provenance.

24.22.2. Omission Types​

Omission Types MAY include:

  • permitted omission;
  • temporary omission;
  • confidentiality omission;
  • legal prohibition;
  • intellectual-property omission;
  • security omission;
  • data-unavailable omission;
  • transition-relief omission;
  • immaterial omission;
  • non-applicable requirement;
  • unsupported omission.

24.22.3. Non-Applicability​

A non-applicable requirement SHALL identify:

  • requirement;
  • subject;
  • applicability rule;
  • evaluated context;
  • reason;
  • evidence;
  • authority;
  • provenance.

Non-applicability SHALL not mean that data was unavailable.

24.22.4. Data Unavailability​

Data unavailability SHALL identify:

  • missing data;
  • expected source;
  • reason;
  • collection effort;
  • estimation option;
  • remediation plan;
  • expected availability;
  • impact;
  • provenance.

24.22.5. Confidentiality Omission​

A confidentiality omission SHALL identify:

  • protected interest;
  • legal or contractual basis;
  • disclosure risk;
  • alternative disclosure;
  • aggregation or redaction option;
  • authority;
  • review date;
  • provenance.

24.22.6. Sensitive Information​

Sensitive information MAY include:

  • personal data;
  • special-category personal data;
  • trade secrets;
  • legally privileged information;
  • security-sensitive information;
  • regulator-confidential information;
  • assurance-confidential information;
  • commercially sensitive negotiations;
  • whistleblower information.

24.22.7. Alternative Disclosure​

Where full disclosure is prohibited or harmful, the profile MAY require:

  • aggregated disclosure;
  • range;
  • narrative summary;
  • restricted annex;
  • delayed disclosure;
  • regulator-only disclosure;
  • evidence reference without reproduction.

24.22.8. Omission Explanation​

A Publication SHALL explain material omissions where required, without disclosing the protected content itself.

24.22.9. Omission Approval​

Material omission MAY require approval by:

  • Publication Authority;
  • legal authority;
  • reporting authority;
  • assurance provider;
  • regulator;
  • tenant governance;
  • security authority.

24.22.10. Omission Expiration​

Temporary omission SHALL possess an expiration or review date.

The Runtime SHALL monitor unresolved omissions.

24.22.11. Unsupported Omission​

An omission without valid basis SHALL:

  • block publication;
  • create a Finding;
  • require remediation;
  • affect assurance;
  • require escalation.

24.22.12. Omission Validation​

HECATE SHALL validate:

  • omission identity;
  • type;
  • basis;
  • authority;
  • materiality;
  • alternative disclosure;
  • duration;
  • assurance impact;
  • explanation;
  • provenance.

24.23. Profile Resolution and Publication Eligibility Runtime​

The Publication Profile Resolution Runtime coordinates CRP, HECATE, Governance Runtime, Security Runtime and Temporal Runtime to produce a deterministic publication-control outcome.

24.23.1. Resolution Request​

A resolution request SHALL identify:

  • Publication Request;
  • Publication Context;
  • subject;
  • audience;
  • purpose;
  • framework;
  • jurisdiction;
  • tenant;
  • channel;
  • time;
  • requested assurance;
  • provenance.

24.23.2. Candidate Profiles​

Candidate profiles MAY include:

  • Core Publication Profile;
  • framework profile;
  • jurisdictional profile;
  • white-label profile;
  • tenant profile;
  • organisation profile;
  • subject profile;
  • audience profile;
  • disclosure profile;
  • channel profile;
  • format profile;
  • language profile;
  • accessibility profile;
  • assurance profile;
  • retention profile.

24.23.3. Candidate Evaluation​

Each candidate SHALL be evaluated for:

  • identity;
  • authority;
  • lifecycle;
  • temporal validity;
  • applicability;
  • tenant;
  • subject;
  • audience;
  • purpose;
  • framework;
  • jurisdiction;
  • channel;
  • compatibility;
  • precedence;
  • provenance.

24.23.4. Resolution Outcome​

A Publication Profile Resolution Outcome SHALL preserve:

  • Resolution Outcome Identifier;
  • request;
  • candidate profiles;
  • selected profiles;
  • rejected profiles;
  • precedence;
  • overrides;
  • conflicts;
  • unresolved issues;
  • effective requirements;
  • Publication Context Fingerprint;
  • explanation;
  • provenance.

24.23.5. Effective Publication Requirement Set​

The effective requirement set SHALL contain:

  • mandatory content;
  • conditional content;
  • prohibited content;
  • validation;
  • approval;
  • assurance;
  • audience;
  • disclosure;
  • channel;
  • format;
  • language;
  • accessibility;
  • deadlines;
  • omissions;
  • retention;
  • correction.

24.23.6. Requirement Identity​

Every effective requirement SHALL preserve:

  • source profile;
  • source requirement;
  • authority;
  • precedence;
  • override state;
  • effective time;
  • provenance.

24.23.7. Resolution Determinism​

Equivalent requests, contexts, profile versions and authority state SHALL produce semantically equivalent outcomes.

24.23.8. Resolution Cache​

A cached outcome MAY be reused only where:

  • Publication Context Fingerprint matches;
  • candidate profile versions remain valid;
  • authority remains valid;
  • no revocation exists;
  • time remains valid;
  • tenant remains equivalent;
  • cache policy permits.

24.23.9. Resolution Failure​

Failure MAY occur where:

  • no applicable profile exists;
  • multiple incompatible profiles apply;
  • authority is unclear;
  • tenant is unresolved;
  • audience is ambiguous;
  • jurisdiction is unresolved;
  • required framework version is unavailable;
  • profile provenance is incomplete.

Failure SHALL produce Indeterminate, not permissive eligibility.

24.23.10. Resolution Explanation​

The Runtime SHALL explain:

  • which profiles were considered;
  • which were selected;
  • why others were rejected;
  • which precedence rules applied;
  • which overrides applied;
  • which conflicts remain;
  • which effective requirements resulted;
  • provenance.

24.23.11. HECATE Resolution Validation​

HECATE SHALL validate:

  • request identity;
  • context;
  • candidate profiles;
  • selected profiles;
  • precedence;
  • overrides;
  • conflicts;
  • effective requirement set;
  • explanation;
  • provenance.

24.24. Profile and Eligibility Provenance, Events and Conformance​

Publication profile and eligibility decisions SHALL preserve complete lineage.

24.24.1. Profile Provenance​

Profile provenance SHALL include:

  • profile identity;
  • source authority;
  • framework source;
  • version;
  • inheritance;
  • composition;
  • overrides;
  • approvals;
  • effective time;
  • compiler lineage;
  • Runtime Bundle;
  • Module;
  • Component;
  • provenance.

24.24.2. Eligibility Provenance​

Eligibility provenance SHALL include:

  • Publication Request;
  • Publication Context;
  • source subjects;
  • source versions;
  • profile-resolution outcome;
  • validation;
  • evidence;
  • materiality;
  • Coverage Matrix;
  • omissions;
  • disclosure decisions;
  • assurance readiness;
  • authority;
  • security;
  • outcome;
  • explanation;
  • timestamps;
  • provenance.

24.24.3. Profile Events​

The Runtime SHOULD emit:

  • PublicationProfileProposed;
  • PublicationProfileApproved;
  • PublicationProfileActivated;
  • PublicationProfileSuspended;
  • PublicationProfileSuperseded;
  • PublicationProfileWithdrawn;
  • AudienceProfileChanged;
  • DisclosureProfileChanged;
  • ChannelProfileChanged;
  • FormatProfileChanged;
  • FrameworkProfileChanged.

24.24.4. Eligibility Events​

The Runtime SHOULD emit:

  • PublicationEligibilityRequested;
  • PublicationEligibilityEvaluated;
  • PublicationEligible;
  • PublicationConditionallyEligible;
  • PublicationRestricted;
  • PublicationRemediationRequired;
  • PublicationIneligible;
  • PublicationEligibilityExpired;
  • PublicationCoverageGapDetected;
  • PublicationOmissionApproved;
  • PublicationOmissionRejected.

24.24.5. Profile Diff​

A Profile Diff SHOULD identify changes in:

  • applicability;
  • content requirements;
  • audience;
  • disclosure;
  • assurance;
  • channel;
  • format;
  • language;
  • accessibility;
  • omissions;
  • deadlines;
  • retention;
  • authority;
  • provenance.

24.24.6. Eligibility Diff​

An Eligibility Diff SHOULD identify changes in:

  • source;
  • context;
  • selected profiles;
  • validation;
  • evidence;
  • materiality;
  • coverage;
  • omissions;
  • assurance readiness;
  • authority;
  • security;
  • outcome.

24.24.7. Impact Analysis​

A profile change SHALL support impact analysis over:

  • active publication requests;
  • draft packages;
  • approved packages;
  • pending assurance;
  • release-ready packages;
  • existing releases;
  • future obligations;
  • channels;
  • tenants;
  • white-label deployments;
  • Modules;
  • Components.

24.24.8. Pergamum Pulse Integration​

Pergamum Pulse MAY derive intelligence including:

  • profile coverage gaps;
  • profile conflict concentration;
  • repeated override use;
  • audience collision;
  • disclosure risk;
  • channel incompatibility;
  • framework mapping gaps;
  • materiality inconsistency;
  • recurring omissions;
  • eligibility bottlenecks;
  • assurance-readiness delays;
  • tenant publication divergence;
  • Module-level publication risk;
  • Component-level publication risk.

Pergamum Pulse SHALL preserve:

  • Module lineage;
  • Component lineage;
  • Publication Profile lineage;
  • Framework Profile lineage;
  • Audience Profile lineage;
  • Disclosure Profile lineage;
  • Channel Profile lineage;
  • Eligibility Outcome lineage;
  • tenant lineage;
  • temporal validity;
  • provenance.

Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.

24.24.9. Part II Conformance Suite​

The Constitutional Compiler Framework SHOULD generate fixtures including:

  • Core profile resolution;
  • framework-profile composition;
  • jurisdictional overlay;
  • white-label overlay;
  • tenant overlay;
  • profile conflict;
  • prohibited override;
  • audience collision;
  • public disclosure;
  • regulator disclosure;
  • restricted annex;
  • channel substitution;
  • format equivalence;
  • translation review;
  • accessibility exception;
  • valid eligibility;
  • conditional eligibility;
  • restricted eligibility;
  • provisional source;
  • AI-generated source;
  • stale source;
  • unresolved contradiction;
  • material Coverage Gap;
  • valid omission;
  • unsupported omission;
  • eligibility expiration;
  • historical profile replay.

Part II Conformance​

An implementation conforms to Part II of the Constitutional Publication Framework where it:

  1. represents Publication Profiles as governed Constitutional Objects;
  2. uses profiles rather than application convention to determine publication requirements;
  3. preserves identity, authority, version, lifecycle and provenance for every profile;
  4. supports Core, framework, jurisdictional, white-label, tenant, organisation and subject-specific profile composition;
  5. prevents lower-order profiles from weakening non-overrideable controls;
  6. represents profile conflict, precedence and override explicitly;
  7. preserves framework identity and version for every framework-derived requirement;
  8. maps Publication Objects to framework requirements without collapsing distinct framework meanings;
  9. represents audiences through governed Audience Profiles;
  10. resolves audience entitlement independently from technical access;
  11. detects incompatible multi-audience packages;
  12. represents disclosure through mandatory, permitted, restricted, redacted, aggregated, embargoed and prohibited states;
  13. distinguishes access permission from publication permission;
  14. governs channels through explicit Channel Profiles;
  15. prevents channel availability from creating publication authority;
  16. governs rendering through versioned Format and Rendering Profiles;
  17. preserves semantic equivalence across multiple renderings;
  18. identifies the authoritative representation where multiple formats exist;
  19. distinguishes zero, missing, unavailable, confidential, estimated and not-applicable values;
  20. governs language, translation, localisation and accessibility;
  21. preserves canonical-language linkage and translation provenance;
  22. evaluates Publication Eligibility independently from release approval;
  23. evaluates source identity, authority, lifecycle, validation, evidence, materiality, assurance, security and temporal validity;
  24. prevents AI-generated content from becoming authoritative without governed validation and approval;
  25. represents eligibility through explicit decision classes;
  26. prevents Indeterminate and Not Evaluated from being treated as Eligible;
  27. represents materiality, Coverage Matrices, gaps and qualifications explicitly;
  28. distinguishes omission, non-applicability, data unavailability, confidentiality and legal prohibition;
  29. prevents unsupported omissions from passing eligibility;
  30. resolves profiles through CRP and validates outcomes through HECATE;
  31. preserves Publication Context Fingerprints and exact profile versions;
  32. supports replay, diff and impact analysis;
  33. preserves both Module and Component lineage;
  34. integrates Pergamum Pulse without granting intelligence automatic publication authority;
  35. provides a conformance suite covering profile composition, audiences, disclosure, channels, rendering, eligibility, materiality and omissions.

Part II Foundational Principle​

Publication Profiles are the governed constitutional mechanism through which ZAYAZ determines what may or must be published, to whom, for which purpose, under which framework, through which channel and under which conditions.

Publication eligibility SHALL be based on explicit profile resolution, source identity, authority, validation, evidence, materiality, assurance readiness, disclosure permission, temporal applicability, security and provenance. Technical availability, prior publication, user-interface visibility, agent generation or content-management access SHALL not create eligibility.

Audience, disclosure, channel, format, language, accessibility and assurance requirements SHALL remain explicit and independently governed. Omissions, non-applicability, confidentiality, unavailability and prohibited disclosure SHALL remain distinguishable and SHALL never be represented through unexplained blanks.

By making publication profile-driven, audience-aware, disclosure-controlled, framework-mapped, channel-governed and eligibility-validated, ZAYAZ can produce regulator-grade, stakeholder-appropriate and white-label publications without weakening constitutional integrity, tenant isolation, assurance or historical traceability.



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