Office Tower Core Layout: 44-Inch Stairs vs 300-Foot Sprinklered Travel

The guide compares stair-width and travel-distance constraints for sprinklered office towers.

It also sets a pre-run check for required stair width.

How the Two Code Constraints Bind

Stair width is a capacity constraint: under IBC 1005.3.1, each occupant requires 0.3 inch of stair width, so required stair width equals occupant load per floor multiplied by 0.3 inch, rounded up to the nearest 0.1 inch. A 500-occupant floor therefore needs 150 inches of total stair width. That requirement scales with occupant count and density; it does not scale with floor-plate length or width.

Travel distance is a geometry constraint: the sprinklered 300-foot limit in IBC 1006.2.1 caps the path from any point to an exit stair. It scales with floor-plate depth, core placement, and the distance between stairs, not with how many people occupy the floor. It is most likely to bind on deep or narrow plates where the farthest point is beyond the limit, so verify the limit against the code edition adopted in your jurisdiction.

The two constraints act on different variables. Required width is an aggregate: it can be met by one wide stair or several narrower ones, provided each stair also meets the 44-inch minimum for occupant loads of 50 or more under IBC 1005.7.1. Travel distance is a local maximum: it is set by the worst single point on the floor, and adding width to a stair does not shorten anyone's path. A layout can therefore pass the 300-foot test while failing egress capacity, or provide enough width while leaving a remote corner beyond the travel limit.

Because width grows with occupant load and travel distance grows with plate depth, the width check is the one that usually fails first in a dense office tower; the 300-foot limit is almost never the binding constraint. In a generative workflow, compute required width before testing geometry: multiply occupant load per floor by 0.3 inch, round up to 0.1 inch, sum the proposed stair widths, and reject the layout if the total is smaller. Only layouts that clear that capacity check should be evaluated for travel distance.

This ordering matters because a capacity shortfall is an aggregate deficit: if total width is short, rearranging the same stairs does not fix it without adding width or stairs. A travel-distance failure, by contrast, can sometimes be fixed by moving a core or adding an exit without changing total capacity. Compute width first, then use travel distance to place and test the stairs.

The Evidence: What the Code Actually Says

Before relying on any generative core run, the first task is not the shape of the layout, but the text of the code itself. The only verification that belongs here is to confirm the specific code section numbers and the verification method for local amendments. For example, IBC 1005.7.1 sets the 44-inch minimum stair width for occupant loads of 50 or more (and 36 inches below 50), but amendments can shift numbering between editions. Because of that, the exact section number must be verified against the code edition adopted by your local jurisdiction, not the edition cited in a template or a previous project.

In parallel, IBC 1006.2.1 permits up to 300 feet of travel distance to an exit in sprinklered buildings (versus 200 feet unsprinklered for most B occupancies). However, that allowance is only valid if the building is fully NFPA 13-sprinklered. A partial system, a different sprinkler standard, or a local amendment can remove that allowance entirely. For that reason, the sprinkler standard and its scope must be confirmed in writing for the project before applying the 300-foot figure to any path.

These are two separate checks, and neither can substitute for the other. Pulling the adopted edition text for both sections, noting any renumbering, and recording the basis for each allowance creates a traceable record for review. This is a documentation step, not an assumption. Without that record, any later comparison between the two constraints has no verifiable basis, regardless of how precise the model inputs may appear.

As James Lin points out in the dev.to analysis, Stop Sprinkling AI Everywhere: The Real Constraint Is Where Leverage Lives, the operators who extract leverage aim their tools at one or two constraints that actually gate access, then deliberately skip the rest. Applied to code review, that same discipline means locking these checks to the exact adopted text first. Only after those section numbers and allowances are confirmed in writing should any capacity math be allowed to proceed.

Options Compared: Core Layout Strategies

Among stair-count configurations, the comparison comes down to total stair width versus the number of shafts required. With each stair at forty-four inches, two stairs provide a combined width that reaches capacity at the load where required width equals the product of occupant load and the width-per-occupant factor rounded up to the nearest tenth of an inch. Three forty-four-inch stairs increase that combined width further, and four increase it again, but each added stair is its own shaft that must be placed within the core regardless of whether the added capacity is used. With that in mind, the winner for any layout where the occupant load does not demand more than the capacity of two forty-four-inch stairs is the two-stair configuration, because adding a third stair delivers no capacity benefit at that load while forcing the placement of an entirely separate shaft.

One method to preserve the exit pair without taking up two separate shafts is the scissor stair, which interlocks two forty-four-inch stairs into one shaft. This consolidation can halve the core footprint for those two exits, but it does not bypass the requirement that the two exits must be separated per IBC 1007.1.1. For a generative core run, that separation check must remain in place even when the vertical enclosures are interlocked, so the footprint savings cannot be assumed to remove that obligation.

In practice, the decision is not which of these forms is most compact by default, but which one satisfies the rounded-up required width with the fewest shafts. The threshold is crossed only when the math shows two forty-four-inch stairs to be insufficient for the floor's occupant load, at which point three or four become necessary. Until that crossing occurs, the two-stair option remains the one that meets the required capacity without consuming the shaft count that would otherwise be unused. This comparison of stair-count configurations is the only trade-off this section introduces for the core strategy itself.

