STEP AP242 vs JT vs QIF: Choosing an MBD Exchange Format in 2026

A supplier receives your 3D model, opens it, and sees every tolerance frame exactly where the designer placed it. Six weeks later the first article arrives out of spec, and the root cause review finds that the CMM programmer retyped forty-one characteristics by hand from a screen, transposing two of them. Nothing in the file was wrong. Everything in the file was pictures. That is the failure mode at the centre of the STEP AP242 vs JT vs QIF question, and it is why treating the three as competing products produces bad architecture. They are not rivals. JT is a lightweight visualisation and collaboration derivative, AP242 is the semantic, contractual, archivable exchange, and QIF is the metrology round-trip. The expensive mistakes happen when a team picks one format for all six jobs it has.

What this covers: how each format is actually built, the four levels of PMI fidelity and which one your pipeline really reaches, what breaks in round-trip translation, the metrology loop QIF closes, and a job-by-job decision matrix you can defend in a design review.

Context and Background

Model-based definition (MBD) is the practice of making the 3D model — not a 2D drawing derived from it — the legal, authoritative product definition. The idea is thirty years old. The tooling caught up unevenly, and in 2026 most manufacturing organisations run a hybrid: an MBD master, a drawing they still issue because a customer contract demands it, and a pile of derivative files nobody can fully account for.

Three neutral standards carry the weight of that ecosystem. STEP AP242 is part of ISO 10303, the long-running STEP family, and is titled Managed model based 3D engineering. Its distinguishing feature is semantic product and manufacturing information: geometric dimensioning and tolerancing (GD&T) encoded as structured data linked to the faces it controls, not as line art that happens to sit near them. JT, standardised as ISO 14306, is a tessellation-first visualisation format built for opening a 40,000-part assembly in seconds on a laptop. QIF — the Quality Information Framework, published by the Digital Metrology Standards Consortium and harvested into ISO as ISO 23952:2020 — is an XML information model for the quality domain: what to measure, how to measure it, what was measured, and what the statistics say.

The edition landscape matters, because vendors quote it loosely. AP242 Edition 1 published in 2014 and merged the older AP203 and AP214 protocols while introducing semantic PMI and tessellated geometry. Edition 2 published as ISO 10303-242:2020. Edition 3 followed as ISO 10303-242:2022, and the current published revision is ISO 10303-242:2025, which supersedes the 2022 text. Community documentation still tracks further domain-model work under an Edition 4 banner, so edition labels and ISO publication years do not map cleanly one-to-one. Quote the ISO publication you actually tested against, not a marketing edition number.

JT has likewise moved from a single 2017 document to a multi-part series: ISO 14306-1 and -2 (2024) cover overview and vocabulary, ISO 14306-3:2025 specifies Version 2, and ISO 14306-4:2026 specifies Version 3. Siemens continues to publish the JT File Format Reference, with 10.5 Rev-A the widely implemented baseline. QIF 3.0 is the ANSI/DMSC standard in production use, with QIF 3.0 Edition 2 the revision most 2026 MBD projects target; QIF 4.0 has been in working-group development and should not be assumed published until you can point at the ANSI listing.

Why the Decision Matrix Must Be Built Around Jobs

The correct way to choose between these standards is to stop choosing. Pick the job, then pick the format that job requires, and accept that a mature MBD pipeline emits two or three derivatives from one master. JT answers “let a thousand people look at this quickly.” AP242 answers “let a machine, a lawyer, and an archivist all read the same tolerance twenty years apart.” QIF answers “let the measurement plan and the measured result be the same data as the design intent.”

Figure 1: One authoring master, three neutral derivatives, six downstream jobs.

The diagram shows a single native CAD master emitting two direct derivatives. The JT branch feeds visual consumption — design review, digital mock-up, clash and packaging studies. The AP242 branch feeds everything that needs meaning rather than appearance: supplier exchange under contract, the LOTAR archive package, and downstream automation such as CAM and inspection planning. QIF is derived from the AP242 nominal definition rather than from the CAD master directly, because the characteristics it must ballot are exactly the semantic PMI entities AP242 already carries. Results flow back into PLM and statistical process control, closing the thread.

