Your China-based production partner has finished the model used in a product film. Now the ecommerce team wants an interactive version, and a distributor wants a file to inspect. Reusing the asset is sensible. Sending the same production package to both destinations is a separate decision.
A film approval covers selected images. A model release should also cover what the delivered file contains. ONCE proposes keeping a useful internal production master and commissioning a purpose-specific release copy, rather than treating every export as the same deliverable.
What the format can carry
The Khronos glTF 2.0 specification allows names for application uses such as display and defines extras as application-specific data. The glTF-Blender-IO project documentation explains that enabling Custom Properties exports those properties from most objects into the corresponding extras field. It also lists separate controls for exporting selected or visible objects.
We checked the relevant sections on October 25, 2026. These are documented mechanisms, not a newly announced security incident. They establish neither that your file contains confidential data nor that every viewer exposes every field. The actual export, its settings and the receiving environment must be checked.
Disabling one property option is not a complete release review. Geometry, object names, images and animation content can require their own inspection. This article is a proposed delivery method, not security certification or legal advice.
Keep the valuable master; release what the task needs
The production master may need editable relationships, material references and revision mappings for future films. A release copy serves a narrower task: a customer rotates the exterior, a buyer examines an approved configuration, or an authorised partner reviews a specified structure. Approve those uses separately.
Imagine a fictional desk-lamp launch. Only one base is currently sold, while the internal model may contain a future-base study, supplier identifiers and engineering notes. Those are hypothetical inspection targets, not findings about a real asset. If they exist and are outside the approved release, deal with them in the release copy—not by damaging the only production master.
Do not indiscriminately remove everything called metadata. An approved configurator may need dimensions, part identifiers or configuration fields. Required copyright and source attribution should remain. A minimal release means necessary, authorised content—not a broken model stripped of useful information.
A release record should cover more than a preview
For each delivery, ONCE recommends recording what stays, what is excluded and who confirms it across four groups:
- Geometry and hierarchy: approved parts, product revision and included structures.
- Names and properties: internal identifiers, notes and custom fields that are not needed outside production.
- Textures and motion: prototype markings, unreleased finishes and unnecessary animation content.
- Runtime and attribution: data the recipient actually needs, plus required copyright and source information.
Inspect the exported object list, resources and fields as appropriate, then review appearance and required functions in the intended viewer. A beautiful turntable cannot establish what fields remain in a package. A field report cannot establish that the material, rotation or configuration still works.
The review provider MeshMarkup's model handoff checklist, updated October 20, 2026, also discusses names, internal parts and inspection of the exported file. That is useful peer practice, not evidence of a universal inspection time or a guarantee for another platform. Our focus here is the separate public-release asset and its continuing relationship to the internal master.
Verify the package that will actually leave
Create a separate release working copy. Select the approved parts and resources, review names and properties, and export using agreed settings. Do not finish the task merely because an unwanted component is absent from the current viewport.
Have another authorised person reopen the actual export: inspect the agreed content categories and test rotation, materials, necessary animations and configuration in the receiving environment. Mark anything beyond the team's inspection capability as unchecked and assign it to an appropriate reviewer. Do not turn an incomplete check into “fully secure.”
Tie the approval record to a specific file version and, where practical, a checksum. The publishing team should receive that exact file. A later model, texture or export-setting change requires another check of affected items, not inheritance of approval from a different package. These steps do not promise to prevent every extraction, inference or misuse. Platform access controls and disclosure permissions remain separate work.
Price release preparation as work
Ask the supplier to scope release-copy preparation, object and field inspection, target-viewer testing, and rechecking after updates. The product owner approves what may leave; the production team prepares the export; the publishing team uses the confirmed package. An existing model does not mean every external use was included in the original order.
For ongoing ONCE content services, a useful commercial direction is to retain a controlled internal asset while making release preparation repeatable. Rebuilding everything and sharing everything are not the only two choices. This is a service-design proposal, not a claim about an existing ONCE system or measured savings.
Brief ONCE with the intended audience, receiving method, approved structures and available files. Define what may be delivered before agreeing preparation, checking and maintenance responsibilities.