Costs and Numbers That Matter

A single 44-inch stair, including its shaft, landings, and walls, consumes roughly 90 to 120 square feet on each floor. Across a 20-story tower, that is 1,800 to 2,400 square feet of non-rentable area. Whether that area becomes an additional stair or leasable space is therefore a capital decision: at a mid-market office rent treated as a local market input rather than a code number, the lifetime revenue effect of one extra stair is a six-figure question.

Occupant load is the multiplier behind that decision. Using 150 square feet gross per occupant as a common office planning factor—verify the value against IBC Table 1004.5 in your edition—occupant load is gross floor area divided by 150. That load feeds the stair-width requirement, so a density change can force added stair capacity and added non-rentable footprint. For example, a 10,000-square-foot floor implies about 67 occupants and about 20.1 inches of required stair width before rounding and any code minimum.

The practical sequence is to price the footprint before pricing the layout. Compute occupant load from the planning factor, derive the required stair width, and compare that requirement with the stair capacity already in the core. If the core's total stair width is below the requirement, reject the layout before measuring travel distance. This keeps the generative run from optimizing a floor plate around a stair count that cannot pass capacity review.

Because the 90–120 square foot figure is a planning range and the rent figure is a market input, both should be recalibrated to the project's actual shaft dimensions and local rents. The code-driven part is the occupant-load-to-width relationship; the cost-driven part is how many stair shafts that relationship forces into the core. That is the rentable-area arithmetic: every stair shaft is a recurring charge against leasable area, not a one-time construction cost.

What the Evidence Does Not Establish

The evidence behind the two-stair default is bounded: it supports a sprinklered office tower only where the tested assumptions hold, and it does not establish that the same default survives every height or occupancy mix. Treat it as a starting point, not a universal clearance, and test the boundaries before a generative core run accepts it.

Height is the first boundary. Once a building crosses the high-rise threshold, the adopted code can impose added stair requirements, including smokeproof enclosures and, in some jurisdictions, extra stairs through local amendment. The two-stair default has not been tested above those heights, so check the high-rise chapter of your adopted code before applying this rule to towers over roughly 75 feet.

Occupancy type is the second boundary. Assembly or amenity floors—conference levels, gyms, and similar spaces—use much lower square-footage-per-occupant factors than office floors. Because of that, one amenity floor can push the required stair width beyond what the two-stair default provides. Verify the occupant load for every floor type, not just typical office floors, before accepting a layout.

These are not rare exceptions; they are the cases where a default can fail silently. A core layout that passes on office floors may still fail on an amenity floor or in a taller tower, and the failure will not be visible in a single typical-floor check.

Use the pre-run width check as a gate for each floor and each height condition, not as a one-time office-floor calculation. If any floor type or height condition falls outside the tested default, reject the layout or add stair capacity before generation proceeds.

25,000 Sq Ft Floor Plate

Take a 25,000 sq ft gross floor plate in a fully sprinklered, 20-story office tower and run the checkpoint arithmetic before any generative core run. The first input is the planning factor: office use at 150 sq ft per occupant, which you should verify against IBC Table 1004.5 rather than assume. Dividing 25,000 by 150 gives 167 occupants per floor. That occupant load — not the travel-distance limit — is the number that will drive the core layout, because it feeds directly into the stair-width calculation that governs how many stairs the floor plate must carry.

Checkpoint 2 is where the binding constraint appears. Under IBC 1005.3.1, each occupant requires 0.3 inch of stair width, so 167 occupants × 0.3 inch = 50.1 inches of required stair width per floor. Round that up to the nearest 0.1 inch and the total required width is 50.2 inches. Two 44-inch stairs, the IBC 1005.7.1 minimum for occupant loads of 50 or more, provide 88 inches of total width — a margin of roughly 75% over the 50.2-inch requirement. That is a clear pass, and it tells you something important: on this plate, the stair-width math leaves room to spare, so the generative run should not be adding stairs to satisfy width. The stair count is set by other pressures, and the width check simply confirms the chosen configuration clears the bar.

Checkpoint 3 is travel distance. On a 200 ft × 125 ft plate, the worst-case path from the most remote point to the far stair runs roughly 180–220 ft. Compare that against the 300-foot limit in IBC 1006.2.1 and the plate passes with margin — the travel-distance constraint is not what binds the layout. This is the pattern the thesis predicts: in a sprinklered office tower, the 300-foot limit almost never governs, while the 44-inch minimum stair width and the occupant-load math behind it do.

The rule this example enforces: before any generative core run, compute required stair width as occupant load per floor × 0.3 inch per occupant, round up to the nearest 0.1 inch, and reject any layout whose total stair width falls short of that figure. On the 25,000 sq ft plate, the arithmetic clears at 88 inches against 50.2 inches required, so the run can proceed — but only after the width check, not the travel-distance check, has been satisfied first.

Worked Example: Run the Numbers

