Execution Model

Workflow execution starts from a matter#

Legal workflow execution is tied to a matter. The backend exposes POST /api/v1/matters/{matter_id}/processes/start and the compatible POST /api/v1/matters/{matter_id}/workflow/start route. The workflow engine validates the matter and workflow definition, then creates MatterWorkflow and MatterTask records.

The frontend can also create a matter in auto execution mode. When the matter has a workflow definition and auto mode is enabled, the backend attempts to launch the workflow immediately after matter creation. Auto execution does not skip attorney review gates that the workflow defines.

Dependencies control task readiness#

Workflow steps declare dependencies through depends_on. At launch, tasks with unmet dependencies wait until upstream work is complete. Approving a matter task through POST /api/v1/tasks/{task_id}/approve marks it completed and asks the workflow engine to advance dependent work.

Human tasks preserve legal review context#

Human tasks are separate records from matter tasks. They support feedback, action, approval, and information task types and are the implemented surface for attorney review and legal approval checkpoints. Feedback submission uses POST /api/v1/matters/{matter_reference_id}/tasks/{task_id}/submit-feedback, stores structured response data, and triggers follow-up processing.

When a review or approval task is pending, the matter's legal lifecycle should surface as under_review or awaiting_approval. See Legal Matter Lifecycle.

Temporal owns durable workers#

Temporal workflows and workers run long-lived execution paths for matter creation, document processing, document embeddings, workflow advancement, automation execution, external tools, inbox monitoring, email token refresh, and follow-up review. The main worker registers task-execution-queue, agent-task-queue, and email-workflows-queue.