# Classifications

> The system hierarchy - three levels, three models to structure them (standards-based, department-led, hybrid), and how to choose yours.

Source: https://app.assetlab.ca/docs/asset-management/classifications

Classifications answer *what kind of thing is this?* - independently of where it sits. The hierarchy is the backbone of every report and cost roll-up: "HVAC backlog portfolio-wide" is a classification query, and so is "what does Parks & Recreation own?". Which of those questions your organization asks decides how you should structure the tree.

## The three levels

| Level | Role | Example |
|---|---|---|
| **System class** | Top-level bucket | Services / Mechanical |
| **System group** | Category within it | HVAC |
| **System** | Specific system | Heat Generating Systems |

The levels are fixed; what you put in them is yours. Three models cover most organizations.

## Choosing your hierarchy model

### Standards-based (Uniformat)

The tree AssetLab ships with. Classes are the major building elements of the ASTM Uniformat II standard (Substructure, Shell, Interiors, Services, …), groups are its category elements (D30 HVAC), systems its specific types (D3020 Heat Generating Systems).

- **Strengths:** a recognized industry standard - condition data lines up with capital plans, FCA reports, consultant studies, and benchmarking datasets without translation. Consistent across every building, with clean cost roll-ups by building system.
- **Trade-offs:** built for buildings - fleet, parks, and IT assets fit awkwardly. The codes take a little staff training, and it's less intuitive for crews who think in departments.
- **Best for:** building-heavy portfolios where capital planning and external comparability matter - which is why it's the default.

### Department-led

Classes mirror your divisions - e.g. *Facilities*, *Parks & Recreation*, *Public Works*, *Fleet* - with each division's asset families as groups (Arenas, Sports Fields, Vehicles) and specifics as systems. The tree scales naturally: a new department is a new class.

- **Strengths:** matches how department-organized teams already think, search, and budget - reports roll up straight to the people accountable for them.
- **Trade-offs:** cross-portfolio system questions get harder ("all HVAC everywhere" now spans several classes), and benchmarking against Uniformat-coded datasets needs a mapping exercise.
- **Best for:** organizations where crews, budgets, and reporting lines all run through departments.

### Hybrid

Standards-based where buildings dominate, department-led branches where a division owns a distinct asset family. A typical municipal tree keeps Uniformat classes for facility systems and adds *Fleet* and *Parks* as their own classes. This is the most common real-world setup - most portfolios aren't purely one thing.

### Deciding

| If… | Lean |
|---|---|
| Consultants, FCA reports, reserve fund studies are part of your life | Standards-based |
| Every report goes to a department head | Department-led |
| Buildings plus fleet/parks/other families | Hybrid |
| Genuinely unsure | Standards-based - it's the easiest to map *from* later |

Match the model to how your team thinks. You can refine groups and systems over time, but **get the top-level classes right before loading assets** - that's the level every roll-up hangs from.

## Asset types - the fourth axis

Separate from the hierarchy, every asset has an **asset type**: the specific kind of equipment ("Split System AC", "Sump Pump", "Overhead Door"). Types are grouped into **asset type groups** for tidy pickers, and each type can carry:

- A default **service life** (years), inherited by assets that don't specify their own
- **Unit-rate replacement costing**: a unit replacement rate, its unit of measure, and the date the rate was last reviewed - so replacement values can be derived from quantity times rate instead of entered one asset at a time

Think of it as: the *system* tells you which budget line the asset belongs to; the *type* tells you what it actually is. Asset types work identically under every hierarchy model.

## Customizing the tree

Administrators manage the whole taxonomy under **Systems**. Safe customizations:

- Renaming to local vocabulary ("Arenas & Ice Plants" instead of a generic label)
- Adding classes, groups, and systems your model needs (a *Fleet* class, refrigeration plants, pool systems)

> [!warning] Restructure before you load assets when you can - historical reports keep the old grouping. That said, reclassifying later is tractable: the **Move** bulk action rewrites class, group, and system for a whole selection at once, and dragging a system in the [Canvas view](/docs/asset-management/assets) re-parents it with every asset under it in one motion. Renames are always safe.

## Where classifications surface

- **Dashboards** - condition and spend broken down by system class and group
- **FCI** - computed per system class within each building, so you can see that Building A's envelope is fine but its mechanical is failing
- **Work categorization** - work orders inherit the asset's system for reporting
- **The replacement planner** - forecasts grouped by system class
- **Infrastructure** - linear networks use their own [feature classes](/docs/infrastructure/networks-and-classes), which play the same role for pipes and pavement

## Practical advice

1. Under any model, spend your customization energy on **systems** (level 3) and **asset types** - that's where local specificity pays off daily.
2. If you keep Uniformat, keep the first two levels close to the standard - that's where external comparability lives.
3. One owner. Taxonomy-by-committee drifts; give one Administrator final say on new entries.