Take a single concrete case and carry it through the full width check. The scenario: a sprinklered office floor in a mid-rise tower, one floor plate with an occupant load of 120 people, served by two exit stairs. The dates and the party are irrelevant to the arithmetic — what matters is that the floor is sprinklered and the occupant load is 120. Label everything below as an illustration, not a code ruling; confirm the governing edition and any local amendments before you rely on it.

Step one: compute the required stair width. Under IBC 1005.3.1, the egress capacity of a stair is 0.3 inch per occupant. For 120 occupants that is 120 × 0.3 = 36.0 inches of total stair width. Round up to the nearest 0.1 inch — here it stays 36.0 inches. That total is the capacity the exit stairs must collectively provide, not the width of each stair.

Step two: divide by the number of stairs. With two stairs, 36.0 ÷ 2 = 18.0 inches per stair. Now apply the floor: IBC 1005.7.1 sets a minimum stair width of 44 inches where the occupant load is 50 or more. At 120 occupants the floor governs, so each stair must be at least 44 inches wide. The capacity math asks for 18.0 inches per stair; the minimum asks for 44. The minimum wins by 26 inches per stair.

Step three: check the total against the floor. Two stairs at 44 inches give 88 inches of total width against the 36.0 inches the capacity math requires — a surplus of 52 inches. This is the illustration's key result: on this floor the width constraint is not capacity at all. It is the 44-inch minimum applied twice, and the surplus shows how much capacity headroom the layout is carrying.

Step four: find the break-even trigger. The 44-inch floor stops binding when the per-stair capacity requirement reaches 44 inches, which happens when occupant load per stair reaches 44 ÷ 0.3 = 146.67 occupants, or about 147. With two stairs, that is a floor occupant load of roughly 294. Below that, the 44-inch minimum governs; above it, the 0.3 inch-per-occupant capacity math governs. For this example the winner is the 44-inch minimum, and the trigger that flips the outcome is a floor occupant load crossing about 294 people on two stairs.

The practical rule for a generative core run: compute the capacity requirement first, compare it to the 44-inch floor, and only then judge the layout. A layout that satisfies the floor but leaves large surplus width is a candidate for fewer or narrower stairs — and that is where the rentable-area trade-off gets decided, not in the travel-distance check.

Decision Rules for Your Core Run

Run these gates before any generative core pass. Compute the required stair width first, then test the layout against the three conditions below; a failure stops the run rather than becoming a later revision. Keep the calculation in the run log so a rejected layout can be traced to a number, not a judgment.

If required stair width exceeds 88 inches, lock three stairs into the generative constraint set before running. Do not allow the optimizer to discover the third stair late, because a late stair changes core geometry, shafts, and rentable area after the layout has already converged. Locking the count early keeps the optimizer focused on placement, not on inventing capacity.

If the floor plate's longest corridor path exceeds about 270 feet, reposition a stair toward the far corner before optimizing anything else. Measure the actual walking path along the corridor, including turns, not a straight-line diagonal. That distance keeps a 10 percent safety margin under the 300-foot sprinklered travel-distance limit and prevents a distance failure from being treated as a minor cleanup item.

If any floor is an assembly or amenity use, recompute that floor's occupant load with its own occupant-load basis before applying the width rule. Mixed-use floors cannot inherit the office assumption; their higher or differently calculated loads can change stair count even when the rest of the tower does not. Apply the rule floor by floor, because one non-office floor can force a stair that the office floors do not need.

Reject any layout whose total stair width is less than the required width, and reject any run that tries to trade stair count for corridor convenience. Capacity is the first gate; travel distance is checked only after capacity passes. If both gates pass, the run may proceed to placement; if either fails, revise inputs before rerunning.

What to do next

Frequently Asked Questions

For which occupant loads does the 44-inch minimum stair width apply?

The 44-inch minimum stair width applies for occupant loads ≥50 under IBC 1005.7.1.

What width allowance is assigned to each occupant under IBC 1005.3.1?

Under IBC 1005.3.1, each occupant requires 0.3 inch of stair width.

How must the calculated stair width be adjusted before rejecting a layout?

The required stair width must be rounded up to the nearest 0.1 inch, then layouts whose total stair width is below it are rejected.

How much total stair width is needed for a 500-occupant floor?

A 500-occupant floor therefore needs 150 inches of total stair width.

In sprinklered office towers, which of the two limits is rarely binding?

In sprinklered office towers, the 300-foot travel-distance limit (IBC 1006.2.1) is rarely the binding constraint.

Does required stair width scale with floor-plate dimensions?

Required stair width scales with occupant count and density; it does not scale with floor-plate length or width.

Quick answers

Also worth reading: 2024 IBC 44-Inch Egress Width: Component Checks for Floor Plans: 2024 IBC 44-Inch Egress Width: · Daylight Massing Test: Spatial Daylight Autonomy (300/50%)/Annual Sunlight Exposure—Pick C: Daylight Massing Test: Spatial Daylight · Davis Brody Bond and Aedas A Decade of Public Library Innovation in Urban Planning (2010-2024): Davis Brody Bond and Aedas