3MF Lattice Acceptance: Identify the Required Extension

3MF lattice acceptance needs more than a statement that the receiving application opens 3MF files. A delivered model can rely on an extension that carries essential geometry. The acceptance question is whether the agreed receiver supports that required information and whether the promised review has actually been performed. This article develops a documentation-based acceptance approach for a hypothetical manufacturing delivery. It does not open a model, evaluate lattice strength or approve a printing process.

Describe the geometry that the contract expects to preserve

Begin with the promised deliverable. Does the recipient need to retain editable beam-lattice information, inspect the represented shape, or receive a separately agreed converted representation? Those tasks can involve different evidence. A supplier should identify the intended geometry and the receiving workflow rather than using one generic file-extension label to cover every expectation.

For a fictional procurement example, imagine a manufacturing team receiving an enclosure with an internal lattice. The supplier provides a 3MF package and a preview image. The preview can explain the intended appearance, but it does not establish how the receiving application interpreted the lattice data. Acceptance should identify the exact package and the question the receiver is expected to answer about that geometry.

Locate the required-extension declaration

The official 3MF Core Specification describes requiredextensions as identifying extensions required to process a model-file. It says that editors and manufacturing devices must not process that model-file without support for its required extensions. This is a specific format rule, not a promise that every application advertising general 3MF support implements every possible extension.

Ask the supplier to identify the relevant declaration and the extension identity used by the delivered model. Retain that information with the receiving application's documented support statement and version. A reader should be able to follow the relationship between the package's requirement and the proposed receiver. A screenshot of an open window does not supply that relationship by itself.

The linked core repository source identifies itself as version 1.4.0, while the beam-lattice source used below identifies version 1.2.0 and its relationship to Core 1.x. Preserve the applicable version context rather than treating a repository branch as an immutable source. A detailed acceptance record should retain the reference snapshot used for its exact claim.

Read why the lattice data cannot simply disappear

The official 3MF Beam Lattice Extension requires a producer using its lattice specification to mark the beam extension as required. It also allows a mesh containing a beam lattice to have no triangles. A triangle-only expectation can therefore miss an important part of what the supplier intended to deliver.

This does not establish that an unknown package is defective or that a particular viewer ignored its content. It establishes a focused question: what representation was supplied, what required support was declared, and what did the receiving workflow actually interpret? Do not resolve that question by removing an unfamiliar requirement and then calling the altered package an unchanged original.

If a conversion is part of the agreement, identify it as a separate transformation with its own source, output and explanation of retained meaning. A converted surface representation might meet a defined review purpose, but that conclusion needs the actual scope and observations. It should not be assumed to preserve every editing capability or every property of the original lattice representation.

Agree on an observable receiving check

The recipient and supplier should specify which object or region will be reviewed and which evidence will show that the intended lattice content is available for the agreed task. Keep the check in an authorized software setting and preserve the original package. This article does not prescribe a viewer, automate an import or claim that a demonstration has already succeeded.

A support statement and an observed import answer related questions. The statement describes the claimed capability of a particular application version; the observation describes what happened with a particular delivery. Retain both if the acceptance depends on both. If only documentation was reviewed, the conclusion should say so and leave the package-specific receiving result unresolved.

Limit the acceptance decision to the promised deliverable

A useful conclusion names the package, required extension, receiver context and observations actually obtained. It should distinguish representation acceptance from manufacturing acceptance. Preserving a lattice in a digital workflow does not establish its material properties, fatigue behavior or suitability for a production process. Those questions need their own design, process and inspection evidence.

The two original diagrams illustrate acceptance relationships without reproducing a real lattice or fabricated import result. Related discussion is available in the 3D manufacturing integration collection and the article directory. Linking the required-extension declaration to the receiving task makes a 3MF delivery review concrete while keeping untested software and physical claims outside the decision.