Pipeline execution flow

A Loom pipeline is the execution window inside a local run where eligible jobs are scheduled, run, and then either allow downstream progress or block it. The current runtime makes that flow visible through explicit phase boundaries, so the docs and the logs now describe the same lifecycle.

Use this page when you want to answer:

• When does the pipeline actually begin?
• What job work can happen inside it?
• What causes downstream work to stop?

The current pipeline envelope

The pipeline itself is the pipeline.execute phase. Loom also wraps it in run-scoped phases:

Phase	Scope	What it means
run.bootstrap	Run	Loom captured run context and workspace attribution
run.pipeline_execute	Run	Outer envelope around pipeline work
pipeline.execute	Pipeline	The actual pipeline body
run.finalize	Run	Loom writes final contract artifacts after pipeline completion

What happens inside pipeline.execute

Inside the pipeline boundary, Loom repeatedly:

1. Selects work that is now eligible
2. Runs those jobs
3. Re-evaluates whether more work can proceed

Each runnable job then emits its own job-level phases, covered in Job execution flow.

What controls whether work can start

Three things still matter most:

Control	What to rely on
Stage order	Earlier stages gate later ones
Explicit dependencies	Jobs wait for required upstream jobs
Upstream result	Failed blocking work prevents dependent downstream work from starting

The phase rollout did not change those rules. It made them observable.

What a blocking failure does

When a blocking job fails:

• The failed job closes with status: "failed"
• Jobs that already finished keep their existing result
• Downstream work that cannot proceed is not run
• The pipeline still emits a clean pipeline.execute finish boundary

That last point matters for diagnostics: the pipeline does not just stop emitting. It closes the phase and writes the pointer documents you need.

How this shows up in runtime artifacts

Artifact	What you see
pipeline/events.jsonl	phase_start and phase_finish for pipeline.execute
pipeline/summary.json	Final pipeline status, exit_code, duration_ms, and optional error
pipeline/manifest.json	Job roster plus failing_job_id and failing_job_manifest_path on failure
phase-report.json	Whether required run and pipeline boundaries were emitted in the right order

Current behavior to rely on

Design and troubleshooting guidance for the current runtime:

• The pipeline is represented by one pipeline.execute boundary per run.
• Job work happens inside that boundary, not before or after it.
• A blocking failure stops dependent downstream work, but Loom still closes the pipeline cleanly.
• run.finalize happens after pipeline.execute completes and is where final contract artifacts are written.

If you need the per-job phase order inside that pipeline, continue to Job execution flow.