Make a CAD Handoff Reproducible

A reproducible handoff lets the recipient reconstruct the intended exchange conditions and repeat the relevant checks. It is more than placing the main model in a transfer folder: references, assets, versions, settings, purpose, and acceptance evidence can all change what the recipient receives.

Define the package boundary

Begin with the acceptance case and identify the payload at the level the recipient will use. A package may contain several representations, but each should have a stated role.

Do not assume that an extension or a manifest makes the package complete. The manifest records an assertion about what was included; a relocation test in a recipient-like environment provides stronger evidence about whether it can actually be resolved and used.

Treat dependencies as part of the model

The main file can be syntactically valid while pointing to resources that only exist on the sender’s machine. Identify whether references are embedded, relative, absolute, resolver-dependent, or intentionally omitted. Preserve the path and context needed by the actual representation, then test the package after moving it away from the source directory.

OpenUSD illustrates why this is representation-specific. The UsdUtilsCreateNewUsdzPackage API documents packaging a specified asset and discovered external dependencies, with resolver context configured by the caller. It also notes that directory dependencies are ignored, packaged layers may receive different asset paths, and some paths may depend on a specific ArResolver that is not available at another site. “All discovered dependencies” is therefore not the same as “works everywhere.”

glTF provides a second bounded example. A .gltf asset can contain JSON plus embedded or external binary and image resources. A .glb can package JSON and one buffer in a binary container but may still refer to external resources. Test the buffers, images, extensions, and URIs in the intended runtime; do not infer self-containment from the file extension.

Record route context, not just file names

The STEP AP242 project emphasizes use cases and business requirements alongside the standard and recommended implementation practices. Apply that discipline to any handoff:

• name the source and destination and the direction of movement;
• record application releases, translator versions, schema/profile, model view, and options;
• state units, coordinate or placement context, and any transformation;
• identify whether the recipient needs exact geometry, a mesh, a runtime scene, structured product data, PMI, or editable authoring information; and
• list intentional exclusions, such as parametric history or application-specific constraints.

If a value is unknown, record it as unknown. A guessed version, default unit, or assumed resolver makes a package look more reproducible while weakening the acceptance evidence.

If the handoff is part of a managed model-based engineering exchange, record the exact protocol edition and applicable scope as part of this context. ISO 10303-242:2025’s public abstract covers areas such as configuration and change data, external documentation references, quality and inspection results, and verification and validation, but that scope does not establish that a particular implementation preserves them.

Use a conceptual manifest

The following is a decision record, not a universal package syntax or directory policy:

package_id: "project-and-delivery-identifier"
purpose: "specific recipient task"
source:
  application: "name and release"
  configuration: "part, assembly, or model-view identifier"
destination:
  application: "name and release"
route:
  direction: "source-to-destination"
  representation: "native, neutral, structured, mesh, scene, or package"
  format_profile_version: "exact value or unknown"
  translator_and_options: "record when material"
payload:
  - path: "primary payload"
    role: "entry point"
dependencies:
  - path: "relative or resolver-qualified resource"
    role: "reference, texture, buffer, layer, drawing, or companion evidence"
context:
  units: "declared units or unknown"
  coordinates: "declared frame/transform or not applicable"
acceptance:
  case: "acceptance-case identifier"
  checks: "named comparisons and downstream operation"
  evidence: "report or record identifier"
known_exclusions:
  - "information intentionally not delivered"

The fields should be adapted to the representation and project. Do not impose a universal directory layout, checksum algorithm, naming convention, or access-control system merely because it appears in an example. If the organization chooses such a control, document it as a local requirement and test that it serves the exchange.

Relocate and repeat the handoff

A practical reproducibility test is:

1. Create the package from the accepted source baseline.
2. Place it in a clean or recipient-like location with the recorded context.
3. Open or resolve the primary payload and every required dependency.
4. Run the acceptance checks and the named downstream operation.
5. Compare the result with the baseline and record warnings, missing resources, or altered paths.

For an archive delivery, add the archive’s ingest and validation conditions. CCSDS’s Producer-Archive Interface methodology describes a tailored agreement covering submission contents, data model, packaging, access, validation, change management, and schedule. It places an initial transfer test before delivery and a separate validation test after transfer. This is a process model, not a CAD-specific package format or a universal contract.

CCSDS information-preparation guidance adds an important timing control: capture representation, process, quality-test, future-use, and change context through overlapping project activities instead of trying to reconstruct it only at final delivery. Repository-assurance guidance likewise asks an archive to state its committed content, preservation objectives, transformational properties, and Archival Information Package definitions. Those controls make preservation claims auditable; they do not prescribe a universal CAD package layout or prove that a destination can use the payload.

Attach evidence and limitations

Keep reports and context with the package or in a traceable companion record. Include the source values, received values, comparison method, agreed tolerances, test tools, versions, screenshots where useful, and the decision owner. State whether a result is accepted, accepted with restrictions, rejected, or still unknown.

When a dependency cannot be delivered, choose deliberately: repair the reference, include the missing resource, change the representation, accept a narrower task, or reject the package. Do not hide a missing dependency behind a statement that the main file opened.

Key points

• Define the package boundary from the recipient’s task and required information layers.
• Include dependencies, route context, and acceptance evidence, not only the main file.
• Test relocation in a clean or recipient-like context.
• Treat manifests as assertions until resolution and task checks support them.
• Keep package rules representation- and organization-specific unless a stated standard actually governs them.