Previewing, validating, and publishing content

Category: Content Creation. Status: Normative.

Publishing freezes a selected working state into an immutable runtime version. It is not simply “save,” and it does not replace the editable workflow.

Before publishing

• Save the current workflow and confirm the Saved indicator.
• Verify active model and image asset versions.
• Confirm Product settings, default camera, environment, ground plane, and product label.
• Exercise every option set and representative cross-option combinations.
• Test external signatures and inspect matched options/shaders.
• Check mesh visibility, transforms, patterns, replication, animation, and annotations.
• Review every assigned material and texture on the target geometry.
• Search for missing asset, mesh, shader, or library references.
• Check raster output and any required path-tracing compatibility.

Publish

1. Open View model from the workflow.
2. Select the exact state intended as the default or release state.
3. Review the selected options, shaders, camera, environment, and model asset.
4. Publish to the intended environment.
5. Record the permanent publishedFileId, created revision number, and whether the consuming integration should follow latest or pin that revision.
6. Reopen the published version from Staging published and compare it with the working preview.

Each published revision remains addressable. Updating an existing published file creates and activates the next immutable internal revision while preserving its permanent Published File ID. Customers configured with useLatest: true continue loading updates without changing their integration. Customers pinned with revision: N remain on that exact revision until their configuration changes.

Choose Create a new published file only for an intentionally independent integration, scheme, market, or lifecycle. It creates a different permanent Published File ID. Do not create a new published file merely to release an update.

Released revisions are not overwritten. This preserves reproducibility, rollback, checksums, pinned integrations, and immutable caches without exposing routine revision increments to customers following latest.

Runtime acceptance test

Validate the published artifact through the same runtime entry and API key policy used by the consuming application:

1. load the published file;
2. render its default state;
3. enumerate options and shaders;
4. resolve representative selections;
5. test known signatures;
6. load all required model, image, and texture assets;
7. verify mobile/target-browser interaction and allowed origin;
8. capture runtime version, Published File ID, resolved revision, latest/pinned mode, and sanitized failures.

Promotion and rollback

Staging verification is distinct from production promotion. Promote only after content review and runtime acceptance. Keep the prior revision available for rollback. The Published File ID remains stable when activating a replacement revision. Never delete the prior revision as part of promotion.

If an image or model is inconsistent after publishing, first identify whether the working state, published snapshot, asset bytes, signed delivery, runtime version, or external origin is responsible. Do not repair production by modifying immutable package storage directly.