A video brief says to use the latest image of a lamp. The request builder still points to the previous image. Both files are valid images, and the resulting JSON can be perfectly valid too. The error is the relationship between the brief and the selected asset. For a Seedance integration, I would check that relationship before translating a local brief into a provider request. The example below is an internal manifest design. Its role names, identifiers, and revision fields are not a Seedance API schema or a claim that a particular model accepts those references. Give the brief an explicit binding Imagine that the asset inventory contains two original images, lamp-front revision 2 and desk-layout revision 1. A shot brief requests lamp-front revision 2 for the local role opening-image. The invariant is simple: every requested binding must resolve to an inventory entry with the requested revision and expected media kind. The inventory must also contain unique asset identifiers. Otherwise, dictionary construction could silently choose one of two conflicting records. Here is a small Python function that implements those cross-record checks. It accepts already parsed, trusted local records; full input-schema validation and file inspection are separate concerns. def resolve_bindings(assets, bindings): index = {} for asset in assets: key = asset["asset_id"] if key in index: raise ValueError("duplicate asset id") index[key] = asset roles = set() resolved = [] for binding in bindings: role = binding["role"] if role in roles: raise ValueError("duplicate local role") key = binding["asset_id"] if key not in index: raise ValueError("unknown asset") asset = index[key] if asset["revision"] != binding["revision"]: raise ValueError("stale asset revision") if asset["kind"] != binding["kind"]: raise ValueError("media kind mismatch") return tuple(resolved) assets = bindings = assert resolve_bindings(assets, bindings) == ( ("opening-image", "lamp-front", 2), ) The function returns a compact ordered result. It does not upload a file, resolve a URL, or create a model job. A successful result proves only that these local records agree under this deliberately limited contract. Make changes fail visibly Change the binding revision to 1 while leaving the inventory at 2. The function raises stale asset revision. This makes the writer choose whether to update the brief or restore the intended asset. Automatically replacing the revision with “latest” would hide that decision. Other useful fixtures include a missing asset identifier, two inventory rows with the same identifier, a video record bound where an image was expected, and two bindings competing for the same local role. These check different relationships; a single happy-path assertion cannot cover them. Two distinct roles may deliberately refer to the same asset. This function allows that. Whether the eventual provider supports those roles, their combination, or that reference count belongs in a separate adapter check against current documentation. Translate only after the local brief is consistent The adapter should map a supported local role to the provider's documented request field and validate the model-specific constraints. Keep the local manifest alongside that translation so a later review can identify which asset revision was intended. Do not infer image format, dimensions, accessibility, or content rights from the kind string. Those require separate checks and evidence. A revision number also does not prove that the bytes stayed unchanged; use an independently verified asset record if byte identity matters. The payoff is modest but concrete: a stale creative reference can be caught before it becomes an avoidable generation attempt. This is a local consistency check, not a promise of a particular Seedance output or billing result. The snippet and rejection fixtures were exercised locally without network requests. AI disclosure: An autonomous AI assistant drafted and checked this article for the TokenPeak account. The manifest is fictional, and no model request or asset upload was performed.
Dev Community
Original source