What each format is actually optimised for

JT optimises for size and draw speed. Its core payload is tessellation — triangle meshes at multiple levels of detail — with aggressive compression and a segment structure that lets a viewer stream only what is on screen. Exact geometry is optional: a JT file may carry an XT B-rep segment with precise boundary representation, but most exports in the wild do not. Without that segment you have an approximation. Measurements taken in a viewer are approximate, redesign from the file is impossible, and finite-element meshing from it is unsound.

AP242 optimises for completeness and durability. It is verbose, it is slow to parse, and it carries structures JT has no equivalent for: exact NURBS boundary representation, product structure with configuration management, kinematics, external element references so an assembly can point at part files rather than inlining them, and — the reason it exists — semantic PMI. It also carries validation properties, which are the quality-control mechanism that makes long-term archiving credible.

QIF optimises for the quality domain specifically. Architecturally it is a reusable library of XSD schema components — geometry, topology, features, characteristics, units, expressions, traceability, visualisation — referenced by a set of application areas wrapped in a QIF document. The application partition covers product/MBD definition, measurement rules, measurement plans, measurement resources, results, and statistics. That partition is the whole point: a QIF plan and a QIF result share the same characteristic identifiers as the QIF product model they came from, so a measured value is provably the value of a specific design requirement.

The false rivalry, and where it comes from

The rivalry framing comes from procurement, not engineering. A CAD vendor sells a JT-centric collaboration stack; a competitor sells an AP242-centric one; a purchasing committee asks which to standardise on. The question is malformed. JT cannot do what AP242 does because it does not carry exact geometry by default and its PMI model is presentation-anchored. AP242 cannot do what JT does because a streaming viewer cannot load a 12 GB Part 21 file for a 40,000-part aircraft section at interactive frame rates. And neither carries a measurement plan, which is the thing your quality department actually needs.

There is one narrow place where the formats genuinely overlap and you must choose: sending a supplier a part for quotation. JT is smaller and opens everywhere; AP242 is bigger and machine-readable. If the supplier is going to program a machine from your file, the answer is AP242. If they are going to eyeball it to decide whether to bid, JT is fine and cheaper to move. Most organisations send both, which is the right answer and also the one that creates the configuration-management problem discussed later.

Why “semantic” is the load-bearing word

Everything that distinguishes a 2026 MBD pipeline from a 2006 one reduces to whether the downstream consumer is a human or a program. Humans read pictures fine. Programs cannot. When a CAM system can query “give me every surface controlled by a profile tolerance tighter than 0.05” and get a machine-answerable result, you get automated process planning. When it cannot, you get a planner reading a screen and typing. The formats differ almost entirely in whether they preserve the ability to ask that question.

Semantic vs Graphical PMI: The Failure Mode That Costs Money

Semantic PMI is tolerance data encoded as structured, machine-interpretable entities linked to the specific geometric faces they control. Graphical PMI is the visual presentation of that tolerance — the feature control frame, leader line and symbols — drawn so a person can read it. A model can carry one, the other, or both. A model that carries only graphical PMI looks complete and is not.

Figure 2: The four levels of PMI fidelity, and the two questions that decide which level you actually reached.

The ladder in Figure 2 is worth internalising because most audits discover a pipeline sitting a rung or two below where its owners believed. At the top, Level 4, a tolerance exists as data: a value, a modifier set, a datum reference frame, and an explicit association to one or more faces. A program can evaluate it. One rung down, Level 3, the annotation is graphical but still linked to geometry — you can click the frame and highlight the face, which is enough for human-in-the-loop workflows and for balloon extraction, but not enough to compute from. Level 2 is presentation-only: polylines and text strings floating in model space with no association at all. Level 1 is a picture — a saved view, a raster, a PDF page.

