The Index That Counts Its Own Reuse

The whole library is 1 file of 311,525 bytes, schema 2, written by the reuse refinery on 2026-09-11 at 15:51:22 and held under 1 vault root. It describes 303 assets weighing 1,811,635,097 bytes in total, which is 1.81 gigabytes. Read the record instead of the folder and 3 things arrive at once. The library is small enough to hold in 1 list of 303 lines. It is completely tagged, because every 1 of the 303 carries at least 1 tag and the vocabulary runs to 229 distinct tags across 12 projects. And it is almost entirely unspent, which is what the rest of this piece is about. Each of the 303 records carries 1 file name, 1 project, 1 media type, 1 kind, a duration, a frame size, a codec, a size in bytes, an mtime, an aspect, an orientation, a tag list and a canon block naming the shot and the version. The oldest file dates from 2026-04-22 and the newest from 2026-09-09, so 1 index holds 141 days of work. The index stops at what it can measure. Almost nothing in it is an opinion.

The field that decides whether a library is an asset or a hoard is the use count field, and it leans in 1 direction. 286 of the 303 records read 0. 11 read 1. 1 reads 2. 5 read 3. That is 17 files of 303 that have ever been spent, which is 5.6 per cent of the library, so 94.4 per cent of it has never been used once. The 2 fields beside it agree without being asked. 17 records carry a last used date and they are the same 17. The other 286 carry nothing there. That is not an oversight. It is the index declining to invent a date it does not have. 0 records carry a note. The heaviest single file in the library, a 207,654,087 byte final in the Salvador tree, has been used 1 time. The second heaviest, 206,686,647 bytes in the same tree, has been used 3 times. Both are finals, both come out of 1 project and both are under 2 gigabytes of library that mostly sat still. The difference between them is not quality. It is whether a cut reached for it.

The 17 spent files are not spread evenly across the work. 5 of them read 3, and those 5 are 4 finals and 1 shot: a 206,686,647 byte Salvador concat, a 128,100,856 byte Sal y Miel final, a 60,714,422 byte complete cut, a 29,533,006 byte shorter cut and a 44,714,996 byte Apocalypse shot. 1 still of 165,134 bytes sits at 2. The other 11 sit at 1, and 6 of those 11 are the 6 shots of 1 TikTok sequence, The Map Is Dead, at 942,435, 1,005,825, 514,670, 746,688, 1,628,094 and 13,353,644 bytes, plus an annotated reel of the same sequence. So the busiest fifth of the used set is a handful of finals from 1 project and the second busiest is 1 whole sequence pulled once and never revisited. The other 286 files have no history at all. A 64,213,163 byte Salvador shot sits outside the used set. So does every 1 of the 182 images in the index except 1. Reuse is not evenly distributed and it is not random. It clusters on the files that finished something.

The index does not call all 303 files usable. It marks 226 reusable and refuses 77, and the refusal is itemised rather than vague. 43 carry a non reusable kind flag, 30 carry a reject marker and 4 carry both. 220 records carry no flag at all. The 226 reusable files weigh 1,485,664,095 bytes, which is 82.0 per cent of the index, and the 77 refused files hold the other 325,971,002 bytes. Split by kind, the reusable 226 read 119 stills, 101 shots and 6 finals. Split by media type across the whole index the 303 read 118 video, 182 image and 3 audio, and the same measurement inside the reusable set reads 104 video, 119 image and 3 audio. Read the reusable set by frame and it holds 177 landscape, 38 portrait, 9 square and 2 audio files that carry no orientation at all. The video is 1 codec, 104 of 104 at h264, at 2 frame rates, 77 at 24 and 27 at 30, and the durations run from 3.4 seconds to 206.17 seconds. The project split is lopsided in the same direction as everything else here: 189 of the 303 assets and 147 of the reusable 226 come out of 1 project.

303 assets, 1,811,635,097 bytes, 1 file of 311,525 bytes.

The index finds its own duplicates instead of hiding them, and it finds them by measurement rather than by name. There are 2 clusters. The first pairs 2 files at 2,913,390 bytes, 10.12 seconds and 1366 by 768. The second pairs 2 files at 1,736,476 bytes, 5.88 seconds and 1366 by 768. In both cases the 2 paths are 1 render filed under 2 spellings of 1 folder name, Nolan One-Shot and Nolan OneShot, so the match reads on bytes, duration and frame rather than on the text of the path. Only 4 files in the entire index sit at 1366 by 768 and 2 of them are those pairs. The rest of the library spreads across a long tail of frame sizes: 76 files at 1280 by 720, 56 at 2816 by 1584, 34 at 2752 by 1536, 26 at 848 by 480, 25 at 1344 by 768, 20 at 720 by 1280 and 13 at 1920 by 1080. A folder that reports its own duplicates to its owner is worth more than a folder that quietly holds them, because the second kind turns into 2 bills for 1 render and nobody can say when.

The spine is simple. A library that writes a 0 beside 286 of its own files is a library that knows what it holds and is honest that nearly none of it has been spent. The number that matters is not 303. It is 17. My view, formed from building systems that had to account for what they deployed, is that the probability a file gets spent is not a property of the file. It is a property of the index around it. Entrade built 200 wood gasification machines on the same arithmetic, which is that the second unit only costs less than the first if the first one's parts are on a list somebody actually reads. The same counting shows up wherever the work has to keep running past the first job: EX Venture carries 35 staff and 200 interns a year, and what keeps that survivable is that the things they do not have to rediscover are written down. 229 tags, 12 projects, 303 records in 1 file of 311,525 bytes and 286 zeroes printed rather than smoothed over. The index is not the library. It is the part of the library that can be argued with.