Inside an Asset Review: How We Inventory a Drive Step by Step

The inventory is a spreadsheet with one row per item group, not per file. Raw footage by shoot day, project files by edit, exports by delivery. A drive with thousands of clips becomes a list of a few dozen lines that a producer can read in one sitting.

For each line I record location, approximate size, last modified date, and whether anyone on the team can tell me what it is. That last column matters most. A folder nobody can identify is a risk regardless of how tidy its name looks.

I use the file manager's own sorting and a directory listing export rather than anything exotic. The method has to be repeatable by a production manager who has never done it, because the point of teaching it is that the team can run it again next year without us.

Duplicates are the easiest finding to explain and the most common. Camera originals copied to a working folder and then copied again to a delivery folder is a pattern I see on almost every drive. Sometimes the copies are identical, sometimes one has been trimmed, and telling those apart is part of the exercise.

Gaps are quieter. A project file that points to media that is no longer on the drive. A final export with no matching project. A shoot day with footage but no notes. These are the findings that matter when someone needs to reopen a job two years later.

I mark each one as confirmed, probable or unclear. Learners often want to delete on sight, but a review records and classifies. Deciding what to remove is a separate conversation with the people who own the material.

Once the inventory is done, I read it again looking for single points of failure. A final export that exists in only one place. A project that lives on a personal drive. Footage with no second copy and no one assigned to look after it.

I rank risks by how hard they would be to recover from, not by how likely they feel. A lost proxy file is an annoyance; a lost master export is a client conversation nobody wants to have.

Each risk gets a plain sentence describing what could go wrong and a note on what information would settle it. That keeps the findings honest. Where I cannot tell, I say so and list the question, rather than guessing and presenting a guess as a fact.

The written review is short on purpose. A summary page, the inventory, the findings grouped by theme, and a list of suggested next steps in a sensible order. Producers tell me they read the summary and the next steps first, so those get the most care.

Suggestions point towards the later modules: a folder structure, a naming convention, metadata, version rules. A review does not build any of that. It shows where the drive is today and what the team might want to decide next.

Any hands-on file handling, such as moving or renaming material for the team, is scoped and agreed separately. I keep that boundary clear in the document so nobody assumes the review quietly includes a clean-up.