# Networks & feature classes

> The structural layer of the Infrastructure module - a tenant-level feature class catalog, networks filed under classes, and the rates and lifetimes that make valuation work.

Source: https://app.assetlab.ca/docs/infrastructure/networks-and-classes

Get this layer right and everything downstream - valuation, condition roll-ups, GIS mapping - falls into place. It's the infrastructure equivalent of [classifications](/docs/asset-management/classifications) for vertical assets. Both networks and classes are managed under **Settings → Infrastructure → Classes & networks** (the old **Infrastructure → Networks** address redirects there).

## The model

**Feature classes** are a tenant-level catalog of the kinds of things you manage: Watermain, Road Segment, Hydrant, Streetlight. A **network** is a service system - Roads, Water Distribution, Sanitary Sewer - and every network is filed under exactly one feature class. Classes contain networks, not the other way around: "Watermain" is the class, and "Water Distribution - North" and "Water Distribution - South" can both sit under it.

Create one network per system you'd report on separately to council - replacement value, condition distribution, and backlog all summarize per network. Resist the mega-network: "Public Works" as one network makes every roll-up useless.

## Feature class settings

Each class in the catalog carries:

| Setting | What it does |
|---|---|
| **Code** | Immutable natural key - used in URLs and map tile filters |
| **Label, category, color, sort order** | How the class presents in lists and on the map |
| **Built-in flag** | Ships with the product; see the restructuring notes below |
| **Unit replacement rate + unit** | $ per m, each, m², or m³ - the basis for valuation |
| **Service life (years)** | Default lifecycle for features priced through this class |
| **Rate reviewed on** | The date the rate was last reviewed |

### Rates resolve through three tiers

A feature's replacement rate (and its service life) resolves in order:

1. The feature's **own** unit replacement value, when set
2. The **material default** - a per-material rates grid under **Settings → Infrastructure → Replacement rates**, keyed on the material string your GIS already publishes
3. The **class rate** - the fallback that, on a typical Esri tenant, supplies all of the pricing

Editing a default re-prices every feature that resolves through it, without touching a row. A watermain class at $1,150/m values every synced segment automatically - 40 km of main becomes $46M of replacement value with no per-feature data entry.

> [!warning] Review unit rates annually. Rates set in 2020 undervalue a 2026 network substantially; your FCI and deficit numbers inherit the error. The **rate reviewed on** date on each class and material row exists to support exactly this discipline - stamp it when you review, and record the source (tender data, index).

## Condition scales

Each network declares the **condition scale** its inspections arrive in: a 0-100 score, a 1-5 grade with 1 best, or a 1-5 grade with 5 best. Inspections are entered in the network's scale and converted to the internal 0-100 score by the database, keeping PACP-style sewer grades and PCI-style road scores comparable in one portfolio.

## Class-level defaults, feature-level overrides

Features inherit rates and service life through the resolution chain but can override individually - the cast-iron main from 1962 can carry its own shortened life without a class fork. Prefer class and material defaults; override for documented exceptions.

## Renaming and restructuring

Label, color, sort order, rate, and service life are editable on every class, and custom classes can also have their code and category changed - a code rename carries over to the networks filed under it. Built-in classes are partially frozen: their code and category can't change, and they can't be deleted. No class - built-in or custom - can be deleted while networks are still filed under it. Moving networks between classes changes how their features price - do it deliberately and re-check network totals on the [map](/docs/infrastructure/map) and dashboard afterward.

## Deleting a network

Deleting a network deletes everything filed under it: every feature, and each feature's inspections, condition history, costs, comments, documents and route membership. Preventive maintenance schedules scoped to the network or to one of its features are deleted with it; work orders and work requests that referenced a deleted feature are kept, with the feature link cleared. You'll be asked to type the network's name to confirm.

> [!danger]
> This cannot be undone, and it is not limited to what you can see. Features that were removed from a GIS feed are retained as hidden records so they can be restored if the feed brings them back - those are deleted too. A network showing no features may still hold hundreds. Hidden records are also cleaned up on their own: any feature that has stayed hidden for 30 days is permanently removed by nightly maintenance.

On a large network the delete runs in batches and reports progress as it goes. Leave the window open until it finishes; closing it partway stops the run, and the network remains with whatever features have not yet been removed. Re-running the delete picks up where it stopped.

Any Esri source that pointed at the network survives the delete, but it is left unattached and its sync is switched off. To reuse it, point it at a new network and re-enable sync. Staged rows from the network's unfinished imports are cleared at the same time; the import history itself is kept.