The estate model
Five levels, from a whole company down to a single device.
The hierarchy
Every estate is the same five-level tree, top to bottom:
- Company — the whole project: an at-a-glance view of every location.
- Location — a site or campus, holding one or more data centres.
- Data centre — a hall or room, laid out as a floor plan of rows.
- Row — a line of racks (a pod or aisle).
- Rack — a cabinet, opened as a U-by-U elevation of the devices inside it.
Devices live inside racks. You drill down by clicking through the tree or the board, and climb back up through the breadcrumb above the canvas.
The URL is the source of truth
Which project is open, and which estate level you are looking at, live entirely in the URL. Every screen is deep-linkable: paste a link to a rack into chat and it opens on that exact rack. Reloading the page, or using the browser's Back and Forward buttons, moves you around the estate exactly as you would expect — because navigation is the URL changing.
A focused path is hierarchical and readable, for example:
/o/acme/p/london-dc— the London project, company overview./o/acme/p/london-dc/dc/hall-a/row/a1/rack/a1-04— focused on one rack, four levels deep.
Names, slugs and renaming
Slugs are derived from names on the fly, GitHub-style, and are unique within their parent — so a row named “A” in one data centre never clashes with an “A” in another, because the hall above it disambiguates the path. Rename anything and its URL simply follows; the old link stops resolving by design, but an id-based fallback keeps legacy links working. There is no separate “slug” field to maintain — the name is the single thing you edit.
Consistent naming
Rack and row names can follow a template that applies across the estate, so a whole aisle numbers itself consistently. Adjust the scheme once under project settings and every generated label follows. See for where the naming scheme lives.