Chapter 24 — Constitutional Publication Framework
Part III — Publication Object Assembly, Validation and Approval
Part III defines how eligible source material is transformed into governed Publication Objects, assembled into Publication Packages, bound to evidence, validation and assurance, reviewed, approved and prepared as immutable Release Candidates.
Part I established the publication architecture and lifecycle.
Part II established Publication Profiles, Audience Profiles, Disclosure Profiles, Channel Profiles, rendering controls and Publication Eligibility.
Part III governs the production and decision layer between eligibility and release.
The governing principle is:
Publication assembly SHALL preserve source meaning, evidence, boundaries, qualifications, profile obligations and provenance. Assembly SHALL not silently create, strengthen, weaken, omit or reinterpret constitutional claims.
The controlled production path is:
Eligible Sources
│
▼
Publication Object Construction
│
├── Semantic Binding
├── Source Binding
├── Evidence Binding
├── Boundary Binding
├── Methodology Binding
├── Uncertainty Binding
└── Assurance Binding
│
▼
Publication Composition
│
├── Narrative
├── Metrics
├── Tables
├── Visualisations
├── Annexes
└── Machine Representations
│
▼
Publication Package Assembly
│
▼
Publication Manifest
│
▼
Publication Validation Plan
│
▼
HECATE Validation
│
▼
Review and Approval Gates
│
▼
Release Candidate
Publication assembly SHALL remain distinct from source calculation, constitutional reasoning, evidence creation, validation, approval, assurance, release, rendering and delivery.
24.25. Publication Object Construction
A Publication Object is the smallest governed semantic unit intended for inclusion in a Publication Package.
It SHALL be constructed only from eligible and attributable sources.
24.25.1. Publication Object Identity
Every Publication Object SHALL possess:
- Publication Object Identifier;
- canonical name;
- object type;
- publication purpose;
- Publication Subject;
- semantic content;
- source references;
- evidence references;
- Publication Context;
- Publication Profile;
- reporting boundary;
- reporting period;
- units where applicable;
- methodology;
- uncertainty;
- limitations;
- disclosure state;
- validation state;
- assurance state;
- lifecycle;
- version;
- integrity digest;
- provenance.
24.25.2. Publication Object Types
Publication Object Types MAY include:
- title;
- heading;
- narrative;
- metric;
- target;
- policy statement;
- action statement;
- risk statement;
- opportunity statement;
- impact statement;
- methodology statement;
- boundary statement;
- comparative statement;
- table;
- chart;
- diagram;
- footnote;
- cross-reference;
- evidence reference;
- assurance statement;
- audit statement;
- signature block;
- legal notice;
- public lookup record;
- machine record;
- annex item;
- correction statement;
- withdrawal statement.
24.25.3. Atomicity
A Publication Object SHOULD be semantically atomic enough that its source, meaning, audience, assurance state, correction impact and version can be independently evaluated.
Atomicity SHALL not require fragmentation that destroys readable meaning.
24.25.4. Object Sources
A Publication Object MAY derive from:
- one or more Runtime Outcomes;
- one or more Constitutional Assertions;
- one or more computations;
- a Governance Decision;
- an assurance or audit conclusion;
- accepted external sources;
- approved editorial synthesis.
The source relationship SHALL be explicit.
24.25.5. Editorial Synthesis
Editorial synthesis MAY combine eligible material into readable narrative.
It SHALL preserve source meaning, qualifications, uncertainty, reporting boundary, reporting period, assurance state and source links.
24.25.6. Generated Narrative
Generated narrative SHALL identify:
- generating actor or Component;
- generation method;
- source set;
- instructions where relevant;
- model identity where relevant;
- review state;
- validation;
- provenance.
24.25.7. AI-Assisted Object Construction
AI MAY assist with drafting, summarisation, plain-language conversion, translation proposals, consistency analysis, cross-references, table narration and accessibility descriptions.
AI SHALL NOT invent evidence, imply assurance, change methodology, suppress findings, resolve material contradiction without governance, create publication authority or approve its own output.
24.25.8. Quantitative Publication Object
A quantitative object SHALL preserve:
- metric identity;
- subject;
- value;
- unit and scale;
- period;
- boundary;
- source data;
- methodology;
- calculation version;
- rounding;
- uncertainty;
- validation;
- assurance;
- provenance.
24.25.9. Narrative Publication Object
A narrative object SHALL preserve:
- subject;
- statement type;
- factual basis;
- source assertions;
- judgement;
- assumptions;
- reporting period;
- boundary;
- limitations;
- validation;
- assurance;
- provenance.
24.25.10. Table and Visualisation Objects
A table SHALL preserve row and column semantics, units, periods, totals, null semantics, source mappings, footnotes, validation and assurance.
A visualisation SHALL preserve chart type, source data, transformation, axes, scale, units, period, omitted values, uncertainty, accessible alternative and provenance.
24.25.11. Footnotes and Cross-References
A footnote MAY qualify methodology, scope, uncertainty, omission, estimate, comparative change, assurance or legal basis.
A material qualification SHALL not be hidden where direct disclosure is required.
A cross-reference SHALL preserve source object, target object, relationship, target version, package, release state and provenance.
24.25.12. Object Lifecycle and Versioning
Lifecycle MAY include Proposed, Draft, Eligible, In Construction, Under Validation, Validated, Under Review, Approved, Included in Candidate, Released, Corrected, Superseded, Withdrawn and Archived.
A new version SHALL be created where changes affect meaning, value, unit, source, evidence, methodology, boundary, period, uncertainty, limitation, disclosure, validation, assurance or language.
24.25.13. Object Validation
HECATE SHALL validate identity, object type, source eligibility, semantic content, boundary, period, units, methodology, uncertainty, disclosure, assurance state, integrity and provenance.
24.26. Source, Evidence and Methodology Binding
Every Publication Object SHALL be bound to the sources, evidence and methodologies that support it.
24.26.1. Source Binding
A Source Binding SHALL identify:
- Binding Identifier;
- Publication Object;
- source subject and type;
- source version;
- source Runtime Outcome;
- source time;
- binding role;
- transformation;
- completeness;
- provenance.
Binding Roles MAY include primary, supporting, comparative, contextual, methodology, evidence, assurance, correction and external-reference roles.
24.26.2. Evidence Binding
An Evidence Binding SHALL identify:
- Evidence Binding Identifier;
- Publication Object;
- evidence;
- supported claim;
- evidence type;
- relevance;
- reliability;
- temporal applicability;
- assurance use;
- confidentiality;
- access path;
- provenance.
24.26.3. Evidence Sufficiency
Evidence sufficiency SHALL be assessed for each material claim and may consider directness, independence, completeness, quality, temporal relevance, corroboration, contradiction, chain of custody and verification.
24.26.4. Methodology Binding
A Methodology Binding SHALL identify:
- methodology and version;
- authority;
- applicable subject;
- calculation boundary;
- assumptions;
- parameters;
- factors;
- allocation rules;
- uncertainty method;
- validation;
- provenance.
24.26.5. Factors, Assumptions and Estimates
Factor binding SHALL preserve factor identity, source, version, geography, time, unit, applicability, uncertainty, licence and provenance.
Material assumptions SHALL preserve reason, owner, authority, evidence, uncertainty, sensitivity, affected objects and validity period.
Estimated values SHALL preserve estimation method, source data, assumptions, model, uncertainty, confidence, reason, replacement plan and validation.
24.26.6. External Source Binding
External bindings SHALL preserve publisher, source identity, acquisition time, version, licence, integrity, quality, permitted use, transformation and provenance.
24.26.7. Binding Integrity and Revalidation
Bindings MAY be protected through digests, signatures, immutable graph relationships, trusted timestamps or evidence-vault references.
Bindings SHALL be revalidated where source, evidence, methodology, authority, correction or assurance state changes.
A broken binding SHALL create a Finding and block validation where material.
24.26.8. Binding Explanation
The Runtime SHALL explain which sources, evidence, methodologies, assumptions and limitations support each material object.
24.27. Publication Composition
Publication Composition combines Publication Objects into coherent structures without changing their constitutional meaning.
24.27.1. Composition Object
A Composition Object SHALL identify:
- Composition Identifier;
- Publication Profile;
- package;
- section structure;
- included objects;
- ordering;
- grouping;
- cross-references;
- annexes;
- audience;
- format constraints;
- version;
- provenance.
24.27.2. Composition Structure
A composition MAY contain cover, title, metadata, executive summary, governance statement, reporting boundary, methodology, materiality, thematic sections, metrics, targets, policies, actions, risks, opportunities, assurance, annexes, machine metadata and signatures.
24.27.3. Section Object
A Section Object SHALL preserve:
- Section Identifier;
- section type;
- purpose;
- included objects;
- order;
- applicable requirements;
- audience;
- disclosure state;
- completeness;
- provenance.
24.27.4. Composition Rules
Rules MAY govern ordering, grouping, section dependency, repeated content, summary-detail relationships, annex separation, machine-human alignment, assurance labelling and correction notices.
24.27.5. Narrative Coherence
Narrative coherence SHALL not override source fidelity.
Editorial transitions SHALL NOT create unsupported causality, imply unsupported certainty, omit material contrary evidence, merge incompatible periods or boundaries, or imply assurance beyond scope.
24.27.6. Duplication and Canonical Objects
Duplicated content SHALL preserve one canonical Publication Object or explicit derived copies.
Divergent copies SHALL be detected.
24.27.7. Summary and Detail
A summary SHALL preserve material facts, adverse information, uncertainty, limitations, assurance state, links to detailed objects and provenance.
24.27.8. Annexes
Annexes MAY separate detailed tables, methodology, restricted evidence, assurance materials, regulatory schedules, machine schemas and correction history.
Annexes SHALL remain part of the Publication Manifest.
24.27.9. Multi-Language, Multi-Audience and Multi-Framework Composition
Multi-language packages SHALL preserve object-level translation linkage and version alignment.
Multi-audience composition SHALL identify common, audience-specific, restricted and redacted objects.
Multi-framework composition SHALL preserve requirement-level mappings.
24.27.10. Composition Conflict
Conflicts MAY arise from incompatible ordering, disclosure, contradictory objects, duplicate metrics with different methods, incompatible assurance labels or audience collision.
Unresolved conflict SHALL block package validation.
24.27.11. Composition Validation
HECATE SHALL validate required sections, ordering, object inclusion, cross-references, summaries, annexes, language alignment, audience separation, framework coverage and provenance.
24.28. Publication Package Assembly
A Publication Package is the governed collection of Publication Objects, metadata, manifests, schemas, renderings and supporting artefacts prepared for validation, review, approval and release.
24.28.1. Package Identity
Every package SHALL possess:
- Publication Package Identifier;
- canonical name;
- package type;
- Publication Request;
- Publication Profile;
- Publication Context;
- Composition Object;
- Publication Objects;
- intended audience, channels and formats;
- reporting boundary and period;
- lifecycle;
- version;
- integrity digest;
- provenance.
24.28.2. Package Types
Types MAY include regulatory filing, sustainability statement, assurance, audit, public report, passport, public registry, API publication, restricted workspace, correction and withdrawal packages.
24.28.3. Package Contents
A package MAY contain Publication Objects, composition, metadata, manifest, schemas, templates, renderings, translations, signatures, evidence references, assurance references, validation results, release notes and attachments.
24.28.4. Package Boundary
The boundary SHALL identify included and excluded objects, restricted annexes, external references, linked evidence, assurance, schemas and channels.
24.28.5. Package Assembly Plan
A Package Assembly Plan SHALL identify:
- eligibility outcome;
- required and optional objects;
- object constructors;
- composition;
- templates;
- languages;
- formats;
- validation;
- review;
- approval and assurance Gates;
- timeline;
- provenance.
24.28.6. Determinism and Snapshot
Equivalent source versions, context, profiles, templates and Components SHALL produce semantically equivalent packages.
A package snapshot SHALL freeze included objects and versions, profiles, context fingerprint, source and evidence references, composition, templates, schemas and preliminary digest.
24.28.7. Draft and Rebuild
A draft package SHALL be visibly non-authoritative and restricted to approved review audiences.
A rebuild SHALL identify prior version, changed sources, profiles, templates, objects, composition and resulting differences.
24.28.8. Integrity and Isolation
Integrity MAY use manifest digests, object digests, Merkle trees, signatures, timestamps and immutable storage.
Packages SHALL remain isolated by tenant, white-label deployment, purpose, audience, classification, assurance engagement and candidate.
24.28.9. Completeness and State
Completeness SHALL evaluate required objects, sections, evidence, metadata, languages, formats, annexes, signatures, assurance and explanations.
Validation State MAY include Not Evaluated, In Validation, Structurally Valid, Semantically Valid, Valid with Findings, Invalid, Indeterminate and Superseded.
24.28.10. Package Explanation
The Runtime SHALL explain package purpose, profile, included objects, covered requirements, omissions, evidence, assurance, changes and provenance.
24.29. Publication Manifest
The Publication Manifest is the authoritative inventory and integrity record for a Publication Package.
It SHALL be machine-readable and human-inspectable.
24.29.1. Manifest Identity
Every manifest SHALL possess:
- Manifest Identifier;
- Publication Package;
- manifest version;
- schema version;
- creation time;
- creating Component;
- Runtime Bundle;
- content digest;
- signature state;
- lifecycle;
- provenance.
24.29.2. Manifest Contents
The manifest SHALL identify:
- package identity and version;
- Publication Request;
- Publication Profile and version;
- Publication Context Fingerprint;
- framework, audience, disclosure, channel and format profiles;
- included Publication Objects;
- object versions and digests;
- source versions;
- evidence and methodology references;
- reporting boundary and period;
- validation results and findings;
- reviews and approvals;
- assurance;
- translations and renderings;
- signatures;
- release readiness;
- provenance.
24.29.3. Inventories
The manifest SHALL include object, source, evidence, requirement, approval, assurance and rendering inventories.
Each inventory SHALL preserve identity, version, scope, state, integrity and provenance.
24.29.4. Manifest Sealing
A manifest MAY be sealed when package content is frozen, validation and required reviews are complete, approvals are complete, assurance is bound, digests are calculated and signatures applied.
Any material package change after sealing SHALL create a new manifest version.
24.29.5. Manifest Validation
HECATE SHALL validate schema, inventories, identities, versions, digests, profile references, source references, validation, approval, assurance and provenance.
24.30. Publication Validation Plan
A Publication Validation Plan defines the validation procedures required before a Publication Package may proceed to approval or assurance.
Validation SHALL be profile-driven.
24.30.1. Validation Plan Identity
Every Publication Validation Plan SHALL possess:
- Validation Plan Identifier;
- Publication Package;
- Publication Profile;
- applicable Validation Profiles;
- validation stages;
- validation Components;
- required evidence;
- expected outcomes;
- severity policy;
- exception policy;
- completion criteria;
- version;
- provenance.
24.30.2. Validation Stages
Stages MAY include:
- identity validation;
- schema validation;
- structural validation;
- semantic validation;
- source-binding validation;
- evidence validation;
- methodology validation;
- boundary validation;
- temporal validation;
- framework validation;
- coverage validation;
- omission validation;
- disclosure validation;
- security validation;
- assurance-binding validation;
- rendering validation;
- accessibility validation;
- cross-object validation;
- provenance validation.
24.30.3. Structural Validation
Structural validation SHALL evaluate required sections, objects, metadata, schema, ordering, cross-references, annexes, signatures and manifest completeness.
24.30.4. Semantic Validation
Semantic validation SHALL evaluate object meaning, subject identity, metric definition, units, value domains, narrative consistency, methodology, boundary, period and missing-value semantics.
24.30.5. Source and Evidence Validation
Source-binding validation SHALL verify that every material object is supported by eligible and versioned sources.
Evidence validation SHALL assess identity, relevance, reliability, integrity, temporal applicability, contradiction, sufficiency, confidentiality and provenance.
24.30.6. Methodology and Boundary Validation
Methodology validation SHALL assess identity, version, applicability, assumptions, factors, allocations, units, uncertainty and comparative consistency.
Boundary validation SHALL assess legal entities, operations, products, facilities, value-chain scope, geography, reporting period, exclusions, acquisitions and disposals.
24.30.7. Framework and Coverage Validation
Framework validation SHALL assess each applicable requirement and its mapped Publication Objects.
Coverage validation SHALL confirm that all mandatory requirements are complete, qualified, omitted with valid basis, or explicitly unresolved.
24.30.8. Cross-Object and Cross-Representation Validation
Cross-object validation SHALL detect contradictory values, inconsistent units, periods and boundaries, duplicate claims, broken totals, inconsistent assurance labels and conflicting correction states.
Human-readable and machine-readable representations SHALL be reconciled.
Material mismatch SHALL block release readiness.
24.30.9. Severity Policy
Finding severity MAY include:
- Information;
- Warning;
- Moderate;
- High;
- Critical;
- Blocking.
Blocking findings SHALL prevent approval unless an explicit valid exception exists.
24.30.10. Validation Finding
Every finding SHALL identify:
- Finding Identifier;
- validation stage;
- affected object;
- requirement;
- observed state;
- expected state;
- severity;
- evidence;
- remediation;
- owner;
- status;
- provenance.
24.30.11. Validation Exception
An exception SHALL identify:
- affected finding;
- exception authority;
- basis;
- scope;
- risk;
- duration;
- compensating control;
- approval;
- provenance.
24.30.12. Validation Outcome
A Publication Validation Outcome SHALL identify:
- plan;
- package;
- stages completed;
- findings;
- exceptions;
- blocking issues;
- completeness;
- decision;
- explanation;
- provenance.
Decision classes MAY include Valid, Valid with Findings, Valid with Approved Exceptions, Remediation Required, Invalid and Indeterminate.
24.30.13. Validation Reuse
Validation may be reused only where package digest, profiles, sources, evidence, context and validator versions remain equivalent.
24.30.14. Validation Explanation
The Runtime SHALL explain which validations were performed, which findings occurred, which exceptions apply, which requirements remain unmet, whether approval may proceed and the associated provenance.
24.31. Review Runtime
Publication Review is the governed human or machine-assisted examination of a Publication Package before approval.
Review SHALL remain distinct from validation and approval.
24.31.1. Review Request
Every review SHALL identify:
- Review Request Identifier;
- package;
- review type;
- reviewer;
- Role;
- authority;
- scope;
- due date;
- required evidence;
- conflict-of-interest state;
- provenance.
24.31.2. Review Types
Review Types MAY include:
- content review;
- data review;
- methodology review;
- framework review;
- legal review;
- security review;
- privacy review;
- assurance-readiness review;
- accessibility review;
- executive review;
- tenant review;
- white-label review;
- regulator-readiness review.
24.31.3. Reviewer Independence
The Publication Profile MAY require reviewer independence from the object author, data preparer, calculation Component, package assembler, approval authority or assurance provider.
24.31.4. Review Scope
Review scope SHALL identify package, sections, objects, requirements, findings, evidence, languages, formats and assurance scope.
24.31.5. Review Comment
A Review Comment SHALL preserve:
- comment identity;
- reviewer;
- affected object;
- issue;
- severity;
- proposed action;
- response;
- resolution;
- time;
- provenance.
24.31.6. Review Decision
Review decisions MAY include:
- Accepted;
- Accepted with Comments;
- Revision Required;
- Escalation Required;
- Rejected;
- Indeterminate.
Review acceptance SHALL not establish publication approval.
24.31.7. Review Resolution and Reopening
Resolution SHALL identify the original comment, action, changed objects, package version, responder, reviewer confirmation, unresolved state and provenance.
A review SHALL reopen where a material package change affects reviewed scope.
24.31.8. Machine-Assisted Review
Machine-assisted review MAY support consistency, citation, duplication, terminology, calculation, policy and accessibility checks.
Machine findings SHALL remain distinguishable from confirmed reviewer conclusions.
24.31.9. Review Evidence and Validation
Review evidence SHALL preserve the request, reviewer, reviewed version, comments, responses, decisions, completion time and provenance.
HECATE SHALL validate reviewer identity, Role, authority, scope, independence, package version, completion and unresolved comments.
24.32. Publication Approval
Publication Approval is the governed decision that a specific Publication Package may proceed toward release under defined conditions.
Approval SHALL bind to an exact package digest.
24.32.1. Approval Request
Every approval SHALL originate from an Approval Request identifying:
- Approval Request Identifier;
- package;
- package digest;
- Publication Profile;
- validation outcome;
- review outcomes;
- assurance state;
- requested release class;
- requested channels;
- requested effective time;
- requester;
- authority;
- provenance.
24.32.2. Approval Authority
Approval Authority SHALL define:
- approver;
- Role;
- subject scope;
- publication class;
- tenant;
- framework;
- audience;
- channel;
- jurisdiction;
- effective period;
- delegation;
- provenance.
24.32.3. Approval Types
Approval Types MAY include:
- content approval;
- data approval;
- methodology approval;
- legal approval;
- security approval;
- executive approval;
- assurance-release approval;
- regulator-filing approval;
- public-release approval;
- emergency approval;
- correction approval;
- withdrawal approval.
24.32.4. Approval Gate
An Approval Gate SHALL define:
- required approval type;
- required Role;
- required independence;
- preconditions;
- package scope;
- package digest;
- decision classes;
- expiration;
- provenance.
24.32.5. Approval Decision
Decision classes MAY include:
- Approved;
- Approved with Conditions;
- Approved for Restricted Release;
- Approved for Specified Channels;
- Approval Deferred;
- Revision Required;
- Rejected;
- Withdrawn;
- Indeterminate.
24.32.6. Conditional Approval
Conditional approval SHALL identify conditions, responsible owner, due time, verification method, release restriction, expiration and provenance.
A pre-release condition SHALL be enforced by the Release Gate.
24.32.7. Multi-Approval
A package MAY require multiple approvals.
The approval model SHALL define sequential or parallel approvals, quorum, unanimity, veto, escalation, substitution and expiration.
24.32.8. Separation and Self-Approval
Approval SHALL remain distinct from authorship, validation, review, assurance, release execution and channel operation.
Self-approval SHALL be prohibited where independence is required.
An agent SHALL not approve its own output.
A Component SHALL not approve a package solely because it generated or validated it.
24.32.9. Approval Expiration
Approval SHALL expire where:
- package changes materially;
- profile or context changes;
- assurance changes;
- evidence is withdrawn;
- source is corrected;
- authority expires;
- release deadline passes;
- approval policy requires renewal.
24.32.10. Approval Withdrawal
Approval may be withdrawn due to new evidence, error, conflict of interest, source withdrawal, security issue, legal change, assurance change or package drift.
Withdrawal SHALL preserve the prior approval record.
24.32.11. Approval Signature
Approval MAY be digitally signed.
The signature SHALL bind approver identity, authority, package digest, scope, conditions, time, certificate, revocation state and provenance.
24.32.12. Approval Outcome
An Approval Outcome SHALL preserve request, package, digest, approver, authority, decision, conditions, expiration, signature, explanation and provenance.
24.32.13. Approval Validation
HECATE SHALL validate approval request, package digest, approver identity, authority, Role, independence, preconditions, conditions, expiration, signature and provenance.
HECATE SHALL not substitute for the approving authority.
24.33. Assurance Binding
Assurance SHALL be bound to the exact subject matter, criteria, scope, period and package content to which the assurance conclusion applies.
24.33.1. Assurance Binding Object
Every Assurance Binding SHALL possess:
- Assurance Binding Identifier;
- assurance engagement;
- assurance provider;
- subject matter;
- criteria;
- assurance level;
- covered Publication Objects;
- excluded Publication Objects;
- reporting period;
- package digest;
- opinion;
- limitations;
- findings;
- signature;
- validity;
- provenance.
24.33.2. Assurance Levels
Assurance Levels MAY include:
- Not Assured;
- Internal Review;
- Agreed-Upon Procedures;
- Limited Assurance;
- Reasonable Assurance;
- Mixed Assurance;
- Other Governed Level.
24.33.3. Mixed Assurance
A package MAY contain different assurance states.
The Publication Manifest SHALL identify assurance at object or section level where material.
24.33.4. Assurance Scope
Assurance scope SHALL identify covered entities, subjects, periods, metrics, narratives, methodologies, exclusions, limitations, criteria and provenance.
24.33.5. Exclusions and Qualifications
An excluded object SHALL not be presented as assured.
A qualified assurance conclusion SHALL preserve qualification, basis, affected objects, effect, audience, release impact and provenance.
24.33.6. Opinion Change
An opinion change SHALL trigger package, approval and release-readiness re-evaluation and may trigger publication correction where already released.
24.33.7. Assurance Package Digest
Assurance SHALL bind to an exact package or object digest.
A material content change SHALL invalidate assurance binding for affected scope.
24.33.8. Assurance Signature
The signature SHALL identify signer, assurance provider, authority, opinion digest, package digest, signing time, certificate, revocation and provenance.
24.33.9. Assurance Readiness Gate
The Gate SHALL validate required evidence, source stability, package completeness, methodology, controls, findings, management representation, access, independence and provenance.
24.33.10. Assurance Binding Validation
HECATE SHALL validate engagement identity, assurance provider, independence, scope, criteria, level, covered objects, exclusions, package digest, opinion, signature and provenance.
24.34. Release Candidate
A Publication Release Candidate is the frozen package proposed for release after required validation, review, approval and assurance have been completed.
It is not yet a Publication Release.
24.34.1. Release Candidate Identity
Every Release Candidate SHALL possess:
- Release Candidate Identifier;
- Publication Package;
- sealed Publication Manifest;
- package digest;
- candidate version;
- intended release class;
- intended channels;
- intended audiences;
- effective time;
- validation state;
- review state;
- approval state;
- assurance state;
- lifecycle;
- provenance.
24.34.2. Candidate Preconditions
A candidate SHALL require:
- completed package assembly;
- sealed manifest;
- completed required validation;
- resolved blocking findings;
- completed required reviews;
- valid approvals;
- valid assurance binding where required;
- completed security and accessibility checks;
- channel compatibility;
- complete provenance.
24.34.3. Candidate Freeze
Candidate freeze SHALL prevent object, template, profile, manifest, rendering and annex mutation without a new candidate version and digest.
24.34.4. Candidate Rendering and Diff
Candidate renderings SHALL be generated from the frozen package and recorded in the manifest.
A Candidate Diff SHALL identify changes from prior candidate, package, release and reporting period.
24.34.5. Candidate Expiration and Withdrawal
A candidate MAY expire due to approval expiration, assurance expiration, source change, profile change, deadline change, security change, channel change or new blocking finding.
Withdrawal SHALL preserve authority, reason, affected candidate, replacement and provenance.
24.34.6. Release Readiness Decision
Decision classes MAY include:
- Release Ready;
- Release Ready with Conditions;
- Restricted Release Ready;
- Channel-Specific Ready;
- Remediation Required;
- Blocked;
- Expired;
- Withdrawn;
- Indeterminate.
24.34.7. Release Readiness Receipt
A Release Readiness Receipt SHOULD contain candidate, manifest digest, validation outcome, review outcomes, approvals, assurance binding, conditions, channel readiness, decision, time, signatures and provenance.
24.34.8. Release Gate
The Release Gate SHALL independently verify candidate identity, manifest integrity, approval validity, assurance validity, authority, effective time, channel eligibility, embargo, withdrawal state, conditions and provenance.
24.35. Assembly Transactions and Change Control
Publication assembly SHALL be transactionally governed where package consistency depends on coordinated changes.
24.35.1. Assembly Transaction
An Assembly Transaction SHALL identify:
- Transaction Identifier;
- package;
- initiating request;
- actor or Component;
- affected objects;
- source versions;
- expected package version;
- operations;
- validation;
- commit condition;
- rollback;
- provenance.
24.35.2. Commit Conditions
Commit MAY require all object writes, manifest updates, source bindings, cross-references, validations, tenant-isolation checks and integrity calculations to succeed.
24.35.3. Partial Failure
Partial failure SHALL preserve completed and failed operations, committed and uncommitted objects, compensation, retry state, package state and provenance.
24.35.4. Concurrency Control
Assembly SHOULD compare expected and actual package versions before commit.
A Package Lock SHALL preserve package, holder, purpose, lock type, acquisition time, expiration, fencing token and provenance.
24.35.5. Change Request
A material package change SHALL originate from a Change Request identifying package, requested change, reason, affected objects and requirements, affected approval and assurance, requester, authority and provenance.
24.35.6. Change Classification
Change classes MAY include:
- editorial non-semantic;
- metadata;
- source update;
- metric change;
- methodology change;
- boundary change;
- period change;
- assurance change;
- audience change;
- channel change;
- correction;
- restatement.
24.35.7. Material and Non-Material Change
A material change SHALL trigger revalidation and MAY trigger re-review, reapproval and reassurance.
A non-material change MAY use an expedited path only where policy permits, meaning and evidence remain unchanged, assurance scope is unaffected, the digest is updated and the change remains provenance-visible.
24.35.8. Change Impact Analysis
Impact analysis SHALL evaluate objects, sections, framework requirements, evidence, assurance, approval, languages, formats, channels, candidate, prior releases and provenance.
24.35.9. Rollback and Audit Trail
Rollback SHALL restore the prior valid package state without erasing the failed transaction.
The assembly audit trail SHALL preserve creation, modification, deletion, source changes, object changes, composition changes, package snapshots, validations, reviews, approvals, assurance, candidate creation and provenance.
24.36. Assembly Provenance, Events and Conformance
Assembly, validation, review and approval SHALL preserve complete constitutional lineage.
24.36.1. Assembly Provenance
Assembly provenance SHALL include:
- Publication Request;
- Publication Context;
- profile-resolution and eligibility outcomes;
- source objects and versions;
- object constructors;
- Publication Objects;
- source, evidence and methodology bindings;
- Composition Object;
- Package Assembly Plan;
- package and manifest versions;
- validation;
- reviews;
- approvals;
- assurance;
- Release Candidate;
- Module and Component lineage;
- timestamps;
- integrity metadata;
- provenance.
24.36.2. Assembly Events
The Runtime SHOULD emit:
- PublicationObjectProposed;
- PublicationObjectConstructed;
- PublicationObjectValidated;
- SourceBindingCreated;
- EvidenceBindingCreated;
- MethodologyBindingCreated;
- CompositionCreated;
- PublicationPackageCreated;
- PublicationPackageRebuilt;
- PublicationManifestCreated;
- PublicationManifestSealed;
- PublicationValidationStarted;
- PublicationValidationCompleted;
- PublicationFindingRaised;
- PublicationReviewRequested;
- PublicationReviewCompleted;
- PublicationApprovalRequested;
- PublicationApprovalGranted;
- PublicationApprovalRejected;
- AssuranceBound;
- ReleaseCandidateCreated;
- ReleaseCandidateExpired;
- ReleaseCandidateWithdrawn;
- ReleaseReadinessConfirmed.
24.36.3. Diff and Replay
An Object Diff SHOULD identify semantic, value, unit, source, evidence, methodology, boundary, period, uncertainty, limitation, disclosure, assurance and provenance changes.
A Package Diff SHOULD identify object, order, section, annex, requirement, omission, language, format, validation, approval, assurance and manifest changes.
Replay SHALL use historical sources, context, profiles, eligibility, assembly Components, templates, constructors, composition, package, validation rules, reviews, approvals, assurance and Runtime Bundle.
24.36.4. Impact Analysis
Changes SHALL support impact analysis over Publication Objects, packages, manifests, candidates, approvals, assurance, channels, releases, tenants, white-label deployments, Modules and Components.
24.36.5. Pergamum Pulse Integration
Pergamum Pulse MAY derive intelligence including:
- object-source gaps;
- evidence-binding weakness;
- methodology inconsistency;
- package-completeness risk;
- cross-object contradiction;
- review bottlenecks;
- repeated approval conditions;
- assurance-scope gaps;
- candidate-expiration risk;
- change-control weakness;
- Module-level assembly risk;
- Component-level assembly risk.
Pergamum Pulse SHALL preserve Module, Component, Publication Object, source-binding, evidence-binding, methodology-binding, package, manifest, validation, review, approval, assurance, candidate, tenant and temporal lineage.
Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.
24.36.6. Part III Conformance Suite
The Constitutional Compiler Framework SHOULD generate fixtures including:
- valid quantitative and narrative objects;
- AI-assisted object;
- unsupported claim;
- broken source binding;
- insufficient evidence;
- methodology conflict;
- estimate with uncertainty;
- composition conflict;
- multi-language and multi-audience composition;
- complete and incomplete packages;
- valid and invalid manifests;
- structural and semantic validation failures;
- cross-object contradiction;
- reviewer conflict of interest;
- valid, expired and self-approved approvals;
- mixed assurance;
- assurance-scope mismatch;
- valid and mutated Release Candidates;
- material and non-material changes;
- assembly replay.
Part III Conformance
An implementation conforms to Part III of the Constitutional Publication Framework where it:
- represents Publication Objects as stable, versioned and provenance-preserving semantic units;
- constructs Publication Objects only from eligible and attributable sources;
- distinguishes source facts, editorial synthesis, assumptions and generated narrative;
- governs AI-assisted object construction and prevents unsupported claims;
- preserves metric identity, units, period, boundary, methodology, uncertainty and assurance state;
- binds every material object to source, evidence and methodology;
- detects broken or stale bindings;
- evaluates evidence sufficiency at claim and object level;
- preserves factor, assumption and estimate lineage;
- composes objects without changing constitutional meaning;
- preserves summaries, details, annexes and cross-references;
- prevents narrative coherence from overriding source fidelity;
- represents Publication Packages independently from Publication Objects;
- creates deterministic Package Assembly Plans and snapshots;
- isolates packages by tenant, purpose, audience and assurance engagement;
- maintains a machine-readable and human-inspectable Publication Manifest;
- inventories objects, sources, evidence, requirements, approvals, assurance and renderings;
- seals manifests before Release Candidate creation;
- validates packages through explicit Publication Validation Plans;
- performs structural, semantic, source, evidence, methodology, boundary, framework, disclosure, assurance and provenance validation;
- detects cross-object and cross-representation inconsistencies;
- represents findings, severities, exceptions and outcomes explicitly;
- distinguishes review from validation and approval;
- validates reviewer identity, Role, authority, scope and independence;
- binds approval to an exact package digest;
- preserves conditional, restricted, deferred, rejected and withdrawn approval states;
- prevents self-approval where independence is required;
- binds assurance to exact subject matter, criteria, scope, period and package digest;
- identifies mixed, excluded and qualified assurance at object or section level;
- creates immutable Release Candidates only after required validation, review, approval and assurance;
- invalidates candidates after material source, profile, approval or assurance change;
- governs assembly through transactions, concurrency control and change classification;
- supports assembly replay, diff and impact analysis;
- preserves both Module and Component lineage;
- integrates Pergamum Pulse without granting intelligence publication authority;
- provides a conformance suite covering object construction, binding, composition, packages, manifests, validation, review, approval, assurance and candidates.
Part III Foundational Principle
Publication assembly is the governed constitutional process through which eligible source knowledge becomes reviewable Publication Objects, coherent Publication Packages, sealed Publication Manifests and release-ready candidates.
Assembly SHALL preserve source meaning, evidence, methodology, reporting boundary, reporting period, units, uncertainty, limitations, disclosure and assurance state. Editorial synthesis, rendering, translation and AI assistance SHALL not create unsupported claims, suppress adverse information or silently change constitutional meaning.
Validation, review, approval and assurance SHALL remain distinct. HECATE validates conformance. Review examines content and readiness. Approval grants bounded publication authority. Assurance binds an independent conclusion to defined subject matter and criteria. None of these functions may substitute for another.
By making object construction source-bound, package assembly deterministic, manifests complete, validation profile-driven, review independent, approval digest-bound and assurance scope-explicit, ZAYAZ can prepare regulator-grade publications without sacrificing semantic integrity, tenant isolation, evidence traceability or accountable governance.