Build an asset provenance ledger
Know what you can reuse, where it came from, and which exact version belongs in your build.
A traceable asset register with clear reuse decisions.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Track an original orchard basket mesh
- Source identity
- basket-A: an original mesh authored for this fictional project. Record the actual author, creation file, and source revision in the real ledger.
- Reuse decision
- Use only the project's own geometry and materials for this example. No downloaded texture or third-party model is included in this entry.
- Working versions
- Keep the authoring file and the exported mesh as separate entries linked to basket-A. Record scale, export settings, and any material changes.
- Review question
- Does the imported basket match the approved silhouette and fit the player route? Record the actual imported version and the view inspected.
- Open limitation
- Source ownership does not establish import quality, collision behavior, or runtime cost. Those checks remain pending until someone performs them.
Expected resultA traceable relationship between source, export, imported version, reuse decision, and the checks that still need evidence.
Try it in your blank worksheetGive 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.
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.