calesthio/generative-media-skills/asset-continuity-management

Asset continuity management

Use this skill to keep generated-media projects reproducible, reviewable, and visually/aurally consistent across many assets, revisions, tools, and deliverables. Treat continuity as a production control system: every asset gets an ID, every change becomes an event, every derivative points back to its sources, and every continuity-critical choice is captured before more generation compounds the mistake.

This skill is provider-independent. Do not assume any particular generator exposes seeds, request IDs, input hashes, content credentials, prompt logs, or model versions. Capture them when available; explicitly record unknown, not_provided, or not_applicable when they are not.

Core rule

Never manage continuity by memory, filenames alone, or chat history alone. Maintain a project-local continuity package with three living records:

1. asset_manifest: one row/object per file or generated unit.
2. source_reference_ledger: one row/object per source, reference, prompt, seed, model/tool context, approval, and rights/usage constraint.
3. continuity_bible: canonical descriptions and locked references for characters, products, locations, wardrobe, brand, voice, music, captions, and recurring design motifs.

If the host pipeline already has artifact schemas, map these records into the native schemas rather than inventing parallel files. If no schema exists, use structured JSON, YAML, CSV, or tables that can be diffed and reviewed.

What to record first

Before generating or editing media, create the minimum continuity control plane:

• Project ID, client/title, date, owner, delivery platforms, target languages/locales, and review contacts.
• Asset ID pattern and file naming pattern.
• Storage locations for working files, approved masters, review exports, source references, and rejected/archived variants.
• Approval policy: who can approve character likeness, product accuracy, brand/legal claims, accessibility, voice, localization, and final delivery.
• Escalation triggers for legal/client review. Do not give legal advice; pause for counsel or client approval when rights, likeness, trademark, claims substantiation, licensed references, synthetic voice/face consent, regulated products, political/medical/financial claims, or platform disclosure obligations are in scope.

Recommended ID pattern:

<project>-<type>-<scene_or_unit>-<role>-v<major>.<minor>

Examples:

• aurora-img-s03-heroProduct-v1.0
• aurora-vid-s05-brollCity-v2.1
• aurora-aud-narration-enUS-v1.3
• aurora-cap-final-esMX-v1.0

Use IDs as stable production identifiers. Filenames may change for delivery, but the asset ID should remain traceable through manifests, review notes, embedded metadata when possible, and final handoff.

Asset manifest fields

For every asset, capture as many of these fields as apply. A strong manifest favors explicit unknowns over blank cells.

asset_id: aurora-img-s03-heroProduct-v1.0
status: draft|candidate|approved|rejected|superseded|delivered
asset_type: image|video|audio|music|sfx|voice|avatar|caption|project-file|prompt|reference|composite|delivery
role: hero_product|character_ref|location_plate|wardrobe_ref|voice_take|music_bed|caption_track|final_master
scene_ids: [s03]
shot_ids: [s03_sh02]
file_path: projects/aurora/assets/images/aurora-img-s03-heroProduct-v1.0.png
checksum_sha256: "<hash after write>"
byte_size: 4821138
duration_or_dimensions: "2048x1152"
format_codec_profile: "PNG; sRGB" # or "MP4 H.264 High, AAC 48kHz"
colorspace_loudness_or_fps: "sRGB" # or "23.976 fps", "-16 LUFS integrated"
created_at_utc: "2026-07-10T18:41:00Z"
created_by: agent|human|vendor|tool
tool_provider: "not_provided|provider name"
tool_name: "not_provided|tool name"
model_or_engine: "not_provided|model id/version"
model_version_verified_at: "2026-07-10" # volatile; re-check at production time
request_or_job_id: "not_provided"
seed: "not_provided"
parameters:
  aspect_ratio: "16:9"
  guidance: "not_provided"
prompt_id: prompt-s03-heroProduct-v1.0
source_ids: [src-product-packshot-v1, ref-brand-board-v2]
parent_asset_ids: []
derived_asset_ids: [aurora-img-s03-heroProduct-v1.1]
c2pa_or_content_credential: present|absent|external|not_checked
embedded_metadata_checked: true
rights_usage_notes: "Client-owned packshot reference; no third-party logo beyond approved brand."
review_notes: "Approved for product shape, color, logo placement."
approval_record_ids: [approval-brand-2026-07-10-01]
supersedes: null
superseded_by: aurora-img-s03-heroProduct-v1.1
retention: keep_master|keep_review|archive|delete_after_delivery

Do not rely on generated filenames from providers. Rename or copy outputs into the project storage convention, then compute a checksum and record the original provider path or URL separately if it matters.

Source and reference ledger

The source/reference ledger is the evidence trail. It should answer: "What did this asset depend on, what did we ask for, what did the tool return, and what constraints apply?"

Capture:

• source_id: stable ID for each reference, source clip, brand file, script, storyboard, prompt, negative prompt, seed bundle, voice sample, music reference, font, LUT, product spec, character sheet, or location reference.
• Origin: user-provided, generated in-project, licensed stock, public-domain, client-owned, commissioned, captured, synthetic, unknown.
• Custody: who supplied it, when, where it is stored, checksum, and whether the original is preserved.
• Rights and consent notes: usage scope, territory, duration, likeness/voice permissions, trademark/brand restrictions, and "needs counsel/client confirmation" flags.
• Generation context: provider/tool/model/version, seed, request ID, endpoint or UI, prompt text, system/style constraints, reference images/audio/video, parameters, safety or policy changes, and date verified.
• Continuity tags: character, product, location, wardrobe, brand, language, shot, sequence, campaign, platform.
• Approval events and rejection reasons.

