Start with the next job the files must support
If a prototype quote excludes source files, first decide whether you are buying a demonstration or a design that another engineer must continue. A demonstration may legitimately end with a physical object, photographs and test notes. A continuing design project needs a usable handover package. Ask the provider to price that package explicitly before accepting the quote; do not assume that paying for the prototype includes every working file.
Write the next task in ordinary language: another engineer must change the support-slot position, regenerate the assembly and send revised parts to a shop. That sentence is more useful than requesting “all CAD.” CAD means computer-aided design, but the label covers files with very different capabilities. A screenshot, a printable surface and a model with editable dimensions can depict the same object while supporting different work.
This guide focuses on testing the package you receive. Use the prototype design brief for the broader assignment and the contractor ownership checklist for rights questions. File delivery and permission to use those files are separate matters; this technical acceptance process does not determine legal ownership.
Separate native models, exchange geometry and fabrication outputs
A native model is saved in the design application's own format. It may preserve useful sketches, dimensions, component relationships and construction history. An exchange file, such as STEP, transfers geometry between applications. A mesh file, such as STL, represents a surface with facets and may be useful for printing. Ask for formats that match the next recipient's actual software and task.
Autodesk's guidance on imported history says that STEP, IGES and STL do not carry Fusion timeline information. It also explains that a Fusion model created in direct modeling mode may have no captured history. Therefore, neither “native” nor a familiar filename extension proves that the original sequence of editable features is present.
Do not reject STEP merely because it lacks that history. A capable engineer may modify imported geometry through direct modeling. The question is whether the agreed change can be made reliably with the delivered information. If a design depends on a table of named dimensions or a particular assembly relationship, specify that capability. If a simple geometry edit is sufficient, do not pay to reconstruct an elaborate history without a reason.
Fusion's export documentation also distinguishes archive and exchange formats and notes limits around external references. For example, a design with external references cannot be exported as a single F3D file; F3Z is an available archive option. An export is not proof that the recipient has a complete working project. Check the package in the intended application.
Turn the quote into a deliverables acceptance matrix
Use the following rows as a starting point, then delete anything outside the assignment. For each retained row, add the exact format, revision, delivery date, responsible person and pass condition. Ask the provider to identify exclusions before work begins. A narrow, affordable scope can be reasonable when its limits are visible.
| Deliverable | What to specify | Acceptance evidence |
|---|---|---|
| Editable design | Application and version; required dimensions or features; included parts and assemblies | The recipient opens a copy, performs the named change and saves it successfully |
| Referenced content | Linked components, libraries, templates and any continuing account dependency | Required references resolve in the agreed receiving environment; exceptions are listed |
| Exchange geometry | Required STEP or other export, units, part names and intended recipient | The receiving tool imports it; an agreed dimension and component inventory match the design |
| Drawings and parts list | Dimensions needed for this build, material notes, purchased-item identifiers and quantities | Revision identifiers agree; the builder can identify each custom and purchased item |
| Build record | Assembly order, fit adjustments, substitutions and prototype-specific operations | An unfamiliar builder can explain the assembly sequence and identify unresolved steps |
| Test evidence | Configuration tested, method, observations and known limitations | The report identifies which file revision and physical specimen produced each result |
A PDF drawing is useful for reading, but an editable drawing source may also be needed if dimensions will change. Similarly, a parts list is more useful when a purchaser can distinguish a generic fastener from a specific bought-in mechanism. Ask for the minimum information needed to repeat the build, not a pile of unexplained files.
Published provider practices differ. AllPrototype's CAD service guide distinguishes STEP geometry from native history and treats native files as an explicit quote item. That is a useful reason to ask the question, not evidence that every designer must follow the same policy. Compare the actual proposals you receive against your matrix.
Run a recipient-side handover test
Agree on this test while scoping the project. Allow time for the designer to correct missing files, and identify who pays for requested changes beyond the agreed deliverables. The test can be performed by your next engineer or another technically capable recipient. It should not depend on secretly copying the provider's private libraries or borrowing their login.
- Identify the package. Save the received archive unchanged. Record its revision, date, filenames and the accompanying exception list. Work from a separate copy so a test edit cannot replace the delivered baseline.
- Open the complete assembly. Use the agreed software version and account permissions. Record missing references, import warnings, unavailable add-ins and any components that appear only as pictures or substitutes.
- Check identity and scale. Compare the component inventory with the parts list. Measure a known overall dimension and one interface dimension. A model that looks correct on screen can still have a unit or configuration mismatch.
- Make one controlled edit. Change the agreed feature in the copy. Recompute or rebuild using the application's normal process. Note what updates automatically, what requires a documented manual step and what fails.
- Generate the next output. Export the revised part and update the related drawing or parts list when that was included in scope. Reopen the output in the intended receiving tool and check the changed dimension.
- Restore and record. Reopen the untouched baseline, record the result for each matrix row and return a specific issue list. Preserve both the delivered package and the test copy with distinct names.
For a cloud-based project, test access from the recipient's own authorized account and confirm the agreed export or retention arrangement. Do not require an offline workflow if the chosen tool legitimately needs cloud services. Instead, make the dependency explicit: who controls the project, which subscription is needed and what remains usable when the engagement ends.
A successful edit proves only the named task in the tested environment. It does not establish that every future modification will be easy, that the design is safe, or that a factory can manufacture it economically. Keep technical handover acceptance separate from the product's performance requirements and tests.
A hypothetical book-stand handover
Suppose an inventor commissions an adjustable book stand. The quote includes a printed prototype, assembly model and STEP exports, but excludes native source files. The next planned experiment will move a support slot by 3 mm to compare two angles. These dimensions and events are illustrative, not results from a real project.
The inventor asks for two priced options: the original demonstration package and a package that lets the next engineer make that slot change. The designer offers native parts, the assembly, a drawing source, a parts list and a short readme. One purchased hinge remains an externally linked component. The agreed test requires that hinge to be available in the recipient's environment through an authorized copy or a documented substitute suitable for this experiment.
At handover, the recipient opens the assembly but finds the hinge reference missing. The stand's main body is present, so a render looks plausible. That is a partial delivery, not a pass for the complete assembly row. The recipient records the missing filename and affected component instead of reporting only that “the CAD is broken.”
After the dependency is resolved, the engineer changes the slot position in a test copy. The part updates, but the PDF drawing still shows the previous revision. The designer supplies the agreed updated drawing output and identifies the baseline revision. The handover passes when the documented package supports the planned edit and its outputs remain consistent. No one claims that this also qualifies the stand for production.
Resolve exclusions without turning the handover into a dispute
When source files are excluded, ask which of three outcomes the provider intends: a finished demonstration only, exchange geometry for another designer, or an editable project available for an additional price. Request the practical limitations of each. A cheaper first experiment may justify a limited package; an imminent redesign may make the limitation expensive.
Do not make technical acceptance depend on an improvised demand for unpaid work. Agree how the review copy, correction window, payment milestone and final transfer fit together. As one concrete example, Mile High 3D's engagement terms describe deliverables by the statement of work and connect usable delivery to payment conditions. Those are that provider's terms, not a universal rule or advice about your contract.
If the provider cannot transfer a proprietary library, ask for a workable scoped alternative: a licensed component, permitted geometry substitute, documented interface or different design. If no option supports the next task, revise the scope or choose another provider before committing. Having more files does not solve a permission gap, and having permission does not repair a missing dependency.
Use this request in a quote discussion: “Please list the files and dependencies needed for another engineer using [application/version] to change [named feature], rebuild the assembly and create [required output]. Identify excluded sources, third-party restrictions, continuing subscriptions and manual steps. Quote the handover test and correction process, and state when final files become available under the agreed payment schedule.”
Keep a small handover record for the next iteration
Store the accepted baseline, readme, matrix results and unresolved exceptions together. Name the person who ran the test and the software environment they used. Keep the received files separate from later experiments. When the next designer changes the assembly, carry forward only the evidence that still applies to that revision.
Before requesting another prototype, check whether the original package still opens, whether purchased components remain available and whether any substitutions alter the test. This short review makes the handover useful beyond the day it arrives. Its purpose is to preserve a repeatable starting point, with visible limits, for the next piece of engineering work.