## Documentation Index

Fetch the complete documentation index at: [/llms.txt](https://docs.firstresonance.io/llms.txt)

Use this file to discover all available pages before exploring further.

A tool in ION is a kind of [part](https://docs.firstresonance.io/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](https://docs.firstresonance.io/build-hardware/tools/manage-tool-models) and act on the physical units in [Tools Inventory](https://docs.firstresonance.io/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](https://docs.firstresonance.io/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](https://docs.firstresonance.io/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. |

Your org can add **custom attributes** to tool models for data the built-in fields don’t cover. See [Custom attributes](https://docs.firstresonance.io/administration/custom-attributes).

## 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](https://docs.firstresonance.io/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](https://docs.firstresonance.io/build-hardware/tools/record-tool-usage).

## Best practices

### Plan tool requirements

Before you add tools to your procedures, map what each operation needs:

- List every operation in your process and the tools each one requires, then map each operation to its tool requirement.
- Record the maintenance cycle and criteria for each tool.

Then add a **Tool** field to each step that needs one, set its validations and whether the tool is required, and specify which tools are valid for the operation. See [Record tool usage on a run](https://docs.firstresonance.io/build-hardware/tools/record-tool-usage). This surfaces gaps between tool inventory and operation requirements, and enforces tool use at the operation level.

### Report on tools

Pull tool data into reports to manage tools proactively. Reports can draw on any tool unit [field](https://docs.firstresonance.io/build-hardware/tools#fields), such as its service due date, last service date, and status. Automate delivery on a cadence or by condition, for example:

- A weekly report on all tools, sent to your tool manager.
- A report of tools two weeks before their service due date, so a calibration or maintenance date is never missed.
- A report of tool inventory that is currently unavailable and needs maintenance or recalibration.
- A report of tools that have been unavailable for a set period.