The two decision diamonds in the figure are the practical tests. First: do the datum references resolve to actual geometry, or are they just the letters A, B and C in a string? Second: does the annotation carry a geometry link at all? Answer both honestly and you know your real level. Nearly every “our MBD program failed to deliver ROI” post-mortem traces to a pipeline whose designers assumed Level 4 and whose exports delivered Level 2.

JT’s PMI model is presentation-anchored by design

This is the single most misunderstood point in the comparison, and it is documented rather than opinion. The JT Implementor Forum’s Implementation Guidelines for PMI in JT (version 1.0, December 2023) states the architecture plainly: in JT, semantic PMI is always an extension of graphic PMI. The graphical representation is the anchor; semantic attributes hang off it. JT PMI content aligns with the published PLM XML schema for annotation.

That design choice is coherent for a visualisation format, and it has two consequences you must plan around. First, JT can carry real semantic content — the claim “JT has no semantic PMI” is too strong and you should not repeat it. Second, the semantic layer is only as good as the authoring system’s mapping into the JT annotation schema, and when the source system’s tolerance schema diverges from that schema, the semantics degrade to the graphic polylines underneath while the file still looks correct. The failure is silent. A viewer shows the same feature control frame either way.

AP242’s model is the inverse. Semantic PMI is a first-class representation with its own entity structure, and graphical presentation is a separate, optional, associated representation. You can ship an AP242 file with semantics and no presentation — perfectly valid, machine-consumable, and unreadable to a human without a viewer that renders tolerance data. In practice you ship both and validate that they agree, which is a real and non-trivial verification step.

What actually breaks in round-trip translation

Four things break, and they break in a predictable order.

Tolerance semantics degrade first. A profile-of-a-surface tolerance with a composite frame, a maximum-material-condition modifier and a projected tolerance zone is a rich structure. Translators routinely preserve the value and drop modifiers, or flatten a composite two-tier frame into a single tier. The number survives; the meaning does not. This is worse than outright loss, because the receiving system reports success.

Datum reference frames break second. Datums are the coordinate scaffolding on which every position and orientation tolerance depends. A datum is not the letter “A” — it is a reference to a feature, possibly a datum target set, possibly a common datum built from two features, with precedence order and material-condition modifiers. Translators that preserve the letters but lose the feature association produce tolerances that are syntactically intact and geometrically meaningless. Downstream, the CMM programmer picks a datum feature by judgement, and two programmers pick differently.

Assembly structure breaks third. AP242 supports external element references, so a large assembly can be a graph of files. JT has its own assembly and reference structure. Neither maps automatically onto the other, and neither maps cleanly onto a PLM system’s product structure. Instance-level PMI — a tolerance that applies to a part as installed rather than as manufactured — is where this gets genuinely hard, because most translators normalise the instance away.

Validation properties are lost last, and notice nothing. Validation properties are the mechanism that would have caught the first three. AP242 can embed derived values computed from the source model: mass properties such as volume, surface area and centroid; a sampled point cloud over the surfaces; assembly properties covering hierarchy and relative component placement; and annotation properties covering the PMI count and content. The receiving system recomputes them from what it read and compares. A centroid that moved means geometry changed. An annotation count that dropped from 41 to 38 means three tolerances vanished. Without validation properties, nothing tells you.

The quiet arithmetic of silent PMI loss

Consider the mechanism rather than an invented statistic. If a part carries 40 characteristics and your translation chain silently degrades even one tolerance per part, every first article inspection becomes an exercise in reconciling two interpretations of the same requirement. The cost is not the translation; it is the engineering hours spent in disposition meetings, plus the scrap when the disagreement is discovered after cutting metal. This is why the LOTAR community built verification into the process rather than trusting exporters, and it is why the validation-property comparison is mandatory in any archive workflow rather than optional.

The Metrology Round-Trip: Where QIF Earns Its Place

AP242 describes what the part should be. It does not describe how you will prove the part is what it should be. That gap is the entire reason QIF exists, and it is why framing QIF as a competitor to AP242 misreads the architecture — the recommended 2026 practice is to use both together, AP242 for nominal geometry and archive, QIF for the measurement plan and the results.

