Start with the missing information, not a different file extension
A thread visible in your CAD window can disappear from a STEP export without any solid geometry being damaged. The original may have shown a cosmetic thread: a visual representation rather than a helical surface. A missing washer, however, is a different problem. It might never have been included in the export, or it might be present but hidden in the receiving application. Treat those symptoms separately before changing the design.
This guide gives you a fault-isolation procedure for a file you already exported. It does not establish that a threaded joint is strong enough or that a manufacturer can produce it. For the broader release package, use the CAD handoff checklist. Here, the deliverable is narrower: identify what vanished, where it vanished, and what evidence would close the issue.
Separate geometry, appearance and instructions
There are three questions to answer. Does the source contain physical thread geometry? Does it contain a visual thread indication? Does it carry the manufacturing requirement, such as the thread specification and usable depth? A screenshot can show the second without proving the first or the third.
In Fusion, the Thread reference distinguishes cosmetic and modeled threads and provides a Modeled option. Inspect the feature setting in your actual source design. If you need geometric confirmation, use a section view and inspect the surfaces rather than relying on shading. Record the application and version; another CAD product can represent or display the same intent differently.
Product and manufacturing information, or PMI, is another layer. NIST distinguishes semantic PMI from graphical PMI: computer-interpretable meaning and its displayed presentation are not interchangeable. STEP can carry more than a bare solid, but that does not prove that your exporter wrote the relevant information or that the recipient reads it. A missing note and a missing helical surface are different observations.
| Observed symptom | First comparison | What it can establish |
|---|---|---|
| Smooth hole in the exported part | Source feature setting and source section | Whether a physical helix existed before export |
| Thread note or callout absent | Source annotation, export options and receiver annotation display | Whether the problem concerns information rather than solid shape |
| One component missing | Expected occurrence list versus export selection and imported tree | Which component needs a separate transfer check |
| Parts visible but assembly behavior absent | Required deliverable versus imported structure | Whether the recipient expected geometry, hierarchy or editable assembly relationships |
Freeze one reproducible case
Save a copy of the source and preserve the suspect STEP file. Give the test a short identifier, such as bracket-export-check-01. Record the source revision, active configuration or design state, export settings, file name and receiving application. Do not overwrite that file during troubleshooting. Otherwise, a supplier can be looking at yesterday's attachment while you inspect today's replacement.
Write down exactly what you expected. “Assembly wrong” is too broad. “The rear spacer occurrence is absent, while both brackets are visible” is testable. For a thread, say whether the expected result is physical helical geometry, a visible annotation, or an agreed manufacturing instruction. If these expectations were never agreed, resolve that before calling the file defective.
Capture one source screenshot and one receiver screenshot from comparable views. Add a section view where it reveals the disputed feature. These images explain the symptom; retain the actual files because a screenshot cannot prove the full transferred model. Do not infer a thread's pitch, fit or usable length from a smooth hole or an approximate-looking helix.
Run the three-stage thread test
- Inspect the source. Open the thread feature or equivalent design information. Record whether the thread is cosmetic or modeled, and confirm the intended hole is the one you inspected. If no physical helix exists, the export cannot be blamed for losing that geometry. The next question is what representation the recipient actually needs.
- Export the smallest useful test. Export a copy containing the affected part using the same relevant settings as the suspect file. Reopen the exported file as a separate document. Keep the source document identifiable so you do not accidentally inspect the original and declare the export correct. Compare the affected section and a known overall dimension.
- Compare the recipient's result. Have the intended receiving application open that exact test file. Record its import options and whether annotations are enabled. If your reopened file shows the relevant geometry but theirs does not, investigate the receiving path. If both lack geometry that exists in the source, investigate the export scope or translator. These are leads for a controlled test, not proof of a particular software defect.
Change one relevant setting at a time and save a new test file. A change of format, configuration, selection and application all at once might make the symptom disappear, but it leaves you unable to explain which change mattered. For a recurring supplier relationship, that uncertainty will return with the next revision.
Check assembly content on its own
Make a short expected-occurrence list before export. Include repeated parts separately when their positions matter: left spacer and right spacer are two occurrences even if they use one part definition. After import, compare that list with the visible assembly and the receiving application's tree. A raw file count or a total body count is not a universal substitute for this check.
If the missing component is absent from the imported tree, inspect the export selection, source visibility or suppression state, configuration and any reported dependency problems. Those are candidate causes to test, not assumptions about how every exporter works. If the component appears in the tree, inspect its visibility and placement before exporting again. An unexpected location can look like a missing part in a tightly framed view.
Then export that component alone as a diagnostic copy. If it transfers alone but not in the assembly, concentrate on assembly scope and packaging. If it fails alone too, investigate that component's source or translation path. When the export produces several referenced files, keep the complete output set together and test the package the recipient will receive.
Supplier upload rules also matter. Xometry's accepted-file guidance says its platform accepts STEP assemblies and lets users select parts to quote; it describes limitations for native assembly files on that platform. That is a receiving-workflow requirement, not a claim that native assemblies are generally unusable. Confirm the actual destination's supported package before repeatedly uploading different extensions.
Worked example: a smooth hole and a missing spacer
Consider a hypothetical bracket assembly with a threaded mounting hole and two spacer occurrences. A supplier opens the STEP file, sees a smooth hole and only one spacer, and reports “the export lost details.” No dimensions or test results in this example are a recommendation for a real product.
The designer checks the source and finds a cosmetic thread. A section view has no modeled helix. That explains the smooth transferred hole, but it says nothing about whether the supplier received a usable thread specification. The designer checks the agreed drawing and asks the supplier which geometry and callout its process requires.
Next, the designer compares the two expected spacer occurrences with the exported assembly. In this illustrative case, the export selection included only one. A single-component test transfers the other spacer correctly. The corrective action is to export the intended assembly content, then verify both occurrences and their positions. Turning on modeled threads would not repair that omission.
The case closes only when each issue has its own evidence: the supplier can identify the required threaded feature and its controlling instruction; both intended spacers appear in the received assembly; and the receiver confirms the tested revision. “The file opens” would have missed both acceptance questions.
Choose the correction that fits the manufacturing route
Do not automatically model every thread to make the preview look convincing. The recipient may need helical geometry for one workflow and a specified hole plus instructions for another. For example, Protolabs' CNC threading guidance gives different modeling instructions for internal threads and external milled threads. Follow the requirements for the chosen process and supplier rather than treating one rule as universal.
If physical thread geometry is required, add or enable it in a controlled source revision, then repeat the export and receiver checks. If the agreed workflow uses a callout instead, confirm the complete specification in the controlling drawing or supported annotation channel. The general manufacturing drawing guide helps organize those instructions. Do not silently replace a specified thread with a merely similar-looking feature.
| Finding | Action | Release decision |
|---|---|---|
| Cosmetic source thread; recipient accepts specified hole and drawing | Confirm the instruction and revision received | Pass this transfer check after acknowledgment |
| Recipient requires a helix; exported geometry lacks it | Correct source or transfer path and retest | Hold |
| Annotation unreadable; geometry appears intact | Resolve annotation support or agree a controlling drawing | Hold until requirements are unambiguous |
| Required component or occurrence missing | Correct scope, packaging or receiving setup; recount | Hold |
Copy this issue ticket into your handoff
- Test identifier and revision: [source revision], [export filename], [date].
- Expected information: [geometry / annotation / component occurrence], identified by [feature or part name].
- Source evidence: [setting, section or occurrence list].
- Export evidence: [selection, format options and reopened-file observation].
- Receiver evidence: [application/version, import settings and observed result].
- One change tested: [change], with [new file identifier].
- Closure: [specific acceptance observation], confirmed by [responsible recipient].
Keep an unresolved item marked unresolved. An attractive render, a successful upload or an empty error log cannot answer every row in this ticket. Use the evidence to close the transfer problem, then continue with the separate fit, manufacturing and functional checks your prototype requires.