Digital thread: what it is, and where it breaks

This article defines the digital thread and covers where it most often snaps: the moment a CAD model becomes a lightweight 3D asset.

What is a digital thread?

A digital thread is the connected record of a product's data across its lifecycle. It links requirements, design, manufacturing, and service information so that any artifact can be traced back to the source that produced it. The thread runs in both directions, carrying production and field data back to engineering.

The Digital Twin Consortium defines it as "a bidirectional, dependable and trustworthy interconnected information system that links multiple dimensions, including structure, behavior, space, time, and lifecycle stages." That is accurate, and hard to act on. In practical terms, the thread is the set of connections that answer one question: for this part, in this state, what produced it, what changed, and what depends on it?

Bidirectionality is the part most often skipped. A thread that only runs forward from engineering to manufacturing is an export pipeline. A real thread also runs backward. Inspection results, as-built configurations, field failures, and service history flow back to the people who own the design.

This guide identifies the data that travels the thread, explains what happens to it during format conversion, and sets out what it takes to keep the connection intact through to real-time 3D.

Digital thread vs digital twin: what is the difference?

A digital twin is a virtual representation of a real thing. A digital thread is the connected record of how that thing came to be and what has happened to it since. The twin is a state, the thread is a history. You need the thread for the twin to stay truthful.

The two are dependent, not interchangeable. A digital twin built from a stale export is a twin of a product that no longer exists. When engineering releases a revision and the twin does not know, the twin keeps simulating the old part. The thread closes that loop.

What data actually travels the thread?

Different parts of a product's data have very different survival odds. Geometry is the obvious payload, and usually the least valuable one. A 3D CAD file describes shape. Everything that makes the shape actionable sits alongside it:

• Part numbers and identifiers. The primary key. Without a stable ID, nothing downstream can be tied back to a source record.
• BOM and product structure. What the assembly is made of, in what quantity, and in what relationship. A CAD BOM is a data structure, not a picture.
• Assembly hierarchy and constraints. Parent and child relationships, subassembly boundaries, mates, and joints. This is how a machine is organized, and it is what a technician navigates.
• Materials and finishes. Physical properties for simulation, plus appearance for visualization. These are two different needs served by one attribute set.
• PMI and GD&T. Product manufacturing information and geometric dimensioning and tolerancing. Tolerance and manufacturing intent are the data that matters most downstream, and the data most likely to be treated as an afterthought.
• Revision and effectivity. Which version this is, and when it applies. Effectivity is what makes a thread a timeline rather than a snapshot.
• Supplier and sourcing attributes. Who makes it, to what specification, and under what agreement.

Where PLM fits

PLM is the system of record for most of the above, and PLM integration is what makes a thread possible rather than aspirational. PLM holds identity, revision, structure, and release state. It rarely governs what happens once data leaves it for a downstream consumer such as a visualization pipeline, a training application, or a configurator. That handoff is where the gap opens.

The research supports this. In a Tech-Clarity survey of 245 companies, about one-third reported multi-CAD related issues, and almost half said they lose time to poor or inefficient collaboration. Engineers spend 19% of their time, roughly one day a week, on non-value-added data management work, and the named tasks include working with the wrong data, recreating data, and translating formats (Tech-Clarity, December 2024). Format translation is not a footnote in the data management problem. It is one of its named causes.

Where the thread breaks: format conversion

Tessellation is the process of approximating an exact CAD surface with a mesh of flat triangles. Real-time engines, browsers, and headsets render triangles, not parametric surfaces, so every CAD model must be tessellated before it can be displayed interactively. The result is a visual approximation with a chosen tolerance.

CAD geometry is exact mathematics. A cylinder is a cylinder: a boundary representation, or BREP, built from analytic and NURBS surfaces that can be evaluated to any precision. A real-time engine cannot render that directly. It renders triangles. So the surface is sampled, and the sampling tolerance becomes a permanent property of the output. Tighten the tolerance and you get fidelity plus triangle count. Loosen it and you get performance plus visible faceting.

Decimation goes further. Once tessellated, models are usually still too heavy for a headset or a browser, so triangles are removed, meshes are merged, occluded geometry is deleted, and hierarchy is flattened. Every one of those operations trades information for frame rate.

The problem is the second thing that happens at the same moment. Unless the pipeline is explicitly built to carry them, the non-geometric attributes in the previous section do not come along. The mesh arrives. The part number does not. The BOM does not. The revision does not. The thread has just been cut, and nothing failed loudly enough for anyone to notice. Downstream, the asset looks correct and carries no provenance.

Formats make this concrete. On the way in you are typically dealing with native CAD such as CATIA V5 and V6 or Siemens NX .prt files, neutral formats such as STEP, IGES, and JT, and BIM formats such as IFC and NWD. On the way out, real-time pipelines commonly use glTF, FBX, and OBJ, while USD is increasingly used as an interchange format across the wider 3D ecosystem. Conversion tooling such as Unity Asset Transformer reads native CAD and neutral formats directly and handles the BREP-to-mesh translation, rather than requiring an upstream export to a mesh format first. It supports more than 70 formats, and preserves hierarchy, materials, and metadata on import.

The distinction that matters is not whether conversion happens. It always happens. The question is whether it is a black box that produces an orphaned mesh, or a defined step that carries identity forward.

What survives CAD-to-real-time-3D conversion, and what does not

The answer varies by attribute, by pipeline, and by how the source data was authored. Nothing here is automatic.

Two points to note:

