Chapter 23 — Constitutional Runtime Framework
Part VIII — Workflow and Agent Runtime
The Workflow and Agent Runtime is the governed constitutional runtime through which ZAYAZ coordinates long-running and multi-step processes, assigns work to human and machine participants, executes bounded agent activity, invokes tools, reacts to Constitutional Events, enforces gates, manages state and preserves complete operational lineage.
Workflow SHALL coordinate constitutional execution without creating constitutional authority.
Agents SHALL act only within explicit identity, capability, authority, context, autonomy and tool boundaries.
The Runtime SHALL distinguish:
- workflow definition from workflow instance;
- workflow coordination from constitutional authority;
- task assignment from authority assignment;
- human participant from represented principal;
- agent identity from model identity;
- agent identity from Runtime Component identity;
- capability from permission;
- plan from approval;
- memory from constitutional knowledge;
- tool access from tool-use authority;
- autonomous execution from unsupervised authority;
- agent proposal from canonical assertion;
- workflow success from constitutional validity.
The governing distinctions are:
Workflow coordinates governed work. It does not create authority.
An agent may propose, reason, calculate and act only within its resolved constitutional authority and approved autonomy boundary.
A technically successful workflow or agent action is not constitutionally successful unless its required context, authority, validation, governance, temporal and provenance obligations are satisfied.
Conceptually:
Constitutional Events and Execution Requests
│
▼
Workflow Profile Resolution
│
▼
Workflow Definition
│
▼
Workflow Instance
│
├── Human Tasks
├── Service Tasks
├── Validation Gates
├── Approval Gates
├── Assurance Gates
├── Timers
├── Event Waits
├── Subworkflows
└── Agent Tasks
│
▼
Agent Runtime
│
├── Agent Identity
├── Capability Profile
├── Authority Profile
├── Autonomy Profile
├── Agent Plan
├── Memory
├── Tool Contracts
├── Guardrails
└── Human Oversight
│
▼
Workflow and Agent Outcomes
│
▼
HECATE Validation
│
▼
Commit, Compensation, Escalation or Rejection
│
▼
Workflow and Agent Provenance
Workflow and Agent Runtime SHALL remain independent of any single workflow engine, process notation, agent framework, model provider, message broker, programming language, tool protocol or deployment platform.
23.78. Workflow Runtime
The Workflow Runtime is the constitutional runtime responsible for coordinating tasks, decisions, events, gates, timers, participants, Components, agents, transactions and state transitions across a governed process.
A Workflow Runtime SHALL execute an approved Workflow Definition within an explicit Runtime Context.
23.78.1. Purpose
The Workflow Runtime SHALL support:
- constitutional governance workflows;
- report preparation;
- ESRS and regulatory disclosure workflows;
- double-materiality workflows;
- evidence collection;
- calculation and validation workflows;
- assurance engagements;
- finding remediation;
- approval and publication;
- supplier engagement;
- product-passport preparation;
- methodology review;
- incident response;
- emergency governance;
- data-quality improvement;
- model governance;
- agent-assisted operations;
- cross-Module orchestration;
- white-label tenant workflows.
23.78.2. Workflow Boundary
A workflow SHALL operate within an explicit Workflow Boundary defining:
- tenant;
- organisation;
- legal entity;
- jurisdiction;
- purpose;
- subject scope;
- data scope;
- temporal scope;
- security scope;
- authority scope;
- side-effect scope;
- publication scope;
- assurance scope;
- Runtime Bundle;
- deployment boundary.
A workflow SHALL NOT expand its boundary implicitly.
23.78.3. Workflow Request
Every authoritative workflow execution SHALL originate from a Workflow Request or a specialised Execution Request containing equivalent metadata.
A Workflow Request SHALL identify:
- Workflow Request Identifier;
- workflow purpose;
- requested Workflow Profile;
- requested Workflow Definition;
- initiating actor or Component;
- represented principal;
- authority;
- Runtime Context;
- target subject or population;
- initial inputs;
- requested start time;
- deadline;
- priority;
- side-effect permissions;
- provenance.
23.78.4. Workflow Admission
Workflow admission SHALL evaluate:
- request identity;
- purpose;
- actor identity;
- authority;
- Workflow Profile;
- Workflow Definition compatibility;
- Runtime Context completeness;
- input integrity;
- tenant isolation;
- required Runtime Bundle;
- resource policy;
- prohibited operations;
- emergency restrictions;
- initial gate requirements.
Admission SHALL fail closed where identity, authority, scope or workflow compatibility cannot be established.
23.78.5. Workflow Components
A Workflow Runtime MAY include Components such as:
| Component | Constitutional Responsibility |
|---|---|
| Workflow Gateway | Accepts Workflow Requests |
| Workflow Resolver | Resolves applicable profiles and definitions |
| Workflow Planner | Produces an executable workflow plan |
| Workflow Engine | Coordinates instance state and transitions |
| Task Manager | Creates, assigns and monitors Tasks |
| Gate Manager | Enforces validation, approval and assurance gates |
| Timer Service | Manages governed deadlines and schedules |
| Event Correlator | Correlates Constitutional Events to workflow waits |
| Agent Orchestrator | Invokes and supervises agents |
| Human Work Service | Coordinates human tasks and collaboration |
| Compensation Manager | Executes compensation and recovery |
| Workflow Evidence Service | Preserves workflow evidence |
| Workflow Explanation Service | Produces explanations |
| Workflow Audit Service | Preserves immutable workflow provenance |
Every Component SHALL belong to a Module and preserve Component lineage.
23.78.6. Workflow Modes
Workflow Modes MAY include:
- authoritative;
- advisory;
- draft;
- simulation;
- replay;
- assurance;
- emergency;
- migration;
- test;
- shadow;
- dry run.
A simulation or dry-run workflow SHALL not produce authoritative side effects.
23.78.7. Synchronous and Long-Running Workflows
A workflow MAY be:
- synchronous;
- asynchronous;
- long-running;
- event-driven;
- scheduled;
- continuous;
- interactive;
- federated;
- hybrid.
Long-running workflows SHALL preserve identity, state, context, authority, version and provenance across pauses and resumptions.
23.78.8. Workflow Planning
The Runtime MAY create a Workflow Execution Plan defining:
- Workflow Definition and version;
- initial state;
- task graph;
- transition graph;
- participant requirements;
- Component requirements;
- agent requirements;
- gate requirements;
- temporal constraints;
- event subscriptions;
- transaction boundaries;
- compensation paths;
- escalation routes;
- completion criteria;
- explanation requirements;
- provenance obligations.
23.78.9. Workflow Determinism
Equivalent Workflow Requests, Runtime Contexts, Workflow Definitions, policy versions, event histories and participant capability states SHALL produce semantically equivalent workflow plans and transition eligibility.
Human decisions, external events and permitted agent non-determinism SHALL be represented as explicit inputs.
23.78.10. Workflow Authority
Workflow execution authority SHALL be resolved independently from:
- workflow configuration;
- technical user privileges;
- queue access;
- task assignment;
- engine administration;
- agent capability.
A workflow engine SHALL NOT create authority merely by assigning a task.
23.78.11. Workflow Validation
HECATE SHALL validate:
- Workflow Request;
- Workflow Profile;
- Workflow Definition;
- instance creation;
- state transitions;
- task completion;
- gate satisfaction;
- event correlation;
- participant authority;
- agent authority;
- transaction boundaries;
- compensation paths;
- completion criteria;
- provenance.
23.78.12. Workflow Security
Workflow security SHALL enforce:
- tenant isolation;
- purpose limitation;
- task-level access;
- subject-level access;
- evidence confidentiality;
- secret isolation;
- agent sandboxing;
- event disclosure controls;
- cross-Module least privilege;
- export restrictions;
- audit integrity.
23.78.13. Workflow Observability
Operational observability MAY include:
- instance count;
- task latency;
- gate latency;
- queue age;
- deadline risk;
- failure rate;
- compensation rate;
- escalation rate;
- human workload;
- agent workload;
- event wait time;
- stuck-instance count.
Operational metrics SHALL not alter workflow semantics.
23.78.14. Workflow Runtime Self-Validation
The Workflow Runtime SHALL validate its own:
- Runtime Manifest;
- active engine versions;
- Workflow Definition inventory;
- timer state;
- event subscriptions;
- task queues;
- agent registrations;
- tool registrations;
- trust anchors;
- tenant overlays;
- runtime drift;
- recovery readiness.
23.79. Workflow Definitions and Profiles
A Workflow Definition is the governed Constitutional Object defining the states, Tasks, transitions, participants, gates, events, temporal constraints, side effects, recovery paths and completion semantics of a workflow.
A Workflow Profile defines which workflow semantics and governance requirements apply for a defined purpose and context.
23.79.1. Workflow Definition Identity
Every Workflow Definition SHALL possess:
- Constitutional Identifier;
- canonical name;
- semantic definition;
- workflow type;
- governing authority;
- applicability;
- lifecycle;
- version;
- temporal validity;
- input contract;
- output contract;
- state model;
- task model;
- transition model;
- gate model;
- participant model;
- event model;
- transaction model;
- compensation model;
- escalation model;
- compiler mappings;
- provenance.
23.79.2. Workflow Profile Identity
Every Workflow Profile SHALL possess:
- Constitutional Identifier;
- canonical name;
- purpose;
- subject types;
- tenant applicability;
- jurisdiction applicability;
- required Workflow Definitions;
- permitted overlays;
- authority policy;
- validation policy;
- approval policy;
- assurance policy;
- temporal policy;
- agent policy;
- tool policy;
- evidence policy;
- completion policy;
- provenance.
23.79.3. Workflow Types
Workflow Types MAY include:
- review;
- approval;
- validation;
- assurance;
- remediation;
- publication;
- governance;
- ingestion;
- calculation;
- evidence collection;
- supplier engagement;
- materiality assessment;
- risk assessment;
- incident response;
- emergency response;
- agent-assisted investigation;
- report preparation;
- product-passport preparation;
- lifecycle assessment;
- federated coordination.
23.79.4. Profile Resolution
CRP SHALL resolve the applicable Workflow Profile using:
- purpose;
- subject type;
- tenant;
- jurisdiction;
- reporting framework;
- reporting period;
- assurance level;
- publication profile;
- security profile;
- emergency state;
- execution mode.
The Runtime SHALL not choose a Workflow Profile through hidden application logic.
23.79.5. Definition Resolution
CRP SHALL resolve the applicable Workflow Definition and version from:
- Workflow Profile;
- Runtime Context;
- subject lifecycle;
- tenant overlay;
- jurisdictional overlay;
- constitutional release;
- effective time;
- compatibility;
- emergency policy.
23.79.6. Workflow Composition
A Workflow Definition MAY compose:
- subworkflows;
- reusable Tasks;
- reusable Gates;
- reusable Transition Policies;
- agent workflows;
- human-review workflows;
- assurance workflows;
- compensation workflows.
Composition SHALL preserve each composed definition’s identity and version.
23.79.7. Workflow Inheritance
A specialised Workflow Definition MAY inherit from a parent definition.
Inheritance SHALL preserve mandatory parent:
- gates;
- authority controls;
- validation controls;
- assurance controls;
- provenance requirements;
- tenant-isolation rules;
- non-bypassable transitions.
23.79.8. White-Label Overlays
Workflow overlays SHALL follow the governed order:
ZAYAZ Core Workflow
│
▼
White-label Base Workflow
│
▼
Tenant Workflow Overlay
│
▼
Organisation Workflow Overlay
│
▼
Runtime Context
An overlay MAY add stricter controls, localisation, tenant Roles and approved extensions.
It SHALL NOT silently weaken mandatory Core or jurisdictional requirements.
23.79.9. Workflow Graph
A Workflow Definition SHOULD be represented as a governed graph containing:
- states;
- Tasks;
- transitions;
- Gates;
- event waits;
- timers;
- forks;
- joins;
- subworkflows;
- compensation paths;
- escalation paths;
- terminal outcomes.
23.79.10. Structured and Adaptive Workflows
A workflow MAY be:
- fully structured;
- semi-structured;
- case-based;
- adaptive within governed bounds;
- agent-planned within governed bounds.
Adaptive behaviour SHALL define the permitted change space and approval requirements.
23.79.11. Dynamic Workflow Change
A running workflow MAY change only where:
- the Workflow Profile permits change;
- change authority exists;
- completed work remains valid or is revalidated;
- pending Tasks are reconciled;
- Gates are re-evaluated;
- a new definition or plan version is recorded;
- provenance preserves the prior path;
- side effects remain controlled.
23.79.12. Workflow Definition Validation
HECATE SHALL validate definitions for:
- identity;
- state completeness;
- transition completeness;
- unreachable states;
- dead ends;
- unbounded loops;
- missing compensation;
- missing escalation;
- gate coverage;
- authority coverage;
- task contracts;
- agent boundaries;
- event correlation;
- temporal correctness;
- tenant isolation;
- provenance.
23.79.13. Workflow Compilation
The Constitutional Compiler Framework MAY compile Workflow Definitions into:
- BPMN;
- state-machine definitions;
- orchestration code;
- event rules;
- task schemas;
- UI forms;
- agent orchestration plans;
- timer configurations;
- API contracts;
- conformance fixtures.
Compiled artefacts SHALL preserve constitutional identity and semantic-loss declarations.
23.79.14. Workflow Versioning
A running instance SHALL identify the exact Workflow Definition version.
A definition update SHALL not silently modify an active instance.
Migration SHALL be explicit, validated and provenance-preserving.
23.79.15. Workflow Compatibility
Compatibility SHALL be evaluated among:
- Workflow Definition;
- Workflow Profile;
- Runtime Bundle;
- Runtime Components;
- agent versions;
- tool versions;
- event schemas;
- tenant overlays;
- jurisdictional overlays;
- subject state.
23.80. Workflow Instances and State
A Workflow Instance is the governed runtime instantiation of one Workflow Definition for one defined purpose, context and subject scope.
Workflow State SHALL remain distinguishable from constitutional state, subject state and task state.
23.80.1. Instance Identity
Every Workflow Instance SHALL possess:
- Workflow Instance Identifier;
- Workflow Definition and version;
- Workflow Profile;
- source Workflow Request;
- Runtime Context;
- Context Fingerprint;
- tenant;
- subject scope;
- initiating actor;
- authority;
- creation time;
- lifecycle state;
- Runtime Bundle;
- instance fingerprint;
- provenance.
23.80.2. Instance Types
Instances MAY be:
- single-subject;
- multi-subject;
- population;
- recurring;
- long-running;
- event-driven;
- case-based;
- federated;
- parent;
- subworkflow;
- simulation;
- replay.
23.80.3. Workflow State
Workflow State MAY include:
- current state;
- active Tasks;
- completed Tasks;
- pending Gates;
- resolved Gates;
- event waits;
- timers;
- participant assignments;
- agent assignments;
- variables;
- evidence references;
- compensation state;
- escalation state;
- completion status.
23.80.4. State Classification
Workflow State SHALL classify data as:
- authoritative workflow state;
- derived state;
- transient state;
- cached state;
- task-local state;
- agent working state;
- simulation state;
- replay state;
- external state.
23.80.5. State Transition
Every transition SHALL identify:
- Transition Identifier;
- prior state;
- subsequent state;
- transition rule;
- triggering event or decision;
- actor or Component;
- authority;
- Gate results;
- time;
- Runtime Context;
- side effects;
- provenance.
23.80.6. State Invariants
A Workflow Definition SHALL define invariants including:
- permitted active-state count;
- required completed Tasks;
- required Gate state;
- participant constraints;
- authority constraints;
- transaction state;
- evidence state;
- subject-state compatibility;
- completion consistency.
HECATE SHALL validate invariants before transitions commit.
23.80.7. State Persistence
Workflow State MAY be:
- ephemeral;
- checkpointed;
- transaction-persistent;
- workflow-persistent;
- audit-persistent;
- legally retained.
Retention SHALL be policy-governed.
23.80.8. State Isolation
Workflow State SHALL be isolated by:
- tenant;
- Workflow Instance;
- subject;
- security domain;
- assurance engagement;
- simulation boundary;
- replay boundary.
23.80.9. Variables
Workflow variables SHALL possess:
- variable identity;
- type;
- source;
- value;
- scope;
- mutability;
- confidentiality;
- temporal validity;
- provenance.
An untyped variable SHALL not control constitutionally significant transitions.
23.80.10. Context Changes
A material Runtime Context change SHALL produce:
- a new Context Fingerprint;
- context-transition event;
- Gate re-evaluation;
- authority re-evaluation;
- task-impact analysis;
- agent-impact analysis;
- plan revision where required;
- provenance.
23.80.11. Instance Suspension
An instance MAY be suspended due to:
- missing approval;
- missing assurance;
- authority uncertainty;
- event wait;
- evidence deficiency;
- participant unavailability;
- agent suspension;
- tool unavailability;
- security incident;
- runtime drift;
- deadline exception;
- external dependency.
23.80.12. Instance Resumption
Resumption SHALL validate:
- current definition version;
- Runtime Bundle;
- Runtime Context;
- authority;
- pending Gates;
- task validity;
- agent validity;
- tool validity;
- event state;
- timer state;
- provenance continuity.
23.80.13. Instance Migration
Migration to a new Workflow Definition version SHALL identify:
- source definition;
- target definition;
- state mapping;
- Task mapping;
- Gate mapping;
- variable mapping;
- event mapping;
- compensation treatment;
- validation;
- authority;
- approval;
- rollback;
- provenance.
23.80.14. Instance Termination
Termination MAY be:
- successful completion;
- rejection;
- cancellation;
- failure;
- compensation completion;
- supersession;
- emergency termination;
- expiration.
The terminal state SHALL be explicit.
23.80.15. Workflow Checkpoint
A checkpoint SHALL preserve:
- Workflow Instance;
- state;
- active Tasks;
- Gate state;
- event position;
- timer state;
- variables;
- agent state references;
- Runtime Bundle;
- Context Fingerprint;
- content digest;
- provenance.
23.80.16. Workflow Replay
Workflow replay SHALL use the historical:
- Workflow Definition;
- Runtime Context;
- events;
- human decisions;
- agent outputs;
- tool results;
- policies;
- Runtime Bundle;
- temporal state.
Replay SHALL be isolated and side-effect controlled.
23.81. Tasks, Transitions and Gates
A Task is the smallest independently assignable and governable unit of workflow work.
A Transition changes Workflow State.
A Gate determines whether a transition or Task may proceed.
23.81.1. Task Identity
Every Task SHALL possess:
- Task Identifier;
- Task Type;
- Workflow Instance;
- Workflow Definition element;
- purpose;
- subject;
- Runtime Context;
- input contract;
- output contract;
- required Role or Component capability;
- authority requirement;
- validation requirement;
- temporal constraints;
- priority;
- lifecycle;
- provenance.
23.81.2. Task Types
Task Types MAY include:
- human task;
- service task;
- agent task;
- validation task;
- approval task;
- assurance task;
- computation task;
- evidence task;
- review task;
- publication task;
- event-wait task;
- timer task;
- subworkflow task;
- compensation task;
- escalation task;
- notification task.
23.81.3. Task Preconditions
Task preconditions MAY include:
- Workflow State;
- subject state;
- authority;
- Context completeness;
- Gate satisfaction;
- evidence availability;
- event arrival;
- timer expiry;
- Runtime Bundle compatibility;
- tool availability;
- agent availability;
- SoD compliance.
23.81.4. Task Postconditions
Postconditions MAY include:
- output validation;
- state update;
- evidence creation;
- finding creation;
- approval result;
- assurance result;
- event publication;
- transaction commit;
- next-task eligibility;
- compensation readiness.
23.81.5. Task Assignment
Assignment SHALL identify:
- assignee;
- represented principal;
- Role or Component;
- authority basis;
- capability;
- tenant;
- due date;
- assignment time;
- delegation where applicable;
- provenance.
Task assignment SHALL NOT create authority.
23.81.6. Candidate Assignees
Candidate assignees SHALL be resolved through:
- Role requirements;
- authority;
- capability;
- tenant;
- jurisdiction;
- availability;
- workload;
- independence;
- SoD;
- competence;
- conflict-of-interest policy.
23.81.7. Task Claim and Release
A Task MAY require claim by a participant.
Claim and release SHALL preserve:
- actor;
- authority;
- time;
- reason;
- prior assignee;
- new state;
- provenance.
23.81.8. Task Delegation
Task delegation SHALL remain distinct from authority delegation.
A participant MAY delegate task performance only where:
- workflow policy permits;
- required authority exists;
- SoD remains satisfied;
- competence requirements remain satisfied;
- delegation is recorded;
- approval applies where required.
23.81.9. Task Completion
Completion SHALL require:
- output contract satisfied;
- required evidence supplied;
- required validation passed;
- authority remains valid;
- temporal conditions satisfied;
- side effects reconciled;
- completion event recorded;
- provenance complete.
23.81.10. Task Rejection
A Task MAY be rejected where:
- input is incomplete;
- assignment is invalid;
- authority is insufficient;
- conflict exists;
- evidence is insufficient;
- requested action is prohibited;
- task is obsolete;
- Context changed.
23.81.11. Transition Rule
Every transition SHALL possess:
- Transition Rule Identifier;
- source state;
- target state;
- triggering condition;
- required Tasks;
- required Gates;
- required authority;
- guard conditions;
- side effects;
- transaction boundary;
- compensation;
- explanation;
- provenance.
23.81.12. Conditional Transition
Conditional transitions SHALL use governed predicates.
Hidden code branches SHALL NOT constitute the sole constitutional definition of transition eligibility.
23.81.13. Parallelism
A workflow MAY fork into parallel branches.
The definition SHALL specify:
- branch identity;
- branch conditions;
- shared state policy;
- transaction policy;
- conflict policy;
- join policy;
- timeout;
- cancellation;
- provenance.
23.81.14. Join Semantics
Join semantics MAY require:
- all branches;
- any branch;
- quorum;
- named branch set;
- condition;
- timeout plus partial completion;
- human decision.
23.81.15. Gate Types
Gates MAY include:
- HECATE Validation Gate;
- Authority Gate;
- Approval Gate;
- Assurance Gate;
- Evidence Gate;
- Temporal Gate;
- Context Gate;
- Security Gate;
- Budget Gate;
- Risk Gate;
- Materiality Gate;
- Human Oversight Gate;
- Agent Autonomy Gate;
- Publication Gate;
- Emergency Gate.
23.81.16. Gate Outcome
Gate outcomes MAY be:
- Satisfied;
- Satisfied with Conditions;
- Not Satisfied;
- Blocked;
- Indeterminate;
- Expired;
- Not Applicable;
- Not Evaluated.
Not Evaluated and Indeterminate SHALL not be treated as Satisfied.
23.81.17. Timer
Every governed timer SHALL identify:
- Timer Identifier;
- timer type;
- Clock Source;
- start;
- due time;
- duration;
- time zone;
- calendar;
- pause policy;
- recurrence;
- expiration action;
- provenance.
23.81.18. Event Wait
An Event Wait SHALL define:
- expected Event Type;
- subject;
- correlation scope;
- causation expectation where applicable;
- temporal window;
- cardinality;
- timeout;
- late-event policy;
- validation;
- provenance.
23.81.19. Task and Transition Events
The Runtime SHOULD emit events including:
- TaskCreated;
- TaskAssigned;
- TaskClaimed;
- TaskStarted;
- TaskSuspended;
- TaskCompleted;
- TaskRejected;
- TaskDelegated;
- TaskEscalated;
- GateEvaluated;
- TransitionStarted;
- TransitionCommitted;
- TransitionRejected;
- TimerExpired;
- EventCorrelated.
23.82. Human Work and Collaboration
Human Work Runtime governs work performed by natural persons and organisational participants within workflows.
Human participation SHALL preserve identity, represented principal, authority, competence, independence, context and evidence.
23.82.1. Human Participant
A Human Participant SHALL possess:
- actor identity;
- represented principal;
- tenant;
- organisation;
- Roles;
- authority assignments;
- delegations;
- competence profile;
- availability;
- conflicts of interest;
- security profile;
- provenance.
23.82.2. Human Task
A Human Task SHALL define:
- purpose;
- instructions;
- subject;
- input;
- expected output;
- decision options;
- evidence requirements;
- authority requirements;
- competence requirements;
- SoD requirements;
- due date;
- escalation;
- accessibility requirements;
- provenance.
23.82.3. Decision Task
A decision task SHALL provide governed decision options.
Free-text decisions MAY supplement but SHALL NOT replace required structured outcomes where constitutional significance exists.
23.82.4. Human Judgement
Human judgement MAY be required for:
- materiality assessment;
- policy interpretation;
- conflict resolution;
- override approval;
- waiver approval;
- assurance conclusion;
- legal applicability;
- evidence sufficiency;
- AI proposal review;
- exception handling;
- emergency declaration.
Judgement SHALL preserve rationale and evidence.
23.82.5. Competence
Competence requirements MAY include:
- professional qualification;
- domain expertise;
- jurisdictional knowledge;
- assurance accreditation;
- technical certification;
- training;
- experience;
- language;
- independence.
23.82.6. Identity Assurance
High-risk tasks MAY require stronger identity assurance.
Identity assurance SHALL remain distinct from authority.
23.82.7. Collaboration
A Task MAY support collaboration among:
- preparers;
- reviewers;
- approvers;
- subject owners;
- stewards;
- verifiers;
- legal users;
- tenant administrators;
- external stakeholders.
Collaboration SHALL preserve each contribution’s identity and time.
23.82.8. Comments and Annotations
Comments and annotations SHALL preserve:
- author;
- represented principal;
- subject;
- scope;
- timestamp;
- confidentiality;
- lifecycle;
- edit history;
- provenance.
A comment SHALL not become a canonical assertion without governed activation.
23.82.9. Attachments and Evidence
Human-submitted attachments SHALL be treated as Evidence Objects or governed attachments.
They SHALL be validated for identity, integrity, applicability, confidentiality and provenance.
23.82.10. Drafting
A human or agent MAY draft:
- disclosure text;
- policy text;
- calculation explanation;
- remediation response;
- assurance response;
- stakeholder communication.
Draft status SHALL remain explicit until approval and publication.
23.82.11. Review
Review SHALL distinguish:
- editorial review;
- technical review;
- constitutional review;
- legal review;
- compliance review;
- assurance review;
- security review;
- accessibility review.
23.82.12. Reassignment
Task reassignment SHALL preserve:
- prior assignee;
- new assignee;
- reason;
- authority;
- time;
- task state;
- evidence;
- provenance.
23.82.13. Absence and Substitution
Human absence SHALL be handled through:
- preapproved substitute;
- task delegation;
- authority delegation where required;
- escalation;
- deadline extension;
- workflow suspension.
Credential sharing SHALL be prohibited.
23.82.14. Workload and Capacity
Capacity MAY influence assignment but SHALL NOT override authority, competence, independence or tenant boundaries.
23.82.15. Accessibility and Language
Human Work Runtime SHOULD support:
- governed localisation;
- accessibility;
- assistive technologies;
- language preference;
- readable explanations;
- alternative formats.
Translation SHALL preserve the canonical decision semantics.
23.82.16. Human Confirmation
Human confirmation SHALL be explicit where an agent or Component prepared the work.
A passive view or absence of objection SHALL not constitute approval unless policy explicitly defines that effect.
23.82.17. Protected Reporting
Whistleblowing, protected disclosure and confidential escalation workflows MAY require:
- identity protection;
- anonymous submission;
- restricted correlation;
- special retention;
- independent routing;
- anti-retaliation controls;
- legal basis;
- evidence integrity.
23.82.18. Human Work Evidence
Human Work Evidence SHALL preserve:
- assignment;
- identity;
- authority;
- instructions;
- input;
- contribution;
- decision;
- rationale;
- evidence;
- time;
- review;
- provenance.
23.83. Agent Runtime
An Agent Runtime is the governed execution environment through which an AI-enabled or autonomous agent perceives inputs, maintains bounded working state, creates plans, invokes approved tools, produces outputs and performs authorised actions.
An agent SHALL be treated as a governed Runtime Component and, where it initiates or performs actions, as an identifiable machine actor.
An agent SHALL NOT be treated as a Constitutional Authority by default.
23.83.1. Agent Definition
An Agent Definition is the governed Constitutional Object defining:
- Agent Identifier;
- canonical name;
- purpose;
- owning Module;
- Component identity;
- supported capabilities;
- prohibited capabilities;
- model requirements;
- instruction artefacts;
- knowledge sources;
- memory policy;
- tool policy;
- authority policy;
- autonomy policy;
- validation policy;
- oversight policy;
- lifecycle;
- version;
- provenance.
23.83.2. Agent Instance
An Agent Instance is one runtime instantiation of an Agent Definition.
Every instance SHALL possess:
- Agent Instance Identifier;
- Agent Definition and version;
- Runtime Component identity;
- model identity and version;
- Runtime Context;
- Context Fingerprint;
- tenant;
- Session Identifier;
- Workflow Instance where applicable;
- authority;
- autonomy level;
- tool set;
- memory state references;
- start time;
- lifecycle;
- Runtime Bundle;
- provenance.
23.83.3. Agent Types
Agent Types MAY include:
- advisory agent;
- drafting agent;
- retrieval agent;
- validation-support agent;
- reasoning-support agent;
- calculation-support agent;
- workflow agent;
- evidence agent;
- report agent;
- supplier-engagement agent;
- assurance-support agent;
- monitoring agent;
- incident-response agent;
- orchestration agent;
- supervisory agent;
- federated agent.
23.83.4. Agent Purpose
Every Agent Instance SHALL operate under an explicit purpose.
Purpose SHALL constrain:
- inputs;
- knowledge retrieval;
- memory;
- tools;
- actions;
- outputs;
- side effects;
- disclosure;
- retention;
- autonomy.
23.83.5. Agent Admission
Agent admission SHALL validate:
- Agent Definition;
- Agent Instance identity;
- model identity;
- model version;
- provider;
- Runtime Context;
- tenant;
- purpose;
- capabilities;
- authority;
- autonomy;
- tool set;
- instruction artefacts;
- memory policy;
- trust state;
- Runtime Bundle;
- security profile.
23.83.6. Agent Lifecycle
An Agent Instance MAY progress through:
Registered
│
▼
Validated
│
▼
Authorised
│
▼
Ready
│
▼
Active
│
├──► Waiting
├──► Suspended
├──► Intervention Required
├──► Failed
▼
Completed
│
▼
Terminated
│
▼
Archived
23.83.7. Agent Inputs
Agent inputs MAY include:
- Execution Requests;
- Workflow Tasks;
- Constitutional Objects;
- Constitutional Relationships;
- Constitutional Contexts;
- evidence;
- validated data;
- Runtime Outcomes;
- events;
- tool results;
- human instructions;
- agent messages;
- memory retrievals.
Every material input SHALL preserve source, identity, context and trust state.
23.83.8. Agent Outputs
Agent outputs MAY include:
- draft content;
- candidate assertion;
- Derived Assertion proposal;
- classification proposal;
- plan;
- tool request;
- validation recommendation;
- remediation recommendation;
- task outcome;
- event;
- escalation;
- explanation;
- structured data.
Agent outputs SHALL be classified by authority and activation status.
23.83.9. Proposal Boundary
Unless an approved policy states otherwise, agent-generated content SHALL be treated as:
- proposed;
- advisory;
- derived;
- provisional;
- simulation-only.
It SHALL NOT be represented as canonical, approved, assured or published merely because the agent produced it.
23.83.10. Agent Side Effects
Agent side effects SHALL require:
- explicit Agent Authority;
- approved tool;
- explicit purpose;
- bounded scope;
- valid Runtime Context;
- validated Agent Plan;
- applicable approval or oversight Gate;
- idempotency;
- provenance.
23.83.11. Agent Determinism
Every Agent Profile SHALL declare its determinism characteristics.
The Runtime SHALL preserve:
- model;
- model version;
- provider;
- instructions;
- prompt artefacts;
- retrieval snapshot;
- tool configuration;
- sampling parameters;
- seed where supported;
- context;
- output;
- validation.
Non-deterministic output SHALL not bypass validation or approval.
23.83.12. Agent Trust
Agent trust SHALL consider:
- Agent Definition approval;
- model identity;
- provider trust;
- software supply-chain integrity;
- instruction integrity;
- tool integrity;
- Runtime Bundle integrity;
- evaluation results;
- security posture;
- incident history;
- drift;
- provenance.
23.83.13. Agent Evaluation
Agents SHOULD be evaluated through:
- capability tests;
- task conformance tests;
- adversarial tests;
- tenant-isolation tests;
- prompt-injection tests;
- tool-misuse tests;
- data-exfiltration tests;
- hallucination tests;
- authority-boundary tests;
- replay tests;
- explanation tests;
- shutdown tests.
23.83.14. Agent Drift
The Runtime SHALL detect material drift in:
- model version;
- provider behaviour;
- instructions;
- tools;
- retrieval sources;
- performance;
- safety;
- output distribution;
- refusal behaviour;
- authority handling.
Material drift SHALL trigger revalidation and possibly suspension.
23.83.15. Agent Suspension
An Agent Instance MAY be suspended due to:
- authority uncertainty;
- model drift;
- security incident;
- tool compromise;
- prompt injection;
- data leakage risk;
- repeated invalid output;
- runaway execution;
- budget breach;
- human intervention;
- Runtime Bundle revocation.
23.83.16. Agent Termination
Termination SHALL:
- stop new actions;
- cancel or isolate pending tool calls;
- preserve state needed for audit;
- revoke temporary credentials;
- close event subscriptions;
- preserve outputs and provenance;
- trigger compensation or remediation where required.
23.84. Agent Identity, Capability, Authority and Autonomy
The Runtime SHALL preserve distinct constitutional representations for:
- Agent Definition identity;
- Agent Instance identity;
- Runtime Component identity;
- model identity;
- provider identity;
- represented principal;
- invoking actor;
- owning Module;
- deployment identity.
These identities SHALL NOT be collapsed.
23.84.1. Agent Identity
Agent identity SHALL identify the governed agent concept.
It SHALL remain stable across model or deployment substitutions where constitutional semantics remain unchanged.
23.84.2. Model Identity
Model identity SHALL identify:
- model provider;
- model family;
- model name;
- exact version or snapshot where available;
- deployment;
- parameters;
- safety configuration;
- data-residency profile;
- provenance.
A model SHALL not be treated as the agent itself.
23.84.3. Capability Profile
An Agent Capability Profile SHALL define:
- supported task types;
- supported subject types;
- reasoning capabilities;
- computation capabilities;
- retrieval capabilities;
- drafting capabilities;
- tool capabilities;
- languages;
- jurisdictions;
- limitations;
- required supervision;
- prohibited operations;
- provenance.
Capability SHALL not imply authority.
23.84.4. Capability Evidence
Capability claims SHALL be supported by:
- evaluation results;
- conformance tests;
- certification where applicable;
- benchmark evidence;
- human review;
- deployment tests;
- incident history;
- provenance.
23.84.5. Agent Authority Profile
An Agent Authority Profile SHALL define:
- permitted actions;
- permitted subjects;
- permitted tenants;
- permitted jurisdictions;
- permitted tools;
- permitted data classes;
- permitted side effects;
- permitted publications;
- permitted delegation;
- temporal validity;
- approval requirements;
- escalation requirements;
- revocation policy;
- provenance.
23.84.6. Least Authority
An Agent Instance SHALL receive only the authority required for its active Task or Plan Step.
Standing broad authority SHOULD be avoided.
23.84.7. Temporary Credentials
Tool credentials SHOULD be:
- task-bound;
- purpose-bound;
- tenant-bound;
- short-lived;
- least-privileged;
- revocable;
- auditable.
Agents SHALL not expose credentials in prompts, memory or outputs.
23.84.8. Autonomy Profile
An Autonomy Profile defines the degree to which an Agent Instance may plan, decide, invoke tools and perform side effects without prior human approval.
Autonomy categories MAY include:
| Autonomy Category | Constitutional Meaning |
|---|---|
| Observe | May inspect approved information but not propose actions |
| Advise | May produce recommendations and explanations |
| Draft | May prepare proposed content or structured changes |
| Execute with Approval | May plan and request tools, but side effects require approval |
| Bounded Execute | May perform predefined low-risk actions within strict limits |
| Supervisory | May coordinate other agents within an approved orchestration plan |
| Emergency Bounded | May perform narrowly defined emergency actions under emergency policy |
No category SHALL imply unrestricted autonomy.
23.84.9. Autonomy Resolution
CRP SHALL resolve the applicable Autonomy Profile from:
- Agent Definition;
- Task Type;
- purpose;
- subject;
- tenant;
- jurisdiction;
- risk;
- materiality;
- security;
- assurance significance;
- publication impact;
- emergency state.
23.84.10. Autonomy Limits
Limits MAY include:
- maximum execution duration;
- maximum tool calls;
- maximum monetary cost;
- maximum data volume;
- maximum graph traversal;
- maximum recipients;
- maximum change count;
- maximum materiality;
- maximum risk score;
- permitted hours;
- permitted environments;
- permitted external endpoints.
23.84.11. Self-Modification Prohibition
An agent SHALL NOT modify its own:
- Agent Definition;
- authority;
- Autonomy Profile;
- instruction authority;
- tool permissions;
- validation requirements;
- oversight requirements;
- termination controls
without a separate governed process and independent authority.
23.84.12. Delegation by Agents
An agent SHALL not delegate authority unless explicitly permitted.
Agent-to-agent task handoff SHALL not transfer more authority than the receiving agent independently possesses.
23.84.13. Agent Impersonation Prohibition
An agent SHALL NOT impersonate a human participant, verifier, approver, regulator or tenant.
Agent-generated communications SHALL disclose machine authorship where required by policy or law.
23.84.14. Authority Revalidation
Agent Authority SHALL be revalidated:
- before privileged tool use;
- before side effects;
- before external communication;
- before publication;
- when Context changes;
- when Task changes;
- when agent handoff occurs;
- when model or tool changes;
- after suspension;
- at policy-defined intervals.
23.84.15. Agent Authority Failure
Where authority cannot be established, the agent SHALL:
- stop the prohibited action;
- avoid side effects;
- preserve the attempted action;
- produce a diagnostic;
- escalate where required;
- preserve provenance.
23.85. Agent Planning, Memory and Tool Use
Agent execution SHALL be governed through explicit plans, bounded memory and approved tool contracts.
The Runtime SHALL distinguish:
- constitutional Execution Plan;
- workflow plan;
- agent-local plan;
- tool-execution plan;
- model-generated chain of thought.
Private model reasoning SHALL not be required as constitutional evidence.
The Runtime SHALL instead preserve concise, reviewable decision rationale, plan steps, tool calls, inputs, outputs and provenance.
23.85.1. Agent Plan
An Agent Plan SHALL identify:
- Agent Plan Identifier;
- source Task or Request;
- purpose;
- Runtime Context;
- target outcome;
- proposed steps;
- required tools;
- required data;
- required authority;
- required approvals;
- risk classification;
- cost and resource budget;
- stopping conditions;
- escalation conditions;
- validation requirements;
- provenance.
23.85.2. Plan Classes
An Agent Plan MAY be:
- predefined;
- template-derived;
- dynamically generated;
- adaptive within bounds;
- human-authored;
- agent-proposed;
- multi-agent;
- recovery plan;
- simulation plan.
23.85.3. Agent Plan Validation
HECATE SHALL validate:
- purpose alignment;
- scope;
- authority;
- autonomy;
- tool compatibility;
- data-access compatibility;
- tenant isolation;
- risk;
- side effects;
- budget;
- termination;
- oversight;
- provenance.
23.85.4. Plan Approval
High-risk Agent Plans SHALL require approval.
Approval MAY be required for:
- publication;
- data export;
- external communication;
- deletion;
- financial action;
- regulatory filing;
- assurance conclusion;
- cross-tenant access;
- new tool use;
- high-impact classification;
- irreversible action;
- emergency action.
23.85.5. Plan Adaptation
An agent MAY adapt a plan only within the approved plan envelope.
Material adaptation SHALL trigger:
- new Agent Plan version;
- revalidation;
- authority revalidation;
- approval where required;
- updated budget;
- provenance.
23.85.6. Working Memory
Working Memory MAY contain transient task state required for active execution.
It SHALL be:
- task-scoped;
- tenant-scoped;
- time-limited;
- access-controlled;
- excluded from canonical knowledge unless activated;
- disposed of according to policy.
23.85.7. Session Memory
Session Memory MAY preserve continuity across related actions.
It SHALL not silently carry authority, consent, tenant context or conclusions into a new session.
23.85.8. Episodic Memory
Episodic Memory MAY preserve prior agent interactions or executions.
Every memory item SHALL preserve:
- source execution;
- subject;
- context;
- time;
- trust;
- confidentiality;
- lifecycle;
- provenance.
23.85.9. Semantic Memory
Semantic Memory MAY contain curated reusable knowledge.
It SHALL preserve:
- source;
- activation status;
- tenant scope;
- constitutional status;
- temporal validity;
- validation;
- provenance.
Vector-store presence SHALL not establish constitutional truth.
23.85.10. Memory Classification
Agent memory SHALL classify content as:
- explicit constitutional knowledge;
- validated runtime knowledge;
- Derived Assertion;
- agent proposal;
- human instruction;
- tool result;
- external content;
- untrusted content;
- simulation content;
- confidential content.
23.85.11. Memory Contamination
The Runtime SHALL prevent:
- cross-tenant memory leakage;
- cross-purpose leakage;
- stale authority reuse;
- untrusted content becoming instruction;
- prompt injection persisting as policy;
- confidential content entering public outputs;
- simulation memory influencing authoritative execution without disclosure.
23.85.12. Memory Retention
Retention SHALL be governed by:
- memory type;
- purpose;
- tenant;
- privacy;
- security;
- evidence requirement;
- audit requirement;
- legal hold;
- model-improvement policy.
23.85.13. Tool Definition
A Tool Definition is the governed Constitutional Object or runtime artefact defining an operation an agent or Component may invoke.
It SHALL possess:
- Tool Identifier;
- canonical name;
- purpose;
- owning Component;
- input contract;
- output contract;
- authority requirements;
- data-access requirements;
- side effects;
- idempotency;
- transaction behaviour;
- timeout;
- retry;
- compensation;
- security profile;
- version;
- provenance.
23.85.14. Tool Classes
Tools MAY include:
- constitutional graph query;
- registry lookup;
- HECATE validation;
- CRP resolution;
- Computation Hub execution;
- report generation;
- evidence retrieval;
- workflow action;
- event publication;
- notification;
- document drafting;
- external API;
- database operation;
- file operation;
- search;
- model invocation;
- code execution;
- human-escalation request.
23.85.15. Tool Registration
A tool SHALL be registered and validated before authoritative use.
Registration SHALL verify:
- identity;
- owner;
- contract;
- authority;
- security;
- tenant support;
- jurisdiction support;
- side effects;
- data residency;
- software supply chain;
- conformance tests;
- provenance.
23.85.16. Tool Resolution
CRP SHALL resolve the permitted Tool Set from:
- Agent Definition;
- Agent Authority;
- Autonomy Profile;
- Task;
- purpose;
- tenant;
- jurisdiction;
- security;
- Runtime Bundle;
- environment.
23.85.17. Tool Invocation
Every material invocation SHALL preserve:
- Tool Invocation Identifier;
- Agent Instance;
- Tool Definition and version;
- purpose;
- input fingerprint;
- authority;
- Runtime Context;
- tenant;
- start and completion time;
- output fingerprint;
- side effects;
- status;
- cost;
- provenance.
23.85.18. Tool Input Validation
HECATE SHALL validate:
- input schema;
- subject scope;
- authority;
- tenant;
- data classification;
- purpose;
- side-effect boundary;
- idempotency key;
- transaction context;
- secrets handling.
23.85.19. Tool Output Validation
Tool output SHALL be validated for:
- schema;
- integrity;
- trust;
- context;
- tenant;
- temporal validity;
- semantic compatibility;
- side-effect confirmation;
- provenance.
23.85.20. Tool Injection Defence
The Runtime SHALL distinguish instructions from data.
External content, documents, websites, messages and tool outputs SHALL NOT acquire instruction authority merely because a model can read them.
Controls SHOULD include:
- instruction hierarchy;
- content labelling;
- untrusted-data boundaries;
- tool allowlists;
- parameter validation;
- output filtering;
- retrieval isolation;
- secret isolation;
- human approval for sensitive actions.
23.85.21. Tool Sandboxing
High-risk tools SHOULD execute within a sandbox defining:
- filesystem scope;
- network scope;
- data scope;
- credential scope;
- execution time;
- resource limits;
- allowed packages;
- output channels;
- side-effect restrictions;
- audit capture.
23.85.22. Tool Failure
Tool failure SHALL preserve:
- invocation;
- failure type;
- partial effects;
- retry eligibility;
- compensation requirement;
- diagnostics;
- escalation;
- provenance.
23.85.23. Cost and Resource Budget
Agent execution MAY be constrained by:
- token budget;
- compute budget;
- monetary budget;
- energy budget;
- carbon budget;
- tool-call budget;
- time budget;
- data-transfer budget.
Budget exhaustion SHALL trigger a governed stop, escalation or plan revision.
23.85.24. Agent Stop Conditions
Stop conditions MAY include:
- objective satisfied;
- maximum steps;
- maximum tool calls;
- budget exhausted;
- confidence insufficient;
- contradiction detected;
- authority missing;
- human intervention;
- security event;
- repeated failure;
- timeout;
- kill signal.
23.86. Multi-Agent Coordination
Multi-Agent Coordination is the governed collaboration among two or more Agent Instances or agent-enabled Components to complete a defined purpose.
Multi-agent capability SHALL not create collective authority beyond the authority independently resolved for the participating agents and orchestration plan.
23.86.1. Multi-Agent Workflow
Every authoritative multi-agent execution SHALL possess:
- Multi-Agent Execution Identifier;
- purpose;
- coordinating Workflow Instance;
- participating Agent Instances;
- roles;
- authority boundaries;
- shared context;
- private contexts;
- message protocol;
- task allocation;
- tool allocation;
- conflict policy;
- consensus policy where applicable;
- oversight;
- provenance.
23.86.2. Coordination Models
Coordination Models MAY include:
- central orchestration;
- hierarchical supervision;
- peer collaboration;
- blackboard architecture;
- market or auction allocation;
- committee review;
- debate;
- ensemble;
- federated coordination;
- human-led coordination.
23.86.3. Agent Roles
Multi-agent Roles MAY include:
- coordinator;
- planner;
- retriever;
- analyst;
- calculator;
- validator;
- critic;
- reviewer;
- verifier;
- synthesizer;
- monitor;
- escalation agent.
Role assignment SHALL not create authority.
23.86.4. Task Allocation
Task allocation SHALL consider:
- capability;
- authority;
- tenant;
- jurisdiction;
- context;
- competence evidence;
- tool access;
- independence;
- workload;
- risk;
- cost;
- availability.
23.86.5. Agent Messaging
Agent messages SHALL be governed events or governed runtime artefacts.
Each message SHOULD preserve:
- Message Identifier;
- sender;
- receiver;
- purpose;
- subject;
- Runtime Context;
- tenant;
- message type;
- content classification;
- correlation;
- causation;
- timestamp;
- integrity;
- provenance.
23.86.6. Message Types
Message Types MAY include:
- task request;
- task acceptance;
- result;
- critique;
- evidence request;
- clarification;
- plan proposal;
- tool request;
- escalation;
- conflict;
- vote;
- handoff;
- completion.
23.86.7. Shared Context
A shared multi-agent context SHALL be explicit and minimal.
Private agent memory SHALL not silently become shared context.
23.86.8. Handoff
An Agent Handoff SHALL identify:
- handing agent;
- receiving agent;
- Task;
- current state;
- context;
- authority;
- unresolved issues;
- evidence;
- memory transferred;
- prohibited memory;
- provenance.
23.86.9. Authority at Handoff
The receiving agent SHALL independently resolve authority.
Authority SHALL not transfer solely because another agent assigned the work.
23.86.10. Consensus
Where consensus is used, the policy SHALL define:
- participants;
- eligibility;
- voting or aggregation method;
- quorum;
- weights;
- tie-breaking;
- dissent handling;
- abstention;
- authority;
- explanation.
Model agreement SHALL not establish truth or authority.
23.86.11. Debate and Critique
Debate or critique MAY improve analysis, but the Runtime SHALL preserve:
- each agent’s output;
- evidence;
- assumptions;
- conflicts;
- revisions;
- final synthesis;
- validation;
- provenance.
23.86.12. Agent Independence
An agent acting as independent reviewer SHALL not share hidden state, instructions or interests that compromise the required independence.
23.86.13. Multi-Agent Conflict
Conflicts MAY include:
- contradictory outputs;
- incompatible plans;
- tool contention;
- authority conflict;
- resource conflict;
- context divergence;
- model disagreement;
- duplicated action;
- circular delegation;
- deadlock.
23.86.14. Conflict Resolution
Resolution MAY use:
- orchestrator policy;
- authority precedence;
- evidence quality;
- independent validator;
- human review;
- re-execution;
- additional agent;
- qualification;
- escalation.
23.86.15. Deadlock
A multi-agent deadlock SHALL trigger:
- detection;
- suspension of affected actions;
- evidence preservation;
- deterministic escalation;
- human intervention where required;
- provenance.
23.86.16. Collective Side Effects
Collective action SHALL require one explicit side-effect authority chain.
Multiple agent recommendations SHALL not be interpreted as approval.
23.86.17. Federated Agents
Federated coordination SHALL validate:
- federation identity;
- external agent identity;
- trust;
- authority;
- tenant and jurisdiction boundaries;
- data-sharing agreement;
- message schema;
- signature;
- provenance;
- revocation.
23.86.18. Multi-Agent Evaluation
Evaluation SHOULD include:
- coordination correctness;
- task-allocation correctness;
- message integrity;
- authority preservation;
- tenant isolation;
- conflict handling;
- deadlock handling;
- cost;
- latency;
- output quality;
- provenance completeness.
23.87. Human-Agent Oversight and Intervention
Human-Agent Oversight is the governed set of controls through which authorised human participants supervise, review, approve, constrain, intervene in or terminate agent activity.
Human presence SHALL not be used as a vague substitute for defined governance controls.
23.87.1. Oversight Profile
An Oversight Profile SHALL define:
- Agent Types;
- Task Types;
- risk classes;
- autonomy classes;
- required human Roles;
- observation requirements;
- approval points;
- intervention rights;
- review frequency;
- escalation;
- evidence;
- provenance.
23.87.2. Oversight Modes
Oversight Modes MAY include:
- human-in-the-loop;
- human-on-the-loop;
- human-over-the-loop;
- pre-approval;
- post-action review;
- exception review;
- sampled review;
- continuous supervision;
- emergency supervision.
The constitutional meaning of each mode SHALL be explicit.
23.87.3. Human-in-the-Loop
Human-in-the-loop SHALL require an authorised human decision before a defined action or transition proceeds.
The required decision SHALL not be inferred from silence.
23.87.4. Human-on-the-Loop
Human-on-the-loop MAY permit bounded autonomous execution while preserving:
- real-time visibility;
- intervention capability;
- alerting;
- action limits;
- stop control;
- complete provenance.
23.87.5. Human-over-the-Loop
Human-over-the-loop governance MAY define policy, evaluation, monitoring and review without supervising every action.
This mode SHALL be limited to sufficiently bounded and low-risk activity.
23.87.6. Oversight Assignment
Oversight assignment SHALL consider:
- authority;
- competence;
- independence;
- tenant;
- jurisdiction;
- availability;
- conflict of interest;
- workload;
- language;
- security clearance.
23.87.7. Review Gates
Agent outputs MAY require:
- factual review;
- constitutional review;
- semantic review;
- legal review;
- compliance review;
- security review;
- assurance review;
- publication review.
23.87.8. Intervention Rights
Authorised overseers MAY:
- pause an agent;
- modify permitted scope;
- reject a plan;
- require additional evidence;
- require human completion;
- revoke a tool;
- reduce autonomy;
- terminate an agent;
- trigger compensation;
- escalate.
Intervention SHALL be recorded.
23.87.9. Kill Control
High-risk Agent Runtime deployments SHALL provide an independently operable kill control.
The control SHALL:
- stop new actions;
- prevent new tool calls;
- revoke temporary credentials;
- isolate pending results;
- preserve audit evidence;
- avoid deleting provenance;
- initiate recovery procedures.
23.87.10. Safe State
Agent termination or suspension SHALL transition affected workflows and systems to a defined Safe State.
The Safe State SHALL identify:
- permitted residual actions;
- pending transactions;
- compensation;
- external side effects;
- human ownership;
- evidence preservation;
- restart requirements.
23.87.11. Override of Agent Output
A human may override an agent output only with sufficient authority.
The Runtime SHALL preserve:
- original output;
- overriding decision;
- authority;
- rationale;
- evidence;
- downstream impact;
- provenance.
23.87.12. Agent Recommendation Acceptance
Acceptance SHALL identify:
- accepted output;
- accepting human;
- authority;
- reviewed evidence;
- modifications;
- conditions;
- time;
- provenance.
A copied agent output SHALL not become human-authored merely because a human submitted it.
23.87.13. Automation Bias Controls
The Runtime SHOULD reduce automation bias through:
- explicit confidence and limitation display;
- alternative options;
- source visibility;
- contradiction visibility;
- independent evidence;
- non-default acceptance;
- reviewer accountability;
- calibrated alerts.
23.87.14. Alerting
Alerts MAY be triggered by:
- authority breach;
- tool misuse;
- unusual side effect;
- repeated failure;
- budget breach;
- data-exfiltration risk;
- prompt injection;
- model drift;
- contradictory outputs;
- overdue human review;
- emergency condition.
23.87.15. Intervention Deadline
Some actions MAY require human response within a defined period.
The profile SHALL define timeout behaviour, including suspension, escalation, automatic rejection or safe-state transition.
23.87.16. Oversight Evidence
Oversight Evidence SHALL preserve:
- oversight assignment;
- observed actions;
- alerts;
- interventions;
- reviews;
- decisions;
- rationale;
- time;
- authority;
- provenance.
23.87.17. Oversight Effectiveness
Pergamum Pulse MAY analyse:
- intervention frequency;
- missed alerts;
- approval latency;
- override frequency;
- agent error capture;
- automation bias indicators;
- reviewer workload;
- false-positive alerts;
- residual risk;
- tenant divergence.
Derived intelligence SHALL remain non-authoritative until governed activation.
23.88. Workflow and Agent Failure, Recovery and Compensation
Workflow and agent failures SHALL be explicit, classified and recoverable according to governed policies.
A failed agent step SHALL not be concealed by a successful overall workflow status.
A failed workflow SHALL not be represented as constitutionally complete.
23.88.1. Failure Classes
Failure Classes MAY include:
- request failure;
- admission failure;
- authority failure;
- Context failure;
- validation failure;
- planning failure;
- task failure;
- participant failure;
- agent failure;
- model failure;
- tool failure;
- event-correlation failure;
- timer failure;
- transaction failure;
- side-effect failure;
- compensation failure;
- security failure;
- tenant-isolation failure;
- provenance failure;
- infrastructure failure.
23.88.2. Failure Severity
Severity MAY consider:
- constitutional significance;
- materiality;
- regulatory impact;
- assurance impact;
- side effects;
- tenant count;
- affected subjects;
- publication status;
- recoverability;
- security;
- environmental or financial impact.
23.88.3. Failure Object
Every material failure SHOULD possess:
- Failure Identifier;
- failure class;
- Workflow Instance;
- Task or Agent Instance;
- affected subject;
- Runtime Context;
- time;
- cause;
- error;
- partial state;
- partial side effects;
- severity;
- retry eligibility;
- compensation requirement;
- escalation;
- provenance.
23.88.4. Retry Policy
Retry SHALL define:
- eligible failure classes;
- maximum attempts;
- delay;
- backoff;
- idempotency;
- authority revalidation;
- context revalidation;
- tool revalidation;
- stop conditions;
- provenance.
Retry SHALL not repeat non-idempotent side effects without control.
23.88.5. Agent Replanning
An agent MAY replan after failure only within its approved autonomy and plan envelope.
Material replanning SHALL require a new plan version and revalidation.
23.88.6. Alternative Participant
A failed or unavailable participant MAY be replaced where:
- candidate resolution is governed;
- authority is sufficient;
- competence is sufficient;
- SoD remains valid;
- context is preserved;
- prior work is reviewed;
- provenance is preserved.
23.88.7. Alternative Agent or Model
Substitution SHALL validate:
- Agent Definition compatibility;
- capability;
- authority;
- Autonomy Profile;
- model compatibility;
- tool compatibility;
- tenant;
- jurisdiction;
- data residency;
- conformance;
- provenance.
23.88.8. Fallback Tool
A fallback tool MAY be used only through an explicit fallback policy.
The Runtime SHALL disclose:
- preferred tool;
- failure;
- fallback tool;
- semantic differences;
- risk;
- quality degradation;
- side-effect differences;
- provenance.
23.88.9. Workflow Compensation
A Compensation Plan MAY reverse, neutralise, correct or supersede completed workflow effects.
Compensation SHALL distinguish:
- exact rollback;
- semantic reversal;
- corrective assertion;
- publication correction;
- notification recall;
- financial adjustment;
- task reopening;
- manual remediation;
- accepted residual effect.
23.88.10. Agent Compensation
Where an agent performed a side effect, compensation SHALL identify:
- original Agent Instance;
- original Tool Invocation;
- authority;
- side effect;
- compensating action;
- responsible actor or Component;
- residual risk;
- validation;
- provenance.
23.88.11. Partial Recovery
Partial recovery SHALL identify:
- restored state;
- unresolved state;
- uncompensated effects;
- affected subjects;
- residual risk;
- escalation;
- required human action;
- provenance.
23.88.12. Quarantine
The Runtime MAY quarantine:
- invalid agent output;
- suspicious tool output;
- poisoned memory;
- compromised evidence;
- malformed events;
- unsafe workflow state;
- compromised Runtime Bundle.
Quarantined material SHALL remain isolated and auditable.
23.88.13. Circuit Breaker
A circuit breaker MAY suspend repeated failing:
- tool calls;
- agent actions;
- event consumers;
- workflow transitions;
- external services;
- model providers.
Circuit-breaker state SHALL be explicit and governed.
23.88.14. Dead-Letter Handling
Failed Tasks, events or agent messages MAY enter a governed dead-letter process.
The process SHALL preserve:
- original item;
- failure;
- attempts;
- context;
- authority;
- remediation;
- replay eligibility;
- provenance.
23.88.15. Workflow Cancellation
Cancellation SHALL define:
- cancelling authority;
- reason;
- affected Tasks;
- active agents;
- pending tools;
- side effects;
- compensation;
- notifications;
- terminal state;
- provenance.
23.88.16. Emergency Shutdown
Emergency shutdown SHALL follow Part VI Emergency Authority and SHALL preserve:
- declaring authority;
- scope;
- agents stopped;
- workflows stopped;
- tools revoked;
- transactions affected;
- compensation;
- evidence;
- retrospective review.
23.88.17. Recovery Validation
HECATE SHALL validate:
- recovery plan;
- retry safety;
- replacement compatibility;
- compensation;
- final state;
- residual effects;
- tenant isolation;
- authority;
- provenance.
23.88.18. Failure Impact Analysis
The Runtime SHALL support impact analysis over:
- dependent Tasks;
- Workflow Instances;
- Agent Instances;
- Derived Assertions;
- Validation Outcomes;
- calculations;
- reports;
- disclosures;
- publications;
- assurance conclusions;
- tenants;
- Modules;
- Components.
23.89. Workflow and Agent Provenance, Explanation and Conformance
Workflow and Agent Provenance is the complete governed lineage explaining how a workflow progressed, how human and machine participants acted, which agents and tools were used, which decisions and Gates applied, which side effects occurred and how the final outcome was produced.
Provenance SHALL be captured during execution.
23.89.1. Workflow Provenance Scope
Workflow Provenance SHALL include:
- Workflow Request;
- Workflow Profile;
- Workflow Definition and version;
- Workflow Instance;
- Runtime Context;
- Context Fingerprint;
- subject scope;
- Tasks;
- assignments;
- participants;
- Roles;
- authority;
- transitions;
- Gates;
- timers;
- events;
- transactions;
- side effects;
- compensation;
- escalation;
- outcome;
- Runtime Bundle;
- Module lineage;
- Component lineage;
- timestamps;
- signatures;
- trust state.
23.89.2. Agent Provenance Scope
Agent Provenance SHALL include:
- Agent Definition;
- Agent Instance;
- Runtime Component;
- owning Module;
- model identity and version;
- provider;
- purpose;
- Runtime Context;
- authority;
- Autonomy Profile;
- Agent Plan;
- instructions;
- retrieval snapshot;
- memory references;
- tools;
- tool inputs and outputs;
- messages;
- human oversight;
- interventions;
- output;
- validation;
- side effects;
- termination;
- provenance.
23.89.3. Instruction Artefacts
The Runtime SHALL preserve governed identities for:
- system instructions;
- agent instructions;
- Workflow Task instructions;
- policy prompts;
- retrieval instructions;
- tool instructions;
- output schemas;
- safety rules.
Untrusted external content SHALL not be represented as a governing instruction artefact.
23.89.4. Decision Rationale
For constitutionally significant agent actions, the Runtime SHALL preserve a concise decision rationale identifying:
- objective;
- relevant inputs;
- selected plan;
- selected tools;
- key constraints;
- alternatives considered where material;
- uncertainty;
- validation;
- approval;
- outcome.
The Runtime SHALL NOT depend upon disclosure of private model chain-of-thought.
23.89.5. Tool Provenance
Tool Provenance SHALL preserve:
- Tool Definition;
- version;
- invocation;
- invoking Agent or Component;
- authority;
- input fingerprint;
- output fingerprint;
- side effects;
- transaction;
- status;
- cost;
- time;
- provenance.
23.89.6. Memory Provenance
Material memory retrieval and storage SHALL preserve:
- memory item;
- memory type;
- source;
- tenant;
- purpose;
- retrieval query or selector;
- access authority;
- use;
- update;
- expiration;
- provenance.
23.89.7. Human Contribution Provenance
Human contributions SHALL preserve:
- actor;
- represented principal;
- Role;
- authority;
- Task;
- input;
- contribution;
- decision;
- rationale;
- evidence;
- time;
- review;
- provenance.
23.89.8. Multi-Agent Provenance
Multi-agent provenance SHALL preserve:
- participating agents;
- roles;
- messages;
- handoffs;
- plans;
- critiques;
- conflicts;
- consensus method;
- dissent;
- final synthesis;
- oversight;
- provenance.
23.89.9. Workflow Explanation
Every material Workflow Outcome SHALL explain:
- why the workflow was selected;
- which definition and version applied;
- which Tasks executed;
- who or what performed them;
- which Gates applied;
- which events triggered transitions;
- which delays or exceptions occurred;
- which side effects occurred;
- why the terminal outcome was reached.
23.89.10. Agent Explanation
Every material Agent Outcome SHALL explain:
- agent purpose;
- identity;
- model and version;
- authority;
- autonomy;
- inputs;
- selected plan;
- tools used;
- evidence or knowledge used;
- uncertainty;
- validation;
- human oversight;
- side effects;
- limitations.
23.89.11. Why-Not Explanation
The Runtime SHOULD support explanations such as:
- why was a Task not assigned;
- why was a transition not permitted;
- why was an agent not selected;
- why was a tool blocked;
- why was human approval required;
- why was autonomy reduced;
- why was a workflow suspended;
- why was an output rejected.
23.89.12. Explanation Security
Explanations SHALL respect:
- tenant isolation;
- access control;
- personal-data minimisation;
- confidentiality;
- legal privilege;
- trade secrets;
- security classification;
- agent-security policy;
- inference-leakage prevention.
23.89.13. Workflow and Agent Events
The Runtime SHOULD produce immutable events including:
- WorkflowRequested;
- WorkflowStarted;
- WorkflowSuspended;
- WorkflowResumed;
- WorkflowMigrated;
- WorkflowCompleted;
- WorkflowCancelled;
- TaskAssigned;
- TaskCompleted;
- GateEvaluated;
- AgentInstantiated;
- AgentAuthorised;
- AgentPlanCreated;
- AgentPlanApproved;
- AgentToolInvoked;
- AgentMessageSent;
- HumanInterventionRequested;
- HumanInterventionPerformed;
- AgentSuspended;
- AgentTerminated;
- CompensationStarted;
- CompensationCompleted.
23.89.14. Provenance Integrity
Integrity mechanisms MAY include:
- cryptographic hashes;
- hash chains;
- digital signatures;
- trusted timestamps;
- append-only logs;
- transparency logs;
- immutable event stores;
- hardware-backed attestations;
- replicated evidence vaults.
23.89.15. Provenance Completeness
Completeness MAY be classified as:
- complete;
- complete with controlled redaction;
- partially complete;
- materially incomplete;
- reconstructed;
- disputed;
- unavailable.
Materially incomplete provenance SHALL prevent unqualified high-assurance use.
23.89.16. Workflow Replay
Workflow replay SHALL reconstruct:
- Tasks;
- transitions;
- Gates;
- human decisions;
- agent actions;
- tool outputs;
- events;
- timers;
- state;
- side effects;
- outcomes.
23.89.17. Agent Replay
Agent replay SHALL identify whether it is:
- exact replay;
- semantic replay;
- deterministic tool replay;
- model replay;
- simulated replay;
- forensic replay.
Where an external model or provider cannot reproduce an output, the replay SHALL disclose the limitation.
23.89.18. Workflow and Agent Diff
A semantic diff SHOULD identify changes in:
- Workflow Definition;
- Runtime Context;
- participants;
- authority;
- Tasks;
- Gates;
- agent versions;
- models;
- instructions;
- memory;
- tools;
- plans;
- outputs;
- side effects;
- outcomes;
- provenance.
23.89.19. Impact Analysis
Changes to workflows, agents, tools, models, policies or authority SHALL support impact analysis over:
- active Workflow Instances;
- pending Tasks;
- active Agent Instances;
- agent plans;
- tool permissions;
- Runtime Outcomes;
- reports;
- disclosures;
- publications;
- assurance conclusions;
- tenants;
- Modules;
- Components.
23.89.20. Pergamum Pulse Integration
Pergamum Pulse MAY derive intelligence including:
- workflow bottlenecks;
- stuck instances;
- task reassignment patterns;
- approval delay;
- agent failure patterns;
- tool failure patterns;
- agent drift;
- excessive autonomy;
- authority-boundary attempts;
- intervention effectiveness;
- automation bias risk;
- human workload;
- agent cost;
- cross-Module dependency risk;
- tenant divergence;
- compensation frequency;
- provenance gaps;
- workflow and agent governance debt.
Pergamum Pulse SHALL preserve:
- Module lineage;
- Component lineage;
- Workflow Definition lineage;
- Workflow Instance lineage;
- Task lineage;
- participant lineage;
- Agent Definition lineage;
- Agent Instance lineage;
- model lineage;
- tool lineage;
- Context lineage;
- authority lineage;
- Runtime Bundle lineage;
- temporal lineage;
- tenant isolation;
- provenance.
Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.
23.89.21. Workflow Conformance Suite
The Constitutional Compiler Framework SHOULD generate workflow fixtures including:
- valid linear workflow;
- valid parallel workflow;
- event-driven workflow;
- timer workflow;
- approval workflow;
- assurance workflow;
- compensation workflow;
- migration workflow;
- tenant-overlay workflow;
- SoD conflict workflow;
- deadlock workflow;
- late-event workflow;
- replay workflow;
- emergency workflow.
23.89.22. Agent Conformance Suite
The Constitutional Compiler Framework SHOULD generate agent fixtures including:
- advisory agent;
- drafting agent;
- bounded tool agent;
- human-approval agent;
- denied-authority case;
- prompt-injection case;
- cross-tenant leakage case;
- tool-misuse case;
- model-drift case;
- memory-contamination case;
- multi-agent conflict case;
- deadlock case;
- kill-control case;
- compensation case;
- replay case;
- explanation case.
Part VIII Conformance
A Constitutional Runtime Framework implementation conforms to Part VIII where it:
- treats workflows as governed constitutional coordination rather than hidden application flow;
- represents Workflow Definitions and Workflow Profiles as governed Constitutional Objects;
- requires identifiable Workflow Requests and Workflow Instances;
- preserves exact Workflow Definition and Runtime Bundle versions;
- resolves workflow applicability through Constitutional Resolution Policies;
- preserves explicit workflow boundaries, state, Tasks, transitions and Gates;
- prevents task assignment from creating constitutional authority;
- validates Task completion and Workflow State transitions through HECATE;
- supports human, service, validation, approval, assurance, event, timer and agent Tasks;
- preserves human identity, represented principal, Role, competence, authority and contribution provenance;
- treats agents as governed Runtime Components and identifiable machine actors;
- distinguishes Agent identity, Component identity, model identity, provider identity and represented principal;
- separates agent capability, authority and autonomy;
- prevents agents from expanding or approving their own authority;
- treats agent outputs as proposed or derived unless governed activation applies;
- requires explicit Agent Plans for material autonomous execution;
- validates agent plans, tools, memory and side effects;
- distinguishes instruction artefacts from untrusted external content;
- prevents untrusted content from acquiring instruction authority;
- governs agent memory by purpose, tenant, lifecycle, trust and provenance;
- registers and validates tools through explicit Tool Definitions and contracts;
- requires authority revalidation before privileged tool use and side effects;
- supports bounded multi-agent coordination without creating collective authority;
- preserves agent messages, handoffs, conflicts, consensus and dissent;
- provides governed human oversight, intervention and kill controls;
- defines Safe State behaviour for suspension and termination;
- supports retry, replanning, substitution, quarantine, circuit breaking and compensation;
- preserves complete Workflow, human, Agent, model, tool and memory provenance;
- supports workflow and agent replay, diff and impact analysis;
- preserves both Module and Component lineage;
- prevents private model reasoning from being required as constitutional evidence while preserving reviewable decision rationale;
- prevents technically successful workflows or agent actions from being represented as constitutionally successful when required authority, validation, approval, assurance or provenance is missing.
Part VIII Foundational Principle
Workflow and Agent Runtime is the governed constitutional mechanism through which ZAYAZ coordinates human and machine work across long-running, event-driven and multi-step processes while preserving authority, validation, temporal integrity, tenant isolation, recovery and complete lineage.
Workflow SHALL coordinate execution but SHALL not create authority. Task assignment SHALL not create permission. Agent capability SHALL not imply authority. Autonomy SHALL remain bounded by purpose, context, risk, tools, time, resources and governance. Agent-generated content SHALL remain proposed, derived or provisional until the applicable validation, approval, assurance and activation requirements are satisfied.
Every workflow SHALL preserve its Workflow Request, Workflow Profile, Workflow Definition, Workflow Instance, Tasks, transitions, Gates, events, timers, participants, agents, tools, transactions, compensation, Runtime Context, Runtime Bundle, Module lineage, Component lineage and complete provenance. Every agent action SHALL preserve Agent Definition, Agent Instance, model identity, authority, Autonomy Profile, Agent Plan, instructions, knowledge sources, memory, tool calls, human oversight, output, side effects and explanation.
By making workflows explicit and agents bounded, observable, interruptible, replayable and provenance-preserving, ZAYAZ enables advanced human-agent collaboration and autonomous ESG operations without surrendering constitutional control, regulatory assurance, white-label tenant isolation or human accountability.