concept

DAG Dependency

The declared edge stating that one task must not start until another has succeeded, and the difference between that and merely running later.

A schedule says when something runs. A dependency says what must be true before it runs. Estates built on schedules alone — the extract at two, the transform at three, the report at four — work until the extract takes ninety minutes, at which point the transform runs against yesterday's data and the report is wrong without being late.

The failure is silent, which is what makes it dangerous: nothing errors, the numbers are simply stale, and the discovery usually comes from a business user weeks later.

Declaring dependencies makes the orchestrator responsible for ordering. The transform waits for the extract's success, not for three o'clock. The interesting design work is then in what "success" means — a task that completes having processed zero rows because the source was empty is a candidate for failure rather than success — and in cross-DAG dependencies, where one pipeline's output feeds another owned by a different team. Those are the edges most often left implicit, and they are exactly where the staleness enters.