FlowDrop Workflow Specification 1.0-draft

One job entry shape, published identically by every surface

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.
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · PIPE-7 · changed in spec 1.0