DCC Pipeline Gates

Export, publish, source integration, and engine import are separate boundaries with different evidence. Gates keep a bad asset near its authoring context instead of allowing an ambiguous engine or build failure.

Separate export from publish#

An export is a local transformation from an authoring scene into an interchange or engine-facing representation. It may be repeated freely while an asset is being prepared. A publish is the controlled act that assigns an identity, runs validators, records provenance, and makes the result eligible for source integration.

A published asset should have a stable logical name, an explicit export profile, and a declared dependency set. The profile describes the transformation rules that matter to the engine, such as coordinate convention, unit conversion, axis policy, mesh processing, material mapping, animation sampling, and texture handling. Version the profile so a changed transformation is never mistaken for the same output.

Make publish inputs explicit#

The publish boundary should know the authoring source identity, export-profile revision, selected object or collection, referenced dependencies, and intended engine destination. Reject ambiguous selections rather than silently choosing a default. This turns an artist-facing action into a repeatable contract.

Make metadata deterministic#

Attach metadata that allows the pipeline to answer what produced an asset and whether two exports represent the same declared input. Use canonical field names, stable ordering, normalized paths, explicit units, and a documented encoding. Do not include volatile fields such as local machine paths, transient timestamps, or arbitrary export order in an identity calculation.

Record the asset logical name, immutable source reference, export-profile revision, dependency identities, content type, target destination, validator version, and output checksums. Keep human-readable notes outside identity fields.

Run validators in layers#

Run validators at the earliest boundary that can explain and correct a problem. Each failure should name the asset, rule, observed value, expected condition, and next action.

Validate before publish#

Local validation checks authoring-side structure: missing references, duplicate identifiers, unsupported transforms, invalid naming, unexpected scale, incomplete material assignments, or incompatible animation data. It should be quick enough to run before a publish attempt and should distinguish errors that block export from warnings that need review.

Validate the publish package#

Publish validation checks the generated package and metadata together. Confirm that required files exist, checksums match, paths stay within the declared destination, dependencies resolve to allowed identities, and metadata is complete. A package that cannot identify its source or export profile is not ready for integration.

Validate source integration#

Run integration validation after the published output enters source control but before it becomes available to downstream engine builds. Check that generated outputs and metadata move together, no unrelated temporary files are included, and the target branch or stream receives the expected asset set. This is where repository policy can prevent a partial asset update from looking complete.

Quarantine failures and explain them#

Failed publishes should enter a quarantine state rather than overwrite a previously approved asset or silently disappear. Preserve the submitted package, validator report, and source reference long enough for diagnosis, while keeping quarantined outputs unavailable to normal engine import and release assembly.

The failure experience matters. Present the rule that failed, the affected object or file, the reason, and a direct recovery action. Link repeated failures to the export profile or dependency contract that caused them. Avoid a generic “publish failed” message that sends authors to a separate team just to discover which field was invalid.

Preserve engine import evidence#

A successful publish is still not proof that the engine accepted the asset as intended. Capture import evidence from a clean or controlled engine import: the published identity, importer and engine version, destination, resolved dependencies, import result, and any warnings or errors. When visual or gameplay review is required, record the review boundary separately from automatic import success.

Use that evidence to detect a mismatch between DCC metadata and engine interpretation. It also gives a build engineer a direct path from an engine import failure back to the source reference and export profile.

Plan recovery before scale#

Recovery starts by locating the last approved publish and its metadata, then deciding whether to restore it or correct and republish the source. Do not repair a quarantined package by hand in the destination; that loses the evidence needed to reproduce the fix. If a validator or exporter changes, revalidate representative approved assets before allowing the new version to become the default profile.

Implementation sequence#

1. Map the current authoring, export, publish, integration, and import handoffs for one asset type.
2. Define a versioned export profile and the minimum deterministic metadata for that type.
3. Separate temporary exports from a controlled publish destination.
4. Add local, publish-package, and source-integration validators in that order.
5. Introduce quarantine storage and actionable failure reports before enforcing new blocking rules.
6. Capture controlled engine import evidence and connect it to the publish identity.
7. Test restoration and corrected republish paths with a known failed package.

Practical checklist#

• Export and publish have separate locations, identities, and permissions.
• Export profiles declare engine-relevant transformation rules and are versioned.
• Published metadata is canonical, complete, and free of volatile identity fields.
• Validators run at authoring, publish-package, and source-integration boundaries.
• Validation reports identify the asset, rule, condition, and recovery action.
• Generated outputs, metadata, and dependencies integrate atomically.
• Failed packages enter quarantine without replacing approved assets.
• Quarantined assets cannot enter normal engine import or release assembly.
• Engine import evidence records the published identity and importer result.
• Recovery restores a known approved publish or republished source through the same gates.

The goal is not to burden every export with ceremony. It is to make the path from authoring source to engine-ready asset deterministic enough that failures are visible, attributable, and recoverable.