I think about buildings in layers.

Not just structurally — foundations, framing, skin — but informationally. What exists in this building. Where it lives. What it connects to. What will need attention first, and what can wait. Those questions have a logic to them, a hierarchy, and once I started mapping that hierarchy explicitly, it changed how I operate.

I call it the Property Stack: Property → Unit → Space → Item → Part. Five levels. This isn't software — it's a framework, a way of thinking about the physical contents of a building so that knowledge can be structured, shared, and made durable. Everything in a building fits somewhere in that structure, from the address on the deed down to the smallest replaceable part inside the most obscure mechanical system. The levels are simple. What you can do with them isn't.

How I got here

When I was building out the systems for Outlook Builds, I kept running into the same friction. Everyone working on a building — me, a technician, a future project manager — had their own mental model of what was in it. Not wrong, exactly, but different. And misalignment in operations isn't a communication problem you fix by talking more clearly. It's a structural problem. The underlying framework has to be shared first.

I'd spent time at WeWork, which at its best was an exercise in thinking rigorously about physical space at scale. Dave Fano and others there were doing serious work on how buildings get understood and organized as data. Managing hundreds of buildings simultaneously taught me that language is infrastructure. Naming conventions, spatial hierarchies, shared vocabularies — these aren't bureaucratic overhead. They're what lets a team function without everyone needing to carry the same information in their head separately.

I was also familiar with Atomic Design — Brad Frost's framework for organizing interface components into atoms, molecules, organisms, templates, and pages. The vocabulary is different, but the underlying logic resonated: complex things are made of simpler things, and if you name and organize those simpler things well, working with the complex whole becomes much more tractable. That instinct, applied to buildings, is the Property Stack.

I'm not claiming to be the first person to think about buildings hierarchically. People have been building and managing structures for thousands of years, and plenty of them had their own systems, their own taxonomies, their own ways of organizing what they knew. I'm just sharing mine — how I think about the physical contents of a building, and why I find this particular way of thinking useful.

The five levels

A Property is a single physical address or site. It's the outer boundary, the anchor at the top of the hierarchy. Everything inside it belongs to it. 70 S 22nd St is a property. 525 McKean Ave is a property. This level isn't about what's inside — it's about establishing where one building ends and another begins before you start describing what it contains.

A Unit is a distinct subdivision of a property, defined by how it's used or occupied. Apartment 1, Apartment 2, the commercial space on the ground floor, the utility room, the common areas — all units. Units separate tenants, functions, and responsibilities. They're how a single property becomes multiple distinct operating environments, each with its own logic.

A Space is a named room or area within a unit. Bathroom, kitchen, laundry room, electrical room, hallway. Spaces are where items live and where work actually happens. I chose "space" over "room" deliberately — a hallway isn't a room, but it's unambiguously a space, and this level needs to be broad enough to include everything inside a unit that has a name and contains things.

An Item is any major installed thing within a space — something with a make, model, age, or maintenance history worth tracking. The toilet is an item. So is the vanity cabinet, the exhaust fan, the HVAC unit, the network rack, the washer. I've standardized items across 15 categories: Structural, Roofing, Doors & Windows, HVAC, Plumbing, Electrical, Fire, Security, AV/IT, Casework, Appliances, Lighting, Flooring, Finishes, and Furniture. Every item in every building I own maps to one of these. The categories are fixed; the items within them aren't. The taxonomy stays stable while the inventory changes underneath it.

A Part is a discrete, replaceable component of an item — but only when it earns its place in the hierarchy. The supply line on a toilet is a part. The wax ring. The shutoff valve. The filter in an HVAC unit. I don't track parts on everything; that would be overkill for a light fixture or a cabinet. But for plumbing, mechanical systems, and critical infrastructure where a single component failing creates a cascade — parts belong. They're the level that lets you anticipate failure rather than just respond to it.

The elegance of nesting

What makes this framework useful isn't any single level — it's the nesting. Every item in a building has an exact address in the hierarchy, and that address carries meaning.

Take the toilet in Apartment 1 at 70 S 22nd St:

Property: 70 S 22nd St → Unit: Apartment 1 → Space: Bathroom → Item: Toilet (Plumbing) → Part: Supply line

Each level adds precision. Each level adds context. The supply line belongs to the toilet. The toilet belongs to the bathroom. The bathroom belongs to Apartment 1. Pull any thread in that chain and you know exactly where you are — not just physically, but in terms of what surrounds it, what it connects to, what the operational context is.

The same logic applies anywhere else in the building. The washer in the utility unit:

Property: 70 S 22nd St → Unit: Utility → Space: Laundry room → Item: Washer (Appliances) → Part: Supply hose

Different category, different unit, completely different system — same five levels, same structure. That consistency is the point. Once the hierarchy is internalized, you can describe anything in the building and anyone working within the same framework knows exactly what you mean and where to find it.

I'm the GC on our properties. I know where every shutoff valve is, what every mechanical system looks like, when the major items were installed. That knowledge is useful right now, while I'm the one holding it. But a company that runs on one person's memory isn't a company — it's a dependency. The Property Stack is how that knowledge gets structured, shared, and made durable. Work orders reference it. Cost tracking references it. Condition assessments reference it. The Stack is the foundation that everything else attaches to.

What this is — and what it isn't

The Property Stack describes what exists. That's its entire job. It doesn't tell you what needs to be done, what anything costs, or who's responsible for what. Tasks, work orders, and expenses live separately and reference back to the Stack. That separation is intentional.

A lot of property management software tries to do everything at once — spatial data, maintenance history, budgets, vendor management — and ends up collapsing it all into a structure where finding anything requires already knowing where you put it. The physical logic of the building gets buried inside the operational data. The Stack solves this by staying focused: it describes the physical reality of the building, fully and precisely, and leaves everything else to the systems that reference it.

The analogy I keep coming back to is a map. A good map doesn't tell you what to do — it tells you what exists and where things are. Once you have the map, you can route work orders through it, track costs against it, assign condition assessments to specific items and parts. But the map has to come first. The Property Stack is how I build one.

What I know so far

The hierarchy isn't finished — I doubt it ever will be. The five levels feel right, but specific buildings always push on the structure somewhere. A piece of equipment that doesn't quite fit a category. A space that's hard to name. That's fine. A framework doesn't need to handle every edge case perfectly to be useful; it just needs to be clear enough that everyone working within it is oriented around the same thing.

What I can say is that having the map changes how you move through the territory. Before the Stack, every building was a collection of things I happened to know. After it, every building is a structured thing I can hand to someone else — a technician, a project manager, anyone — and have them understand immediately. For a company trying to build real operational depth, that's not a small shift.

I'm sharing this because I find it genuinely interesting, and because I think the way you organize information about your buildings matters more than it usually gets credit for. What you do with it is up to you.

‍