A decision framework for defining the purpose, information layers, evidence, tolerances, and failure disposition that make a CAD transfer acceptable.

Define an Acceptance Case for a CAD Exchange

“The file opened” is an observation. An acceptance case states whether the received data is usable for a named task, under a named exchange condition, with evidence that another person can inspect.

Start with the receiving decision

Write the decision before choosing an export option. A useful acceptance question has this shape:

Can the destination use this received representation for [specific task], under [version/profile and route], while preserving [required information layers] within [stated limits]?

The task changes the answer. A supplier may need a measurable solid and drawing information; a BIM coordinator may need object relationships, properties, and spatial context; an inspection workflow may need selected PMI and geometry; a visualization handoff may need a scene that loads with its resources. An archive may need a retrievable representation and enough context to interpret it later, without requiring the original authoring history.

State the minimum exchange

Record the route and its boundaries in plain language. At minimum, identify:

Exchange element	Question to answer
Source and destination	Which environment creates the data, and which environment or service receives it?
Direction	Is this export/import, a reference, a one-way delivery, an update, or a return to the source?
Representation	Which native, neutral, structured, tessellated, scene, or packaged representation is being tested?
Version and profile	Which application releases, schema versions, model views, profiles, extensions, or translator versions apply?
Purpose	What must the recipient actually do with the result?
Required layers	Which geometry, topology, structure, intent, PMI, spatial, visual, manufacturing, or dependency information must survive?
Permitted loss	What may be transformed, omitted, or rebuilt without making the result unacceptable?

The STEP AP242 project makes the same distinction in its own context: a standard needs to be associated with use cases and business requirements. A format name is not a substitute for the work the recipient must perform.

Turn layers into observable criteria

For every required layer, state what will be inspected and what result counts. Avoid the phrase “preserved” without naming the property.

Information layer	Example acceptance observation	Still unproven unless separately checked
Exact geometry	Selected dimensions, topology conditions, or validation properties agree within an agreed tolerance.	Unmeasured local defects, editability, PMI, or assembly semantics.
Product structure	Required instances, identities, configurations, and references are present and resolve.	Parametric history or equivalent authoring behavior.
PMI and documentation	Required semantic or graphic annotations are present and usable in the destination task.	That visual annotations are computer-interpretable, or that every annotation survived.
Spatial context	Units, axes, frames, placements, and coordinates produce the expected result in the task.	Correctness of an untested transform or application-specific interpretation.
Visual or runtime asset	Scene, materials, cameras, and required resources load in the target viewer or runtime.	CAD authoring, engineering semantics, or a self-contained package.
Manufacturing or inspection data	The selected downstream operation or inspection workflow can use the named data.	Other operations, products, releases, or untested attributes.

For a STEP exchange, NIST describes validation properties such as area, volume, centroid, PMI, assembly, annotation, attribute, and tessellated properties. A receiving value within an agreed tolerance validates the compared property set; it does not validate every layer. The tolerance and property set belong to the actual task, not to a universal rule.

Separate evidence levels

Keep these claims distinct in the acceptance record:

Transport success: the payload was delivered and could be opened or parsed.
Syntax or schema validity: the file satisfies the tested structural rules.
Scoped conformance: the implementation passed a named profile, model view, recommended practice, or certification test.
Preservation evidence: selected information properties match between source and destination.
Task acceptance: the recipient completed the named operation using the received result.
Future retrieval: a later test showed that the retained package and context could still be interpreted for its stated future purpose.

The levels build evidence, but none silently substitutes for the next one. A buildingSMART certification test, for example, is tied to particular IFC exchange requirements and a Model View Definition, with automatic and manual verification. It is a useful test model, not a certificate that every IFC delivery satisfies every project task.

The current buildingSMART IFC Validation Service makes the same boundary explicit for a file preflight: it separates STEP syntax, IFC schema, normative IFC rules, and non-normative industry-practice checks. Project-specific rules and geometric visualization remain outside that service. A valid service result can therefore prepare the file for later acceptance checks, but cannot replace them.

Assign evidence and failure disposition

Name who produces or reviews each piece of evidence and decide in advance what happens when a criterion fails.

Criterion result	Responsible evidence	Possible disposition
Pass within scope	Report, comparison, screenshot, or downstream task record tied to the tested package	Accept for the named purpose and retain the scope.
Pass with restriction	Evidence shows a deliberate exclusion or a narrower usable operation	Accept only with the restriction stated in the delivery record.
Fail with recoverable cause	Diagnostic result identifies settings, dependencies, profile, or preparation to change	Correct the cause, preserve the original, and repeat the affected checks.
Fail with representation loss	A required layer cannot be recovered through the selected route	Choose another representation or route, or renegotiate the required layer.
Unknown	The test or source evidence does not establish the condition	Do not claim acceptance; assign a test or state the uncertainty explicitly.

The acceptance decision should be owned by the party responsible for the receiving task. Tools can produce measurements and reports, but a report does not decide whether the recipient’s work is safe to continue.

Use a deliberately non-universal template

This is a planning record, not a format-specific file syntax:

acceptance_case: "supplier machining handoff"
source:
  environment: "named source application and release"
  representation: "native or neutral form"
destination:
  environment: "named recipient application and release"
  task: "specific operation the recipient must complete"
route:
  direction: "source-to-destination"
  format_or_profile: "exact format, schema, profile, and version"
  translator_or_settings: "record if material"
required_layers:
  - "geometry: selected properties within agreed tolerance"
  - "assembly: required identities and references"
  - "PMI: named information and presentation checks"
criteria:
  - "observable check and evidence owner"
permitted_loss:
  - "explicitly acceptable transformation"
failure_disposition: "repair, alternate route, restricted acceptance, or reject"
evidence_date: "date of test"

Do not fill an unknown field with a plausible default. An omitted unit, profile, dependency, or acceptance owner is an exchange risk that should remain visible until someone resolves it.

Key points

Define the recipient’s task before the export.
Name the information layer and observable check rather than saying “complete.”
Keep syntax, conformance, preservation, task acceptance, and retrieval as separate claims.
Record permitted loss and the action for every failed or unknown criterion.
Treat a tolerance as an agreed condition for a stated comparison, not a universal threshold.