A board can look complete in its author’s 3D viewer and lose components when another engineer opens it. The model files may live in a personal download folder, a machine-specific library directory, or an environment variable that the recipient does not have. Verify the dependency package before using the transferred model for enclosure decisions.
KiCad’s project documentation defines KIPRJMOD as the current project directory. Project-relative references can therefore avoid dependence on one user’s absolute path. The appropriate approach still depends on how the team controls shared libraries and model revisions.
Inventory the dependencies
List the models referenced by the board, their resolved locations, and the library objects that use them. Separate standard installed models from custom supplier or team models. Record any path variables that must exist for the project to open correctly. Include the expected folder contents, not just the variable name, so another engineer can reproduce the configuration.
Also check whether the referenced file is the intended geometry. A path that resolves successfully can still point to an old package variant. Match custom models to the approved component identity and keep the source or revision evidence with the model record.
Choose a reproducible package
| Dependency type | Possible controlled arrangement |
|---|---|
| Project-specific model | Model stored with the project and referenced relatively |
| Shared company model | Versioned library with documented installation or retrieval |
| Standard application model | Recorded library version and expected path configuration |
| Unavailable model | Explicitly listed omission with its review consequence |
Follow the model’s permitted sharing terms when packaging it. A missing file should not be hidden by substituting an unrelated shape with similar dimensions. If a simplified envelope is used intentionally, identify it as such and state which mechanical questions it can answer.
Test away from the authoring environment
- Copy the release package to a clean review location.
- Open it without access to the author’s personal model folders.
- Check unresolved dependencies and compare the component inventory.
- Inspect model orientation, offset, scale, and board side.
- Export the intended mechanical deliverable and inspect that result separately.
Do not treat a cached viewer image as evidence that dependencies are present. The recipient should be able to regenerate the view and export from the supplied files and documented environment.
Complete the handoff with a short dependency manifest and a list of intentional omissions. Mechanical reviewers can then distinguish an absent component model from an actual empty region of the board. The STEP export review covers geometry checks after the dependency package is reproducible.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist