---
id: PIPE-1
family: RT-PIPE
level: core
profiles: [runtime]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-pipe/pipe-1
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# PIPE-1 — Run status is read from persisted state, on two routes and one envelope

*RT-PIPE (Part II) · level: core · profiles: runtime · added in 1.0*

The live picture of a run is whatever has been persisted for it, not what some in-memory tracker happens to remember. A poll therefore answers the same value to every caller, including one served by a process that has just started.

## The rule

> **Normative.** This is the rule.
>
> 1. A run's status is published by two reads: the full pipeline document and a lightweight status document.
>
> 2. Both answer the standard `{success: true, data}` envelope, publish the persisted lifecycle value verbatim as `data.status`, and answer `404` with `{success: false, error}` for a run that does not exist and `403` for one the caller may not view.
>
> 3. The full document adds `node_statuses`, `jobs`, `job_status_summary` and `execution_data` alongside `id`, `name`, `description`, `createdAt`, `lastExecuted`, `executionCount` and `timestamp`; the lightweight document carries `id`, `status`, `createdAt`, `lastExecuted`, `pendingInterrupt` and `pausedReason` and must not carry the jobs payload.
>
> 4. Both read persisted state only, so a status written outside the request path is what the next poll returns.

## Related rules

- Referenced by: PIPE-9

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.