What Is an Operator-Hours Ledger in Scheduling? EDGEBIC Definition

An operator-hours ledger in scheduling is the running tally the engine keeps of how many hours each operator is already booked on each shift date during a scheduling run, keyed by operator, date, and shift, so that no operator is ever booked beyond that shift's available hours. It is rebuilt fresh on every run and never stored as permanent state, so it always reflects the plan currently being computed rather than history.

This entry is part of the EDGEBIC by User Solutions glossary series; for the wider vocabulary of scheduling, see the manufacturing glossary. The ledger works hand in hand with an operator's attend fraction, which determines how many hours a given step actually books against a person.

How an Operator-Hours Ledger Works

When the engine schedules people alongside machines, it needs a way to know how much of each operator's day is already spoken for. The operator-hours ledger is that memory. As the run places skilled steps, each booking adds hours to the operator, date, and shift cell it lands in, and the engine consults the cell before making the next booking.

The rule the ledger enforces is deliberately simple: the total hours booked against any one operator on any one shift can never exceed that shift's hours. A person with eight hours on Monday has eight hours, full stop, no matter how many skills they hold or how many machines would like to use them. Once those hours are consumed, the operator is full for that shift and further steps that need them wait for the next window with hours to spare.

Two design choices keep the ledger honest. First, it books hours as quantities, not as wall-clock intervals, so two steps can overlap in time within a shift as long as their combined hours fit. Second, it is run-scoped: it is rebuilt from scratch every scheduling run and never persisted, so it always reflects the crew bookings of the current plan and never carries stale state between runs. It is a planning structure, not a payroll or actuals record.

A Concrete Example

Take Joe, who works an eight-hour Monday shift and happens to hold five certifications. Five different steps across the plant could all use Joe on Monday, and without any hours accounting the engine might cheerfully book him onto all five, planning far more work than one person can do.

The operator-hours ledger prevents exactly that. As the run books Joe onto the first step, his Monday cell accumulates hours. It keeps accumulating through the second and third steps until the total reaches eight. At that point Joe's Monday is full. The remaining steps that need him do not vanish and do not overbook him; they slide to the next window where Joe still has unbooked hours, perhaps Tuesday, or wait for a colleague who shares the skill.

Joe holding five skills never turned his eight-hour day into forty hours. The ledger held the line at the one number that matters: the hours actually in his shift.

How EDGEBIC Uses It

The operator-hours ledger is an internal, run-scoped part of how the engine schedules labor.

• It caps bookings so no operator, date, and shift combination is ever booked beyond the shift's available hours, whatever else is competing for that person.
• It books hours, not intervals, so overlapping steps within a shift are legal as long as their combined hours fit the shift.
• It is rebuilt every run and never persisted, so it always mirrors the current plan and never leaks stale bookings into a later run.

The bookings the ledger constrains are the same ones surfaced to planners as schedule operator assignments, the crew rows for each scheduled operation. When you need to reserve one named person for a step rather than share the qualified pool, that is an operator pin, which still books its hours through this ledger.