Skip to main content
A logical creative can arrive before its destination is known. It may carry several equivalent trafficking representations—for example, inline display markup plus an Internal Redirect pair, or VAST 2.0, 3.0, and 4.0 URLs. Preserve those alternatives in one CreativeRepresentationSet revision, then resolve exactly one into an ordinary seller-bound creative manifest. This is not creative rotation or A/B testing. Every entry represents the same creative content through a different delivery contract. A representation set is scoped to one canonical format kind: every representation must share the same format_kind. Interchangeable packagings for different media types belong in separate sets or separate sync_creatives items—seller selection is choosing between delivery contracts for one format, not between media types. Selection chooses a representation_id. It never chooses or creates one of the variant identities.

​
Representation-set object

The set always means “choose exactly one compatible representation.” Arrays inside a manifest asset slot still mean repeatable cardinality; they do not mean representation alternatives.
creative_id identifies the durable creative. revision_id identifies this complete immutable buyer input state, and each representation_id is stable and unique within that revision. Ingestion stores every valid entry without invoking URLs, executing markup, resolving macros, or discarding an unsupported representation.

​
Revision identity

The complete representation set is the revision preimage. Producers remove exactly the top-level $schema, creative_id, revision_id, revision_content_digest, and name properties, serialize everything else with RFC 8785 JCS, and place the lowercase-hex SHA-256 in revision_content_digest. $schema is transport/schema-location metadata, not creative content. Other unknown fields and representation array order are significant. Producers and resolvers reject duplicate JSON member names, and resolvers recompute the digest before selection. Changing any representation, its source metadata, the set-level provenance, representation order, or another unknown revision-bearing field requires a new revision_id and digest. Renaming the set does not. Selecting, transcoding, macro-binding, or serving one representation does not mint a new revision. This extends the ordinary sync_creatives revision contract: the complete set—not the selected manifest—is bound to (creative_id, revision_id). Reusing that identity with a different digest or canonical content fails with CREATIVE_REVISION_CONTENT_MISMATCH. The selected manifest carries the verified digest so a downstream seller can retain the complete-set binding even when it receives only the derived output.

​
Seller-bound resolution

Resolution follows this order:
  1. Discover the destination’s product format option and seller-wide execution capabilities.
  2. Filter candidates by canonical format_kind and the selected format_option_ref.
  3. Apply the option’s asset shape and delivery-mechanism constraints.
  4. For VAST, intersect product and seller version sets.
  5. Normalize tracker defaults, bind one exact VAST/DAAST execution version, and match every first-class tracker against the destination’s tracker execution contract.
  6. Evaluate every declared macro against product and seller macro capabilities as a separate check.
  7. Select exactly one compatible representation.
The buyer may perform these checks locally from seller discovery and submit the selected ordinary manifest. On the wire, build_creative representation resolution is intentionally narrower: only the destination sales agent may advertise creative.representation_resolution.supported: true and accept a set. A standalone creative agent does not own the product or seller execution ceilings and cannot claim seller compatibility. Silent guessing is never allowed. The request carries representation_destination.product_id plus the exact effective product format_option. The destination seller verifies that declaration against its current product, every named placement/publisher narrowing, and its current seller-wide execution ceilings. When placement_refs is omitted, the output must satisfy the common effective contract for every placement where it may deliver. target_capability_id selects the seller’s creative-operation route; it is not a substitute for the inventory contract. Resolution requires explicit compatibility inputs. In particular, every video_vast source representation has an exact asset vast_version, while the selected product option and seller advertise non-empty plural vast_versions. An absent set is unproven and cannot be treated as accepting every version on this opt-in resolution path. When a first-class vast_tracker or daast_tracker has no sibling exact-version delivery document, representation_destination carries execution_vast_version or execution_daast_version. The value must belong to the destination acceptance set and is echoed in representation_selection. It joins the selected representation and output digest in the execution-review identity, so changing it requires re-resolution and ordinary re-review. Package assignment must preserve the same exact version. Equivalence is a buyer assertion, not something the set digest proves. The digest proves that the complete asserted set was not changed; it does not prove that two representations render the same ad or behave identically. A seller MUST apply its ordinary validation and review policy to the exact selected output before approving or serving it. The seller does not need to fetch, execute, or approve every unselected candidate, and it MUST NOT treat acceptance of one candidate as approval of another. Different sellers may select different candidates, but each selected output is separately submitted through sync_creatives and reviewed before it can serve. A later selection likewise requires an explicit buyer sync and ordinary re-review, so an unreviewed hidden candidate can never replace the approved execution. Pass a representation set to the destination seller’s build_creative route with the product contract and an advertised strategy:
This is a deterministic, single-output mode. It cannot be combined with generation or transformation instructions, transformers, refinement, evaluators, catalog sampling, creative/variant fan-out, brand-generation context, or media-buy/package tag-generation context. macro_values is the one permitted operation that may change the derived manifest: selection happens first, then declared build-time macro binding runs without changing the retained source set. Preview fields may request a sidecar render of that selected output, but preview inputs or context never authorize mutation of the manifest or its digest. A pure resolution response never carries build_variant_id. The output is the normal seller-bound manifest. representation_selection carries complete-revision lineage through sync_creatives and readback:
The paired redirect stays one asset. A receiver cannot combine its ad-request URL with another row’s click-through URL or update either half independently. selected_output_digest is SHA-256 over RFC 8785 JCS of a shared manifest projection. From either the returned CreativeManifest or its later CreativeAsset sync wrapper, remove exactly top-level $schema, representation_selection, creative_id, revision_id, name, tags, status, weight, placement_refs, placement_ids, and inputs; include every other field, including unknown delivery fields. The identical projection makes ordinary library wrapping and metadata-only edits digest-neutral while fingerprinting the selected seller-bound output separately from the source revision. A changed selection, macro binding, translation, or transcode may keep the same buyer revision_id, but it changes this output fingerprint.

