Asset Lineage and Provenance
Original, project-agnostic instructions. Agent-host effectiveness remains experimental.
When to use
Track immutable asset identities and derivation operations with versioned metadata, integrity checks, and explicit access, privacy, and retention boundaries. Use for an actual task in this domain, under the consuming repository’s approved policies.
When not to use
Do not impose this procedure on unrelated or trivial work. Do not migrate tools, install services, perform production effects, publish, or delete resources without the task’s required authorization.
Inputs and tailoring
Resolve the task goal, accepted source/contract baseline, relevant paths, installed versions, actual project-owned commands, effect policy, and required evidence. Read existing configuration before asking for information it already contains. Concrete repository roots, credentials references, command bindings, and private policies belong in the consuming adapter, not this public skill.
Procedure
1. Establish the boundary
Separate byte/version identity from access URLs. Signed URLs expire and renew without changing the asset. Record media type, length, checksum algorithm, and storage version where available.
2. Choose the supported contract
Connect inputs, transformations, outputs, and execution identities. Record observed model/provider version, approved parameters, and source revisions. Distinguish multi-input compositions, partial outputs, and failures.
3. Implement or qualify the path
Preserve metadata through crops, transcodes, captions, thumbnails, voice changes, and exports. New bytes produce derived identities. Validate cross-resource references against tenant/access policy.
4. Exercise failure and integration seams
Keep personal source images, voices, prompts, and consent records protected. Apply approved deletion/retention rules to derivatives and shared references. Provenance metadata does not confer usage rights or establish consent.
5. Verify and hand back evidence
Test missing parents, forbidden cycles, repeated imports, digest mismatches, expired URLs, partial failure, and cross-tenant links. Reconstruct a synthetic transformation chain and verify referenced bytes where possible.
Output
Return a task-sized implementation or review record containing the accepted invariant, source/environment identity, concrete decisions and changed paths, actual check results, evidence locations, remaining uncertainty, and next action. Distinguish passed, failed, blocked, and not-run checks; package shape is not behavior evidence.
Failure handling
A provider does not expose the model revision: record unknown provenance instead of inventing reproducibility, seeds, rights, or consent. When access or prerequisites are unavailable, preserve existing work and report the smallest missing input. Do not fabricate commands, results, compatibility, or successful external effects.
Example
A synthetic illustration becomes a thumbnail and captioned video; each has its own bytes and derivation record, while renewing a download URL creates no new asset. This is a synthetic example, not a completed production or agent-host run.
Evaluation
Use references/scenarios.json for intended, boundary, and non-trigger evaluation inputs. Keep their status not-run until a separate real host evaluation records actual outcomes.
Technical references
Consult documentation for the installed versions before using version-sensitive APIs. These are underlying-technology references, not copied upstream skill bodies.
Bind composition to current dependencies
Include the accepted storyboard/narration/caption identities in a render handoff, not only the media filenames. A scene replacement creates a new candidate and invalidates affected continuity checks. Preserve old accepted output while the replacement is being qualified; possession of an asset hash is not proof of usage rights.