What Is a Prior Operations Safety Prompt in Scheduling?

A prior operations safety prompt is a warning raised when actuals are recorded on an operation while earlier operations in the same job still have none, offering either to fill the gap from the plan or to send you back to record it properly. It exists because a routing is physically sequential: a job cannot have reached the fourth step without having passed through the first three, so a missing record is always a reporting gap rather than work that did not happen. EDGEBIC by User Solutions raises the same prompt from the planner's logging dialog, from a saved board drag, and from the shop floor terminal.

How it works

Every path that writes actuals passes through the same check. Before the write is committed, the job's routing is examined for operations that sit earlier in the sequence than the one being logged and that carry no recorded start.

If there are none, nothing happens. The overwhelming majority of saves fall here, because logging in sequence is the normal case.

If there are some, the save pauses. The prompt names the work centers that are missing actuals, so the question being asked is concrete rather than abstract. It is a decision point, not a notification.

Accepting fills the gap from the plan. Each missing operation has its planned dates copied into its actuals. The job's record becomes continuous and the original save completes. Crucially, the filled values are tagged as system-filled rather than entered, so they remain identifiable afterwards on the logging grid and in reporting. The tag clears the moment someone edits the value, which is the right behavior: an edited value is a real one.

Canceling writes nothing. The save is abandoned, the operation stays as it was, and the planner is free to go and record the earlier steps properly before trying again.

The reason the check is worth the interruption is what happens downstream. Rescheduling determines where a job really is by finding the latest operation carrying any actual and treating that as the point reality has reached. A gap before that point forces the engine to reason about a job that appears to have skipped work, and the reasoning it does is necessarily an inference. Making the gap explicit at logging time, while someone still remembers the week in question, converts a guess made by software into a decision made by a person.

A concrete example

A job runs saw, mill, paint, then inspection. Saw and mill ran last week and the paperwork was never entered. Paint ran yesterday and the operator is logging it now.

The save is attempted. The check finds saw and mill with no recorded start, and the prompt appears naming both work centers.

The operator knows the mill's real dates because the run sheet is on the bench, but nobody can find the saw's. So the correct move is to cancel, log the mill from the run sheet, and try paint again. This time only saw is missing. The operator accepts the backfill, saw takes its planned dates tagged as system-filled, and paint's actuals are written.

The record now reads: saw estimated from plan, mill measured, paint measured. Anyone reading it later can see exactly which of those three numbers is worth anything, which is a materially better outcome than three numbers that all look the same.

Had the operator accepted the backfill on the first prompt, both saw and mill would carry planned dates, the mill's real variance would be gone, and a report a month later would show two steps that ran precisely to plan. The prompt did not prevent that; it made it a choice.

How EDGEBIC uses it

The prompt is one of the few places where EDGEBIC interrupts rather than warns and continues, and the reason is that the alternative is irreversible. A schedule with a hole in its actuals is not obviously wrong at a glance; it looks like a job that has partly run. Discovering the hole later usually means discovering it during a reschedule that produced a strange date. Interrupting at the point of writing is the cheapest possible moment. How the prompt behaves on the board is covered in EDGEBIC Gantt safety prompts prior operations.

Backfilled values are not silently indistinguishable from measured ones. They carry a provenance marker described in what is an actuals entry source in shop floor tracking, and the badge that surfaces it is covered in the auto-filled actuals badge explained. Reading a run of zero-variance operations correctly depends entirely on noticing that marker.

The reason the engine cares is the resume logic described in what is the next step start date in rescheduling, and the inference it would otherwise have to make is described in what is an inferred completion in rescheduling. The proper alternative to backfilling is capturing actuals where the work happens, which is what what is a shop floor kiosk covers.

The takeaway

A prior operations safety prompt turns an invisible reporting gap into an explicit choice at the only moment when someone still has the information to make it well. The rule of thumb is short: cancel when the real numbers are recoverable, accept when they are not, and never let the tag on a backfilled value go unread. A shop that sees this prompt every day does not have a prompt problem, it has a logging-coverage problem, and the prompt is the thing telling it so. For the wider vocabulary see the manufacturing glossary, and for the product itself see EDGEBIC.