# The tool digital twin

How Tooling Metrics mirrors every physical tool in the system — what data it needs, what it tracks automatically, and what you can read back.

Source: https://support.toolingmetrics.com/en/start-here/digital-twin/
Updated: 2026-10-29

A modern machining workshop generates data at every step — the engineer designs the process in CAM, purchasing orders the tools, the operator assembles and runs them, and the machine cuts the part. In most shops this data never comes together: proven cutting parameters and assembly choices live in an experienced programmer's head, stock counts live in a spreadsheet nobody fully trusts, and in larger shops the same problem repeats across more systems — ERP handles purchasing, the tool crib keeps its own records, CAM has its own tool library, and the three rarely agree on what exists, what condition it's in, or what it costs. A good deal of it — how long a tool actually ran, how it performed on a given material, where it ended up after moving to another machine or site — is never captured at all. The decisions made in one place do not benefit from what was learned in another, and knowledge that was never written down disappears the day the person holding it leaves.

The **digital thread** is the idea that all this data should be connected — flowing from design to purchasing to shopfloor to analysis and back again, without manual re-entry or disconnected records. The **tool digital twin** is where each physical tool participates in that thread. Every time the tool moves, gets used, or changes condition, its digital counterpart is updated. Every insight the workshop needs about that tool — location, cost, condition, remaining life — comes from the twin.

## From catalog to shopfloor: how the twin takes shape

The digital twin of a tool does not start on the shopfloor. It begins as manufacturer data and engineering knowledge, and progressively becomes more specific until it represents one physical tool in one machine slot.

**A Product** is a manufacturer's catalog specification stored in the Library — Tooling Metrics' central tool repository. The Library aggregates products from multiple manufacturers into a single, searchable collection: each product carries geometry, ISO 13399 parameters, connection codes, drawings, and 3D models in a standardized format. A product represents "this component exists in the world," not "we own one." Products are the raw material of the digital thread: centralized, vendor-neutral manufacturer knowledge that feeds every downstream decision from tool assembly design to purchasing to inventory.

**A Tool Assembly** is an engineering design: a specific stack of products (holder + adaptor + cutting edge) chosen to perform a machining operation, with cutting parameters defined per material. It is the *digital master* — what the tool should be, as designed by your engineers. It lives in the Library and does not change as physical tools are used. When the engineer releases a project, the Tool Assembly is what purchasing reads to know what to order.

**An Item** is the inventory record created when an engineer syncs a Product into the workshop's stock system. The sync carries product specifications and ordering data directly into Inventory and Purchasing — no re-entry required. Purchasing reads the Item's order codes and supplier data to procure it; Inventory applies stock rules to store and replenish it. The Item is the unit the workshop manages in quantity: "we have 24 of this insert in stock." Each Item can read all semantic data from the Product it is synced with, so it can act automatically on the rules you define.

**A Serialized Item** distinguishes one physical piece from another of the same inventory item. When a specific piece arrives — a particular holder, a particular insert — it receives a unique identifier, either scanned from the manufacturer's data matrix code or registered manually. From that point, this physical piece has its own record in the system: its own location, condition, runtime history, and cost, entirely separate from every other piece sharing the same inventory number. Each serialized item's usage is monitored, and a service order is triggered automatically when one of its service thresholds is reached.

**A Tool** is the digital twin of a specific assembled tool on the shopfloor. It is born when a Tool record is created from a Tool Assembly — either manually, one at a time, or through the Setup Assistant, which creates all required tools for a job at once and generates a pick list in a single step. A Tool brings together serialized items — holder, adaptor, cutting edges — into a single assembly, and it is this combination that makes complete lifecycle tracking possible: every piece in the assembly carries its own identity and history, and the Tool record ties them together through every step from assembly to machine to service to retirement. It is the living node in the digital thread.

The twin maintains two views of the physical tool simultaneously: a **current snapshot** — the tool's precise location (a specific storage location in the warehouse, or a specific tool slot on a machine magazine/turret), its current condition, how much life remains, and what economic value is left — and a **complete history** — every movement, runtime entry, edge change, cost posting, and service event since the tool was created. These two views span both the technical perspective (how long has this cutting edge run, and is it nearing indexing or replacement?) and the economic perspective (what has this tool cost to run, and what value remains?). Together, they make the Tool record the single source of truth for every decision that touches that tool.

## Seeding the twin: data you configure once

Before the twin can do its job, it needs a foundation of design data. Most of this is configured once — by engineers and administrators — and rarely needs revisiting.

**Product data** enters the system from a GTC package import (automatic, covering an entire vendor catalog) or from individual manufacturer files. When a `.p21` data file is attached, **Save & Parse Data File** populates parameters and connection codes in a single step. This is the first link in the thread: manufacturer knowledge encoded in a standard format, flowing directly into Tooling Metrics without manual transcription.

**Tool Assembly Builder** defines the product stack, its geometry, and the cutting data for each operation and material. The system validates connection code compatibility automatically as each product is added — so the engineer knows before going to the shopfloor whether two parts will physically fit together.

