Prepare CAD Data for Long-Term Retrieval and Reuse
Long-term preservation is a future acceptance problem. The goal is not merely to retain bytes, but to give a later reader enough representation, relationship, provenance, and process context to interpret the data for a stated purpose.
Define the future use
Decide what “reuse” means before selecting an archival representation:
| Future need | Information to preserve and test |
|---|---|
| Inspect or measure | Geometry representation, units, coordinate context, accuracy or tolerance assumptions, and the inspection method. |
| Reconstruct product structure | Parts, instances, configurations, identities, references, and the relationships that make the structure meaningful. |
| Read engineering requirements | PMI, drawings, materials, classifications, and the distinction between semantic and graphic information. |
| Coordinate or place a model | Frames, placements, transforms, project context, and the relationship to any external reference system. |
| Reuse a visual asset | Scene graph, materials, images, buffers, cameras, variants, version, and resolver or path context. |
| Continue authoring | Native or sufficiently editable representation, dependencies, application context, and a tested editing operation. |
These are separate objectives. Preserving a readable shape does not prove that a product structure, semantic PMI, parametric history, or application-specific behavior can be recovered.
Preserve representation and context together
Retain the original or native form when future authoring or forensic interpretation depends on it, alongside a neutral or derived form when that improves independent readability or downstream access. State why each representation is present and what it does not preserve.
Record, at least:
- source application, release, configuration, and creation context;
- format, schema/profile, extensions, units, coordinate system, and transformations;
- external references, assets, layers, payloads, resolver context, and package boundaries;
- geometry, structure, PMI, visual, manufacturing, and other required data domains;
- provenance: origin, changes, custody, transformations, and responsible decisions;
- integrity or fixity information and how it is checked;
- access rights and restrictions; and
- the intended future audience, task, acceptance checks, and known exclusions.
Do not treat a format as “future-proof” because it is open or readable today. Openness can help, but future interpretation also depends on representation information, dependencies, context, and a retrieval test.
Use an archival process model carefully
The current CCSDS OAIS reference model treats an archive as an organization-operated system of information, technology, and policy-based processes that preserves information for a defined Designated Community. Its Archival Information Package includes Preservation Description Information (PDI), whose exact contents are determined by the archive.
OAIS identifies six PDI classes useful for a CAD preservation record:
| PDI class | CAD-relevant question |
|---|---|
| Reference | How is the object identified and how can it be found or accessed? |
| Context | What does the object relate to, and why was it created? |
| Provenance | Where did it come from, what changed, and who or what handled it? |
| Fixity | How can undocumented alteration be detected? |
| Access rights | Which restrictions, licenses, or preservation conditions apply? |
| Preservation description | Are all the required preservation details present for this archive and audience? |
The model is a preservation framework, not a CAD package layout, checksum algorithm, migration schedule, or guarantee of future application behavior. Define those implementation choices for the organization and test them.
CCSDS’s Information Preparation to Enable Long-Term Use explains why that context should be collected throughout the project. Its five overlapping collection groups cover initiation, planning, execution, closing, and control; highlighted information includes representation, semantics, quality tests and results, provenance, future uses, and properties whose transformation matters. The guidance is general and voluntary, so adapt it to the designated community and preservation objectives rather than treating it as a fixed CAD retention schema.
CCSDS’s Producer-Archive Interface methodology adds a useful delivery boundary: a tailored agreement can state submission contents, data model, packaging, access, validation procedures, and change management. It describes an initial transfer test before delivery and a separate validation test after transfer. This is process guidance rather than a universal CAD retention policy.
Repository assurance is a separate question from the contents of one retrieved model. CCSDS’s repository-audit criteria call for a documented commitment to the content, preservation objectives, and transformational properties being preserved, along with definitions of the Archival Information Package and its Representation Information. They also describe ongoing monitoring and periodic audit or certification. This makes the archive’s claim reviewable; it does not prove that a particular CAD package is editable or usable in a future application.
Respect domain-specific guidance
LOTAR describes modular long-term archiving and retrieval standards with basic parts, common process parts, and data-domain-specific parts for subjects such as explicit geometry, assembly structure, and graphic or semantic PMI. Its mission and scope explicitly concern aerospace and defence product-data standards and recommendations. That makes it a strong model for rigorous continuity work, not a blanket requirement for every organization or every CAD archive.
ISO 10303-242:2025 provides a current protocol-scope reference for managed model-based 3D engineering. Its public abstract includes long-term archiving and retrieval, configuration and change data, external documentation, quality and inspection results, and verification and validation. Treat that as a reason to identify the relevant data domains and edition in a preservation case—not as evidence that a particular implementation or archived package supports them.
When applying any such framework, identify the exact part, edition, organizational scope, and data domain. Do not claim compliance from a framework overview or assume that a listed part proves a particular archive package is retrievable.
Test retrieval, not only ingest
A retrieval test should start from the retained package rather than from the original authoring environment:
- Select a representative retained object and record the future task.
- Retrieve the payload, dependencies, representation information, and provenance context.
- Verify fixity and document any transformation or migration.
- Open or interpret the retained representation in the designated environment.
- Compare the required geometry, structure, PMI, spatial, visual, or manufacturing properties.
- Perform the future operation and record restrictions or missing information.
- Preserve the retrieval result as evidence and schedule the next test according to local risk.
The test interval and migration strategy are organizational decisions; no general preservation framework establishes a universal cadence. If retrieval fails, preserve the failure, retain the original baseline if available, and decide whether migration, another representation, or a narrower future purpose is responsible.
Understand representation limits
The format examples in this category make the boundary concrete. glTF is a runtime asset-delivery format that deliberately does not retain 3D authoring information; a successful load supports a runtime task, not CAD history or parametric editing. An OpenUSD package may depend on a configured resolver, and an ARKit-oriented packaging path may transform features such as VariantSets. A package can therefore be valid and useful while still requiring specific retrieval context.
Keep four outcomes separate:
- Retained: the required bits and relationships were preserved.
- Readable: a designated environment can interpret the representation.
- Usable: the future task works with the retrieved result.
- Editable: the intended authoring operations and design intent remain available.
Do not report the strongest outcome when only a weaker one was tested.
A practical retrieval record
future_purpose: "specific retrieval and reuse task"
designated_community: "people expected to interpret the package"
retained_representations:
- "native/source form and release"
- "neutral or derived form and profile"
dependencies_and_context:
- "references, assets, units, coordinates, resolver, and representation information"
preservation_information:
reference: "identifier and access path"
context: "relationships and creation purpose"
provenance: "origin, changes, and custody"
fixity: "verification method"
access_rights: "restrictions and conditions"
retrieval_test:
environment: "designated environment and release"
checks: "named properties and downstream operation"
result: "accepted, restricted, failed, or unknown"
known_limits:
- "future application behavior"
- "parametric editability not tested"
Adapt the record to the archive and data domain. It should make future interpretation possible without implying that a neutral export has recreated the original authoring environment.
Key points
- Define future tasks and required information layers before selecting representations.
- Preserve dependencies, representation information, provenance, fixity, context, and access conditions.
- Use LOTAR and OAIS as scoped process and preservation models, not universal CAD guarantees.
- Test retrieval from the retained package and record the actual result.
- Distinguish retained, readable, usable, and editable outcomes.