Conformance, Validation, and Fit for Purpose Are Different Claims
“Compatible” compresses several evidence questions into one word. A valid file may still lose the layer a recipient needs, and a scoped certification result may still leave the recipient’s actual task untested.
Use an evidence ladder
Report an exchange at the highest level the evidence actually supports:
| Level | Claim it can support | What remains open |
|---|---|---|
| Syntax or schema validity | The file structure satisfies the tested parser, schema, or syntax rules. | Whether the geometry, semantics, dependencies, or task are usable. |
| Scoped conformance | An implementation or file met the requirements of a named profile, model view, recommended practice, or test program. | Other profiles, directions, releases, models, products, and recipient tasks. |
| Named-property preservation | Selected source and destination properties agree under the stated comparison method. | Unmeasured properties and information layers. |
| Destination-task acceptance | The recipient performed the named operation with the received result. | Other operations, future changes, or broader product compatibility. |
| Future retrieval | A later retrieval test showed that the retained package and context could be interpreted for a stated future purpose. | Unplanned uses, future application behavior, and permanent editability. |
The ladder is cumulative only when each step is separately evidenced. A syntax pass is not a preservation pass; a preservation pass is not task acceptance; task acceptance today is not a future retrieval guarantee.
What a syntax check tells you
NIST’s STEP File Analyzer and Viewer describes checks for basic STEP format problems, including missing or extra attributes, incompatible or unresolved entity references, select-value types, and unexpected characters. Such a result can explain why a file fails to import or whether the tested structure has obvious errors.
It does not establish that an importer preserves the model’s geometry, assembly identity, PMI, editability, external dependencies, or downstream usefulness. State the parser, file, format/profile, and result; do not label the whole exchange “validated” unless the required higher-level checks were also performed.
What conformance evidence tells you
Conformance is always to something specific: an application protocol, schema, profile, model view, recommended practice, test corpus, or program rule. The STEP AP242 project distinguishes the formal standard from use cases, business requirements, and recommended implementation practices. A standard describes a representational contract; it is not evidence that every implementation supports every feature.
The buildingSMART certification model is a concrete example. Its testing is tied to particular IFC exchange requirements and a Model View Definition. It can combine automatic test routines, regression tests, export and import test cases, manual verification, and final reporting. A result from that system should identify the selected IFC scope, test assets, direction, release, and date. It should not become a general claim about all IFC uses or every project delivery.
The buildingSMART IFC Validation Service is a related but narrower example of file conformity. It separates STEP syntax, IFC schema, normative IFC rules, and non-normative industry-practice checks. The service does not check project-, national-, or organization-specific rules, and it does not provide geometric visualization. Its result therefore belongs at the conformity level, before project-specific and destination-task validation.
The 3MF Consortium’s published conformance-test repository shows why a test label needs its exact scope. Its suites pair 3MF Core with selected extensions and pin the specification versions used by those suites. A suite’s scope can identify what was intended to be tested; it does not establish a named implementation result or downstream acceptance.
ISO 10303-242:2025 is another useful example of scope without route proof. Its public abstract includes managed product data, configuration and change context, long-term archiving and retrieval, quality and inspection results, and verification and validation among the protocol’s scope areas. That scope reference does not show that a particular exporter, importer, profile, or receiving task preserves those areas.
What preservation validation tells you
Preservation validation asks whether named information survived the route. Select properties from the acceptance case and compare them directly.
NIST’s STEP guide describes validation-property groups for geometric, PMI, assembly, annotation, attribute, and tessellated information. Its geometric example compares values such as area, volume, or centroid from the originating and receiving CAD systems within an agreed tolerance. The result is meaningful because the property set, direction, units, file, and tolerance are explicit. It is still limited to those comparisons.
Do not turn a matching volume into proof that every face, tolerance, assembly relationship, or editable feature survived. Likewise, a visible annotation may establish graphic presentation while leaving its computer-interpretable semantic representation unproven. Report each layer separately.
What fit for purpose tells you
Fit for purpose is a destination decision. It asks whether the recipient can complete the operation that justified the exchange, using the received result and the agreed conditions.
Examples include:
- a supplier completing the named machining preparation;
- an inspector reading the required PMI and measuring the received geometry;
- a coordinator using the required object relationships and spatial context;
- a renderer loading the scene with its resources; or
- an archive operator retrieving and interpreting the preserved package.
The task test should be repeatable and bounded. Record the operation, input package, destination version, settings, observed result, restrictions, and evidence owner. “The model looks right” can be useful visual evidence, but it is not enough when the task depends on exact geometry, semantics, dependencies, or editing.
Keep the report qualified
Use a scope statement that travels with the result:
Tested: [source] -> [destination], [direction], [format/profile/version]
Model/package: [identifier, configuration, and dependencies]
Checks: [syntax, conformance, named properties, and task operation]
Result: [pass, restricted acceptance, fail, or unknown]
Proven: [specific layers and comparisons]
Not proven: [unmeasured layers, other versions, other directions, or other tasks]
Date and tools: [test date, checker, applications, releases]
This is especially important for historical evidence. NIST’s PMI verification material uses particular test cases, CAD releases, standards, and validation software, and warns against treating its results as a comparison of different current versions. Historical results can reveal test design and failure categories; they do not establish today’s product behavior.
Avoid common overclaims
| Overclaim | Responsible wording |
|---|---|
| “The format is lossless.” | “The selected properties were preserved for this route and purpose; other layers were not established.” |
| “The file is compliant, so it is accepted.” | “The file passed the named structural or conformance checks; destination-task acceptance is recorded separately.” |
| “The certificate proves compatibility.” | “The certificate covers the stated program scope, test cases, profile/model view, and date.” |
| “The import succeeded, so editing is safe.” | “The file opened; required editing operations still need to be tested.” |
| “The old test result still applies.” | “The historical result informs risk; the changed release or route requires current evidence.” |
Key points
- Name the object of every claim: syntax, profile, property, task, or retrieval test.
- Carry direction, version, profile, model, date, and tool context with the result.
- Keep standards and conformance evidence separate from implementation and destination behavior.
- Treat validation as scoped comparison, not a universal certificate.
- Say what was not proven; unknown remains unknown.