AI for CAD Tools
What an AI agent can read from a JT file such as geometry, structure and annotations, and what only the native NX model holds.
·
⏱
8 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
A JT file gives an AI agent assembly structure, attributes, tessellated geometry and, when exported that way, exact surfaces and annotations. It does not hold the feature tree, sketches, constraints, parameters or design intent, which stay in the NX original. Use JT for questions about what exists and where it is used, use the native file and its history for questions about why and how to change it, and test any tool on your own files before trusting it. Insist that answers say which layer they came from.
Walk into any Teamcenter shop and the file people outside engineering actually open is a JT file. Purchasing, quality, service and manufacturing planning rarely have an NX seat, so the lightweight JT copy becomes the version of the design everyone else sees. That makes it tempting to point an AI agent at the JT files and expect it to understand the product.
It can understand a good deal, but not everything. This post sorts what an agent can read out of a JT file from what only the NX original holds, so you can decide which file an agent should be querying for which question. For the neighbouring format question, our guide to STEP, IGES and Parasolid interoperability covers what survives other translations.
What a JT file is, and why it is everywhere
JT is a lightweight three-dimensional format created for visualization and review, originally developed within what became Siemens and later published as an ISO standard (ISO 14306). Its job is to let many people open a large assembly quickly, on ordinary hardware, without the CAD system that authored it.
To make that possible, a JT file stores geometry as tessellation, which means surfaces broken into small triangles, often at several levels of detail so that a viewer can show a coarse version of a large assembly and refine it on demand. Depending on how it was exported, a JT file can also carry precise boundary-representation geometry, the exact surfaces and edges that the original model was built from, along with assembly structure, part attributes and annotations.
The words that matter there are "depending on how it was exported." A JT file is a container with optional contents, and two files that both end in .jt can hold very different amounts of information. One may be a coarse mesh of a casting with a part number. Another may carry exact surfaces, product and manufacturing information and a full attribute set. Any honest statement about what an agent can read has to start with which of those you actually have in the vault.
Assemblies add a second variation. A JT assembly can be saved as a single file with every part inside it, or as a top-level file that points to one JT file per part. An agent that reads only the top-level file in the second case sees structure but no geometry, which surprises people the first time.
IN PRACTICE
It integrates directly with PLM and existing workflows, making past designs, standards, and calculations instantly available. The result is fewer errors, faster decision-making, and a more consistent process across teams.
- Sergey G., Board Member
What an agent can read out of a JT file
Treat the readable content as four layers, from most to least dependable.
Assembly structure. Which parts and sub-assemblies belong to which parent, how many of each, and how they are named. This is usually the most reliable layer and the one that supports bill of materials style questions.
Attributes. Part numbers, descriptions, revisions, materials and mass, where the export wrote them into the file. These are only as good as the metadata mapped at export time, and they are often the first thing to go stale.
Geometry. Tessellated shape is always the baseline. It supports size, rough volume, bounding box and visual comparison. Where precise boundary-representation data is present, an agent can also reason about exact faces, holes and radii.
Product and manufacturing information. Tolerances, datums, notes and surface finish callouts attached to the model, when the export included them. This layer is valuable for inspection and review questions, and it is present far less often than people assume.
In practice, this means an agent reading JT can answer questions such as which assemblies use a given part, how large a component is, whether two parts look alike, and what a callout says on a model that carries annotations. Those are real questions that engineers and their colleagues in other departments ask every day.
It also means an agent should report which layer an answer came from. A statement based on a mesh is an approximation. A statement based on exact surfaces or an attached tolerance is firmer. The difference should be visible to the person reading the answer, and a tool that blurs it is asking for misplaced trust.
What stays in the NX original
The native NX part holds the thing JT was designed to leave out: the history of how the model was built. A JT file is a published result. The NX file is the working record.
The feature tree and its order. Sketches, extrudes, patterns and the sequence in which they were applied. A JT file shows where a hole is, not that it was driven by a pattern of eight, or that it was added after an engineering change.
Sketch geometry and constraints. The relationships that make a model update predictably, such as a hole that stays centred on a boss when the boss moves.
Expressions and parameters. The named values and formulas that drive dimensions, including the ones that encode a design rule.
Design intent. Why a wall is the thickness it is, which dimension is the controlling one, and what the designer expected to change later.
Authoring-system specifics. Features and settings that have no equivalent in a neutral format are simplified or dropped when the file is exported.
None of this is a flaw in JT. A format built for fast viewing and wide distribution should not carry every working detail. But it does mean that questions about how to change a model, why it was built a certain way, or whether a parameter drives other features cannot be answered from the JT copy. Those questions belong to the NX original, or to the people who built it.
There is also a freshness point. A JT file is a snapshot taken at release or export time. If the NX original has moved on, the JT may still describe the previous state. For anything that depends on the current design, check the revision recorded in the data management system against the revision of the file you are reading.
Choosing the right file for the question
Once the split is clear, most questions sort themselves. Questions about what exists, where it is used and how big it is can be answered from lightweight data. Questions about why it is the way it is, or how to modify it, need the native file and the decisions around it.
This is where the retrieval layer matters more than the file format. Engineering knowledge rarely sits in one place: the JT copy is in the vault, the original is in NX, the reasoning is in an old change order, and the standard that drove the tolerance is in an old document. An assistant that can reach across those sources and say which one it used is more useful than one that is expert in a single file type. Our overview of making Teamcenter search work and our look at what the Teamcenter API gives engineering teams describe the data these layers draw from.
Leo AI is built for this cross-source situation. It is an AI assistant for mechanical engineers, trained on more than a million pages of standards, books and articles, and it connects to an organisation's wider knowledge base, including product data and lifecycle systems as well as local and network directories. It works as an intelligence layer on top of existing PDM and PLM systems, not a replacement for them, and offers integrations with leading platforms such as SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM and others. The value driver here is consistency: the same past designs, standards and calculations available to everyone, with the source shown.
Support for any particular file format should be confirmed against your own data, and JT is no exception. Run the check below before relying on any tool, including ours, for questions that depend on JT contents.
A five-step test on your own JT files
A short test on real files will tell you more than a feature list. Pick ten JT files that represent your range, from a simple part to a large assembly, and work through the following.
Inspect what the export contains. For each file, note whether it carries exact surfaces, annotations and attributes, or only a mesh. Record the export settings so the result can be repeated.
Ask for the assembly structure. Compare what the agent returns with the structure shown in the data management system. Any missing or duplicated parts point to an export or reference problem.
Ask for attributes. Check part number, revision and material against the vault record. If they disagree, find out which one is stale.
Ask a tolerance question on a model known to carry annotations, and a second on one that does not. A good tool answers the first with the callout and says plainly that the second has nothing to read.
Ask something only the native file can answer, such as which dimension drives a hole pattern. The correct response is to say the JT does not hold that, and to point to the NX original.
The last step is the most telling. A tool that invents an answer where the file holds no evidence is more dangerous than one that admits a gap. We make a similar argument for design checks in model-based definition versus 2D drawings, where the question is again what the model actually carries.
FAQ
Search across your CAD and PLM data
See how Leo AI works with your existing PDM, PLM and CAD data.
Leo AI is an assistant for mechanical engineers, trained on 1M+ pages of standards, books and articles and connected to your own engineering knowledge base.
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