Some of these losses are correct: you do not want NURBS on a headset. The losses that hurt are the informational ones, and those are avoidable. A mesh that knows its part number and revision is a thread. A mesh that does not is a picture.

Model-based definition and MBSE raise the stakes. If the model is the authoritative definition rather than the drawing, then attributes lost at conversion are not cosmetic. They are the specification.

What happens when engineering changes the part?

A digital thread is not a one-time export, and this is where most teams feel the break first.

The scenario is routine; Engineering releases a revision and a bracket moves by four millimeters. Upstream, everything behaves: the change order is raised, reviewed, and released, and PLM records it correctly. Downstream, every artifact built from the old geometry is now quietly wrong. The training module still teaches the old assembly sequence. The configurator still shows the old bracket. The maintenance walkthrough still points a technician at a hole that is no longer there.

Nothing errors, and that is the problem. Manual pipelines depend on someone remembering to re-export, identifying every downstream asset derived from that part, and re-running the conversion. In practice, either one person holds that knowledge, or nobody does.

The value of the thread is early visibility into design changes, which removes the cost of late-stage modification. Visibility upstream is not enough if the downstream artifacts do not update. The thread has to be actionable, meaning a change in the source system triggers re-conversion and flags the assets that depend on it.

The gains from tightening this loop are measurable. Siemens reports that Teradyne cut engineering change order cycle times from 90 days to 14, an 84% reduction, cut the cost of implementing change orders by 60%, and saw $2 million in annual savings. The win comes from removing manual handoffs, not from working faster inside them.

Treating conversion as a repeatable, triggered operation rather than a task is the whole shift. That is what automating CAD-to-3D workflows is for.

How to keep the thread intact through to 3D

"How do you create a digital thread?" - the answer is an architecture program. The part that concerns conversion comes down to six practices. Require them of any pipeline, whoever builds it.

1. Keep part identity stable across conversion. Decide on the identifier that travels: usually the PLM object ID plus revision, not the file name. Write it onto the converted object. If a downstream asset cannot name its source, the thread ends there. This is the highest-value practice on the list.

2. Map source properties to target metadata explicitly. List the properties that must survive, define where each one lands, and test the mapping as part of the pipeline. Default behavior is not a specification. Anything you have not named will eventually go missing.

3. Automate conversion, and version the recipe. Tessellation tolerance, decimation targets, merge rules, and material mappings are all inputs. Store them in source control and apply them programmatically, so the same input produces the same output next quarter. A manual optimization pass is unreproducible by definition.

4. Make conversion event-driven. Trigger re-conversion from a release event in the source system rather than from a person's memory. This is what turns a set of exports into a thread that stays current.

5. Store converted assets where they can be found and re-derived. Converted assets are derived data, so treat them accordingly: catalogued, searchable, versioned, and disposable. Sound 3D asset management means you can regenerate an asset from source rather than protecting an artifact nobody can reproduce.

6. Link the converted asset back to the source record. Not a copy of the metadata, a link. The converted asset is a derivative of a released engineering object, and it should say so. This is what makes impact analysis possible: when a part changes, you can enumerate everything downstream of it.

This is the discipline applied to software build pipelines, applied to 3D data. For the wider architecture question, including where these responsibilities sit between engineering and IT, see this guide to governing 3D data infrastructure.

Digital thread examples by industry

Aerospace and defense

Aerospace is the most mature use case, and the origin of the term. The driver is regulatory: an airframe component must be traceable from requirement through design, material certification, manufacture, and inspection, and that record must survive for decades. The thread connects requirements management, CAD, MBD, manufacturing execution, and inspection results, demonstrating that the part was built exactly to engineering specification. Break it and you have a compliance problem, not an efficiency problem. At the 3D end, the same data drives assembly guidance and maintenance training on aircraft.

Automotive

Automotive runs on variant complexity. A vehicle line is thousands of configurations, each with its own valid BOM and effectivity window. The thread ties configuration rules to geometry, so a given build's parts are the right parts. Without it, teams reconcile spreadsheets. At the 3D end, this powers design review across distributed teams, virtual builds ahead of tooling, and configurators that show a car that can actually be ordered. Get the thread wrong and the configurator sells a variant the plant cannot make.

Industrial equipment

Industrial machinery is sold once and serviced for twenty years. The thread connects the as-designed machine to the as-built and as-maintained machine, per serial number, across the installed base. What breaks without it is service: a technician arriving at a machine whose documentation describes a different revision. At the 3D end, 3D visualization software turns that per-serial record into interactive service instructions, remote assistance, and operator training on the exact configuration in front of the user.

Common digital thread challenges

The obstacles are mostly organizational, and mostly predate any integration work.

Source systems that were never designed to talk. PLM, ERP, MES, ALM, and CAD were bought at different times, for different owners, with different data models. There is no version of this project that is only a data project.

Split ownership. Engineering owns the definition, IT owns the platforms, manufacturing and service own the consequences. Nobody owns the thread, so the gaps between systems belong to no one.

Data quality that arrives with the data. The thread does not create quality. It propagates whatever exists. In a survey of 250 engineering leaders across the US and Europe, 95.6% called following company design standards critically important or important, yet only 55% of design standards were documented, current, and frequently used. The data attached to a model is often fragile before any conversion touches it.

The conversion break. This is a challenge in its own right, because it is the one most likely to be invisible to the people funding the program.

Some of these are simply hard. Split ownership is not a tooling problem, and no product resolves it. The realistic goal is a thread that is intact on the paths that carry consequences.