​
Sync, review, and readback

On sync_creatives, the seller enforces two different invariants:
  1. (creative_id, revision_id, revision_content_digest) binds immutable buyer source content—the complete representation set, never only the selected entry.
  2. (selected_representation_id, selected_output_digest, execution_vast_version-or-null, execution_daast_version-or-null) binds the current seller-bound execution submitted for review.
Changing the source set requires a new buyer revision_id. Changing only the selected execution does not mint a buyer revision, but it is an updated creative and follows the ordinary re-review lifecycle; approval never transfers silently to different execution bytes. list_creatives returns the exact current representation_selection while that selected execution remains current. A downstream seller that receives only the selected manifest can verify its output digest and retain the asserted source-set digest, but cannot claim it independently inspected hidden source representations. Resolution is an explicit buyer-initiated operation, not a continuously reevaluated seller policy. After a selected output is accepted by sync_creatives, later product, placement, VAST, macro, or seller-capability changes MUST NOT cause the seller to rerun the strategy, replace representation_selection, or move the creative into re-review on behalf of the buyer. Those changes apply to future resolution requests and assignment validation. To replace the current execution, the buyer explicitly calls the destination seller’s build_creative route with the current destination contract and then submits the returned manifest through sync_creatives. build_creative alone does not mutate the creative library; the subsequent sync is the buyer-visible update that starts ordinary re-review. If a seller can no longer serve an already accepted execution, it MUST NOT silently substitute another representation. It uses the ordinary seller/system-initiated creative lifecycle and media-buy impairment surfaces, while preserving the exact selection lineage for audit. Buyers reconcile the status through creative.status_changed, list_creatives, and get_media_buys, then explicitly resolve and sync a replacement when needed. An independent seller-initiated re-review may evaluate the same pinned execution, but it does not authorize representation re-selection. Representation resolution is a trafficking-time destination choice, not a viewer- or device-time fallback mechanism. highest_compatible_vast means the highest exact VAST version accepted by the selected product and seller; it does not mean the highest version supported by a particular player or device. The selected representation remains pinned for every execution until the buyer explicitly resolves and syncs a replacement. Device-specific media selection, VAST wrapper fallback, and player compatibility remain inside the selected VAST document and its MediaFile alternatives. Buyers that need distinct device contracts must target separate product options or submit separate creatives; a representation set never authorizes runtime switching between its members. This version does not combine representation_selection with the sync-only localization mutation. A selected sync item MUST omit localization, including null, and the stored creative MUST NOT already have localization that omission would preserve. To migrate an existing localized creative, first submit a separate ordinary sync with localization: null and no representation_selection; only after that removal is accepted may the selected output be synced. Locale topology and materialized locale assets need their own explicit pre-binding projection; treating them as library metadata would allow served bytes to change without changing either review fingerprint.
Migrating an existing localized creative to representation selection is destructive and non-atomic. First, submit a sync_creatives item with localization: null to clear all locale assets — existing localized delivery stops while that sync is under review. Only after the null-sync is accepted may the selected output be synced. There is no atomic path: a re-review window exists between the two steps, and a buyer currently serving localized creatives will experience a delivery gap during migration.

​
Resolution failure

When no candidate works, return CREATIVE_REPRESENTATION_UNRESOLVED. error.details MUST conform to error-details/creative-representation-unresolved.json, with exactly one representation_rejections entry for every candidate. Unsupported representations remain in the immutable set; failure does not delete or rewrite them.
tracker_contract_mismatch and macro_unsupported are deliberately distinct. A seller reports the former with the manifest asset path, normalized selector identity, and destination option reference. Library-only sync_creatives can preserve a selected output and validate its structure, but package assignment must revalidate the trackers against the immutable package snapshot before spend.

​
VAST representations

One VAST asset declares one exact vast_version; a product option and seller declare accepted sets.
If the seller-wide ceiling is ['3.0', '4.0', '4.1', '4.2'] but the selected product accepts only ['3.0', '4.0'], the compatible candidates are VAST 3.0 and 4.0. highest_compatible_vast chooses 4.0 only after that intersection is computed; if multiple compatible candidates declare the same highest exact version, the first in representation array order wins. That strategy is valid only for a video_vast destination; using it for another format returns INVALID_REQUEST and never silently falls back. representation_order always chooses the first compatible entry. Resolution must never relabel the VAST 3.0 asset as 4.0.

​
Representation namespaces

CreativeRepresentationSet.representations[].representation_id identifies an equivalent trafficking representation within one creative revision. It is distinct from:
  • revision_id, the complete immutable buyer input state;
  • build_variant_id, a generated or transformed output leaf;
  • locale_variant_id, a buyer-authored localized asset set;
  • assignment weight or rotation groups; and
  • served variant_id, an agent-assigned immutable execution returned by get_creative_delivery.
Do not reuse values across these namespaces as a shortcut. Preserve the explicit representation_selection join instead.