**Cost allocation method** determines how usage cost is posted each time an item or a tool is consumed. Four methods are available today: a flat amount per pick, a percentage of purchase price, a percentage of unit cost, or a rate per unit of usage time (for tools where cost tracks cutting hours). A fifth method — a rate per index, for indexable inserts where each edge rotation is the unit of consumption — is planned but not yet available. The method is set once at the Internal Category or item level and inherited by every item below it. When a tool is picked or runtime is recorded, the twin posts the cost automatically without any additional entry.

**Life limit** sets the maximum usage time or cycle count before a tool needs service or replacement. It is the baseline the twin measures remaining life against.

**Stock rules** define where items are stored, in what condition, and at what quantities. Once configured, they drive automatic replenishment without human intervention.

## Keeping the twin current: data you record during work

The twin stays current through a small number of inputs from the people working with the physical tools. These inputs are kept minimal deliberately — the goal is to capture what the system cannot observe itself.

**Runtime** is the primary manual input in the production workflow. After a tool returns from a machine, the operator enters how long it ran and which cutting edges were active — and, if the tool failed during the run, marks it as broken. This single entry drives everything downstream: remaining life percentage, service threshold checks, usage cost for time-based methods, and the usage history that shows how this tool performed compared to others like it. A breakage report captures the failure as a data point rather than a silent loss, feeding into the historical record that helps engineers identify patterns of premature failure on specific materials or operations.

**Cutting edge condition** is updated when a serialized cutting edge's state changes — the same *Brand new → Used → Need service → Under service → Refurbished → Scrapped* condition tracked on any serialized item. Only a serialized cutting edge has a condition; a non-serialized one (generic inserts tracked in bulk, not by individual serial number) still accumulates runtime history, just not a per-piece condition. This keeps the twin accurate about what is physically on the tool and drives the Replace Edge workflow when a piece reaches *Need service* or *Scrapped*.

**Serial number on receipt** is registered when a serialized item arrives — scanned from the manufacturer's data matrix code or typed once. After registration, the piece has its own identity in the system and the twin takes over tracking it automatically.

## What the twin captures on its own

Once the foundation is in place, the twin records the majority of a tool's data without any manual step. This is the digital thread doing its job: data generated by normal workshop activity flowing into the system automatically.

**Every movement** — pick, return, transfer, receipt, restock, scrap — is logged with a timestamp, location, quantity, and condition. On-hand, in-circulation, and forecasted quantities update in real time. The operator does not fill in a movement log; validating the pick list or return list is the movement log.

**Usage cost** is posted at the moment the tool is transferred to a machine for pick base costing, or every hour with time base costing. The twin already knows the cost method and unit cost; no additional entry is needed. Real-time cost data is the result.

**Remaining cost** decrements automatically as usage cost posts — a running estimate of the economic value left in a serialized tool, available at any time.

**Remaining life %** is recalculated after every runtime entry, measured against the configured life limit. Warning thresholds trigger automatically at configured percentages, surfacing tools that need attention before they fail.

**Service thresholds** are checked automatically against every serialized item — usage time, usage cycles, accumulated cost, or remaining value. Crossing one changes the piece's condition to *Need service* and drafts the paperwork to get it moving — a Transfer toward a For service storage location, or a service Purchase Order if it is already at the root warehouse — without anyone watching for it. Shipping the item out to the vendor is still a deliberate step: someone reviews the drafted document and creates the Service Pick themselves.

**Documents for jobs and orders** — pick lists, tool records, purchase receipts, and restocks — are generated automatically from the engineering and purchasing records. The operator clicks one button in the Setup Assistant; the system creates the full document set.

## What the twin feeds back: the thread flowing upward

The digital thread is bidirectional. Data flows down from engineering design into the physical tool — but as the tool is used, the twin feeds data back up to every part of the workshop that needs it.

**Engineers** can see how a tool actually performed — how long it lasted on a specific material, what it cost per part — and use that to refine cutting data and tool selection for the next job. This performance data is available at the item level (comparing one item against another of the same type) and down to the individual serialized item (tracing the complete life of one physical piece). That granularity turns accumulated runtime history into decisions: which supplier's inserts last longer on hardened steel, and did that specific tool run unusually short before its last service?

**Purchasing** has real-time stock levels, in-circulation quantities, and on-order status for every item, without anyone having to count or report. The replenishment scheduler reads from the twin continuously.

**Production managers** can answer questions that used to require manual research: where is tool T-04 right now, which tools on Machine 2 are approaching end of life, and what did last week's jobs cost in tooling.

**Shopfloor operators** receive the twin's data as direct work instructions. The pick list tells them exactly which tool to pick and where to find it — down to the specific storage location — so there is no searching, no guessing, and no risk of picking the wrong item for the job. The Tool Assembly design serves as a digital setup sheet: component by component, the operator can verify they have assembled the tool correctly before it goes to the machine. The result is faster setup with fewer errors.

**Quality and maintenance** have a complete audit trail for every serialized piece — every location it has been, every service event, every runtime entry — accessible from a single tab on the serialized item record.

This is the value of the digital twin: the physical tool and its digital counterpart move through the workshop together. Every touchpoint generates data. Every question about the tool has an answer.