Jira progress: loading…

WTE

Workflow Test Engine

1. Purpose

The Workflow Test Engine is the assurance engine that validates Workflow Definitions and isolated Workflow Executions against governed functional, temporal, authority, gate, security, side-effect, and provenance requirements. It supports static conformance checks, scenario execution, simulation, dry-run, replay, shadow testing, regression testing, and migration validation. It must preserve test evidence and must not permit authoritative side effects from non-authoritative test modes.

• Workflow definitions must be validated for completeness, unreachable states, dead ends, unbounded loops, missing compensation/escalation, gate and authority coverage, task contracts, event correlation, temporal correctness, tenant isolation, and provenance (/cdf/constitutional-runtime-framework-8, §23.79.12).
• Workflow execution supports explicit test, simulation, replay, shadow, and dry-run modes; simulation/dry-run cannot create authoritative side effects (/cdf/constitutional-runtime-framework-8, §23.78.6).
• Replays must use the historical definition, context, events, human decisions, agent/tool outputs, policies, runtime bundle, and temporal state, while remaining isolated and side-effect controlled (/cdf/constitutional-runtime-framework-8, §23.80.16).
• Workflow transitions and task completion have explicit gate, authority, evidence, temporal, side-effect, and provenance requirements (/cdf/constitutional-runtime-framework-8, §23.80–23.81).

2. Boundary with related engines

• Workflow Runtime / Engine: executes and coordinates governed workflow instances.
• TrustGate Scheduler / Orchestrator: decides when and how background/asynchronous workflows and jobs run; it explicitly does not make assurance decisions (/trustgate/trustgate-engines/trustgate-scheduler-orchestrator-engine).
• Workflow Test Engine: evaluates whether definitions and executions conform to expected workflow semantics and assurance rules, ideally in isolated test/simulation/replay environments.

Recommended further contents for the document

A useful specification could include:

1. Purpose and non-goals

   • Conformance testing and assurance of workflows.
   • Not a production scheduler, authority resolver, or primary workflow runtime.

2. Inputs

   • Workflow Definition and version
   • Workflow Profile
   • Runtime Context / context fingerprint
   • Test scenario / fixture
   • Event sequences, timer state, task/participant inputs
   • Expected transitions, gate outcomes, outputs, evidence, and side-effect assertions
   • Runtime Bundle and policy versions

3. Test modes

   • Static definition validation
   • Unit testing of tasks, predicates, and transitions
   • End-to-end execution tests
   • Simulation and dry-run
   • Historical replay / deterministic regression testing
   • Shadow execution
   • Migration and compatibility testing across workflow-definition versions

4. Required checks

   • Reachability, dead ends, loops, forks/joins
   • Gate and authority coverage
   • Task input/output contract validity
   • Timer and event-wait behavior
   • Compensation, escalation, suspension, and resumption paths
   • Tenant/security isolation
   • Side-effect suppression or reconciliation
   • Provenance/evidence completeness
   • Determinism under equivalent inputs and histories

5. Outputs

   • Pass/fail/indeterminate result
   • Failed invariant or contract
   • Execution trace and transition history
   • Expected-versus-actual differences
   • Definition/version/context/runtime-bundle fingerprints
   • Test evidence suitable for audit and release assurance

6. Integration points

   • HECATE for definition and runtime validation
   • Workflow Definition/Profile resolution
   • Workflow Runtime for isolated execution
   • Scheduler only for scheduling periodic/regression suites, if needed
   • CI/CD or constitutional compilation outputs, since workflows may compile into conformance fixtures (/cdf/constitutional-runtime-framework-8, §23.79.13)

---