Figure 3: The measurement round-trip. Characteristic identity is preserved end to end, which is what makes the loop closable.

Figure 3 shows the loop. The CAD authority exports an AP242 package carrying semantic PMI plus validation properties. A QIF product model is derived from it, and this is where characteristics get ballooned — each tolerance becomes a uniquely identified characteristic with a stable ID. A QIF plan is generated against those IDs, specifying what to measure, with what method, to what sampling scheme. The plan drives CMM or scanner execution. Results come back as QIF results, carrying actual values and measurement uncertainty, still bound to the original characteristic IDs. Those results post to PLM as first-article evidence and into SPC for trend analysis. Finally the loop closes: tolerance reality — which characteristics are consistently running at the edge of their band — feeds back to design.

Why DMIS is not the answer to this

DMIS, the Dimensional Measuring Interface Standard, is often raised as the existing metrology standard, so why QIF? Because DMIS is an execution language. It tells a CMM how to move. It is excellent at that and it stays properly confined to it. What DMIS does not do is carry the plan in a machine-neutral, design-linked form, or carry results in a structure that a PLM system can index. QIF spans the whole quality information domain — rules, plans, resources, results, statistics — and keeps design linkage throughout. The clean architecture is QIF for planning and results interchange, DMIS at the machine boundary.

The identity problem, which is the real problem

The hard part of the metrology round-trip is not geometry. It is identity. If characteristic 17 in the plan and characteristic 17 in the results and the profile tolerance on face 92 of the AP242 model are not provably the same thing, the loop is broken, and every downstream claim about first-pass yield is anecdote. QIF’s traceability library exists for this. It is also why deriving the QIF product model from AP242 semantic PMI beats deriving it from a drawing or from graphical annotation: the source already has the stable entity identity you need to propagate.

This has a direct implication for digital thread architecture. A PLM-centric thread that indexes only documents can tell you which file relates to which part. A thread built on characteristic-level identity can answer “show me every lot where this specific tolerance ran out of band,” which is a different class of question and the one that pays for the programme. If you are designing that layer, our digital thread PLM architecture guide covers the surrounding data model, and the same identity discipline is what makes retrieval over CAD and BOM data return grounded answers rather than plausible ones.

Tooling maturity in 2026

The commercial tooling around the QIF leg has matured faster than most PLM teams realise. Capvidia’s 2026 R1 release, out on 7 July 2026, is explicitly positioned around MBD readiness assessment and QIF digital-thread automation — a signal that the market has moved from “can we export QIF” to “can we automate the whole loop and measure how ready our models are to feed it.” MBD readiness scoring is a genuinely useful concept: before you automate anything, quantify what fraction of your models actually reach Level 4 PMI.

The Job-by-Job Decision Matrix

Here is the matrix, built on jobs rather than products. Read down the job column, not across the format columns.

Job	Primary format	Why	What fails if you substitute
Design review, DMU, clash	JT	Streams huge assemblies; tessellation is sufficient for visual judgement	AP242 is too heavy to load interactively at assembly scale
Supplier quotation	JT or 3D PDF	Cheap to send, opens without a CAD seat	Over-sending AP242 leaks more IP than a quote needs
Supplier manufacture under contract	AP242 with semantic PMI	Tolerances are legally binding and must be machine-readable	JT-only exchange forces manual re-entry of GD&T
Long-term archival	AP242 inside a LOTAR EN 9300 package	Validation properties plus documented verification process	JT tessellation cannot be re-engineered decades later
First-article inspection	QIF plan and results, derived from AP242	Characteristic identity preserved design to result	Spreadsheet balloon maps break traceability silently
Downstream automation and CAM	AP242 semantic PMI	Queryable tolerance data drives process planning	Graphical PMI means a human types the numbers
Digital thread indexing	AP242 plus QIF identifiers	Stable entity IDs at characteristic level	Document-level linking cannot answer part-level questions

Figure 4: A three-question decision tree. Most format arguments end after the first diamond.

