One Anchor For Ten Clips

Start with the weight. The ledger for one cafe sequence is 4,358 bytes. It names ten clips and every one of them is marked done. Beside it sit 18,444,988 bytes of delivered video, so the record weighs 0.024 per cent of the thing it describes. Ten rows, 6 fields each: status, url, file, bytes, render id and the reference. All ten rows carry all 6, and they carry them in the same shape. The ten row objects are 3,853 of those bytes, and the braces and commas holding them are the other 505. No row is short a reading. Written at 15:44:07 on 15 September 2026, 2.0 seconds after the last file landed and 7 minutes 50 seconds after the first. A file smaller than one still of the shoot holds the only account of what the machine produced.

The reference column is the finding. In all ten rows it holds the same string: one JPEG on a temporary file host. The string is 74 characters long, it appears 10 times, and those 10 copies are 740 of the ledger's 4,358 bytes. That is 17.0 per cent of the file taken by a single image. Under that column sit 10 distinct render ids of 36 characters each, every one of them inside its own url - 10 of 10 urls ending in the id of the row that carries them - and 10 of 10 rows pointing at one host, under one path. So ten separate jobs, ten separate outputs, and one shared image deciding what the person in every clip looks like. The stills index in the same folder does the opposite: eleven stills, eleven separate temporary links, one each.

The bytes column runs 1,343,863 to 2,941,462. That is a spread of 2.19 times across ten clips of exactly the same length. The mean is 1,844,499, and not one of the ten files weighs that. The nearest sits 61,870 bytes under it and the next nearest 61,732 over it. Ten files averaging 229,368 bytes for every second of film, while the range inside that average runs 167,112 to 365,778. Every clip measures 8.041667 seconds, 848 by 480, 24 frames a second, and 1,930 frames in all, which is 9,557 bytes a frame. The length was the part that got held constant. Everything else was left to the renderer.

All ten paths are absolute and all ten sit in one directory. Every path resolves, and every recorded byte count matches the file it names, exactly, 10 for 10. Those ten files were written between 15:36:14 and 15:44:05, 7 minutes 50 seconds apart, and the ledger was closed 2.0 seconds after the last of them. The prefix reads Documents, which looks like a second copy of the vault, and it is not: it is a link to the vault itself. So the column that looks wrong is right, and the column nobody would think to check is the one that repays the check. A ledger is worth exactly what can be verified against the disk, and this one can be verified to the byte.

Ten clips, one reference image.

Version one holds 18,194,412 bytes. Version two holds 18,444,988. Version three holds 23,139,855, and renames all ten files while it is at it. A fourth folder holds 0 files. Two more hold 20 each. Between the first pass and the second, all 10 of the ten clips changed while the total moved 250,576 bytes, or 1.38 per cent. One clip grew 411,382 bytes and another shrank 229,661. 18 log files sit in that folder, and the shared reference appears in two of them. The set moved far more inside than the total ever shows.

The probability that a single image on a temporary file host outlives the ten renders that depend on it is not zero. Most people price it at zero until the link stops resolving and nothing can be rebuilt. Ten ids of 36 characters, ten paths in one directory, ten files of 8.041667 seconds each, and one image holding all of it together. Keep the copy. Write the 6 fields. Check one row against the disk. The group of ten is a group because one thing held it, and the whole ledger is 4,358 bytes - less than 0.024 per cent of the film it accounts for.