What Is Phantom Capacity in Scheduling?

Phantom capacity is schedulable hours that no physical machine actually backs, created when a machine pool or resource group is treated as a capacity-bearing work center in its own right rather than as a routing label over real machines. It is the scheduling equivalent of booking a meeting into "Conference Rooms" as if that were a fourth room, when only three physical rooms exist: the calendar accepts the booking, but there is nowhere to hold the meeting.

This entry is part of the EDGEBIC by User Solutions glossary; the broader dictionary lives in the manufacturing glossary.

How It Happens

A scheduling engine gives every work center that has shifts a real capacity bucket: so many hours per shift, per day, that jobs can be booked into. That is correct and necessary for physical machines.

The trap appears when a pool of interchangeable machines is also modeled as a work center. Now the engine seeds a bucket for the pool and a bucket for each machine inside it. The pool's hours are supplied by the very same machines that already have their own buckets, so those hours exist twice in the engine's accounting. Schedule a job into the pool's bucket, and another job into a member's bucket for the same window, and the plan has committed the same machine-hour to two jobs. On paper it looks fine. On the floor, one job waits.

Why It Matters

Phantom capacity is dangerous precisely because it is invisible until execution. The schedule looks feasible, due dates look achievable, utilization looks healthy, and then production falls behind for no reason a planner can find in the plan. The whole point of finite capacity scheduling is to refuse to book more hours than a machine actually has (see finite versus infinite capacity scheduling). A double-counted pool quietly reintroduces the infinite-capacity problem the shop bought a scheduler to avoid.

The Fix: A Pool With No Capacity of Its Own

The clean solution is to make the machine pool a routing concept, not a machine. The pool is a name a routing step can target, and it holds no hours at all. Only the physical members hold capacity. Any total a dashboard shows for the pool is computed on the spot as the sum of its members' hours, purely for display.

Because the pool never enters the engine's set of capacity-bearing work centers, there is no extra bucket to double-count. When a step routed to the pool is scheduled, the engine resolves it to a real member and books against that member's actual capacity. The plan can only ever promise hours a real machine supplies.

How EDGEBIC Uses It

In EDGEBIC, a work center group is exactly this zero-capacity pool. A routing step can target the MILLING group instead of a specific mill, but the group itself holds no hours and never joins the scheduler's work-center collection. Only the member mills carry capacity, and any pool figure you see on a Resource Calendar or dashboard is a live sum of those members, computed for display.

At schedule time, the engine performs a group explosion: it converts the group-bound step into a real member plus one candidate per remaining member, each carrying its own hours, and books against real buckets. This is the structural reason a group is a separate entity rather than a special kind of work center. Making it a work-center subtype is exactly what would create phantom capacity, so the design forbids it. For where groups sit in the wider pipeline, see the work center groups overview and the scheduling engine guide. A different way a bucket can show hours nothing real stands behind is a stale capacity reservation, a booking an earlier run left behind for work that never started.