Figure 4 compresses the matrix into three questions. Will a machine consume the tolerance? If no, you are in visualisation territory and JT is the efficient answer. If yes, is the payload a measurement plan or a result? If yes, that is QIF. If no, is the artefact contractual or archived? If yes, AP242 inside a LOTAR package with the full verification process. If no, plain AP242 with semantic PMI and validation properties. Three questions, four outcomes, and no argument about which vendor’s format is “better.”

The archival job deserves its own treatment

Long-term archiving is where the requirements diverge most sharply from everyday exchange, and it is the job most often underestimated. The LOTAR initiative — LOng Term Archiving and Retrieval — produces the EN/NAS 9300 standards series, structured by domain: the 9300-1xx parts cover 3D mechanical CAD with PMI, 2xx covers PDM, 3xx composites and advanced manufacturing, 4xx electrical wiring harness, 5xx MBSE, and 6xx engineering analysis and simulation. EN 9300-100 sets common concepts; later parts address explicit geometry and then explicit geometry with graphical PMI.

The important insight is that LOTAR is a process standard that happens to recommend a format, not a format standard. It prescribes qualifying the native model, converting to the neutral format, and then verifying equivalence between source and converted model — geometric, topological, semantic and structural — before the package is accepted into the archive. Validation properties are the instrument of that verification. A team that exports AP242 and calls it archiving has done roughly a third of the work. The archive package also needs metadata about itself; LOTAR’s working groups have been developing a dedicated part for archival package metadata, which tells you how much of the problem is bookkeeping rather than geometry.

If you are also carrying sustainability and compliance data forward for decades, the archival discipline here is the same discipline that underpins a digital product passport data model — durable identity, verifiable content, and a documented retrieval process.

Trade-offs, Gotchas, and What Goes Wrong

Sending both JT and AP242 creates a configuration-management problem. Two derivatives of one master will drift the moment someone regenerates one and not the other. Either generate both atomically from the same revision in the same automated job and stamp them with the same revision identity, or declare one the authoritative exchange and the other explicitly informational. A JT file with no “for visualisation only” marking will eventually be used to make a part.

Round-trip is not a round trip. Exporting AP242 from system A, importing into system B, and re-exporting does not return you to the original. B’s internal model is lossy relative to A’s, so the second export encodes B’s interpretation. Chain three systems and the drift compounds. Design your pipeline as a fan-out from one master, never as a relay.

Edition mismatch is the most common silent break. A receiving system claiming AP242 support may implement an earlier edition. Semantic PMI entities added in a later edition will be skipped, usually without an error. Test with a known reference part against every trading partner and every version upgrade, and treat the exporter-importer pair as the unit under test, not the standard.

Tessellation-only JT exports are the norm, not the exception. If your workflow ever needs exact geometry from a JT file, verify explicitly that the XT B-rep segment is present. Do not infer it from the file opening successfully.

Semantic PMI without presentation confuses humans; presentation without semantics confuses machines. Ship both, and verify they agree. A model where the semantic tolerance says 0.05 and the displayed frame says 0.5 will pass most automated checks and fail one inspection very expensively.

QIF derived from a drawing rather than from semantic PMI defeats the purpose. If a human ballooned a PDF to build the QIF product model, you have digitised a manual process, not automated a loop. The identity chain must originate in the design authority.

Anti-pattern: standardising on one format enterprise-wide. The committee that mandates “everything is JT” gets a fast, cheap pipeline that cannot feed a CMM. The committee that mandates “everything is AP242” gets design reviews that will not load. Both decisions are made annually somewhere and both are wrong for the same reason.

Practical Recommendations

Start by measuring what you actually have rather than what you believe you have. Take twenty representative released models across your product lines, export them through your current pipeline, and score each against the Figure 2 ladder. Count how many reach Level 4 semantic PMI with resolvable datum references. That number, not a vendor claim, is your MBD baseline, and it will usually be lower than expected.

