The Index Is Checked Before The Render

On 14 September 2026, at 16:13, the library was scanned and the stamp was written to the minute. 158 video assets across 10 projects. The auto-use rule sits at the top of the file, above every row of the catalog: before rendering any shot for new content, find the index for an existing clip, match on project, tags and duration, and reuse it. After any render, scan, so the library grows. That is the entire instruction, and it is written as a step rather than a preference, because a preference is the thing a deadline overrules. The order matters more than the wording. Render first and the folder fills with near duplicates that nobody can tell apart 3 months later. Find first and the same folder behaves like a stock library with 1 owner. 1 find, 1 scan, 2 orders of work. The difference is which 1 runs first. The probability that a team re-renders a clip it already owns is high when the search step sits after the render instead of before it, and the bill is not the render fee. It is the version confusion that follows.

The index is not prose. It is asset_index.json, generated by the video-library skill, and every row is a record with fixed fields: the clip path, the kind, the duration, the resolution, the frame rate, the byte size, the tags and the reuse counter. 158 rows. All 158 read root, because these are the master files rather than proxies. 44 of them are 1920x1080, 36 are 1280x720, 26 are 848x480, 12 are 1344x768, 11 are 720x1280, 9 are 1080x1920, 8 are 768x1364, 4 are 1366x768, 4 are 1284x716, 2 are 1270x726, and 1 test output sits at 720x480. Frame rate is 24.0 on almost every row, with 30.0 on the social cuts and 8.0 on that one test file. A list built like this can be sorted, diffed and queried. A folder of filenames cannot. The catalog is what makes the find step cheap enough to actually run at 23:00 on a shoot night, which is the only test that matters.

No row needs the file to be opened to be judged. A 7.0 second clip at 1280x720 and 24.0 frames per second is 1 decision, and a 19.2 second final at 1920x1080 is another. The durations cluster hard: 30 rows at 8.0 seconds, 29 at 7.0, 16 at 5.9, 12 at 14.4, 10 at 6.0, 10 at 5.0, 9 at 15.0 and 3 at 10.1. Byte size runs from 65.0KB on a 2.1 second test output to 50.4MB on a single 30.0 second shot at 1280x720. 1 project holds 67 of the 158 assets, a second holds 40, a third holds 19 and a fourth holds 12. Read that list without opening 1 file and the shape of the library is already visible: a long tail of short vertical cuts and a small head of finished 1920x1080 sequences. That is what a search step needs. Not a hope that somebody remembers. A row that answers the question.

Beside every row sits the reuse counter, and the counter is what does the arguing for you. All 158 rows currently read 0x. Not 3 rows, not the archive only: every one of them. That single column is the difference between a folder and a ledger. A 0x reading is not proof that a clip is spare. It is proof that nobody has ever come back for it, and those are 2 different facts with 2 different fixes. The first asks whether the asset is good enough to use. The second asks why the search never happened. A counter turns duplication from a debate into a reading. The probability of a duplicate render being caught by memory alone, on a team of 35 people and 200+ interns a year, is not high enough to plan around. The counter costs 1 column and settles the question the first time somebody queries it. Everything else in the index exists to make that column trustworthy.

Render first and the index is a graveyard. Scan after every render and it is an asset.

Every asset carries its version in the filename. The suffix .0V1.0. sits at the end of all 158 paths, so a second pass becomes .1V1.0. and both rows stay in the index side by side. Nothing is overwritten. A re-render is a new row rather than a lost one, and the older cut stays searchable instead of disappearing into a folder named final_final. That single convention is why the byte sizes in the catalog can be trusted as history rather than as the current state of a folder. 2 rows for 1 shot is not clutter. It is the audit trail, and it is what lets a cut be recovered when the 1 that was shipped turns out to be wrong. The same discipline holds at other scale in the same file: 200 wood-gasification machines across the UK and Europe were built from a fixed sequence that was tuned per site, and 210 energy systems were deployed across Africa and Asia on the same principle. Fix the shape, then version the instances.

The rule has 2 ends and they cost the same amount of time. Render first and the index is a graveyard: rows accumulate, none of them are read, and the same shot gets ordered again by somebody who did not know it existed. Scan after every render and the index is an asset, because the next brief starts with a query instead of a blank timeline. 158 assets, 10 projects, 1 scan stamp, 0 rows reused. That last number is the honest reading of the library as it stands, and it is not a criticism of the clips. It is a reading of the process. 1 rule, 2 orders of work, and the difference is which 1 you run first. A 393 page book and a 158 row catalog obey the same law. Write down what was made, in a form the next person can search, or the work has to be done twice. The probability that any media library stays usable without a written index is close to 0, and every month of delay makes the bill larger.