# Build an asset provenance ledger

BerryBlox creator resources
Edition 1.0 · November 5, 2026

Know what you can reuse, where it came from, and which exact version belongs in your build.

Take away: A traceable asset register with clear reuse decisions.
Intermediate · 7 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Give each source one identity

Before importing a model, sound, image, font, or code module, give it a stable entry in your project register. Keep the original source separate from your working copy. A folder full of similarly named exports makes it difficult to tell which one was reviewed.

Roblox assets have platform IDs, but an ID alone does not record the creator's permission for your intended use. Preserve the source page, creator attribution, acquisition date, and terms you actually relied on. For an original asset, identify its author and editable source.

- **Register ID / asset type / intended use:** ____________________
- **Creator / original source URL / acquisition date:** ____________________
- **Permission or license evidence location:** ____________________
- **Editable original / working copy / platform asset ID:** ____________________

Source checked November 5, 2026: [Roblox: Assets](https://create.roblox.com/docs/projects/assets).

## Decide reuse before integration

Write a separate decision for each intended use: reference only, modify, redistribute, or include in a published experience. Permission for one use does not establish all of the others. If the terms are unclear, hold that asset and choose an original or clearly permitted replacement.

Inspect code-bearing models before use, including scripts in descendants and unexpected dependencies. Preserve your inspection notes. This worksheet does not scan files, grant rights, or certify that an asset is safe.

- [ ] The exact source and rights evidence are retained.
- [ ] Required attribution is present in the intended destination.
- [ ] Third-party components inside the asset have been considered.
- [ ] Unclear permission is marked held with a named next action.

- **Decision / reviewer / date:** ____________________
- **Required credit text and destination:** ____________________
- **Dependencies or embedded scripts to inspect:** ____________________

## Bind the review to the actual version

Record a version label and a file hash where practical. A preview of last week's mesh does not approve today's revised export. Keep the original, edited source, export, and preview linked under the same register ID, with a short explanation of what changed.

Technical integrity, visual fit, and game integration answer different questions. Record them separately so a successful import is never mistaken for an accepted appearance or a successful player test.

> Illustrative ledger: ORCHARD-CRATE-01, original mesh by your team; source v3; export v3; preview v3. Technical import passes. Handle silhouette needs review. Game integration is not tested. Keep the review open until the named gap is resolved.

- **Version / file identity / change summary:** ____________________
- **Technical check and result:** ____________________
- **Visual review and reference view:** ____________________
- **Integration build and route tested:** ____________________

## Keep the register useful at handoff

Give the next person the smallest complete package: selected editable source, export, chosen preview, permission record, and known limitations. Keep rejected versions as history without making them appear approved. Record which build consumes the selected export.

When you replace a source, update its consumers and repeat the affected checks. A stale register can be more misleading than no register because it creates false confidence.

- [ ] Each included asset resolves to a selected version.
- [ ] Held or rejected material is visibly separate.
- [ ] The receiving owner can locate the permission record and source.
- [ ] Replacement consumers and required retests are listed.

- **Receiving owner / build / included version:** ____________________
- **Missing materials / next action / owner:** ____________________

## Evidence and limits

This original editorial ledger organizes your evidence; it is not legal advice, a rights clearance, a malware scanner, or a collection of game assets. Roblox documentation explains platform asset identities; it does not establish your rights to any particular asset.

You may copy, adapt, and use this BerryBlox worksheet in your own projects and team handoffs. Third-party documentation and assets retain their own terms. No licensed production-kit source is included.