> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Temporal Engine

> The Rust workflow engine behind Workflow Studio — deterministic, multi-tenant automation on Temporal.

# Temporal Engine

A Rust implementation of the StateSet deterministic workflow engine (v2), built on
[Temporal](https://temporal.io). A single data-driven **ResponseAutomationV2** workflow serves
every brand — replacing per-brand workflow code — backed by LLM tool-use, knowledge base search,
and connector integrations.

This is the engine that [Workflow Studio](/stateset-response/responsecx-workflow-studio)
configures.

## System overview

```
  External                Kubernetes Cluster              Infrastructure
 ──────────      ┌──────────────────────────────┐      ──────────────────
  Gorgias        │  engine-api    (Axum, :8080) │        Temporal Server
  Shopify   ◀───▶│  engine-worker (       :9090)│◀────▶  PostgreSQL
  Recharge       │  dispatcher    (       :9091)│        (control plane)
  OpenAI         │  migrate       (schema job)  │
  Qdrant         └──────────────────────────────┘

  clients ──▶ engine-api ──start/signal/query──▶ Temporal ──▶ engine-worker ──▶ external
                   │                                 ▲
                   └──CRUD/ingest──▶ PostgreSQL ──────┘
                                          ▲
                                    dispatcher polls outbox
```

## What the engine does

Given a customer support ticket, it orchestrates an end-to-end automated response:

1. **Loads brand-specific automation rules** from the control plane database.
2. **Fetches the full ticket** with message history.
3. **Evaluates skip rules** — business hours, ticket age, intent filters — to decide whether
   automation should run at all.
4. **Checks escalation patterns** to detect sensitive topics.
5. **Gathers context** — customer data from Shopify, subscriptions from Recharge, articles from
   the knowledge base.
6. **Runs an LLM with tool-use**, calling tools in a loop.
7. **Classifies intent and confidence** via configured classification phases.
8. **Optionally pauses for human review** when confidence is below threshold.
9. **Dispatches the response**, applies tags, sets ticket status.
10. **Triggers follow-up actions** such as snooze workflows for automated check-ins.

<Note>
  Every step is an **idempotent Temporal activity**. The workflow itself is deterministic
  orchestration — all side effects live in activities. This is what makes a run replayable and
  lets a worker crash mid-flight without duplicating external calls.
</Note>

## Workspace crates

| Crate                  | Responsibility                                                     |
| ---------------------- | ------------------------------------------------------------------ |
| `engine-types`         | Shared request/result and workflow payload models                  |
| `engine-config`        | Runtime config from environment                                    |
| `engine-observability` | Tracing setup                                                      |
| `engine-control-plane` | Multi-tenant brand control plane, migrations, outbox dispatch, DLQ |
| `engine-activities`    | Temporal activities                                                |
| `engine-workflows`     | Deterministic workflow orchestration                               |
| `engine-worker`        | Temporal worker process                                            |
| `engine-api`           | Axum API for workflow execution and control-plane endpoints        |
| `engine-tui`           | Terminal UI                                                        |

## Binaries

```bash theme={null}
cargo run -p engine-api
cargo run -p engine-worker
cargo run -p engine-control-plane --bin dispatcher
cargo run -p engine-control-plane --bin migrate
cargo run -p engine-control-plane --bin import_brand_manifests -- --tenant-id <uuid>
cargo run -p engine-control-plane --bin onboard_brand -- --tenant-id <uuid> --brand <slug>
```

## Mission Control

The React dashboard in `dashboard/` is the operator mission control for the engine. It defaults
to the production engine API; override with `VITE_ENGINE_API_BASE` to point it elsewhere. In
local development Vite proxies API calls to the production host unless `ENGINE_API_PROXY_TARGET`
is set.

<Warning>
  That local-development default means a dashboard running on your machine talks to **production**
  unless you set `ENGINE_API_PROXY_TARGET`. Set it before doing anything destructive.
</Warning>

## Next

<CardGroup cols={2}>
  <Card title="ResponseAutomationV2" icon="diagram-project" href="/next-temporal/workflow">
    The workflow phases, signals, and tool-use loop.
  </Card>

  <Card title="Control plane" icon="server" href="/next-temporal/control-plane">
    Multi-tenancy, outbox/DLQ, progressive migration.
  </Card>

  <Card title="Configuration" icon="sliders" href="/next-temporal/configuration">
    AutomationConfig, skip rules, escalation, environment.
  </Card>

  <Card title="Operations" icon="gauge" href="/next-temporal/operations">
    Deployment, metrics, health probes, security.
  </Card>
</CardGroup>