What Is a Downstream Changed Flag in Scheduling?

A downstream changed flag is a marker placed on the later operations of a job when an earlier operation in that job is saved to a new position, indicating that those operations may now be out of sequence. It records a possibility, not a fact, and it changes nothing: no dates move, no capacity shifts, no report reads differently. In EDGEBIC by User Solutions it appears as one of the operation state colors on the scheduling board and clears automatically once the job has been re-planned.

How it works

When an operation is saved to a new position, the board looks at the rest of that job and marks every operation that comes after it. The logic is deliberately simple, because the flag is not trying to be a verdict.

It is scoped to the job. Only later operations in the same job are flagged. Other jobs sharing the same machines are not marked, even though they may be more affected in practice, because the relationship the flag describes is a routing dependency rather than a capacity one.

It is visual only. This is the property most worth internalizing. The flag writes nothing. A flagged operation still holds the dates it held a moment ago, still occupies the capacity it occupied, and still appears in a dispatch list exactly as before. Nothing about the plan has been recalculated; the board is simply pointing at the operations whose relationship to their predecessor has just been disturbed.

It is conservative. The flag fires whenever an upstream operation moved, without checking whether the move actually broke anything. An operation with three days of slack gets flagged for a two hour upstream slip just as a tightly coupled one does. That is a design decision rather than an oversight: computing whether each downstream operation is genuinely infeasible would mean running the scheduling engine, and if you are going to run the engine you may as well let it fix the plan rather than describe it.

It clears by being resolved. Because the flag is derived from the disturbed relationship rather than stored as a durable property, re-planning the job removes the condition that produced it. On the next reload the flag is simply not there. It does not need dismissing, and there is nothing to acknowledge.

The whole design follows from one intent: a manual override should never quietly leave a mess. Without the flag, dragging an operation forward would produce a board where a later operation now overlaps its predecessor's new end, looking perfectly normal in every color and every column, and staying that way until someone noticed on the floor.

A concrete example

A job runs saw, mill, then paint. The engine has planned mill for Monday 08:00 to Tuesday 12:00, and paint for Tuesday 13:00.

The mill was down Monday, so the planner drags the mill bar to start Tuesday 08:00 and saves. The mill now runs Tuesday 08:00 to Wednesday 12:00.

Paint is immediately flagged. It is still planned for Tuesday 13:00, and it still holds Tuesday 13:00 on the booth, but that time now falls inside the mill's new window. The flag is saying so. Nothing about paint has changed and nothing will until somebody decides what should happen.

The planner presses re-schedule with the job in scope. The engine keeps the mill's recorded start, plans the mill's remaining hours forward, and re-places paint at the first slot the booth actually has free after the mill ends. That turns out to be Wednesday 13:00, because two other jobs already hold the booth on Wednesday morning. Paint's flag clears on reload.

Note what the flag did and did not do across that sequence. It did not move paint, calculate a new date, or free the booth slot paint was holding. It made a single sentence visible: this operation may no longer be in sequence. Everything after that was the engine's work, triggered by a planner who now knew there was something to trigger.

How EDGEBIC uses it

The flag is one half of the override-and-warn contract. EDGEBIC will let a planner move an operation almost anywhere and warns rather than blocks, on the principle that the person at the screen often knows something the data does not. The flag is what stops that permissiveness from being careless: the consequence of the move is surfaced immediately, in the same view, without the planner having to go looking. How the ripple appears in practice is covered in how drag drop shows the downstream ripple.

It arrives as one of the board's operation colors, which are described in what is an operation state in a production gantt, and it is the only one of them that describes a possibility rather than a record. Because it is scoped to a job, the standard response is a run scoped the same way: see what is a targeted reschedule.

The flag also has a natural upper bound worth knowing. It never fires from a staged change, only from a saved one, because staged edits are visible only to the person making them. That distinction is described in what is a pending schedule change in scheduling. For the general dependency relationships the flag is guarding, see how EDGEBIC orders operations dependency graphs.

The takeaway

A downstream changed flag is the schedule saying "you should look at this," and nothing stronger. Reading it as a data change leads people to hunt for something that moved and find nothing; reading it as a to-do list leads them to the one action that resolves it, which is letting the engine re-plan the job. The habit worth building is scanning for leftover flags after a run, since a flag that survives a reschedule usually means that operation sat outside the run's scope and still needs attention. For the wider vocabulary see the manufacturing glossary, and for the product itself see EDGEBIC.