What Is a Dependency Violation in Scheduling?

A dependency violation is when a routing step is scheduled to start before the step it depends on has finished, so a downstream operation begins on work that is not yet ready. Within a single job it means step N+1 starts before step N ends, and it is flagged as a warning because a raw overlap usually signals a sequencing fault, though deliberate lot streaming is an intentional overlap that the check excludes. It is the anomaly that catches a routing whose precedence got lost.

This entry is part of the EDGEBIC glossary; see the manufacturing glossary for the wider vocabulary and the scheduling anomaly definition for the family.

How a Dependency Violation Works

A routing is an ordered chain of operations: mill, then drill, then finish, then inspect. Each step depends on the one before it, and the schedule must respect that order. The engine builds the chain forward, placing each step only after its predecessor's end time, so a freshly generated plan should never violate its own precedence.

The dependency check reads the plan and, within each job, compares consecutive steps. If a later step's start time falls before the earlier step's end time, the two overlap, and the downstream operation is scheduled to work on material the upstream step has not finished producing. That raw overlap is the violation, reported as a warning so the planner can look at why the order broke.

It is a warning rather than a critical error for one important reason: not all overlap is wrong. Lot streaming deliberately overlaps operations, and the check has to distinguish an intentional overlap from a broken one.

When Overlap Is Legitimate

Overlapping two operations can be exactly right. In lot streaming, partial batches move downstream as they are finished, so the next station starts while the current one is still running. A tray of 25 machined parts can move to deburring while the lathe keeps turning the remaining 175. That overlap compresses the schedule and is a deliberate planning choice.

The dependency check knows this. It excludes any step configured with a start-to-start overlap (downstream begins a set number of hours after upstream starts) or a piece-count transfer batch (downstream begins once a set number of pieces exist). When either is set, the overlap is intentional and not flagged. A violation is only reported when steps overlap with no such setting behind them, which means the precedence was genuinely lost, not deliberately relaxed.

So the check reads as: this downstream step starts before its predecessor ends, and nothing in the routing says that overlap was meant to happen.

This is why a dependency violation is a warning rather than a critical error, unlike a collision or an inversion. The two of those describe something physically impossible; a dependency overlap describes something that might be exactly what the planner wanted (streaming) or might be a broken link. The check cannot always tell intent from data alone once you strip out the streaming settings it knows about, so it surfaces the overlap and leaves the judgment to the planner. Most violations turn out to be missing links, but the warning severity respects that some are deliberate.

A Concrete Example

A job routes through milling and then drilling. Milling is scheduled 8 a.m. to noon; drilling is scheduled to start at 11 a.m., an hour before milling finishes. The routing has no overlap or transfer-batch setting on the milling step.

The dependency check flags a violation: drilling starts on parts milling has not yet produced. The planner opens the routing and finds the link between milling and drilling was never set, so the engine scheduled the two steps independently and they happened to overlap. Correcting the successor link so milling points to drilling, then re-running the schedule, places drilling after milling's noon end. The warning clears, and the job now runs in its correct order.

Had the planner actually intended the overlap, they would have set a start-to-start overlap or a transfer-batch size on milling instead, and the check would have excluded the pair from the start.

How EDGEBIC Flags Dependency Violations

In EDGEBIC, dependency checking lives in the Scheduler Anomalies report under the Reports menu, in the dependency-violation category. Run it per job or plant-wide. The summary strip shows the dependency chips: green when every job's steps run in order, amber when an unexplained overlap is found. Clicking a flagged row opens the job so you can see which two steps overlap and by how much.

The engine prevents most violations by ordering operations from the routing's dependency links before it schedules them. When a violation still appears, it points at the routing configuration (a missing or broken link between two steps) rather than an allocation mistake. For how the engine builds and honors that order, see how EDGEBIC orders operations with dependency graphs, and for the common setup slips, dependency and sequencing mistakes.

If the overlap you see is meant to be lot streaming, the transfer batch definition covers how to configure the intentional version so the check treats it correctly. For the full validation catalog, read what the EDGEBIC anomaly checks actually look for and the schedule diagnostics overview.

A plan with no dependency violations is one where every job does its steps in the order the routing demands, and any overlap that remains is overlap you asked for. That is the difference between a compressed schedule and a broken one.