There's a moment every operator dreads. A technician calls about a leaking supply line in a unit you haven't visited in three months, and the question isn't what failed — it's where. Which unit. Which bathroom. Which toilet. And whether the shutoff valve is behind the vanity or under the sink, and whether it actually turns or whether it's the one that's been frozen for years and you'd been meaning to replace.
If you're the only person who knows the answer, that's not expertise. That's a liability.
I've been working through a framework I call the Property Stack — a way of organizing everything inside a building into a five-level hierarchy so that knowledge about what exists, where it lives, and what connects to what can survive beyond my own memory. It sounds like an operational detail. It is an operational detail. It's also the foundation of everything else I'm building at Monval, and I think it's more relevant to how a real estate portfolio performs than most investors give it credit for.
Property → Unit → Space → Item → Part. That's it. Five levels. Let me explain what I mean by each, and then I'll explain why I think it matters beyond just running a tight operation.
How I Got Here
I spent time at WeWork before starting Monval. Not as a tenant — inside the operations. At its peak, WeWork was managing hundreds of buildings across dozens of cities, and one of the hard problems they were working on was how you hold institutional knowledge about physical space at scale. Dave Fano and others there were doing serious work on this: spatial hierarchies, naming conventions, how you describe a building as data rather than just as a place. I was paying attention.
The lesson I took wasn't about WeWork's specific approach — they had resources and technology we'll never have at the scale I'm operating. The lesson was about the underlying problem. Managing one building, you can hold the whole thing in your head. Managing ten, you start losing threads. Managing fifty, the threads you've lost are the ones that cost you.
I also kept thinking about Atomic Design — Brad Frost's framework for organizing interface components into atoms, molecules, organisms, templates, and pages. The web design vocabulary is different, but the logic is exactly the same: complex things are made of simpler things, and if you name the simpler things clearly and nest them predictably, you can reason about the complex whole without having to hold all of it in your head at once.
That's what I wanted for buildings. Not software — a mental framework. A way of thinking that could be shared.
The Five Levels
Property is a single physical address or site. 70 S 22nd St is a property. 525 McKean Ave is a property. This level just establishes where one building ends and another begins. It's the outer boundary before you start describing what's inside.
Unit is a distinct subdivision within a property, defined by how it's used or occupied. Apartment 1. Apartment 2. The commercial ground floor. The utility room. The common stairwell. Units separate tenants, separate functions, and separate operational responsibilities. A single property becomes multiple distinct operating environments, each with its own logic.
Space is a named room or area within a unit. Bathroom, kitchen, laundry room, electrical room, hallway. 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 anything inside a unit that has a name and contains things.
Item is where the framework starts to earn its keep. An item is any major installed thing within a space — something with a make, a model, an age, or a 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 fifteen 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 those fifteen. The categories are fixed. The items within them aren't. The taxonomy holds while the inventory changes underneath it.
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 cartridge in an HVAC unit. I don't track parts on everything. That would be overkill for a light fixture or a cabinet handle. But for plumbing, mechanical systems, and critical infrastructure where one component failing creates a cascade — parts belong. They're the level that lets you anticipate failure instead of just clean it up.
The Elegance of Nesting
What makes this useful isn't any single level. It's the nesting.
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 operationally. What surrounds it, what it connects to, what the potential failure modes are.
Same structure 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. That consistency is the whole point. Once someone has internalized the hierarchy, they can describe anything in the building and I know exactly what they mean and where to find it. No hunting. No asking the person who's done it before.
What This 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 in separate systems and reference back to the Stack. That separation is intentional.
Most property management software tries to collapse everything into one structure — spatial data, maintenance history, budgets, vendor management — and what you get is a system where finding anything requires already knowing where you put it. The physical logic of the building gets buried inside operational data. When you need to understand what's actually in a unit, you're scrolling through work orders.
The Stack stays focused: physical reality, organized precisely, separate from everything else. 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. Everything else is layered on top.
Why This Is Actually an Investment Problem
Here's where I think most investors miss it.
If you own one property and you're the operator, building knowledge living in your head is fine. Inconvenient sometimes, but fine. The moment you're running multiple buildings — or the moment you bring in any additional staffing — that stored knowledge becomes a fragility. Not just operationally, but in terms of what the portfolio is actually worth.
A building where one person knows where everything is isn't a more valuable building. It's a building with a hidden dependency. The value evaporates when that person's attention goes elsewhere — which it will, because that's what growth requires.
I'm the GC on our properties right now. I know where every shutoff valve is at 70 S 22nd St. I know the HVAC units were replaced in 2023 and what the filter schedule is. I know which bathroom exhaust fan runs loud and why. That knowledge is genuinely useful. But it's useful in a way that doesn't compound. It helps me today and it disappears when I stop being the person who's in the building.
The Property Stack is how that knowledge gets structured and shared so it survives beyond me. Work orders reference it. Cost tracking references it. Condition assessments map to specific items in specific units. When a new property manager comes on, or when we bring in a technician who hasn't worked these properties before, they're not starting from scratch. They're starting from the map.
For anyone thinking about the investment case for a portfolio like this: operations that run on shared, structured knowledge are more durable than operations that run on one person's expertise. That durability shows up in maintenance costs, in tenant retention, in how quickly you can respond when something fails. Those aren't soft benefits. They're margin.
What I Still Don't Know
The hierarchy isn't finished. I doubt it ever will be.
The five levels feel right — I've run them across everything I own and haven't hit a case where something didn't fit. But the categories within the Item level get challenged regularly. A piece of equipment that sits between HVAC and Electrical. A space that functions more like a unit. Edge cases at the boundaries of the taxonomy.
That's fine. A framework doesn't need to handle every edge case perfectly to be worth using. It needs to be clear enough that everyone working inside it is oriented around the same thing — and flexible enough that the edge cases don't break the logic.
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 and have them understand. Not just understand — work within.
For a company trying to build real operational depth across multiple properties, that's not a minor improvement. It's the difference between knowledge that's portable and knowledge that isn't.