> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beaconrevenue.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Capacity — what you can actually serve
> The six inputs behind a capacity read, how utilization and the ceiling are worked out, when to start adding, and the two places this model deliberately stops.
Capacity is not headcount. A team of ten with two people ramping and one on a long lead time is not a team of ten, and a growth plan built on the headline number is built on a figure nobody can actually deploy.
A designed model. No surface serves a capacity read from your data yet.
## Six inputs
| Input | What it is |
| - | - |
| Supply | How much you have, counted as what can actually be deployed |
| Lead time | How long it takes to add more, from decision to arrival |
| Ramp | How long after arrival before it is fully productive |
| Utilization | How much of the supply is in use |
| Ceiling | The most this pool can carry before quality degrades |
| Cost | What the pool costs — a reference figure only |
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](/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
Where demand on a pool comes from.
The cost side, at account level.
Why a hiring read never acts on its own.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.