> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs-shaunak-branch.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Building the Asset Hierarchy

Before you begin configuring your asset hierarchy, it's important to understand what Reliability needs in order to model, monitor, and act on asset health effectively.

At its core, the Reliability platform connects three things:

* **Asset structure** — which assets exist, and how they relate to one another
* **Sensor telemetry** — what signals describe their behavior
* **Failure models** — how those signals indicate degradation, risk, or abnormal behavior

This configuration establishes the **digital twin** of your operations. Once defined, it connects to monitoring, ML scoring, alerting, and case management.

You'll be representing a real-world structure, like a wind farm or manufacturing line, using a set of logically linked components: facilities, assets, subsystems, and sensors.

## Understanding what you're building

The Reliability asset hierarchy is made up of a small number of core object types that together define how the system monitors equipment and responds to potential failures.

| Type                                   | Purpose                                                                                                                                                                                                               |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Facility`                             | Represents a site or logical grouping of assets (e.g., wind farm, plant, building).                                                                                                                                   |
| `ReliabilityAsset`                     | Represents a maintainable unit of equipment (e.g., turbines, gearboxes, generators, and converters)                                                                                                                   |
| `Sensor`                               | Sensors provide the raw data used by models, metrics, and alerts.                                                                                                                                                     |
| `ExpectedSensor`                       | An abstract label (e.g., `INLET_PRESSURE`) that represents the intended purpose of a measurement. These enable generalization across similar assets and tie directly into model features and failure detection logic. |
| `AssetClass`                           | A reusable template that defines what expected sensors and failure modes are applicable to a given kind of asset.                                                                                                     |
| `FailureMode` and `FailureModeLibrary` | Patterns of degradation or abnormal behavior that the system should detect. These are defined in terms of expected sensors and diagnostics. Libraries group them for reuse across asset classes.                      |

Together, these types define the structure, behavior, and failure semantics of the Reliability application.

When you build a hierarchy, you're not just labeling equipment, you're also configuring:

* Which assets are monitored
* What sensors they expose
* What “normal” behavior looks like
* What kinds of failures should be anticipated
* How those failures map to alerts and operational action

## How configuration happens

There are multiple ways to build and populate this structure:

* **Through the UI**: Best for exploring, validating, or refining individual facilities. Use the *Asset Hierarchy Viewer* and *Sensor Mapping* tools to interactively create and review your model.
* **Through bulk upload or scripted pipelines**: Preferred for production environments. Asset and sensor definitions are often staged ahead of time using spreadsheets, data integration flows, or preloading scripts. These methods allow you to define expected sensors, failure modes, bounds, and tags at scale.

This tutorial assumes you're using the UI to define or refine your asset hierarchy. It walks through:

1. Creating a facility
2. Building an asset structure under that facility
3. Assigning classes that determine diagnostics
4. Attaching and aligning sensors
5. Reviewing the hierarchy for completeness and telemetry readiness

## Prerequisites

Before you begin, confirm the following:

* **Asset classes are available**: Your environment includes the necessary `AssetClass` definitions with their associated `ExpectedSensor` and `FailureModeLibrary` entries. If not, request that these be imported or configured by your admin team.
* **Expected sensors are defined**: Each sensor to be mapped must correspond to a defined `ExpectedSensor`. These are required for ML models and alert logic, and must follow platform conventions (e.g., no spaces, alphanumeric names).
* **(Optional) P\&ID diagrams are parsed**: If you're using piping and instrumentation diagrams to support sensor mapping, make sure the diagrams have been uploaded and parsed in advance.
* You will also want to make sure you have all the necessary permissions and environment settings to access the UI. You can check that you meet the requirements laid out \[here]]\(../../prerequisites).

## Build using the UI

### Step 1: create a facility

Go to *Config → Facility Management* or open the **Asset Hierarchy Table**.\
Click `Add Facility`, enter a name (e.g., “North Wind Farm”), and save.\
The facility will appear in both the table and graph view of the Asset Hierarchy Viewer.

![Filter Panel](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/asset_hierarchy_viewer_filter.png)

### Step 2: add and structure assets

You can add assets from scratch, from prebuilt templates, or by selecting an asset class.

#### Add from hierarchy template

Templates let you instantiate a predefined tree of assets with known classes and relationships.

1. Select a facility or parent asset in the graph.
2. Click `Add from Hierarchy Template`.
3. Choose a template, preview the structure, and save.

![Add With Template](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/add_asset_with_h_template.png)

#### Add from asset class

Use asset classes to create a new asset with built-in expected sensors and failure modes.

1. Click `Add from Asset Class`.
2. Filter by class if needed.
3. Select one or more classes and click `Add`.

![Add From Asset Class](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/add_from_asset_class.png)

#### Add custom asset

To create an asset manually:

1. Click `Add Custom Asset`.
2. Enter a name and click `Save`.

![Add Custom Asset](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/add_custom_asset.png)

### Step 3: manage the hierarchy

From either the graph or the table view, you can:

* **Move** assets to reparent them\
  ![Moving assets](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/move_asset.png)
* **Duplicate** assets and their children
* **Delete** assets\
  ![Delete Asset](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/delete_asset.png)
* **Swap asset class** to change which diagnostics and expected sensors apply\
  ![Swap Asset Class](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/swap_asset_class.png)
* **Save as template** to reuse structures later

Be sure to click **Save Changes** to persist your edits. Changes are not saved automatically.

### Step 4: map sensors to assets

Click `Map Sensors` on any asset to open the Sensor Mapping page.

![Map Sensors](https://mintlify.s3.us-west-1.amazonaws.com/devdocs-shaunak-branch/apps/reliability/8.8/developer-guide/configuring-application/asset-hierarchy/img/map_sensors.png)

From here:

* Use the **Master Sensor List** to search for relevant telemetry
* Add sensors to the asset with the + button or multi-select checkboxes
* Reference `ExpectedSensor` entries to understand what each asset class expects
* Use the dropdown in the `Expected Sensor` column to formally map physical sensors to canonical sensor types

> This mapping step enables model scoring, diagnostic reasoning, and alert triggering. Sensors that are not mapped to an expected sensor will not be included in model inputs or failure mode detection.

You can **save as draft** if you're still reviewing, or **mark as complete** once the mapping is finished.

### Step 5: use P\&ID parsing (optional)

If diagrams have been parsed and connected:

* Use `Filter by Connected P&IDs` to limit sensor selection to those confirmed in the diagram
* Use `Browse P&IDs` to view diagrams in a second tab for reference

This can help confirm tag-to-asset associations when onboarding sensors from unfamiliar sources.

### Step 6: finalize and commit changes

Once your hierarchy is built and sensors are mapped:

* Confirm all assets have assigned classes
* Ensure each mapped sensor is aligned with an expected sensor
* Click **Save Changes** to persist your updates

The structure you've configured now defines how telemetry connects to risk models and alerting logic across your deployment.