Provider/platform rules are volatile. Re-check production-time rules for disclosure, content credentials, watermarking, model availability, pricing, supported inputs, retention, commercial-use terms, and safety policies when a project will ship publicly or commercially.

Continuity bible

Create canonical entries for anything that must remain consistent. Each entry should contain the locked description, approved reference assets, banned variations, and QA checklist.

Use entries like these:

character:
  id: char-maya-v1
  canonical_description: "Late-30s field engineer, warm brown skin, shoulder-length black curls, amber safety glasses, navy utility jacket with orange stitching."
  locked_reference_assets: [maya-turnaround-v1, maya-face-close-v2, maya-wardrobe-v1]
  invariants:
    - face shape and hair volume
    - amber safety glasses
    - navy/orange jacket
    - calm, competent posture
  allowed_variations:
    - jacket may be zipped or open
    - helmet on/off depending on scene safety
  forbidden_variations:
    - different hair color
    - logo on jacket unless brand-approved
    - age shift younger/older than brief
  approval_required_for:
    - face regeneration
    - wardrobe redesign
    - synthetic voice or avatar use

product:
  id: product-orbit-bottle-v1
  canonical_description: "Matte white insulated bottle, rounded square body, teal cap, vertical ORBIT wordmark centered on front."
  locked_reference_assets: [orbit-packshot-front-v1, orbit-packshot-side-v1]
  invariants:
    - silhouette and cap color
    - exact approved wordmark placement
    - no invented claims, certifications, or UI labels
  forbidden_variations:
    - misspelled logo
    - unapproved ingredient/feature claims
    - altered capacity or materials

Also create entries for:

• Locations and sets: geography, era, weather, signage, layout, props, time of day.
• Wardrobe and styling: garments, colors, accessories, makeup, hair, continuity by scene.
• Brand system: logo usage, colors, typography, UI, tone, claims, disclaimers, lower thirds.
• Audio identity: narrator voice, pronunciation dictionary, music motifs, sound design palette, loudness target.
• Avatar identity: avatar ID, consent source, voice ID, language constraints, gesture style, lip-sync notes.
• Caption/localization style: reading speed, speaker labels, subtitle format, terminology glossary, do-not-translate terms.

Scene and shot linkage

Every production unit should link scene/shot intent to assets and edit decisions:

scene_id: s03
shot_id: s03_sh02
story_function: "Reveal product solving the setup problem."
continuity_requirements:
  character_ids: [char-maya-v1]
  product_ids: [product-orbit-bottle-v1]
  location_ids: [loc-lab-v1]
  brand_ids: [brand-orbit-v1]
required_assets:
  image: [aurora-img-s03-heroProduct-v1.0]
  video: [aurora-vid-s03-productPushIn-v1.0]
  audio: [aurora-aud-s03-vo-enUS-v1.0]
edit_decisions:
  - cut_in: "00:00:18.500"
  - cut_out: "00:00:23.000"
  - transition: "match cut from blueprint line to bottle edge"
  - caption_asset_id: aurora-cap-master-enUS-v1.0
qa:
  - product wordmark readable and correct
  - character glasses remain amber
  - no extra invented text in background

For film-style or multi-shot video generation, link generated clips to the beat they cover. If a generated clip contains multiple internal shots, describe the internal shots with approximate time ranges and note any continuity breaks inside the clip.

Versioning and regeneration controls

Use semantic production versions:

• v0.x: exploration, not approved.
• v1.0: first approved candidate for the unit.
• v1.x: minor fixes that preserve the approved concept, composition, and identity.
• v2.0: material change to prompt, model, seed, reference, edit intent, identity, product design, or approval basis.

Before regenerating, decide whether the goal is:

1. Repair: preserve identity/composition; adjust defects only.
2. Variant: same approved concept; explore controlled alternatives.
3. Replacement: new creative direction or provider/model path.

Regeneration checklist:

• Lock the parent asset ID, prompt ID, seed, references, model/tool version, and continuity bible entries.
• State which fields may change and which must not change.
• Use the same seed only if the provider supports it and seed behavior is documented or observed for that provider. Seeds are not a guarantee across model versions, providers, or changed reference inputs.
• If model/tool version changed, record it as a material change even when the prompt is identical.
• Keep rejected outputs when they explain a decision, contain a useful partial element, or document a client/legal rejection. Otherwise archive according to the retention policy.

Prompt and decision logs

Keep prompt records as first-class assets, not throwaway chat snippets.

prompt_id: prompt-s03-productPushIn-v2.0
target_asset_role: video product push-in
scene_ids: [s03]
prompt_text: |
  A controlled studio push-in toward the matte white Orbit bottle...
negative_prompt: |
  misspelled logo, extra labels, altered cap color, warped bottle shape...
continuity_constraints:
  character_ids: []
  product_ids: [product-orbit-bottle-v1]
  location_ids: [loc-studio-v1]
references:
  - source_id: orbit-packshot-front-v1
    purpose: "shape/logo lock"
  - source_id: brand-board-v2
    purpose: "color and lighting"
parameters:
  aspect_ratio: "16:9"
  duration: "5s"
  seed: "123456789"
model_context:
  provider: "provider name or not_provided"
  model: "model name/version or not_provided"
  version_verified_at: "2026-07-10"
change_reason: "v2 uses approved packshot reference after v1 distorted cap."