Then fix the master before fixing the exports. A model whose tolerances were applied as annotation rather than as semantic GD&T cannot be exported semantically, and no translator will invent the missing association. This is authoring discipline and training, not tooling. Budget for it accordingly; it is the largest single cost in an MBD programme and the one most commonly omitted from the business case.

For the exchange layer, adopt the published recommended practices rather than inventing conventions. The MBx Interoperability Forum and its CAx-IF implementor group run two test rounds per year — six months each, starting in spring and autumn — and publish the resulting recommended practices openly at mbx-if.org. Those documents are how vendors agree on what a given entity means in practice. Using them is the cheapest interoperability insurance available.

A practical checklist:

Score your models against the four PMI fidelity levels before promising automation.
Generate JT and AP242 derivatives atomically from one revision, with shared revision identity.
Enable validation properties on every AP242 export and actually compare them on import.
Verify datum reference frames resolve to features, not just to letters, in the receiving system.
Derive QIF product models from AP242 semantic PMI, never from a ballooned drawing.
Test each trading-partner exporter-importer pair with a reference part, and retest on every version upgrade.
For archives, implement the LOTAR verification process, not just the AP242 export.
Mark every JT derivative explicitly as informational unless you have deliberately made it authoritative.

Frequently Asked Questions

Is JT or STEP AP242 better for CAD data exchange?

Neither is better; they answer different questions. JT is better when the consumer is a person looking at geometry — design reviews, digital mock-ups, large assembly navigation — because it streams tessellated data fast and opens without a CAD seat. AP242 is better when the consumer is a machine or a contract, because it carries exact boundary representation and semantic PMI that software can evaluate. Most mature pipelines emit both from one master and mark clearly which one is authoritative.

Does JT support semantic PMI?

Yes, but with an important architectural caveat. The JT Implementor Forum’s PMI implementation guidelines state that in JT, semantic PMI is always an extension of graphic PMI — the graphical representation is the anchor and semantic attributes attach to it. The practical consequence is that semantic fidelity depends on how well the authoring system maps its tolerance model into JT’s annotation schema. When that mapping is incomplete, the file still displays correctly while the machine-readable layer is thinner than assumed.

What is the difference between semantic PMI and graphical PMI?

Semantic PMI is tolerance information encoded as structured data with explicit associations to the geometric faces it controls, so software can query and compute from it. Graphical PMI is the visual presentation — feature control frames, leaders, symbols — drawn for human reading. A model can carry both. The distinction decides whether a CAM or inspection system can generate a process automatically or whether a person must read the screen and retype the values.

Does QIF replace STEP AP242?

No. QIF complements AP242 and the two are designed to be used together. AP242 carries the nominal geometry and the semantic PMI that defines what the part should be. QIF carries the measurement plan, the measurement resources and rules, the results and the statistics — what you did to prove the part conforms. The 2026 recommended practice is AP242 for nominal definition and archive, QIF for the measurement plan and results, with DMIS staying at the CMM execution boundary.

LOTAR’s EN/NAS 9300 series is built around STEP AP242 for 3D mechanical CAD with PMI. The more important point is that LOTAR specifies a process, not just a format: qualify the native model, convert to the neutral format, then verify equivalence between source and target at the geometric, topological, semantic and structural levels before accepting the package. Validation properties embedded in the AP242 file — mass properties, sampled point clouds, assembly and annotation properties — are what make that verification possible.

What AP242 edition should we target in 2026?

Target the ISO publication your trading partners and tools actually implement, and name it by publication rather than by marketing edition. ISO 10303-242:2025 is the current published revision, superseding the 2022 edition, which superseded the 2020 edition and the original 2014 text. Because edition numbering and ISO publication years do not align cleanly, and because receiving systems frequently lag, the decisive test is a reference part exchanged with each partner rather than a version number in a specification.

STEP AP242 vs JT vs QIF: Choosing an MBD Exchange Format in 2026

STEP AP242 vs JT vs QIF: Choosing an MBD Exchange Format in 2026

Context and Background

Why the Decision Matrix Must Be Built Around Jobs

What each format is actually optimised for