In / On / For

Every complex building holds three populations at once, and the only thing separating them is one small word.

In. The people who work in the building. Permanent staff, clinical teams, knowledge workers, managers, operators. These are the people enterprise technology budgets were written for.

On. The people who work on the building. Contractors, trades, facilities technicians, security, service vendors, maintenance crews. They keep the place running, they work in its worst rooms, and they are not on the corporate network or on managed devices.

For. The people the building works for. Patients, customers, guests, fans, students, residents. They arrive with their own phones, their own applications, and their own AI.

The distinction matters because enterprise networks grant access through membership in an organization, while buildings operate on physical presence. The second and third populations are present without being members. Almost every network in almost every building is designed for the first one.

Where it came from

The taxonomy came out of a connectivity argument, but it is not a connectivity framework. It is a way of counting who is actually in a building, and the count keeps coming back different from the one on the payroll. Anything provisioned by organizational membership serves one population and silently excludes two, whether that thing is a network, a badge system, a work order tool, or an AI deployment.

When to run this

Before provisioning anything to a building population. Also during diligence on a property, during any AI rollout that touches physical operations, and any time a plan says "our users" without saying who that excludes.

The steps

1. Where does coverage fail? Name the four worst rooms in the building. Plant room, sub-basement, loading dock, stairwell core. If you cannot name them, ask the facilities team, because they can.

2. What does an outsider do to get access? Count the steps. A front desk, a form, or a rotating password is friction that scales with every tool your vendors adopt.

3. Does it survive movement? Start something on floor three, walk to floor seven, and see whether it is still running. That single test predicts most of what follows.

4. What already assumes access? Inventory what is deployed, what is piloting, and what your vendors are bringing with them. That is the actual demand curve, not the roadmap.

5. Who is present at peak, and who is provisioned? Count all three populations on the busiest hour of the busiest day. The gap between those two numbers is the size of the problem.

What a bad answer looks like

A count that matches the employee roster means only the In population was counted. Every complex building has the other two.

A plan that solves On and For by provisioning them has not solved anything. It has committed to administering people the building does not employ, forever, and that overhead grows with every contractor and every visitor.

And treating the three as a hierarchy is a misread. They are concurrent. The vendor servicing the chiller and the patient in the radiology suite are in the building at the same time as the staff, with the same expectation that what they carry will work.

What to do with the output

The gap between present and provisioned is a design requirement, not a support ticket. It belongs in the specification for whatever gets built next.

Where the gap is large and the rooms are hard, the fix is architectural rather than incremental. Adding capacity for the population you already serve does not reach the two you do not.

And note who owns the answer. In most properties the population with the largest gap reports to nobody who controls the network. That is the finding, and it is usually more useful than the count.