The Ten Rows Add To The Folder

A render log sits in one folder beside the files it describes. It weighs 2,468 bytes, sha256 7fd476928d65a997, and it was written on 2026-09-15 at 16:36:18. Inside are 10 rows and nothing else. Every row carries the same 4 fields in the same order: status, file, bytes, rid. Status reads done in all 10, not nine of 10, not one still running. The file column names 10 paths. The bytes column gives 10 integers. The rid column gives 10 ids. That is the whole document. It declares no duration, no frame rate, no resolution, no codec, no date, no cost, no checksum of any kind. A reader looking for the shape of the work will not find it here. A reader looking for the weight of the work will find it to the byte, which is a different and narrower thing, and it is the only thing this file set out to hold.

Take the bytes column in the order it is written: 3,576,324, 2,293,349, 3,040,517, 4,048,148, 1,302,981, 1,277,429, 1,538,035, 1,527,724, 2,032,882, 2,502,466. Add it up and you get 23,139,855. Now open the folder the ten paths point into. It holds 10 files and no others, and their sizes add to 23,139,855. The difference is 0 bytes. Not close. Not the same to three significant figures. The same integer. Every name in the log matches a name on disk, every recorded size matches the size on disk, and all 10 paths resolve at the moment of reading. The column itself runs from 1,277,429 on 06 juice to 4,048,148 on 04 overhead brunch, a spread of 3.169, 10 distinct values, a mean of 2,313,985.5 bytes, 22.0679 mebibytes of finished footage. And the column is not sorted. It is in the order the renders landed, which is the one ordering that carries information the folder itself has stopped carrying.

The folder still remembers when each file arrived. First write 16:29:32, last write 16:36:18, 405.786 seconds apart, which is 6 minutes and 45.786 seconds of work. Take the 9 gaps between consecutive files and the smallest is 44.487 seconds, the largest 45.896, the mean 45.087. Ten renders, each landing inside five seconds of forty five. That is a cadence, not a scramble: one shot every three quarters of a minute, all the way down the list. Now read the log's own timestamp against the last file's. It lands 0.001 seconds after it. One millisecond. There is no pause between the final render finishing and the receipt being written, which tells you the log is not a document somebody maintains. It is an artefact of the run, and the run wrote it on its way out of the door.

Every row ends with a 36 character identifier, and there are 10 of them for 10 rows, all distinct, all in the eight, four, four, four, twelve form. They are real identifiers in the sense a parser cares about. Read the ninth character of each and something odd appears. All 10 carry version 9. The identifier standard defines versions one through eight. It does not define nine, and it never has. The variant nibble, four characters later, is spread across four values instead: 8 in 1 rows, 9 in 2 rows, a in 2 rows, b in 5 rows. So the set is uniform where it should vary more and varied where it should be uniform, which is what a generator looks like rather than a specification. Sort the ids and the order changes, so they are not sequential and never were. They are the one column in the file that cannot be checked against anything outside it, and they are the only thing in the file that would survive a re-render untouched.

2,468 bytes for 10 renders.

Beside the render log sits a second document, 2,282 bytes, sha256 cde8d69da141d7f1, written at 16:35:37. Where the log gives 4 fields a row, this one gives a single field: a local path pointing at a link. There are 10 rows. Every link points at the same host, a temporary file service, over https, with a 12 character id and no two base paths alike. The 10 stills behind those links exist on disk and weigh 5,054,840 bytes between them, from 395,823 to 580,942. What the map does not carry is a hash, a size, a date or a copy. Nothing inside it can prove the file at the end of a link is the file that was sent. And the map was written mid run, 4.396 seconds after render nine landed and 41.281 seconds before render ten did. Read the two documents side by side and the ten subjects are the same ten, in the same order, row for row: overhead_table, overhead_hands, overhead_fruit, overhead_brunch, coffee, juice, eating, hands, sunlight, plants. What does not line up is the frame numbers behind them, which run 17, 18, 19, 20, 13, 14, 10, 11, 15, 16. Ten beats, one order, two numbering schemes, and 0.5 of the still folder's 20 frames covered.

The tree the log lives in holds 6 version folders, 71 files and 107,472,209 bytes. The log describes one of those folders and 14.08 per cent of those files, 21.53 per cent of those bytes. It is a precise record of a small slice and it never claims to be more. The cost of keeping it is 246.8 bytes of text per row, or 2,468 bytes of log to describe 23,139,855 bytes of footage, a ratio of 9,376 to one. The sibling map is cheaper and thinner still, 2,282 bytes to address 5,054,840, 2,215 to one, and every address in it is rented by the day. That is the part worth pricing. The probability that a re-render returns the same byte count is not zero, and it is small enough that most people treat these ten numbers as a guarantee without deciding to. Nothing in the log can catch the day the folder and the record stop agreeing, because the only thing that compares them is a person who happens to open both. A log that totals its folder to the byte is not proof of anything. It is a receipt from a machine that has not changed its mind yet.