What Survived the CAD Export? Geometry, PMI and the Supplier's Actual Requirements
By Daoyu Guan
A purchasing engineer sends a STEP file to a machining supplier. The supplier opens it, rotates the part, and confirms that the model looks right. Both teams now know that a particular application displayed a recognizable shape. They have not yet established that every manufacturing requirement arrived or that both teams interpret the same information as authoritative.
The missing requirement might be a tolerance, datum relationship, surface specification, material instruction, or assembly note. Sometimes it is present in another delivered document. Sometimes it is in the model but the receiving software does not interpret it as expected. A useful CAD handoff checks those possibilities explicitly instead of treating a screenshot as a complete acceptance test.
Identify the different kinds of information
Geometry describes shape. Product and Manufacturing Information, usually shortened to PMI, can carry requirements associated with that shape. The distinction matters even when a viewer puts both on the same screen.
NIST's STEP File Analyzer and Viewer overview distinguishes semantic PMI, which supports computer interpretation, from graphical PMI, which represents annotations visually. The tool's description also covers geometry, validation properties, and STEP information analysis. STEP AP242 can carry PMI; a neutral-format export does not necessarily discard it.
The receiving application and export settings still matter. A visual annotation that a human can read is not automatically a machine-readable requirement in the downstream inspection system. Conversely, a missing annotation in one viewer does not prove the source file contains no relevant information. Investigate the actual file and the intended workflow.
For a supplier agreement, specify which information must survive and how it will be checked. “We accept STEP” is a statement about a file family. It is not a complete statement about semantic PMI, graphical presentation, application compatibility, or contractual authority.
Declare the source of authority
Some projects use a drawing as the controlling definition. Others use a model-based definition or a specified combination of documents. The parties need an explicit agreement, including how conflicts are resolved. Do not assume a colorful 3D file automatically overrides the drawing, or that a PDF always overrides the model.
A release manifest can identify the delivered files, revisions, units, intended applications, and controlling references. It should also name the person authorized to resolve discrepancies. A hash can help establish that two people reviewed the same bytes; it does not establish that those bytes contain correct or sufficient engineering requirements.
Separate design authority from publication authority. A content editor can check that a download link points to the approved release. The editor should not decide which datum system governs a part because one version looks clearer in a browser.
Turn “opens successfully” into a bounded finding
Opening a file is one test. Other tests address information content and downstream use. Keep their conclusions separate so that a successful first step does not silently approve the rest.
| Check | Example of evidence retained | What it does not establish by itself |
|---|---|---|
| File identity | Filename, revision, size, and checksum | That the engineering definition is correct |
| Import | Application and version; import log | That every required entity was interpreted |
| Shape review | Agreed geometric comparisons or validation results | That tolerances and notes are complete |
| PMI review | Required annotations and associations checked | That every downstream process uses them correctly |
| Process handoff | Agreed machining or inspection interpretation | That production has been approved |
| Engineering release | Named approval of the defined package | That a different later package is also approved |
This table is a proposed handoff structure, not a claim that NIST prescribes this purchasing process. The appropriate technical checks depend on the product, requirements, and systems involved.
Record failures with enough specificity to be useful. “CAD issue” leaves the next team guessing. “Receiving viewer displayed the bore but not the associated positional requirement identified in manifest item M-04” gives them a testable discrepancy.
A fictional bracket handoff
Imagine a fictional bracket, part BK-27, revision D. The agreed release contains a STEP model, a drawing, and a material specification. The drawing is declared controlling for the tolerances in this example. These identifiers and circumstances are invented for teaching; no manufacturing file was tested for this article.
The supplier imports the model and sees the expected hole pattern. The geometry review passes its agreed checks. A separate review finds that the drawing includes a positional requirement relative to named datums, while the receiving viewer's model display shows only nominal hole locations.
The correct conclusion is narrow: the import and shape checks succeeded, but the displayed model does not communicate that requirement in the reviewed workflow. Since the agreed drawing carries the controlling requirement, the supplier must still demonstrate how its process and inspection plan use that drawing. A recognizable hole pattern does not waive the tolerance.
Now change the agreement. Suppose the model's semantic PMI is intended to be authoritative for an automated inspection workflow. The earlier result is no longer enough. The team needs a check that the intended downstream system receives and interprets the relevant PMI and its associations. Reading a note manually from a PDF cannot be passed off as proving that automated path.
The two scenarios can use similar-looking files and still require different acceptance evidence. That is why the release agreement should precede the export rather than be inferred from whatever the recipient can open.
Inspect units, orientation, and assembly context
A model can look familiar while its interpretation is wrong. For a practical review, identify the unit convention and verify a few agreed reference dimensions through an appropriate measurement method. Do not infer the units solely from the filename or the supplier's usual practice.
Assembly context needs similar attention. Ask whether the deliverable is an individual part, an assembly, or a simplified representation. A supplier may need the position of a mating feature or the relevant assembly revision to interpret an otherwise complete-looking part file.
Coordinate systems and orientation should be stated where they affect the downstream operation. The purpose is not to prescribe a universal CAD convention. It is to make the assumptions that matter to this transaction explicit and reviewable.
If the package contains a lightweight preview for sales use and a controlled technical file for engineering, label them differently. A public preview should not acquire engineering authority merely because it is easier to download.
Keep annotations attached to the correct object
An annotation has meaning in relation to the feature or geometry it describes. When reviewing an exchange, ask whether the recipient can identify that relationship. Seeing all the expected text strings is weaker evidence than establishing their correct associations.
A useful test case includes requirements whose interpretation depends on their attachment, rather than only a general note in a corner. The responsible engineers can choose a small representative set for an initial compatibility exercise and decide whether a broader check is necessary. An editorial team should not invent an acceptance sample size and describe it as an engineering rule.
The distinction matters for automated reuse too. A content extraction system might recognize the text of a tolerance while losing the feature it governs. Copying that isolated text into a capability page can create a statement that appears technical but no longer conveys the original requirement.
Use a file analyzer as evidence within its scope
NIST also publishes the tool's source repository and documentation. A tool description can help a team choose an analysis method. It is not evidence that the specific supplier's file was analyzed, passed, or approved.
If your team runs an analyzer, retain its version, settings, input-file identity, output, and interpretation. Distinguish a syntax or entity finding from a manufacturing decision. A file can be structurally readable yet insufficient for the intended process; a warning can also require investigation rather than establish that a part is defective.
Do not publish “NIST verified” because the team consulted a NIST software page. Using a publicly available tool is not institutional endorsement or third-party approval. Name the actual analysis performed and the party responsible for its conclusion.
Make changes visible after the first approval
A successful exchange of revision D does not prove that revision E preserves the same requirements. A new export setting, software update, or revised part can change the handoff. Link acceptance evidence to the exact release it covered.
When a new package arrives, compare the manifest and identify what changed. The responsible team can then determine the checks that need repeating. Preserve prior evidence as prior evidence; do not overwrite it with a new filename and leave the old approval date attached.
The same discipline applies to a public product download. If a manufacturer publishes sample geometry or an example model, state whether it is illustrative, current, configurable, or suitable for a defined engineering use. A drawing revision process and a website update process should communicate with each other.
Describe CAD capabilities precisely on an export website
“CAD support” is broad. A more useful capability page names the formats and the intended exchange task, while directing buyers to confirm revision, PMI, and downstream requirements. That gives a prospective customer a concrete technical question to ask.
Avoid promising that every model preserves all tolerances across every system. Describe tested compatibility only when there is actual evidence, and identify its boundaries. If a capability has not been verified, present it as a requirement to discuss rather than an established result.
Xindar's manufacturing export services can help structure English capability pages and documentation request paths. That work does not establish a supplier's CAD compatibility, conduct design approval, or replace the engineers responsible for the release.
Questions about CAD exchange
Does STEP always remove manufacturing information?
No. STEP AP242 can carry PMI. Check what the actual export contains and what the receiving application interprets; do not generalize from one viewer or export setting.
Is a screenshot enough to accept the file?
It can show a particular visual state. It does not establish complete information transfer, semantic associations, or downstream use. Define the acceptance task and retain evidence appropriate to it.
Does matching a file checksum prove compatibility?
No. It helps confirm file identity. Compatibility and engineering sufficiency require separate checks of content and interpretation.
Which takes precedence, the model or the drawing?
Use the project's explicit authority and conflict-resolution agreement. If it is missing, resolve that question before treating either representation as controlling.
Source and scope notes
The NIST software overview and official repository support the distinctions among geometry, semantic PMI, graphical PMI, and file analysis. The worksheet, fictional bracket, and release exercises are original proposed practices. No CAD file was opened or analyzed, no supplier was assessed, and no manufacturing approval was issued in preparing this article.