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

# PIPE-7 — One job entry shape, published identically by every surface

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

Three surfaces publish a job. They publish one key set in one order, because two copies of a formatter had already drifted apart once.

## The rule

> **Normative.** This is the rule.
>
> 1. Every surface that publishes a job entry emits exactly the keys `id`, `label`, `status`, `priority`, `node_id`, `pipeline_id`, `created_at`, `started`, `completed`, `execution_time_us`, `retry_count`, `max_retries`, `error_message`, `input_data`, `output_data`, `metadata`, `timestamp`, in that order: the single-job read, a run's job list and the jobs inside a run's full document.
>
> 2. `pipeline_id` is a string or null; a stored value that is neither an integer nor a string is discarded rather than published under a key documented as a string, and the discard is reported, because only something outside the implementation writes a non-scalar there.
>
> 3. `execution_time_us` prefers the precise duration recorded for the job and otherwise derives it from the start and completion stamps at second granularity, and is null for a job that never completed; the same value must be published for a job by `node_statuses` and by the job entry, computed once, so the two payloads read side by side can never disagree numerically.

## Related rules

- Names: PIPE-4, PIPE-5
- Referenced by: PIPE-4, PIPE-5

---

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.