# How tool assemblies work

How a Tooling Metrics tool assembly stacks components from spindle to cutting edge, how connection codes enforce compatibility, and what releasing an assembly does.

Source: https://support.toolingmetrics.com/en/library/overview/tool-assemblies/
Updated: 2026-10-29

## A digital design, not a physical tool

A **Tool Assembly** is the digital design of a complete cutting tool — an ordered stack of Products (holder, adaptors, cutting unit) from the spindle down to the cutting edge. It is a design artifact, not a physical object: you can have one Tool Assembly design and many physical **Tools** built from it, sitting in different locations across the shop. Keeping these separate matters because a change to the design (a new component, a corrected parameter) shouldn't silently rewrite the history of tools already built and running in production — the design and its physical instances evolve on their own timelines.

## Why the stack has to be ordered

Each component in a Tool Assembly connects to the one above it and the one below it. Every product carries connection codes — machine-side and cutting-side, drawn from its ISO 13399 data — and the assembly builder only offers products whose machine-side code matches the open connection of the component just added. This is what makes "Add to Machine Side" filter the product list: it isn't a convenience filter you can turn off, it's the mechanism that keeps a Ø63 face mill from ending up on a CAT40 holder it can't physically fit.

The same connection data drives the **CAD Viewer**'s 3D rendering and the calculated **Gauge Length** and **Cutting Diameter** — those numbers come from the stacked geometry, not from manual entry.

## Building assets is a separate step from designing

Adding components only defines the structure. **Build Assets** is what turns that structure into a rendered 3D model, a 2D drawing, and combined ISO 13399 parameters for the whole stack — the outputs that setup sheets and CAM exports actually consume. This is kept as a distinct action, rather than something that happens automatically on every component change, because rendering is comparatively expensive: it runs inline when it can, and falls back to a background job only when a build is slow enough to be worth not blocking on.

## What releasing actually changes

Releasing a Tool Assembly does two things in one step: it syncs every component Product to an Inventory Item — because from this point on, purchasing and stock tracking need to know these parts exist as things to be bought and stored — and it flips the assembly's own status from **Draft** to **Released**. A **Released** assembly is what a project operation or the WAP kiosk can pick from; a **Draft** one can't.

**Active** status is deliberately not something you set. It's reached automatically the moment the first physical Tool built from the assembly is itself released into circulation — the design only becomes "in active use" once a real tool exists to justify that label. Archiving is similarly protected: an assembly can't be fully archived while physical Tools built from it are still out there and non-retired, because those tools still need a defined place to be stored and returned to.