> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firstresonance.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> How ION models a tool: a tool model as a part, its serialized inventory, subtypes, maintenance interval, and derived maintenance status.

A tool in ION is a kind of [part](/build-hardware/parts). A tool model is a part with type `Tool`, and its physical units are tool inventory: individual, serialized instances of that model. One model can back many units. Tools are always serialized; there are no lot-tracked or untracked tools.

You curate the definition in the [Tools Library](/build-hardware/tools/manage-tool-models) and act on the physical units in [Tools Inventory](/build-hardware/tools/manage-tool-inventory). Both surfaces live in the **Supply Chain** section of the sidebar. Procedure steps reference tools to record which unit an operator used.

## Subtypes

A subtype groups tool models beyond their tool number. Torque wrenches of several models can share a `Torque Wrench` subtype, which lets a run step call out a class of tool without naming one model. You set subtypes in the **Subtypes** field on a tool model, and a model can carry more than one. A step's [tool field](/build-hardware/tools/record-tool-usage) can then validate against a subtype to accept any unit spanning those models. For the steps, see [Manage tool models](/build-hardware/tools/manage-tool-models#categorize-tools-with-subtypes).

## Fields

A tool model carries the part fields plus a few tool specifics.

| Field                    | Notes                                                                                         |
| ------------------------ | --------------------------------------------------------------------------------------------- |
| **Tool Number**          | Identifies the tool model. Required.                                                          |
| **Revision**             | Engineering revision value. Required. Revising creates the next revision as a new record.     |
| **Description**          | Free text.                                                                                    |
| **Subtypes**             | One or more groupings the model belongs to.                                                   |
| **Maintenance Interval** | How long a unit stays in service after each service date. Applies to every unit of the model. |

A tool unit carries the model reference plus its own fields.

| Field                 | Notes                                                                    |
| --------------------- | ------------------------------------------------------------------------ |
| **Serial Number**     | Unique identifier for the unit. Required.                                |
| **Tool / Part**       | The tool model this unit instances. Required.                            |
| **Location**          | Where the unit sits. An unavailable location makes the unit unavailable. |
| **Last Service Date** | When the unit was last serviced. Drives the service due date.            |
| **URI**               | Optional link, such as a calibration certificate.                        |

<Tip>
  Your org can add **custom attributes** to tool models for data the built-in fields don't cover. See [Custom attributes](/administration/custom-attributes).
</Tip>

## Maintenance interval and status

The maintenance interval lives on the tool model; each unit carries its own last service date. ION adds the interval to a unit's last service date to derive a **Service Due** date, and from that a **Maintenance Status** of **Available** or **Unavailable**. A unit past its service due date reads **Overdue** and **Unavailable**; a unit in an unavailable location also reads **Unavailable** regardless of its service schedule. If the interval or the last service date is missing, service due reads `N/A`. See [track maintenance status](/build-hardware/tools/manage-tool-inventory#track-maintenance-status-and-service-due).

## Tool usage on runs

A procedure step can require a tool through a **Tool** field. When the step runs, the operator selects the unit they used, creating an auditable usage log. The field can restrict input to a subtype or a single model, and can accept only units that are currently available. See [Record tool usage on a run](/build-hardware/tools/record-tool-usage).