A designed model. No surface serves a capacity read from your data yet.
Six inputs
The same six describe any constrained pool: implementation people, support hours, compute. They are the whole vocabulary — nothing gets a seventh.
Utilization and the ceiling are different questions
Utilization is how busy the pool is. The ceiling is how busy it can be before throughput stops improving — and it is rarely 100%. A pool run at its ceiling has no absorption left for anything unplanned, so the useful reading is not “are we at capacity” but “where are we against the band this pool works well in”.The gap, and when to act on it
The gap read says whether you are over or under, and how long you have before the pool saturates at the current rate. That second half is the point. If it takes four months to add capacity and ramp it, a shortfall four months out is already a decision — and one that reads as comfortable if you only look at utilization today. Beacon surfaces it as a proposal with the lead time and ramp stated; it does not act on it. See Proposals, not actions.Where this stops
No manufacturing or inventory planning. This models constrained service capacity. Physical production and stock are a different problem and Beacon does not pretend otherwise. The cost figure is a reference. It is here so a capacity read has a rough shape attached. The canonical cost of a team or a pool lives in your finance system, and where the two differ, yours is right.Related
How your lifecycles connect
Where demand on a pool comes from.
What a customer costs and what they return
The cost side, at account level.
Proposals, not actions
Why a hiring read never acts on its own.