Chapter 23 — Constitutional Runtime Framework
Part IV — Validation Runtime
The Validation Runtime is the governed constitutional runtime through which HECATE determines whether Constitutional Objects, Constitutional Relationships, Constitutional Assertions, Runtime Contexts, Execution Plans, Runtime Outcomes, evidence, graphs, calculations, reports and operational states conform to applicable constitutional requirements.
Validation SHALL be treated as a first-class constitutional process.
Validation SHALL NOT be reduced to implementation-specific field checks, database constraints, schema parsers, user-interface rules or application conditionals. Those mechanisms MAY implement portions of a Validation Plan, but they SHALL remain projections of constitutional Validation Rules.
The governing distinction is:
Constitutional Resolution Policies determine which validation knowledge applies. HECATE determines whether the evaluated subject conforms to that knowledge.
Conceptually:
Constitutional Validation Rules
│
compiled by
▼
Constitutional Compiler Framework
│
▼
HECATE Runtime Bundle
│
resolved through
▼
Constitutional Resolution Policies
│
▼
Applicable Validation Profile
│
▼
Validation Request
│
▼
Validation Plan
│
├── Structural Validation
├── Semantic Validation
├── Governance Validation
├── Temporal and Context Validation
├── Provenance Validation
├── Evidence Validation
├── Graph Validation
└── Aggregate Validation
│
▼
Validation Results
│
▼
Validation Findings
│
▼
Validation Outcome
Validation Runtime SHALL remain deterministic, explainable, reproducible, context-aware, temporally accurate, provenance-preserving and independently auditable.
23.35. HECATE Runtime
The HECATE Runtime is the constitutional validation execution system of ZAYAZ.
HECATE SHALL evaluate applicable Validation Rules against governed validation subjects within an explicit Runtime Context and SHALL produce traceable Validation Results, Validation Findings and Validation Outcomes.
HECATE SHALL execute constitutional validation semantics without redefining them.
23.35.1. Purpose
HECATE SHALL provide the common validation runtime for:
- constitutional activation;
- ingestion;
- runtime admission;
- context sealing;
- Resolution Policy activation;
- Execution Plan validation;
- pre-execution validation;
- in-execution validation;
- pre-commit validation;
- post-commit verification;
- computation validation;
- report validation;
- publication eligibility;
- assurance support;
- regulatory conformance;
- Digital Product Passport validation;
- white-label overlay validation;
- AI-generated assertion validation;
- graph integrity validation;
- continuous validation.
23.35.2. Authority Boundary
HECATE validates conformance.
HECATE SHALL NOT:
- create constitutional authority;
- alter Constitutional Identifiers;
- approve its own Validation Rules;
- silently weaken mandatory requirements;
- erase Validation Findings;
- convert failed validation into successful validation;
- convert AI-generated content into canonical knowledge;
- substitute assurance for validation;
- redefine Constitutional Resolution Policies;
- infer that an unevaluated subject is valid.
HECATE MAY prevent activation, execution, commit or publication where the applicable Validation Profile grants blocking authority.
23.35.3. Logical Architecture
Validation Gateway
│
▼
Validation Subject Resolver
│
▼
Validation Profile Resolver
│
▼
Validation Planner
│
├── Rule Dependency Resolver
├── Evidence Resolver
├── Context Resolver
└── Validator Capability Resolver
│
▼
Validation Engines
│
├── Structural
├── Semantic
├── Governance
├── Temporal
├── Provenance
├── Evidence
├── Graph
└── Aggregate
│
▼
Finding and Outcome Aggregator
│
▼
Explanation, Provenance and Remediation
This architecture defines constitutional responsibilities rather than mandatory deployable services.
23.35.4. HECATE Components
HECATE MAY include Components for:
- request admission;
- subject resolution;
- profile resolution;
- rule resolution;
- Validation Plan generation;
- rule execution;
- evidence evaluation;
- graph validation;
- finding management;
- remediation management;
- outcome aggregation;
- explanation;
- audit;
- observability.
Every HECATE Component SHALL possess stable Component identity and Module lineage.
Pergamum Pulse SHALL preserve both Module and Component lineage.
23.35.5. Validation Engines
Each Validation Engine SHALL declare:
- engine identity;
- supported Validation Rule types;
- supported subject types;
- supported execution modes;
- deterministic guarantees;
- numerical guarantees where applicable;
- evidence capabilities;
- context requirements;
- security profile;
- version;
- compatibility;
- provenance.
A technical rules engine SHALL NOT become constitutionally authoritative merely because HECATE uses it.
23.35.6. Compiled Artefacts
HECATE MAY execute:
- HECATE-native rules;
- SHACL shapes;
- JSON Schema validators;
- SQL constraints;
- graph constraints;
- policy rules;
- decision tables;
- code validators;
- workflow gates;
- numerical test functions;
- report validation plans.
Every compiled artefact SHALL preserve lineage to its Constitutional Validation Rule, Projection Profile and Compiler Manifest.
23.35.7. Validation Modes
Validation Modes MAY include:
- synchronous;
- asynchronous;
- batch;
- streaming;
- event-triggered;
- scheduled;
- continuous;
- interactive;
- offline;
- edge;
- federated;
- replay;
- simulation;
- assurance.
Validation Mode SHALL NOT alter constitutional meaning.
23.35.8. Evaluation Strategies
A Validation Plan MAY use:
- fail-fast evaluation;
- complete evaluation;
- severity-threshold evaluation;
- dependency-gated evaluation;
- risk-based evaluation.
Fail-fast SHALL stop only where continuing provides no constitutionally required value or would create unacceptable risk.
23.35.9. Determinism
Equivalent:
- subject state;
- Validation Request;
- Context Fingerprint;
- Validation Profile;
- Validation Rule versions;
- evidence state;
- HECATE Runtime Bundle;
- validator Component versions
SHALL produce semantically equivalent Validation Outcomes.
23.35.10. Isolation and Trust
HECATE SHALL enforce:
- tenant isolation;
- execution isolation;
- evidence isolation;
- jurisdictional isolation;
- security classification;
- assurance-engagement isolation;
- simulation isolation.
HECATE SHALL reject untrusted rules, profiles, Runtime Bundles, validator Components and external validation results from authoritative execution.
23.35.11. Self-Validation
HECATE SHALL validate its own:
- Runtime Manifest;
- Runtime Bundle integrity;
- Component inventory;
- active Validation Profiles;
- rule completeness;
- trust anchors;
- tenant overlays;
- disabled rules;
- runtime drift;
- conformance status.
A critically invalid HECATE Runtime SHALL NOT produce authoritative Validation Outcomes except under an explicitly governed emergency profile.
23.36. Validation Request and Validation Plan
A Validation Request is a specialised Execution Request that asks HECATE to evaluate one or more subjects for a defined purpose.
A Validation Plan is the deterministic governed artefact that defines how the Validation Request SHALL be executed.
23.36.1. Validation Request
Every Validation Request SHALL identify:
- Validation Request Identifier;
- purpose;
- subject identity or subject selector;
- subject version or temporal state;
- Runtime Context;
- requested Validation Profile;
- validation scope;
- execution mode;
- assurance requirement;
- actor;
- authority;
- Request Fingerprint;
- provenance.
23.36.2. Validation Subjects
Validation Subjects MAY include:
- Constitutional Objects;
- Constitutional Relationships;
- Constitutional Assertions;
- Constitutional Contexts;
- schemas;
- properties;
- Value Providers;
- Resolution Policies;
- Runtime Bundles;
- Runtime Manifests;
- Execution Requests;
- Execution Plans;
- Runtime Outcomes;
- evidence;
- datasets;
- calculations;
- models;
- workflows;
- graphs;
- reports;
- disclosures;
- Digital Product Passports;
- AI-generated proposals;
- tenant overlays;
- deployments.
23.36.3. Validation Purpose
Purpose MAY include:
- activation;
- admission;
- ingestion;
- compatibility;
- execution readiness;
- transaction commit;
- publication;
- assurance;
- certification;
- verification;
- regulatory conformance;
- migration;
- replay;
- incident investigation;
- data-quality improvement;
- simulation;
- AI proposal screening.
Purpose SHALL constrain profile selection and outcome interpretation.
23.36.4. Validation Scope
Validation Scope SHALL define:
- subject population;
- object versions;
- relationship types;
- graph boundaries;
- reporting periods;
- jurisdictions;
- tenant boundaries;
- evidence boundaries;
- rule families;
- severity thresholds;
- excluded scope;
- sampled scope;
- unresolved scope.
23.36.5. Subject Snapshot
Authoritative validation SHALL operate against an identifiable subject snapshot preserving:
- subject identity;
- subject version;
- effective time;
- valid time;
- transaction time;
- data fingerprint;
- graph snapshot where applicable;
- evidence snapshot;
- provenance.
Validation against mutable unversioned state SHALL be explicitly qualified.
23.36.6. Validation Plan Identity
Every Validation Plan SHALL possess:
- Validation Plan Identifier;
- plan version;
- Validation Request;
- Validation Request Fingerprint;
- subject snapshot fingerprint;
- Context Fingerprint;
- Validation Profile;
- Validation Rule Set;
- HECATE Runtime Bundle;
- planner identity and version;
- Plan Fingerprint;
- lifecycle;
- provenance.
23.36.7. Validation Plan Contents
A Validation Plan SHALL define:
- subject and snapshot;
- purpose and scope;
- Validation Profile;
- applicable Validation Rules;
- rule versions;
- rule dependencies;
- execution order;
- parallelisable rules;
- required evidence;
- validator Components;
- input and output contracts;
- aggregation policy;
- severity policy;
- stopping conditions;
- timeout and retry policy;
- exception policy;
- remediation policy;
- explanation requirements;
- provenance requirements.
23.36.8. Rule Dependency Graph
Validation Rules MAY depend upon other rules.
Dependencies MAY include:
- requires successful result;
- requires completed result;
- requires evidence;
- requires derived value;
- invalidates;
- supersedes;
- conflicts with;
- aggregates.
Cycles SHALL be prohibited unless a bounded iterative profile explicitly permits them.
23.36.9. Validation Gates
A Validation Plan MAY define:
- identity gate;
- schema gate;
- authority gate;
- evidence gate;
- semantic gate;
- transaction gate;
- assurance gate;
- publication gate.
23.36.10. Plan Optimisation
HECATE MAY optimise through:
- parallel execution;
- incremental validation;
- safe result reuse;
- dependency pruning;
- indexed graph validation;
- batch evaluation;
- shared evidence retrieval;
- rule compilation.
Optimisation SHALL NOT omit mandatory rules, weaken severity, reduce evidence requirements or conceal unevaluated rules.
23.36.11. Plan Validation
HECATE SHALL validate the Validation Plan for:
- request-plan consistency;
- subject identity;
- profile applicability;
- rule completeness;
- dependency integrity;
- Component capability;
- evidence availability;
- scope completeness;
- tenant isolation;
- temporal consistency;
- aggregation completeness;
- provenance completeness.
23.36.12. Plan Approval
High-risk Validation Plans MAY require approval where:
- mandatory rules are overridden;
- assurance conclusions are produced;
- sampling replaces full-population validation;
- AI-assisted validation affects material outcomes;
- blocking rules are disabled;
- emergency mode applies;
- external validators are used;
- scope is materially reduced.
23.37. Validation Profiles and Rule Resolution
A Validation Profile is the governed Constitutional Object defining which Validation Rules, evidence requirements, execution semantics and outcome policies apply to a defined purpose and context.
Constitutional Resolution Policies SHALL resolve the applicable Validation Profile, Validation Rules and rule versions.
23.37.1. Validation Profile Identity
Every Validation Profile SHALL possess:
- Constitutional Identifier;
- canonical name;
- semantic definition;
- profile type;
- governing authority;
- applicability;
- lifecycle;
- version;
- temporal validity;
- included and excluded rule sets;
- evidence requirements;
- execution mode;
- aggregation policy;
- blocking policy;
- exception policy;
- provenance.
23.37.2. Profile Types
Profiles MAY include:
- constitutional activation;
- registry ingestion;
- runtime admission;
- context sealing;
- resolution;
- computation;
- workflow;
- report;
- publication;
- assurance;
- regulatory;
- tenant;
- white-label;
- Digital Product Passport;
- supply-chain;
- product carbon footprint;
- lifecycle assessment;
- AI proposal;
- security;
- migration;
- replay;
- simulation.
23.37.3. Profile Resolution
CRP SHALL resolve the applicable profile using:
- purpose;
- subject type;
- tenant;
- jurisdiction;
- reporting framework;
- reporting period;
- constitutional release;
- assurance level;
- publication profile;
- execution mode;
- security profile.
HECATE SHALL NOT select profiles through hidden application logic.
23.37.4. Profile Composition
Profiles MAY compose other profiles.
ESRS Publication Validation Profile
│
├── Core Constitutional Validation
├── Tenant Validation
├── ESRS Structural Validation
├── ESRS Semantic Validation
├── Evidence Validation
├── Governance Validation
└── Publication Validation
Composition SHALL define inclusion, precedence, conflicts, version compatibility and aggregation.
23.37.5. Profile Inheritance and Overlays
A specialised profile MAY inherit from another profile.
Overlays MAY be:
- Core;
- white-label base;
- tenant;
- jurisdictional;
- organisational;
- assurance-specific;
- experimental.
Tenant overlays MAY add stricter rules but SHALL NOT silently disable mandatory Core or jurisdictional rules.
23.37.6. Validation Rule as Constitutional Object
Every Validation Rule SHALL possess:
- Constitutional Identifier;
- canonical name;
- semantic definition;
- rule type;
- subject type;
- governing authority;
- applicability;
- lifecycle;
- version;
- temporal validity;
- severity;
- materiality classification where applicable;
- assurance significance;
- input contract;
- evaluation logic;
- expected result;
- evidence requirements;
- dependencies;
- remediation guidance;
- exception eligibility;
- compiler mappings;
- provenance.
23.37.7. Rule Types
Rule Types MAY include:
- presence;
- datatype;
- cardinality;
- uniqueness;
- range;
- pattern;
- enumeration;
- relationship;
- semantic compatibility;
- authority;
- temporal;
- provenance;
- evidence;
- reconciliation;
- aggregation;
- dependency;
- lifecycle;
- graph constraint;
- calculation;
- unit consistency;
- materiality;
- publication;
- security;
- assurance;
- custom domain rule.
23.37.8. Mandatory and Advisory Rules
A rule MAY be:
- mandatory;
- blocking;
- constraining;
- advisory;
- informational;
- assurance-only;
- simulation-only;
- deprecated.
Advisory rules SHALL NOT create mandatory rejection unless the applicable profile explicitly aggregates them into a blocking threshold.
23.37.9. Rule Applicability
Applicability MAY depend upon:
- subject type;
- classification;
- context;
- jurisdiction;
- tenant;
- lifecycle;
- reporting period;
- methodology;
- assurance level;
- evidence status;
- workflow state;
- publication intent.
An inapplicable rule SHALL produce Not Applicable, not Passed.
23.37.10. Validation Rule Set
The resolved rule collection SHALL form a Validation Rule Set possessing:
- Rule Set Identifier;
- Validation Profile;
- Context Fingerprint;
- rule identities and versions;
- dependency graph;
- resolution provenance;
- completeness status;
- fingerprint;
- creation timestamp.
23.37.11. Rule Conflicts
Rule conflicts SHALL be represented explicitly.
Unresolved mandatory rule conflict SHALL prevent authoritative validation.
23.37.12. Rule Versioning
Historical validation and replay SHALL identify exact rule versions.
A later rule version SHALL NOT silently reinterpret historical Validation Results.
23.37.13. Rule Compilation
The Constitutional Compiler Framework MAY compile rules into target-specific executable artefacts.
Projection loss SHALL never occur silently.
23.38. Structural Validation
Structural Validation determines whether a subject conforms to its applicable Constitutional Schema and Constitutional Properties.
Structural Validation SHALL evaluate constitutional structure rather than implementation syntax alone.
23.38.1. Schema Resolution
The applicable Constitutional Schema and version SHALL be resolved through CRP before structural evaluation.
23.38.2. Structural Checks
HECATE MAY validate:
- required properties;
- datatypes;
- cardinality;
- uniqueness;
- reference integrity;
- collections;
- ordering;
- containment;
- composition;
- aggregation;
- inheritance;
- extension points;
- namespace;
- schema compatibility;
- structural completeness.
23.38.3. Datatype Semantics
Implementation coercion SHALL NOT silently convert invalid constitutional values into valid values.
HECATE SHALL preserve the original observed value and any permitted transformation.
23.38.4. Reference Integrity
HECATE SHALL detect:
- unresolved references;
- wrong target type;
- stale aliases;
- revoked targets;
- cross-tenant references;
- invalid versions;
- forbidden external references.
23.38.5. Lifecycle-Specific Completeness
A draft, proposed, active and published subject MAY have different structural completeness requirements.
The applicable lifecycle profile SHALL be explicit.
23.38.6. Serialization Independence
Passing JSON Schema, XML Schema, SQL, GraphQL or SHACL validation SHALL NOT prove constitutional structural validity where the projection omits constitutional constraints.
23.38.7. Structural Result
A Structural Validation Result SHALL preserve:
- subject;
- schema;
- property or structural location;
- expected structure;
- observed structure;
- rule;
- status;
- severity;
- remediation;
- validator Component;
- provenance.
23.39. Semantic Validation
Semantic Validation determines whether the meaning, classification, relationships, values and interpretations of a subject conform to constitutional semantics.
A subject MAY be structurally valid while semantically invalid.
23.39.1. Semantic Identity
HECATE SHALL detect:
- identifier collision;
- alias ambiguity;
- wrong namespace;
- wrong object type;
- obsolete mapping;
- unauthorised identity substitution.
23.39.2. Relationship Semantics
HECATE SHALL validate:
- Relationship Type;
- source and target roles;
- endpoint compatibility;
- directionality;
- cardinality;
- ownership;
- temporal applicability;
- governance;
- prohibited combinations;
- assertion origin.
A technically connected edge SHALL not be considered semantically valid without these checks.
23.39.3. Classification
Classifications SHALL resolve through governed Constitutional Value Providers.
HECATE SHALL detect unknown, deprecated, incompatible and context-inapplicable values.
23.39.4. Unit and Currency Semantics
HECATE SHALL validate:
- quantity kind;
- unit;
- scale;
- denominator;
- dimensional consistency;
- conversion;
- rounding;
- precision;
- currency;
- exchange-rate source;
- exchange-rate date;
- price-year basis.
23.39.5. Methodology
HECATE SHALL validate methodology identity, version, boundary, assumptions and applicability.
Methodologies SHALL not be silently combined where incompatible.
23.39.6. Equivalence and Compatibility
Similarity or mapping SHALL NOT automatically establish constitutional equivalence.
HECATE SHALL distinguish:
- semantic compatibility;
- structural compatibility;
- temporal compatibility;
- methodological compatibility;
- implementation compatibility;
- assurance compatibility.
23.39.7. Conflict
HECATE SHALL detect:
- contradictory definitions;
- incompatible classifications;
- mutually exclusive relationships;
- inconsistent boundaries;
- incompatible units;
- contradictory assertions;
- incompatible methodologies.
23.39.8. Inferred and AI-Generated Knowledge
Derived assertions SHALL preserve:
- reasoning profile;
- source assertions;
- rule identity;
- confidence;
- context;
- temporal applicability;
- provenance.
AI-generated proposals SHALL be validated for grounding, identity, unsupported claims, context applicability, confidence, authority and approval requirements.
AI fluency SHALL not be treated as semantic validity.
23.39.9. Semantic Result
The result SHALL preserve:
- semantic subject;
- expected meaning;
- observed meaning;
- registry or ontology references;
- context;
- rule;
- status;
- confidence where applicable;
- validator;
- explanation;
- provenance.
23.40. Governance and Authority Validation
Governance and Authority Validation determines whether a subject and the actions performed upon it comply with applicable ownership, stewardship, approval, authority, accountability and separation-of-duties requirements.
23.40.1. Governance Checks
HECATE MAY validate:
- ownership;
- stewardship;
- approval;
- review;
- audit;
- delegation;
- interpretation authority;
- certification;
- verification;
- lifecycle authority;
- override authority;
- waiver authority;
- publication authority;
- emergency authority;
- agent authority.
23.40.2. Authority Chain
HECATE SHALL detect:
- missing authority;
- expired authority;
- authority outside scope;
- broken delegation;
- circular delegation;
- unauthorised sub-delegation;
- authority escalation;
- conflicting authorities.
23.40.3. Separation of Duties
Examples include:
- requester SHALL NOT be sole approver;
- author SHALL NOT be sole verifier;
- evidence submitter SHALL NOT be sole certifier;
- compiler publisher SHALL NOT be sole runtime activator;
- finding owner SHALL NOT be sole waiver approver;
- AI agent SHALL NOT approve its own proposed change.
23.40.4. Approval
Approval validation SHALL confirm:
- approver identity;
- approver authority;
- approved version;
- scope;
- conditions;
- timestamp;
- expiration;
- revocation;
- signature;
- separation of duties.
Approval of one version SHALL NOT validate a materially changed version.
23.40.5. Override and Waiver Authority
Overrides and waivers SHALL be validated for:
- eligible target or rule;
- authority;
- scope;
- reason;
- duration;
- approval;
- compensating controls;
- residual risk;
- review requirements.
A waiver SHALL NOT convert a failed result into a passed result.
23.40.6. Agent Authority
AI and autonomous Components SHALL be validated for:
- Agent Identity;
- model or Component version;
- assigned capabilities;
- purpose;
- scope;
- time limit;
- data access;
- side-effect authority;
- approval requirements;
- tool permissions;
- auditability.
23.40.7. Governance Result
The result SHALL preserve:
- subject;
- action;
- actor;
- authority;
- role;
- assignment;
- delegation;
- policy;
- separation-of-duties evaluation;
- result;
- finding;
- explanation;
- provenance.
23.41. Temporal and Context Validation
Temporal and Context Validation evaluates whether subjects, rules, policies, authorities and evidence apply within the Runtime Context and applicable time dimensions.
Part III defines Context Assembly and Context Fingerprints. This section defines how HECATE executes reusable temporal and contextual rules.
23.41.1. Time Dimensions
HECATE SHALL distinguish:
- effective time;
- valid time;
- transaction time;
- observation time;
- evidence acquisition time;
- publication time;
- regulatory issuance time;
- reporting period;
- fiscal period;
- execution time.
23.41.2. Temporal Checks
HECATE SHALL detect:
- use before activation;
- use after inactivation;
- use after revocation;
- overlapping versions;
- gaps in mandatory applicability;
- mismatched reporting periods;
- late-arriving evidence;
- backdated authority;
- future-effective policies used as current;
- invalid historical reconstruction.
23.41.3. Context Checks
HECATE SHALL validate:
- mandatory context dimensions;
- context coherence;
- context inheritance;
- override authority;
- tenant compatibility;
- jurisdiction compatibility;
- framework compatibility;
- Runtime Bundle compatibility;
- security constraints;
- assurance requirements;
- Context Fingerprint consistency.
23.41.4. Qualification Propagation
Conditional, provisional, incomplete and simulation-only contexts SHALL propagate their qualification to Validation Results and Validation Outcomes.
23.41.5. Historical and Future Evaluation
Historical evaluation SHALL use historical graph state, rule versions, policies, authority and evidence state.
Future evaluation SHALL distinguish approved future-effective knowledge from forecasts, draft policy and scenario assumptions.
23.41.6. Temporal and Context Result
The result SHALL preserve:
- evaluated time dimensions;
- Runtime Context;
- Context Fingerprint;
- applicable intervals;
- conflicts;
- gaps;
- qualifications;
- rule;
- status;
- validator;
- provenance.
23.42. Provenance and Lineage Validation
Provenance and Lineage Validation determines whether origin, derivation, custody, transformation and implementation lineage are complete, coherent, trustworthy and fit for purpose.
23.42.1. Provenance Checks
HECATE MAY validate:
- origin identity;
- source authority;
- source version;
- acquisition time;
- derivation chain;
- chain of custody;
- causal lineage;
- compiler lineage;
- Runtime Bundle lineage;
- Module lineage;
- Component lineage;
- transformation lineage;
- signatures;
- redactions;
- retention;
- provenance completeness.
23.42.2. Derivation
Derived knowledge SHALL preserve:
- source inputs;
- method;
- Component;
- Module;
- version;
- parameters;
- context;
- temporal boundary;
- output;
- confidence where applicable.
23.42.3. Chain of Custody
HECATE SHALL validate:
- custodians;
- transfer events;
- timestamps;
- signatures;
- integrity checks;
- access events;
- transformation events;
- redactions;
- breaks in custody.
23.42.4. Compiler and Runtime Bundle Lineage
Generated artefacts SHALL preserve:
- constitutional source release;
- source object identities;
- compiler identity and version;
- Projection Profile;
- Compiler Manifest;
- build fingerprint;
- semantic verification;
- projection-loss analysis.
Runtime Bundles SHALL preserve content digests, signatures, dependencies, overlays and revocation status.
23.42.5. Module and Component Lineage
Every constitutionally significant outcome SHALL preserve:
- Module identity;
- Component identity;
- Component version;
- deployment identity;
- Runtime Bundle;
- Execution Identifier;
- Validation Plan Step;
- provenance.
23.42.6. Provenance Completeness
Completeness MAY be classified as:
- complete;
- complete with controlled redaction;
- partially complete;
- materially incomplete;
- reconstructed;
- disputed;
- unavailable.
The required level SHALL depend upon purpose and assurance.
23.42.7. Provenance Result
The result SHALL preserve:
- subject;
- provenance graph;
- evaluated requirements;
- missing links;
- conflicts;
- trust state;
- completeness classification;
- findings;
- validator;
- provenance of the validation itself.
23.43. Evidence and Assurance Validation
Evidence Validation determines whether evidence is authentic, applicable, sufficient, current, trustworthy and connected to the claim, assertion, calculation, disclosure or outcome it supports.
Assurance Validation determines whether the validation process and evidence satisfy an applicable assurance profile.
Validation determines conformance. Assurance determines the justified level of confidence that may be placed upon that conformance.
23.43.1. Evidence Object
Every Evidence Object SHOULD possess:
- Evidence Identifier;
- evidence type;
- source;
- issuer;
- acquisition method;
- acquisition time;
- relevant period;
- subject;
- supported claim;
- custody;
- integrity;
- verification status;
- confidentiality;
- retention;
- provenance.
23.43.2. Evidence Types
Evidence MAY include:
- primary documents;
- invoices;
- meter readings;
- sensor observations;
- transaction records;
- contracts;
- certificates;
- regulatory publications;
- supplier declarations;
- audit workpapers;
- scientific publications;
- calculation traces;
- model outputs;
- photographs;
- geospatial records;
- laboratory results;
- signed attestations;
- external registry records;
- machine-generated logs.
23.43.3. Evidence Evaluation
HECATE SHALL evaluate:
- applicability;
- authenticity;
- integrity;
- sufficiency;
- quality;
- independence;
- acquisition time;
- chain of custody;
- verification;
- expiration;
- revocation;
- conflict;
- licensing;
- confidentiality.
23.43.4. Evidence Quality
Quality MAY consider:
- primary versus secondary source;
- independence;
- precision;
- completeness;
- recency within the correct temporal model;
- verification;
- methodological fitness;
- uncertainty;
- source authority;
- reproducibility.
Quality scoring SHALL be governed and explainable.
23.43.5. Evidence Conflict
Conflicting evidence SHALL remain visible.
Resolution MAY consider authority, verification, custody, recency, methodology, independence, precision and assurance status.
23.43.6. Sampling
Where sampling is used, HECATE SHALL validate:
- population;
- sampling method;
- sample size;
- selection procedure;
- representativeness;
- exclusions;
- confidence level;
- tolerable error;
- extrapolation;
- limitations.
23.43.7. Assurance Profiles
Assurance Profiles MAY include:
- no assurance;
- internal review;
- limited assurance;
- reasonable assurance;
- certification;
- regulatory verification;
- contractual assurance.
23.43.8. Assurance Limitations
Limitations SHALL be recorded where:
- scope is incomplete;
- evidence is unavailable;
- sampling is constrained;
- independence is impaired;
- methodology is provisional;
- context is uncertain;
- material findings remain open.
23.43.9. Evidence and Assurance Results
Results SHALL preserve:
- evidence identity;
- supported claim;
- applicability;
- authenticity;
- integrity;
- sufficiency;
- quality;
- independence;
- conflicts;
- assurance profile;
- limitations;
- verifier identity;
- findings;
- provenance.
23.44. Cross-Object, Graph and Aggregate Validation
Cross-Object, Graph and Aggregate Validation evaluates constraints that cannot be determined from one isolated subject.
Many ESG, reporting, assurance and supply-chain defects exist only across relationships, populations, periods, calculations or graph paths.
23.44.1. Cross-Object Consistency
HECATE MAY validate:
- shared identifiers;
- aligned boundaries;
- compatible lifecycle states;
- consistent units;
- consistent classifications;
- aligned periods;
- coherent authority;
- duplicate facts;
- required counterpart objects.
23.44.2. Graph Integrity
HECATE SHALL validate:
- node identity;
- relationship identity;
- endpoint integrity;
- Relationship Type;
- endpoint roles;
- cardinality;
- prohibited cycles;
- required and forbidden paths;
- partition boundaries;
- tenant isolation;
- temporal applicability;
- provenance.
23.44.3. Graph Paths and Subgraphs
HECATE MAY validate paths and subgraphs for:
- allowed Relationship Types;
- maximum depth;
- authority;
- temporal continuity;
- provenance continuity;
- tenant continuity;
- completeness;
- closure;
- snapshot consistency;
- security.
23.44.4. Dependency and Cycle Validation
HECATE SHALL detect:
- missing dependencies;
- incompatible versions;
- circular dependencies;
- revoked dependencies;
- untrusted dependencies;
- tenant leakage;
- unresolved dependency context.
Cycles SHALL be evaluated per Relationship Type.
23.44.5. Aggregate Reconciliation
HECATE MAY validate:
- sum of parts equals total;
- allocation shares reconcile;
- opening plus movement equals closing;
- report totals match source data;
- subgroup totals reconcile;
- currency conversions reconcile;
- unit conversions reconcile;
- period totals reconcile.
23.44.6. Calculation Chains
HECATE SHALL validate:
- input identity;
- input version;
- formula identity and version;
- parameters;
- units;
- rounding;
- intermediate results;
- uncertainty;
- output;
- provenance.
23.44.7. ESG Domain Validation
Domain-specific validation MAY include:
- Scope 1, 2 and 3 classification;
- organisational and operational boundaries;
- emission-factor applicability;
- activity-data units;
- market-based and location-based separation;
- renewable-energy claims;
- biogenic carbon treatment;
- avoided-emissions separation;
- double-counting prevention;
- base-year consistency;
- lifecycle functional unit;
- system boundary;
- allocation;
- cut-off criteria;
- data quality;
- PEF and OEF requirements;
- product-to-supply-chain traceability;
- disclosure completeness;
- report-to-source traceability.
23.44.8. Multi-Period and Population Validation
HECATE MAY validate:
- period continuity;
- restatements;
- methodology changes;
- boundary changes;
- trend consistency;
- duplicates;
- outliers;
- coverage;
- completeness;
- population distributions;
- statistical consistency.
23.44.9. Federated Validation
Federated validation SHALL evaluate:
- source trust profile;
- identity mapping;
- synchronization state;
- version alignment;
- staleness;
- projection loss;
- authority;
- provenance;
- cross-domain conflicts;
- tenant and jurisdiction boundaries.
23.44.10. Incremental Validation
HECATE SHOULD support dependency-aware Incremental Validation.
When a subject changes, HECATE SHALL identify affected:
- rules;
- objects;
- relationships;
- graph paths;
- calculations;
- aggregates;
- reports;
- disclosures;
- evidence conclusions;
- assurance conclusions;
- cached outcomes.
Only the constitutionally affected scope SHOULD be revalidated.
23.44.11. Continuous Validation
Continuous Validation MAY monitor:
- streaming data;
- registry changes;
- policy changes;
- evidence revocation;
- graph changes;
- Runtime Bundle changes;
- authority changes;
- context changes;
- external synchronization;
- runtime drift.
Every continuous finding SHALL preserve its triggering event and subject snapshot.
23.45. Severity, Findings, Exceptions and Remediation
Validation defects SHALL be represented through governed Validation Findings rather than unstructured log messages.
Severity, confidence, materiality, assurance significance, regulatory significance and remediation priority SHALL remain distinct.
23.45.1. Validation Result
A Validation Result is the result of evaluating one Validation Rule against one defined subject or scope.
Result statuses SHALL include:
- Passed;
- Failed;
- Indeterminate;
- Not Applicable;
- Not Evaluated;
- Error;
- Cancelled.
A technical runtime error SHALL not be represented as a failed constitutional rule unless the rule was actually evaluated and failed.
23.45.2. Validation Finding
A Validation Finding is a governed Constitutional Object or governed runtime object representing a condition requiring attention, action, qualification or governance.
Every finding SHALL possess:
- Finding Identifier;
- finding type;
- subject;
- Validation Rule;
- Validation Result;
- Validation Request;
- Validation Plan;
- Runtime Context;
- severity;
- materiality;
- confidence;
- assurance significance;
- regulatory significance;
- description;
- evidence;
- affected scope;
- lifecycle;
- owner;
- remediation status;
- exception status;
- provenance.
23.45.3. Severity
Severity values SHALL include:
- Information;
- Recommendation;
- Warning;
- Error;
- Critical Error.
Severity SHALL reflect constitutional impact, not technical inconvenience.
23.45.4. Materiality and Confidence
Materiality MAY be:
- immaterial;
- potentially material;
- material;
- highly material;
- not assessed.
Confidence MAY be:
- confirmed;
- high;
- medium;
- low;
- disputed;
- unknown.
These dimensions SHALL not be collapsed into severity.
23.45.5. Finding Lifecycle
Detected
│
▼
Confirmed
│
├──► Disputed
├──► Waived
├──► Accepted Risk
▼
Remediation Planned
│
▼
In Remediation
│
▼
Remediated
│
▼
Revalidated
│
▼
Closed
Lifecycle transitions SHALL preserve authority, reason, timestamp and provenance.
23.45.6. Validation Exception
A Validation Exception permits continued processing despite a finding under explicitly governed conditions.
An exception SHALL NOT change the underlying Validation Result.
23.45.7. Validation Waiver
A waiver SHALL identify:
- waived rule;
- subject;
- scope;
- reason;
- authority;
- compensating controls;
- residual risk;
- start and end time;
- review date;
- approval;
- provenance.
23.45.8. Non-Waivable Rules
The Constitution MAY declare rules non-waivable, including:
- Constitutional Identity integrity;
- tenant isolation;
- mandatory legal prohibitions;
- required provenance retention;
- required disclosure of uncertainty;
- prohibition on unauthorised publication;
- prohibition on presenting Not Evaluated as Valid;
- prohibition on presenting AI-proposed knowledge as canonical.
23.45.9. Suppression
Technical suppression MAY reduce repeated presentation of a finding, but SHALL NOT erase it or change its constitutional status.
23.45.10. Accepted Risk
Accepted Risk SHALL preserve:
- decision authority;
- rationale;
- risk owner;
- residual risk;
- review date;
- conditions;
- affected outcomes;
- provenance.
23.45.11. Remediation Task
A Remediation Task SHALL include:
- Task Identifier;
- finding;
- responsible Role;
- required action;
- due date;
- priority;
- evidence requirement;
- dependencies;
- revalidation requirement;
- escalation;
- status;
- provenance.
23.45.12. Corrective and Preventive Action
Corrective Action MAY include:
- data correction;
- schema correction;
- relationship correction;
- authority correction;
- evidence replacement;
- methodology correction;
- recalculation;
- report restatement;
- publication correction;
- workflow correction;
- rule correction;
- Runtime Bundle replacement;
- tenant overlay correction.
Preventive Action MAY include stronger validation, earlier validation, process redesign, improved evidence controls, better monitoring, rule clarification, compiler improvement or Component replacement.
23.45.13. Remediation Validation
A finding SHALL not be closed solely because remediation was reported complete.
HECATE SHALL revalidate the affected subject and dependencies.
23.45.14. Escalation and Recurrence
Findings MAY escalate based on severity, materiality, age, recurrence, regulatory significance, assurance significance, missed due date and systemic scope.
Pergamum Pulse MAY identify recurring patterns while preserving underlying findings and lineage.
23.46. Validation Outcomes, Explanations and Provenance
A Validation Outcome is the governed aggregate constitutional conclusion produced by one Validation Plan.
A Validation Outcome SHALL not collapse failed, indeterminate, not-applicable and unevaluated states into a single boolean.
23.46.1. Outcome Statuses
| Outcome | Meaning |
|---|---|
| Valid | All required applicable rules passed |
| Valid with Warnings | Mandatory rules passed; non-blocking findings exist |
| Conditionally Valid | Use is permitted only under explicit conditions |
| Provisionally Valid | Temporary validity pending evidence, approval or final evaluation |
| Invalid | One or more applicable mandatory rules failed |
| Blocked | Validation or use cannot proceed due to a blocking condition |
| Indeterminate | A conclusion cannot be reached |
| Not Applicable | The Validation Profile does not apply |
| Not Evaluated | Required validation has not been performed |
| Cancelled | Validation was cancelled before conclusion |
| Error | Runtime failure prevented a valid conclusion |
23.46.2. Aggregation
The Validation Profile SHALL define how results aggregate.
Aggregation MAY consider:
- mandatory failures;
- severity thresholds;
- materiality;
- assurance significance;
- regulatory significance;
- Indeterminate results;
- Not Evaluated rules;
- exceptions;
- waivers;
- accepted risk;
- profile-specific tolerances.
23.46.3. Boolean Prohibition
HECATE SHALL NOT expose a single boolean as the sole constitutional Validation Outcome.
A boolean MAY be provided only as an explicitly mapped implementation projection.
23.46.4. Outcome Identity
Every Validation Outcome SHALL possess:
- Validation Outcome Identifier;
- Validation Request;
- Validation Plan;
- subject;
- subject snapshot;
- Runtime Context;
- Context Fingerprint;
- Validation Profile;
- Validation Rule Set;
- status;
- findings;
- exceptions;
- waivers;
- qualifications;
- remediation requirements;
- HECATE Runtime Bundle;
- validator Components;
- start and completion times;
- fingerprint;
- provenance.
23.46.5. Scope and Qualification
The outcome SHALL identify its:
- subject scope;
- graph scope;
- population scope;
- temporal scope;
- tenant scope;
- jurisdiction scope;
- profile scope;
- evidence scope;
- assurance scope.
Qualifications MAY include advisory-only, simulation-only, incomplete scope, sampled population, provisional evidence, fallback rule, reduced assurance, context uncertainty or unversioned dependency.
23.46.6. Validity and Invalidation
A Validation Outcome MAY expire or be invalidated upon:
- subject change;
- context change;
- rule change;
- evidence expiration;
- authority change;
- Runtime Bundle change;
- temporal expiry;
- dependency change;
- revocation;
- new finding.
Invalidation SHALL preserve the original outcome and trigger impact analysis.
23.46.7. Validation Explanation
Every authoritative outcome SHALL have machine-readable and human-readable explanations identifying:
- what was validated;
- why the profile applied;
- which rules applied;
- which rules passed;
- which rules failed;
- which rules were Indeterminate;
- which rules were Not Applicable;
- which rules were Not Evaluated;
- which findings were created;
- which exceptions or waivers applied;
- how the outcome was aggregated;
- what remediation is required;
- what limitations remain.
23.46.8. Explanation Layers
Explanations SHOULD support:
- executive summary;
- subject-owner explanation;
- developer explanation;
- governance explanation;
- regulatory explanation;
- assurance explanation;
- machine explanation;
- forensic explanation.
All layers SHALL preserve the same underlying Validation Outcome.
23.46.9. Validation Provenance
Validation Provenance SHALL include:
- Validation Request;
- Validation Plan;
- subject snapshot;
- Runtime Context;
- Context Fingerprint;
- Validation Profile;
- Validation Rule Set;
- rule versions;
- evidence;
- validator Components;
- Module lineage;
- Component lineage;
- execution order;
- intermediate values;
- results;
- findings;
- exceptions;
- remediation;
- outcome;
- timestamps;
- signatures;
- trust state.
23.46.10. Validation Events
HECATE SHOULD produce immutable events including:
- ValidationRequested;
- ProfileResolved;
- RuleSetResolved;
- ValidationPlanCreated;
- RuleEvaluationStarted;
- RuleEvaluationCompleted;
- FindingCreated;
- FindingEscalated;
- ExceptionGranted;
- WaiverGranted;
- RemediationCreated;
- RemediationCompleted;
- RevalidationRequested;
- OutcomeProduced;
- OutcomeInvalidated;
- ValidationFailed;
- ValidationCancelled.
23.46.11. Replay and Diff
HECATE SHALL support validation replay using the original subject snapshot, context, profile, rule set, evidence and Runtime Bundle.
A Validation Diff SHOULD identify changes in subject, context, rules, evidence, results, findings, exceptions, qualifications and outcome.
23.46.12. Impact Analysis
Changes to a Validation Rule, profile, subject, evidence source or Runtime Bundle SHALL support impact analysis over:
- prior Validation Outcomes;
- affected subjects;
- reports;
- disclosures;
- calculations;
- publications;
- assurance conclusions;
- tenants;
- Modules;
- Components.
23.46.13. Observability
Operational metrics MAY include:
- validation volume;
- latency;
- rule execution time;
- finding frequency;
- Indeterminate rate;
- Not Evaluated rate;
- exception frequency;
- waiver age;
- remediation duration;
- revalidation rate;
- runtime drift.
Operational metrics SHALL not alter validation semantics.
23.46.14. Pergamum Pulse Integration
Pergamum Pulse MAY derive intelligence including:
- systemic validation risk;
- recurring findings;
- weak evidence patterns;
- rule coverage gaps;
- excessive exception use;
- stale waivers;
- Component reliability;
- Module-level conformance;
- tenant divergence;
- jurisdictional divergence;
- assurance readiness;
- remediation effectiveness;
- validation debt;
- runtime drift.
Pergamum Pulse SHALL preserve:
- Module lineage;
- Component lineage;
- subject lineage;
- Validation Rule lineage;
- Validation Profile lineage;
- Context lineage;
- Runtime Bundle lineage;
- temporal validity;
- tenant isolation;
- provenance.
Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.
23.46.15. HECATE Conformance Suite
The Constitutional Compiler Framework SHOULD generate a HECATE Conformance Suite including:
- valid fixtures;
- invalid fixtures;
- boundary cases;
- temporal cases;
- tenant-isolation cases;
- authority cases;
- graph-cycle cases;
- evidence cases;
- rule-conflict cases;
- exception cases;
- replay cases;
- determinism cases.
Part IV Conformance
A Constitutional Runtime Framework implementation conforms to Part IV where it:
- treats HECATE as the governed constitutional validation runtime;
- separates rule applicability resolution from rule evaluation;
- represents every Validation Rule as a governed Constitutional Object;
- requires an identifiable Validation Request and deterministic Validation Plan;
- resolves Validation Profiles and rule versions through Constitutional Resolution Policies;
- preserves a fingerprinted Validation Rule Set;
- supports structural, semantic, governance, temporal, context, provenance, evidence, graph and aggregate validation;
- distinguishes Validation Result, Validation Finding and Validation Outcome;
- distinguishes Passed, Failed, Indeterminate, Not Applicable and Not Evaluated;
- prohibits unevaluated or indeterminate subjects from being represented as valid;
- represents findings, exceptions, waivers and remediation as governed objects;
- preserves the failed result when an exception or waiver is granted;
- supports incremental and continuous validation;
- supports deterministic replay and semantic diff;
- validates subject snapshots rather than ambiguous mutable state;
- preserves complete validation provenance;
- preserves both Module and Component lineage;
- supports impact analysis when rules, evidence, subjects, contexts or runtime artefacts change;
- prevents untrusted HECATE configurations from producing authoritative outcomes;
- produces machine-readable and human-readable Validation Explanations.
Part IV Foundational Principle
Validation Runtime is the governed constitutional mechanism through which HECATE determines whether constitutional and operational subjects conform to the requirements that apply within an explicit Runtime Context.
Constitutional Resolution Policies SHALL determine which Validation Profiles, Validation Rules and rule versions apply. HECATE SHALL execute those rules against identifiable subject snapshots, evidence and graph states, producing distinct Validation Results, Validation Findings and Validation Outcomes. Structural validity, semantic validity, governance validity, temporal validity, provenance validity, evidence sufficiency and aggregate consistency SHALL remain distinguishable while contributing to one explainable constitutional outcome.
A waiver, exception, accepted risk or technical suppression SHALL never rewrite a failed Validation Result into a passed result. An Indeterminate, Not Applicable or Not Evaluated state SHALL never be represented as Valid. Every outcome SHALL preserve its subject, scope, context, rule set, evidence, findings, validator Components, Runtime Bundle, Module lineage, Component lineage and complete provenance.
By making validation deterministic, context-aware, incremental, continuously observable and independently replayable, ZAYAZ ensures that constitutional knowledge, ESG data, calculations, reports, supply-chain assertions, Digital Product Passports, AI proposals and runtime decisions remain trustworthy from ingestion through publication and assurance.