The AI Platform

    Workflow Run History

    Workflow definitions and workflow runs are separate records.

    The workflow definition CRDT stores the editable graph: metadata, nodes, edges, variables, and input schema. It answers "what should run?" and is saved only when the editor commits a workflow snapshot.

    The workflowRuns CRDT stores execution telemetry: queued, running, terminal status, runner lease, per-node records, structured logs, and artifact references. It answers "what happened in this run?" and changes during execution.

    Small local payloads can remain inline in workflowRuns for fast inspection. Large payloads and cloud-runner payloads are written to R2 using deterministic keys:

    workflow-runs/{workspaceId}/{workflowId}/{runId}/...

    The CRDT keeps only the artifact reference, byte length, hash, content type, and preview, so run sync does not carry unbounded input/output data.

    On desktop, the same run records are also mirrored into the app's local SQLite store through the CRDT persistence layer. That local mirror powers offline inspection and fast reopen behavior; it is a cache of the workflowRuns CRDT, not a separate source of truth.

    Runner ownership follows a queue and claim flow:

    1. A run is first recorded as queued.
    2. A runner claims it by writing running with runner kind, runner id, version, attempt, and lease expiration.
    3. Heartbeats renew the lease while work is in progress.
    4. The final record becomes succeeded, failed, or cancelled.

    Cloud APIs authorize run and artifact access through workspace membership and Cerbos workflow actions. The Durable Object socket receives authenticated user/workspace context from the API layer; clients cannot gain access by supplying only userId or peerId query strings.