# Core concepts

> The mental model behind AssetLab - organizations, the two hierarchies every asset lives in, and how the modules fit together.

Source: https://app.assetlab.ca/docs/start/core-concepts

## Your organization is the boundary

Everything in AssetLab belongs to exactly one **organization** - your tenant. Users sign in with an email one-time passcode and work inside the organization they were invited to. Data never crosses organizations: every record, document, and API call is scoped to yours.

If you operate several distinct portfolios (for example, two municipalities managed by the same firm), each one is its own organization with its own users, settings, and API keys.

## The two hierarchies

Every asset in AssetLab is positioned along two independent dimensions: **where it is** and **what kind of system it belongs to**. Keeping these separate is what makes AssetLab reporting work - you can roll up costs by building, by system class, or both.

### Location hierarchy - where things are

| Level | Example |
|---|---|
| **Site** | Main Campus |
| **Building** | Arena - Building B |
| **Location** | Mechanical Room 201 |

Each building belongs to a site, and each location belongs to a building. Assets can be placed at any level - a rooftop unit might sit at the building level, while a pump lives in a specific mechanical room.

### System hierarchy - what things are

| Level | Example |
|---|---|
| **System Class** | Mechanical (D) |
| **System Group** | HVAC (D30) |
| **System** | Heat Generating Systems (D3020) |

System classes follow the Uniformat convention out of the box, so your portfolio benchmarks cleanly against industry standards - but the model is a choice, not a mandate. Department-organized teams restructure the tree around their divisions, and many portfolios run a hybrid; the hierarchy is fully editable on the **Systems** page. See [choosing your hierarchy model](/docs/asset-management/classifications) before loading assets.

### Assets reference both

An asset record points into both hierarchies at once, plus an **asset type** (e.g. "Centrifugal Pump") and optionally a **manufacturer**. That is the whole data model in one sentence:

- *Where:* site → building → location
- *What:* system class → system group → system
- *Which:* asset type, manufacturer, model, serial

> [!tip] When you update an asset's location or system, set every level of the hierarchy - site, building, and location together - so roll-ups stay consistent.

## Vertical and linear assets

The asset registry covers **vertical** assets - equipment inside sites and buildings. Municipalities also manage **linear infrastructure**: roads, watermains, sewers, sidewalks. Those live in the [Infrastructure module](/docs/infrastructure), which adds networks, feature classes, GIS geometry, and Esri sync on top of the same organization boundary.

## The modules at a glance

| Module | What it does |
|---|---|
| [Asset Management](/docs/asset-management) | Registry, hierarchies, condition, risk, FCI, floorplans, QR codes |
| [CMMS](/docs/cmms) | Work orders, work requests, preventive maintenance, forms, parts, vendors, compliance |
| [Projects](/docs/projects) | Capital and maintenance projects, budgets, tasks, replacement planning |
| [Infrastructure](/docs/infrastructure) | Linear assets, GIS sync, zones, routes, corridors, level of service |
| [AI & MCP](/docs/ai) | Connect Claude or ChatGPT to your data through the Model Context Protocol |
| [Manage](/docs/manage) | Users, roles, settings, API keys, webhooks, import/export |

## How records flow

A typical operational loop looks like this:

1. A requester submits a **work request** from the portal.
2. Staff review it and convert it into a **work order** against the right asset, location, system, or infrastructure feature.
3. Completing the work order records **costs** against the asset automatically.
4. Condition assessments and costs feed **risk scores** and **FCI**.
5. Assets that age past their useful life surface in the **replacement planner**, which seeds **projects** and budgets.

Every module reads from the same registry, so data entered once keeps paying off downstream.

## Next steps

- Follow the [facilities quickstart](/docs/start/facilities-quickstart) to build your first site.
- Managing roads and pipes? Start with the [municipal quickstart](/docs/start/municipal-quickstart).
- Understand [who can do what](/docs/start/roles-and-access) before inviting your team.