The Auto-Filled Actuals Badge Explained in EDGEBIC

In EDGEBIC by User Solutions, the auto-filled badge marks an actuals row whose hours were written by the system from the plan rather than observed by a person on the floor. It is a small pill in the Source column of the Log Actuals grid, and it answers a question every planner eventually asks about a suspiciously tidy row: did somebody actually see this happen, or did we assume it?

Provenance is not a luxury in shop floor data collection. Once a number lands in the actuals record it drives reschedules, progress percentages, and variance reports, and it does so regardless of where it came from. The badge is how EDGEBIC keeps assumed data visible instead of letting it blend in with the real thing.

Where Auto-Filled Rows Come From

There is one main source, and it is a shortcut somebody deliberately took.

An operator walks up to a machine and starts an operation that sits third in its job's routing. The first two steps have no logged actuals: maybe the earlier operator forgot to punch, maybe the work genuinely ran but nobody recorded it. EDGEBIC notices and shows a warning before the run punch opens: earlier steps in this job have no actual dates.

The operator has two honest choices. Walk away, find out what really happened upstream, and get it logged. Or acknowledge the warning and continue, in which case EDGEBIC fills the missing upstream steps from their planned start and end dates so the job is not left with a hole in its history. That second path is the backfill, and everything it writes is badged. The full mechanics of that prompt are covered in the prior-step actuals gate at the kiosk.

The other source is mirrored data. When a routing step runs on a parallel work center, the sibling row's hours are copied from the primary rather than observed independently, and they are tagged the same way for the same reason. See why a parallel step's actuals follow the primary.

What the Badge Actually Tells You

The important nuance is that a badged number is not wrong. It is the plan's number, which is the best available guess at what happened when nobody recorded it. It is simply not evidence. A shop that treats it as evidence ends up quoting future jobs against times nobody ever measured.

The Badge Clears the Moment You Edit

This behavior is worth calling out because it is easy to miss. The badge is not a permanent stamp that requires an administrator to remove. Type a new value into the hours or pieces cell and the badge disappears immediately, before the save, and the record is retagged as human-entered when it commits.

That live response is deliberate. A planner working down a list of badged rows gets instant confirmation that each one has been dealt with, and the remaining badges are an honest to-do list. Nobody has to remember which rows they already fixed.

A Worked Example

Job with a four-step routing. The kiosk operator at step three acknowledges the prior-step warning on Wednesday morning.

Steps 10 and 20 are now marked started and complete on their planned dates, so the reschedule that night plans step 40 forward from step 30's real finish, and it does not try to move steps 10 or 20 at all. The plan is coherent. The history is half-invented, and the two badges say so plainly.

Thursday morning the planner asks the saw operator what really happened. The answer: the saw ran Monday, not Tuesday, and took 4.2 hours, not 3.0. That correction goes into the grid, the badge clears, and the shop's cycle-time data on that part becomes worth something.

Why This Matters Beyond Tidiness

Three concrete consequences follow from knowing which rows are assumed.

Quoting. Estimated hours on future jobs are only as good as the observed hours behind them. Backfilled rows always match the plan exactly, so a data set full of them will confirm whatever the routing already said and tell you nothing new.

Variance analysis. A plan-versus-actual report reading badged rows shows zero variance on those steps, because plan and actual are literally the same number. Real variance is diluted by the fake zeros.

Trust. When a supervisor challenges a number, being able to say "that one came from a punch, this one we filled in" ends the argument in seconds. Being unable to say it turns every review into a debate about the data instead of the operation. That is the same reason actuals are immutable and every supervisor correction is append-only.

Keeping the Badges Rare

The badge is a symptom, not the disease. Its frequency is a direct measure of punch discipline on your floor. A shop where operators punch in and out of every operation will see it almost never. A shop where the kiosk is used casually will see it constantly, and its schedule will drift accordingly.

The cure is the daily rhythm rather than a setting: punch at the start of every operation, punch the pauses with a reason, punch complete at the end, and let the planner reschedule on a fixed cadence. That cadence is described in the daily rhythm of a kiosk-run shop.

The Bottom Line

The auto-filled badge separates what your shop observed from what EDGEBIC inferred. Backfilled and mirrored rows behave like any other actuals in the plan, so the badge is your only signal that a number is a plan value wearing a history's clothes. Replace badged rows with real values while the shift still remembers, and treat a rising badge count as a floor-habit alarm. See the whole execution loop in the shop floor execution guide, or explore EDGEBIC.