Chapter 23 — Constitutional Runtime Framework
Part II — Constitutional Execution
Constitutional Execution defines how the Constitutional Runtime Framework accepts an Execution Request, establishes authority and scope, constructs a deterministic Execution Plan, coordinates Runtime Components, controls state and side effects, produces governed Runtime Outcomes and preserves complete Execution Provenance.
Execution SHALL be treated as a constitutional process rather than an implementation detail.
No runtime action becomes constitutionally valid merely because software successfully performed it. Constitutional validity requires that the action was requested, admitted, authorised, planned, executed, validated and recorded in accordance with the applicable Constitution, Constitutional Context, Runtime Bundle, Runtime Manifest and governance policies.
Execution Request
│
▼
Admission and Authority Validation
│
▼
Runtime Context and Scope Resolution
│
▼
Deterministic Execution Plan
│
▼
Governed Execution Session
│
├── Resolution
├── Validation
├── Reasoning
├── Computation
├── Workflow
├── Events
└── Side Effects
│
▼
Outcome Validation
│
▼
Commit, Compensation or Rejection
│
▼
Execution Provenance and Explanation
Every constitutionally significant execution SHALL be reproducible to the degree permitted by its declared execution mode and governed sources of non-determinism.
23.11. Execution Request
An Execution Request is the governed runtime object that asks the Constitutional Runtime Framework to perform one or more runtime capabilities.
Every authoritative execution SHALL originate from an identifiable Execution Request.
The request SHALL conform to a Constitutional Schema or another explicitly governed runtime contract.
23.11.1. Request Purpose
Every request SHALL state its constitutional purpose.
Purposes MAY include:
- resolving applicable constitutional knowledge;
- validating a Constitutional Object, Relationship, assertion or evidence object;
- evaluating a reporting or regulatory obligation;
- executing a governed computation;
- progressing a workflow;
- determining publication eligibility;
- reconstructing historical state;
- simulating future or alternative state;
- verifying evidence;
- invoking an authorised agent;
- generating an explanation;
- performing impact analysis;
- executing assurance procedures.
Purpose SHALL constrain execution scope, authority and permissible side effects.
A request SHALL NOT be repurposed during execution without a governed amendment or a new Execution Request.
23.11.2. Request Identity
Every Execution Request SHALL possess:
- Request Identifier;
- request type;
- initiating actor identity;
- initiating authority where applicable;
- creation timestamp;
- requested capability;
- intended purpose;
- target Constitutional Objects or runtime entities;
- requested Runtime Context;
- requested execution mode;
- requested side effects;
- required outcome type;
- provenance;
- integrity metadata.
Request identity SHALL remain stable across retries and distributed transport.
A materially different request SHALL receive a new Request Identifier.
23.11.3. Request Types
| Request Type | Constitutional Purpose |
|---|---|
| Query Request | Retrieve or traverse constitutional knowledge |
| Resolution Request | Select applicable constitutional knowledge |
| Validation Request | Evaluate conformance or admissibility |
| Reasoning Request | Derive governed assertions |
| Computation Request | Execute a governed calculation or model |
| Workflow Request | Initiate or progress constitutional workflow |
| Mutation Request | Create or alter authorised runtime state |
| Publication Request | Publish an eligible constitutional outcome |
| Replay Request | Re-execute a prior execution |
| Reconstruction Request | Rebuild historical runtime state |
| Simulation Request | Evaluate a non-authoritative scenario |
| Assurance Request | Execute assurance or verification procedures |
| Agent Request | Invoke an AI or autonomous Component within defined authority |
Request Type values SHOULD originate from a governed Constitutional Value Provider.
23.11.4. Request Inputs
Inputs SHALL be explicitly declared and typed.
Inputs MAY include:
- Constitutional Identifiers;
- Constitutional Objects and Relationships;
- Constitutional Context references;
- evidence and observations;
- parameters and datasets;
- prior Runtime Outcomes;
- workflow state;
- external references;
- simulation assumptions.
Every input SHALL preserve its origin, identity, version, temporal state and trust status where constitutionally relevant.
Unidentified inputs SHALL NOT be used for authoritative execution unless an applicable policy explicitly permits provisional input.
23.11.5. Request Preconditions
Preconditions MAY include:
- required lifecycle state;
- required authority;
- required evidence;
- required Runtime Bundle;
- minimum assurance level;
- required validation status;
- expected prior state;
- expected constitutional release;
- temporal applicability;
- dependency availability;
- trust threshold.
Mandatory preconditions SHALL be evaluated before side effects occur.
Failure SHALL reject or suspend execution according to governing policy.
23.11.6. Request Constraints
A request MAY constrain:
- execution duration;
- resource or financial cost;
- traversal depth;
- permitted or prohibited Components;
- permitted data regions;
- permitted external services;
- reasoning and model profiles;
- consistency level;
- assurance level;
- side effects.
Request constraints MAY narrow but SHALL NOT expand constitutional authority.
23.11.7. Request Fingerprint
Every authoritative request SHALL possess a deterministic Request Fingerprint derived from constitutionally relevant content, including:
- request type and purpose;
- target identities;
- input identities and versions;
- requested context;
- execution mode;
- side-effect declaration;
- preconditions;
- constraints.
Irrelevant transport and infrastructure metadata SHALL be excluded unless it affects constitutional behaviour.
The Request Fingerprint SHALL support duplicate detection, idempotency, replay, cache safety, audit correlation and dispute resolution.
23.11.8. Request Admission
Every request SHALL pass governed admission control.
Admission SHALL evaluate:
- identity and schema conformance;
- actor identity and authority;
- purpose legitimacy;
- context completeness;
- Runtime Boundary compliance;
- input integrity;
- tenant isolation;
- trust requirements;
- resource policy;
- prohibited operations;
- emergency restrictions.
Admission SHALL fail closed where identity, authority or constitutional scope cannot be established.
23.11.9. Request Amendment
A pending request MAY be amended only where:
- the amendment is authorised;
- the request has not crossed an immutable execution boundary;
- the amendment is recorded;
- a new Request Fingerprint is produced;
- affected plans and approvals are invalidated or re-evaluated;
- provenance links the previous and amended forms.
Material amendment after execution begins SHOULD create a new Execution Request.
23.11.10. Request Rejection
A rejected request SHALL produce a governed rejection outcome containing:
- Request Identifier;
- rejection reason;
- governing policy;
- failed admission criteria;
- responsible authority;
- remediation or appeal path where applicable;
- timestamp;
- provenance.
Rejected requests SHALL remain auditable.
23.12. Execution Plan
An Execution Plan is the deterministic governed artefact that defines how an admitted Execution Request SHALL be executed.
The plan SHALL translate constitutional intent into an ordered or partially ordered set of Plan Steps without redefining constitutional meaning.
It SHALL be produced from the Execution Request, Runtime Context, Runtime Bundle, Runtime Manifest, applicable policies and available Runtime Component capabilities.
23.12.1. Plan Identity
Every Execution Plan SHALL possess:
- Execution Plan Identifier;
- plan version;
- source Request Identifier;
- Request Fingerprint;
- Context Fingerprint;
- Runtime Bundle identity;
- Runtime Manifest identity;
- planner identity and version;
- Plan Fingerprint;
- lifecycle state;
- governing authority;
- provenance.
A material plan change SHALL produce a new version and fingerprint.
23.12.2. Plan Contents
An Execution Plan SHALL define, where applicable:
- purpose and scope;
- authority;
- required Runtime Components and capabilities;
- ordered and parallelisable steps;
- dependencies;
- input and output contracts;
- validation and approval gates;
- transaction boundaries;
- consistency requirements;
- temporal evaluation points;
- reasoning profile;
- side-effect boundaries;
- retry and timeout policies;
- compensation actions;
- completion criteria;
- outcome validation;
- explanation requirements;
- provenance obligations.
23.12.3. Plan Steps
Each Plan Step SHALL define:
- Step Identifier;
- capability requirement;
- selected Runtime Component or selection rule;
- input and output contracts;
- preconditions and postconditions;
- dependencies;
- authority requirement;
- validation requirement;
- temporal rule;
- side-effect declaration;
- transaction participation;
- retry classification;
- compensation rule;
- provenance requirement.
Plan Step identity SHALL remain stable across attempts where the semantic step is unchanged.
23.12.4. Plan Graph
The plan SHOULD be represented as a governed directed graph.
Admission
│
▼
Context Resolution
│
▼
Authority Resolution
│
├──────────────┐
▼ ▼
Validation Candidate Resolution
│ │
└──────┬───────┘
▼
Computation
│
▼
Outcome Validation
│
▼
Commit
The Plan Graph SHALL distinguish:
- mandatory and optional dependencies;
- parallel and conditional branches;
- failure and compensation branches;
- approval gates;
- terminal outcomes.
Cycles SHALL be prohibited unless an applicable workflow or iterative computation profile explicitly permits and bounds them.
23.12.5. Static and Dynamic Planning
Planning MAY be static, dynamic, governed-adaptive or hybrid.
Dynamic planning MAY select later steps from runtime outcomes only where:
- the selection policy is predetermined;
- the permitted plan space is bounded;
- every choice is explainable;
- authority is preserved;
- the resulting plan version is recorded;
- hidden model discretion does not redefine constitutional behaviour.
23.12.6. Plan Determinism
Equivalent admitted requests, contexts, bundles, manifests and capability inventories SHALL produce semantically equivalent plans.
Where several equivalent Components exist, selection SHALL follow a governed deterministic policy or record the explicitly permitted source of non-determinism.
23.12.7. Plan Optimisation
The Runtime Planner MAY optimise a plan provided semantic equivalence is preserved.
Permitted optimisations MAY include:
- parallelisation;
- redundant validation elimination;
- safe result reuse;
- traversal reduction;
- locality optimisation;
- batching;
- projection selection;
- prefetching;
- conformant Component substitution.
Optimisation SHALL NOT remove mandatory validation or approval, weaken authority, change temporal semantics, expand side effects or reduce provenance.
23.12.8. Plan Validation
HECATE SHALL validate the Execution Plan for:
- identity completeness;
- request-plan consistency;
- context compatibility;
- authority sufficiency;
- Component capability compatibility;
- dependency integrity;
- cycle safety;
- transaction and compensation completeness;
- side-effect compliance;
- temporal correctness;
- tenant isolation;
- outcome validation coverage;
- provenance completeness.
An invalid plan SHALL NOT execute authoritatively.
23.12.9. Plan Approval
A plan MAY require approval based on:
- execution risk;
- side-effect significance;
- regulatory or financial materiality;
- data sensitivity;
- assurance profile;
- use of AI or autonomous agents;
- external services;
- emergency mode.
Approval SHALL preserve approver identity, authority, scope, timestamp, conditions and provenance.
Approval of one plan version SHALL NOT approve a materially changed version.
23.12.10. Plan Explanation
Every plan SHALL be explainable before execution.
Its explanation SHALL identify:
- why the plan was selected;
- which policies shaped it;
- which Components were chosen;
- which alternatives were rejected;
- which validations and approvals will occur;
- where side effects, failure or compensation may occur;
- which outcomes are possible.
23.13. Execution Session
An Execution Session is the governed boundary coordinating one or more related executions over a defined period and purpose.
Session continuity SHALL NOT obscure the identity, context, authority or provenance of individual executions.
23.13.1. Session Identity
Every session SHALL possess:
- Session Identifier;
- session type;
- initiating purpose and actor;
- governing authority;
- tenant and jurisdiction boundaries;
- initial Runtime Context;
- initial Runtime Bundle;
- lifecycle state;
- creation timestamp;
- expiration policy;
- provenance.
23.13.2. Session Types
Session Types MAY include:
- interactive user;
- workflow;
- reporting;
- assurance;
- investigation;
- computation;
- agent;
- federation;
- replay;
- simulation;
- publication.
Session Type SHALL constrain continuity, state, authority and side effects.
23.13.3. Session Context
A session MAY provide inherited context, but every execution SHALL establish its own effective Runtime Context and Context Fingerprint.
Session context SHALL NOT conceal changes in tenant, jurisdiction, reporting period, constitutional release, Runtime Bundle, authority, assurance level or security profile.
23.13.4. Session State
Session State MAY contain:
- prior requests and outcomes;
- workflow state;
- unresolved questions;
- approved assumptions;
- evidence references;
- temporary selections;
- conversation history;
- agent memory;
- execution checkpoints.
Session State SHALL be classified, scoped, secured and retained.
Session memory SHALL NOT become constitutional knowledge merely because it persists.
23.13.5. Session Authority
Authority SHALL be re-evaluated at constitutionally significant operations.
Authentication or prior approval SHALL NOT create unlimited continuing authority.
Re-evaluation SHOULD occur upon privilege elevation, publication, approval, external side effects, cross-tenant access, context or bundle change, high-risk agent action and assurance conclusion.
23.13.6. Session Isolation
Sessions SHALL be isolated by tenant, actor, purpose, security domain, jurisdiction, workflow, simulation status and assurance engagement.
23.13.7. Session Expiration
Every session SHALL define expiration or closure based on inactivity, duration, workflow completion, authority expiration, bundle revocation, context invalidation, security events or explicit termination.
Expired sessions SHALL NOT continue authoritative execution without re-admission.
23.13.8. Session Closure
Closure SHALL:
- stop new executions;
- complete or cancel active executions according to policy;
- preserve final state;
- seal audit records;
- apply retention rules;
- revoke temporary authority;
- dispose of ephemeral secrets;
- record closure provenance.
23.14. Execution Scope
Execution Scope defines the precise constitutional, operational and data domain within which execution may act.
Scope SHALL be resolved before execution and enforced throughout it.
23.14.1. Scope Dimensions
Scope MAY include:
- tenant, organisation and legal entity;
- Module and Component;
- Constitutional Object and Relationship;
- registry and graph partition;
- dataset and reporting population;
- product, facility and supply-chain scope;
- jurisdictional and temporal scope;
- workflow and publication scope;
- side-effect scope.
23.14.2. Scope Expression
Scope SHALL be expressed through governed references, selectors or policies, including:
- explicit Constitutional Identifiers;
- governed collections;
- graph subgraphs;
- classification selectors;
- relationship-path selectors;
- contextual and temporal selectors;
- policy-defined populations.
Open-ended implementation queries SHALL NOT substitute for governed scope where constitutional significance exists.
23.14.3. Scope Resolution
Scope resolution SHALL identify:
- requested scope;
- authorised scope;
- policy scope;
- available data scope;
- final effective scope;
- excluded and unresolved scope.
The effective scope SHALL be the valid intersection of applicable boundaries and authority.
23.14.4. Scope Expansion
Scope SHALL NOT expand implicitly.
Expansion SHALL require explicit need, governing policy, sufficient authority, re-validation, a revised plan and fingerprint, updated audit and approval where required.
23.14.5. Scope Reduction
Scope MAY be reduced only where reduction does not invalidate purpose or conceal excluded material.
Reduction SHALL record the removed scope, reason, responsible actor or policy, effect on completeness and assurance, and provenance.
23.14.6. Scope Completeness
Scope SHALL be classified as:
- complete;
- conditionally complete;
- materially incomplete;
- intentionally sampled;
- simulated;
- unknown.
A materially incomplete scope SHALL NOT produce an unqualified authoritative conclusion.
23.14.7. Scope Leakage Prevention
The runtime SHALL prevent direct and inferred access or side effects outside effective scope, including through graph traversal, joins, caches, logs, vectors, AI prompts, explanations, external calls and telemetry.
23.15. Execution Authority
Execution Authority is the constitutionally recognised permission to initiate, perform, approve, commit, publish or govern an execution.
Authority SHALL remain distinct from actor identity, technical access and operational capability.
23.15.1. Authority Types
Authority Types MAY include:
- request;
- execution;
- data access;
- validation;
- approval;
- delegation;
- computation;
- mutation;
- publication;
- assurance;
- override;
- emergency;
- revocation.
23.15.2. Authority Resolution
Authority SHALL be resolved from:
- actor identity;
- Constitutional Roles;
- assignments and delegations;
- tenant and jurisdictional policy;
- workflow state;
- object and relationship governance;
- temporal validity;
- purpose and scope;
- separation-of-duties rules.
Resolution SHALL be deterministic and explainable.
23.15.3. Authority Chain
Every authoritative execution SHALL preserve an Authority Chain identifying:
- originating Constitutional Authority;
- applicable Role;
- assignment;
- delegation;
- policy basis;
- scope;
- temporal validity;
- conditions;
- actor exercising authority.
Broken or circular chains SHALL invalidate authority.
23.15.4. Delegated Authority
Delegation SHALL preserve delegating authority, delegate, capability, scope, purpose, validity period, conditions, revocation and provenance.
Delegation SHALL NOT exceed the delegator's authority.
Sub-delegation SHALL require explicit permission.
23.15.5. Component Authority
Each Runtime Component SHALL execute under explicit least-privilege authority defining permitted capabilities, data scope, side effects, services, tenants, jurisdictions, execution modes and autonomy level.
23.15.6. Agent Authority
AI agents and autonomous Components SHALL NOT inherit unrestricted authority from an invoking user, service or workflow.
Agent Authority SHALL be explicit, purpose-bound, scope-bound, time-bound, capability-bound, revocable, observable and auditable.
Actions exceeding Agent Authority SHALL require separate approval.
23.15.7. Separation of Duties
Applicable separation-of-duties constraints SHALL be enforced.
Examples:
- requester is not sole approver;
- compiler publisher is not sole runtime activator;
- calculation author is not sole verifier;
- evidence submitter is not sole certifier;
- AI agent does not approve its own constitutional proposal.
23.15.8. Authority Revalidation
Authority SHALL be revalidated at significant gates, including elapsed-time thresholds, scope or context change, bundle change, privilege elevation, side-effect initiation, approval, publication, emergency entry and revocation.
23.15.9. Emergency Authority
Emergency Authority MAY permit exceptional execution only where constitutionally defined.
It SHALL preserve declaration, declaring authority, basis, scope, duration, bypassed controls, compensating controls, mandatory review and complete provenance.
It SHALL expire automatically.
23.15.10. Authority Failure
Where authority cannot be established, execution SHALL deny the action, prevent prohibited side effects, record the attempt, generate diagnostics and preserve audit and provenance.
23.16. Execution Lifecycle
Every execution SHALL progress through a governed lifecycle.
Requested
│
▼
Admitted
│
▼
Planned
│
▼
Authorised
│
▼
Ready
│
▼
Executing
│
├──► Suspended
├──► Compensating
├──► Rejected
└──► Failed
│
▼
Outcome Validated
│
▼
Committed
│
▼
Completed
│
▼
Archived
23.16.1. Lifecycle States
Lifecycle values SHALL originate from a governed Constitutional Value Provider.
Each state SHALL define entry conditions, permitted operations, authority, transitions, exit conditions, timeout behaviour and provenance requirements.
23.16.2. Requested
Requested indicates receipt of a syntactically identifiable request. It SHALL NOT imply admission or authority.
23.16.3. Admitted
Admitted indicates successful admission control and SHALL record the admission decision, evaluated controls, effective request, fingerprint, actor, authority status and timestamp.
23.16.4. Planned
Planned indicates creation and HECATE validation of a valid Execution Plan.
23.16.5. Authorised
Authorised indicates satisfaction of all authority and approval requirements needed to begin execution.
23.16.6. Ready
Ready indicates availability of required Components, dependencies, locks, resources and trust conditions.
Readiness SHALL remain distinct from authority.
23.16.7. Executing
Executing begins with the first Plan Step.
The runtime SHALL preserve current, completed and pending steps, intermediate outcomes, state transitions, Component identities, authority revalidations, temporal state, side effects, diagnostics and provenance.
23.16.8. Suspended
Suspension MAY occur due to missing approval, unavailable dependency, authority uncertainty, evidence deficiency, security incident, runtime drift, policy conflict, external wait state or resource constraint.
23.16.9. Outcome Validated
Outcome Validated indicates passage of required postconditions, validations and assurance gates.
23.16.10. Committed
Committed indicates acceptance of authoritative state changes and side effects within the declared transaction model.
Where global atomicity is unavailable, the consistency and compensation model SHALL be explicit.
23.16.11. Completed
Completed requires termination of mandatory steps, existence of a final Runtime Outcome, side-effect reconciliation, complete provenance, available explanations and a sealed Execution Manifest.
23.16.12. Failed
Failed indicates inability to satisfy completion criteria after permitted recovery.
Failure SHALL preserve failed step, classification, partial outcomes, side effects, compensation, retry eligibility, diagnostics and provenance.
23.16.13. Rejected
Rejected indicates a constitutional decision that the request, plan, authority, context or outcome is inadmissible.
Rejection is distinct from technical failure.
23.16.14. Archived
Archived indicates transfer to governed retention while preserving replay, assurance and legal-hold requirements.
23.17. Deterministic Execution
Equivalent Execution Requests, Runtime Contexts, Runtime Bundles, Runtime Manifests, Execution Plans and declared external inputs SHALL produce semantically equivalent Runtime Outcomes wherever deterministic behaviour is required.
23.17.1. Determinism Domain
The Determinism Domain MAY cover:
- constitutional selection;
- policy selection;
- validation and reasoning outcomes;
- computations within declared tolerance;
- workflow transitions;
- side-effect intent;
- explanation;
- provenance structure.
Semantic equivalence is primary. Byte identity is required only where explicitly declared.
23.17.2. Deterministic Inputs
All constitutionally relevant inputs SHALL be accounted for, including:
- Runtime Context;
- time and random sources;
- datasets and external responses;
- model identity and parameters;
- numerical libraries;
- locale, units and currency rates;
- graph snapshot;
- policy versions;
- Component versions.
Unrecorded ambient state SHALL NOT influence authoritative execution.
23.17.3. Time Determinism
The runtime SHALL distinguish execution clock, effective time, valid time, transaction time, observation time and publication time.
Use of the current system clock SHALL be recorded.
23.17.4. Randomness
Randomness MAY be used only under a governed profile.
Where outcome-affecting, the runtime SHALL preserve random source, algorithm, seed or replay token, distribution parameters, sampling count and numerical settings.
23.17.5. External Dependencies
External dependencies SHALL be explicit inputs preserving dependency identity, endpoint or registry, version, request and response fingerprints, timestamp, trust state, cache status and fallback behaviour.
Unversioned dependencies SHALL reduce disclosed reproducibility.
23.17.6. Numerical Determinism
Computations SHALL declare precision, rounding, unit conversion, tolerance, overflow, missing-value behaviour, aggregation order, library version and relevant hardware constraints.
23.17.7. AI and Model Determinism
AI-assisted execution SHALL declare:
- model identity, version and provider;
- prompt or instruction artefact;
- tool configuration;
- retrieval snapshot;
- sampling parameters;
- safety policy;
- output validation;
- approval requirements.
Non-deterministic model output SHALL NOT directly become an authoritative constitutional outcome without governed validation or approval.
23.17.8. Determinism Verification
The CRF SHOULD compare repeated executions against identical fingerprints.
Material divergence SHALL produce a Determinism Violation event.
23.18. Idempotency
Idempotency ensures repeated processing of the same authorised intent does not create duplicate constitutional effects.
23.18.1. Idempotency Key
A governed Idempotency Key MAY derive from Request Identifier, Request Fingerprint, tenant, target, operation type, temporal boundary, workflow state or a policy-validated caller key.
23.18.2. Idempotency Scope
Scope MAY be Plan Step, execution, session, workflow transition, target object, publication event, external integration or defined time window.
23.18.3. Idempotency Outcomes
A repeated request MAY return a prior outcome, continue an in-progress execution, re-execute safely, reject a semantic conflict or create a new execution where intent differs.
23.18.4. Semantic Idempotency
Constitutional idempotency concerns semantic effect, not transport duplication alone.
23.18.5. Side-Effect Classification
Operations SHALL declare whether they are naturally idempotent, conditionally idempotent, deduplicated, non-idempotent or compensatable.
23.18.6. Idempotency Record
The runtime SHALL preserve key, scope, fingerprint, Execution Identifier, status, side-effect status, timestamps, expiry, conflict state and provenance.
23.18.7. Idempotency Conflict
The same key presented with materially different constitutional intent SHALL fail closed and preserve both requests for investigation.
23.19. Transaction Boundaries
A Transaction Boundary defines the state changes and side effects treated as one governed consistency unit.
23.19.1. Transaction Types
Types MAY include:
- local atomic;
- distributed;
- saga;
- workflow;
- event;
- publication;
- graph assertion;
- registry;
- assurance;
- compensating transaction.
23.19.2. Transaction Identity
Every transaction SHALL identify:
- Transaction Identifier;
- Execution Identifier;
- participating Plan Steps and Components;
- state stores or services;
- consistency model;
- isolation level;
- commit criteria;
- rollback or compensation policy;
- lifecycle state;
- provenance.
23.19.3. Transaction Invariants
Invariants MAY include object validity, Relationship integrity, authority, balanced allocation, evidence completeness, publication and workflow consistency, uniqueness, tenant isolation and temporal consistency.
HECATE SHALL validate applicable invariants before commit.
23.19.4. Atomicity
Where declared, all transaction effects commit or none commit.
The runtime SHALL NOT claim atomicity for best-effort coordination.
23.19.5. Isolation
Isolation SHALL prevent outcome-affecting interference among concurrent executions.
Required isolation SHALL reflect state criticality, regulatory significance, conflict risk, performance and consistency needs.
23.19.6. Commit Protocol
Commit SHALL occur only after mandatory steps complete, validations pass, authority remains valid, invariants hold, approvals exist, side effects are prepared or confirmed, provenance is sufficient and the commit decision is recorded.
23.19.7. Distributed Commit
The protocol MAY use two-phase commit, three-phase commit, consensus, transactional outbox, event sourcing, saga orchestration, saga choreography or another governed protocol.
The runtime SHALL disclose whether it guarantees global atomicity, causal consistency or eventual convergence.
23.19.8. Transaction Timeout
Non-trivial transactions SHOULD define timeouts triggering rollback, compensation, suspension or failure.
23.19.9. Transaction Evidence
Significant transactions SHALL preserve evidence of preparation, validation, authority, commit decision, effects, failures, recovery and final consistency.
23.20. Rollback and Compensation
Rollback restores state within an atomic transaction.
Compensation performs explicit counter-actions where completed effects cannot be technically rolled back.
23.20.1. Recovery Classification
Each side-effecting Plan Step SHALL declare itself:
- reversible;
- compensatable;
- supersedable;
- manually remediable;
- irreversible;
- externally controlled.
Irreversible operations require heightened authority and validation.
23.20.2. Rollback Plan
A Rollback Plan SHALL define trigger, affected state, order, locks, authority, validation, timeout, failure handling and provenance.
23.20.3. Compensation Plan
A Compensation Plan SHALL define compensating action, prerequisites, effect, responsible Component, authority, ordering, retry, validation, residual risk and escalation.
23.20.4. Compensation Semantics
The runtime SHALL distinguish exact reversal, semantic reversal, financial adjustment, correcting assertion, superseding publication, recall, manual remediation and accepted residual effect.
23.20.5. Compensation Authority
Authority to perform the original action SHALL NOT automatically confer authority to compensate, revoke, recall or republish.
23.20.6. Compensation Ordering
Compensation SHOULD execute in reverse dependency order unless constitutional semantics require otherwise.
23.20.7. Partial Compensation
Partial compensation SHALL disclose uncompensated effects, reason, current state, residual risk, responsible authority, remediation and escalation status.
23.20.8. Corrective Assertions
Where an assertion or publication cannot be erased, correction SHOULD use governed relationships such as:
- corrects;
- supersedes;
- revokes;
- replaces;
- qualifies;
- disputes.
Historical visibility SHALL be preserved.
23.20.9. Human Remediation
Human remediation SHALL be a governed task with responsible Role, authority, due date, evidence, completion criteria, validation and provenance.
23.20.10. Recovery Validation
HECATE SHALL validate whether effects were reversed or neutralised, invariants restored or qualified, residual effects disclosed, authority valid, provenance complete and downstream dependants addressed.
23.21. Replay
Execution Replay is the governed re-execution or reconstruction of a prior execution using preserved requests, contexts, bundles, manifests, plans, inputs and dependency states.
23.21.1. Replay Types
Replay MAY be:
- exact;
- semantic;
- historical;
- diagnostic;
- forensic;
- simulation;
- comparative;
- migration;
- assurance.
The Replay Type SHALL determine whether side effects are prohibited, simulated or permitted.
23.21.2. Exact Replay
Exact replay requires the original request, fingerprints, Runtime Context, Runtime Bundle, Runtime Manifest, plan, Component versions, external responses, time source, random seed or replay token and model configuration.
Where required elements are unavailable, the replay SHALL NOT be called exact.
23.21.3. Semantic Replay
Semantic replay MAY use constitutionally equivalent artefacts or Components to verify that the same constitutional outcome is produced.
23.21.4. Historical Replay
Historical replay SHALL use the original effective, valid and transaction-time boundaries.
Current policies or data SHALL NOT silently replace historical versions.
23.21.5. Replay Isolation
Replay SHALL occur within an isolated boundary preventing duplicate external effects, publication, notifications, production mutation, cache contamination and workflow progression.
23.21.6. Replay Side Effects
Replay side effects SHALL be classified as prohibited, simulated, captured but not emitted, emitted to a dedicated environment or explicitly authorised for recovery.
23.21.7. Replay Manifest
Every replay SHALL produce a Replay Manifest identifying source and Replay Identifiers, type, purpose, actor, authority, source and substituted artefacts, missing artefacts, Replay Context, side-effect policy, comparison criteria, outcome, divergence and provenance.
23.21.8. Divergence Analysis
Divergence Analysis SHALL compare request, context, plan, policies, bundles, Components, dependencies, numerical results, validation, reasoning, side effects, explanation and provenance.
Divergence SHALL be classified as representational, tolerable numerical, expected contextual, implementation defect, constitutional semantic divergence, unavailable evidence or unknown.
23.21.9. Replay Authority
Replay of sensitive, regulated or personal data SHALL require explicit authority.
23.21.10. Replay Retention
Replay capability SHALL respect retention, privacy, licensing, security and legal constraints.
Where complete replay is prohibited, the runtime SHOULD preserve the maximum lawful verification capability through fingerprints, summaries, attestations or controlled evidence vaults.
23.22. Execution Provenance
Execution Provenance is the complete governed lineage explaining how a Runtime Outcome was produced.
It SHALL integrate with the Constitutional Provenance Graph and preserve both Module and Component lineage.
Provenance SHALL be captured during execution rather than reconstructed solely from logs.
23.22.1. Provenance Scope
Execution Provenance SHALL include, where applicable:
- Execution Request;
- actor and Authority Chain;
- Runtime Context and fingerprint;
- Runtime Boundary and Execution Scope;
- Runtime Bundle and Runtime Manifest;
- Execution Plan and Plan Steps;
- Runtime Components;
- inputs and evidence;
- policies and validation;
- resolution candidates and decisions;
- reasoning rules and derived assertions;
- computations and external dependencies;
- state transitions and events;
- side effects and transaction decisions;
- rollback or compensation;
- Runtime Outcome and explanation;
- timestamps, signatures and trust state.
23.22.2. Provenance Events
Examples include:
- RequestReceived;
- RequestAdmitted;
- RequestRejected;
- ContextResolved;
- AuthorityResolved;
- PlanCreated;
- PlanValidated;
- PlanApproved;
- StepStarted;
- StepCompleted;
- ValidationPerformed;
- ResolutionPerformed;
- AssertionDerived;
- SideEffectPrepared;
- SideEffectCommitted;
- TransactionCommitted;
- TransactionRolledBack;
- CompensationStarted;
- CompensationCompleted;
- ExecutionFailed;
- OutcomeValidated;
- ExecutionCompleted;
- ReplayPerformed.
Every event SHALL possess identity, timestamp, actor or Component identity, Runtime Context, associated execution and integrity metadata.
23.22.3. Causal Lineage
Provenance SHALL distinguish:
- caused by;
- derived from;
- used;
- generated;
- validated by;
- authorised by;
- resolved through;
- computed by;
- compensated by;
- superseded by.
Temporal sequence alone SHALL NOT prove causality.
23.22.4. Module and Component Lineage
Every significant Plan Step and Runtime Outcome SHALL preserve:
- owning Module identity;
- executing Component identity;
- Component version;
- deployment identity;
- Runtime Bundle lineage;
- compiler lineage.
Pergamum Pulse SHALL preserve both Module and Component lineage without flattening one into the other.
23.22.5. Provenance Integrity
Integrity MAY be protected through:
- cryptographic hashes;
- hash chains;
- digital signatures;
- append-only storage;
- trusted timestamps;
- transparency logs;
- hardware-backed attestations;
- replicated evidence stores.
The mechanism SHALL match the assurance significance of the execution.
23.22.6. Provenance Completeness
Provenance MAY be classified as:
- complete;
- complete with controlled redactions;
- materially incomplete;
- partially reconstructed;
- unavailable;
- disputed.
Materially incomplete provenance SHALL NOT support an unqualified high-assurance outcome.
23.22.7. Provenance Redaction
Redaction SHALL preserve the fact, authority, basis and scope of redaction, integrity of the remaining chain and a controlled access path where permitted.
Redaction SHALL NOT silently alter meaning.
23.22.8. Provenance Query
The CRF SHALL support queries answering:
- who requested and authorised execution;
- which Constitution, Context, Runtime Bundle and Components applied;
- which evidence, datasets, policies and validators were used;
- which alternatives were rejected;
- which side effects and recovery actions occurred;
- how the final outcome was derived.
23.22.9. Execution Explanation
Explanation SHOULD distinguish:
- constitutional facts;
- request-supplied facts;
- resolved selections;
- computed outcomes;
- inferred assertions;
- AI-proposed content;
- human decisions;
- rejected alternatives;
- uncertainty;
- limitations.
23.22.10. Assurance and Audit Export
Provenance MAY be exported for internal audit, external assurance, regulatory review, customer review, incident investigation, dispute resolution and scientific reproducibility.
Exports SHALL preserve identity, integrity, context and redaction state.
23.22.11. Provenance Retention
Retention SHALL be governed by constitutional policy, jurisdiction, reporting and assurance obligations, legal hold, privacy, contract, tenant policy and evidentiary significance.
Deletion or anonymisation SHALL itself produce governed provenance where lawful.
23.22.12. HECATE Validation
HECATE SHALL validate:
- identity integrity;
- chain completeness;
- causal and temporal consistency;
- authority traceability;
- Module and Component lineage;
- input and output traceability;
- policy and side-effect traceability;
- rollback and compensation traceability;
- signature validity;
- tenant isolation;
- redaction validity;
- retention compliance.
23.22.13. Pergamum Pulse Integration
Pergamum Pulse MAY derive intelligence concerning:
- execution failure patterns;
- policy bottlenecks;
- validation gaps;
- authority concentration;
- separation-of-duties risk;
- Component reliability;
- Module-level risk;
- runtime drift;
- unexplained divergence;
- evidence weakness;
- compensation frequency;
- assurance readiness.
Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.
Part II Conformance
A Constitutional Runtime Framework implementation conforms to Part II where it:
- requires an identifiable Execution Request for every authoritative execution;
- performs governed admission before planning;
- creates a deterministic, validated and explainable Execution Plan;
- preserves explicit Execution Session identity where continuity exists;
- resolves and enforces Execution Scope;
- resolves authority independently from technical capability;
- enforces a governed Execution Lifecycle;
- declares and verifies its determinism profile;
- prevents duplicate semantic side effects through governed idempotency;
- declares Transaction Boundaries and consistency guarantees;
- provides rollback or compensation appropriate to each material side effect;
- supports governed replay and divergence analysis;
- preserves complete Execution Provenance;
- preserves both Module and Component lineage;
- prevents incomplete, unauthorised or failed executions from appearing constitutionally successful.
Part II Foundational Principle
Constitutional Execution is the governed process through which an admitted request becomes a planned, authorised, bounded, deterministic and provenance-preserving runtime outcome.
No constitutional execution SHALL depend upon hidden application flow, implicit authority, ambient context, undeclared side effects or irreproducible state. Every execution SHALL identify what was requested, who or what was authorised to perform it, which scope and context applied, which plan was followed, which Components acted, which validations and policies governed the result, which state changes occurred and how the final outcome was derived.
By treating Execution Requests, Execution Plans, Execution Sessions, Transaction Boundaries, Replay Records and Execution Provenance as governed runtime artefacts, ZAYAZ ensures that operational behaviour remains deterministic, resilient, independently auditable and constitutionally traceable from intent through execution to outcome.