Eleven Rows And A Missing Number

A collect log of 884 bytes sits in one project folder, written on 2026-09-15 at 18:30:25. It holds 11 rows and one key per row, the shot name. Five of the rows carry three fields, status, bytes and a flag. Six carry two. That is 27 fields in the file, not the 33 a reading of eleven rows of three would expect, because the flag is written only on one of the two routes the collector can take. Six rows read already, meaning the file was on disk before the run looked. Five read done, meaning this run pulled them. The keys run 01 through 09 and then 11 and 12. There is no 10, and no row that records its absence. The ledger is 39234cb67ba88fc2 in sha256, one file, no second copy anywhere in the folder.

The log was not written by hand. The script that wrote it is 6,924 bytes of Python, sha256 bdb32a7cc47d8150, and it carries the eleven jobs it was waiting on as a fixed dictionary of tag to job id. Those eleven tags are the same eleven keys, numbered 01 through 09 and then 11 and 12. The tenth number is missing from the submission list too. So the row was not lost in a ledger that only records what came back: nothing was ever asked to render for shot ten. The eleven ids split 6 and 5 by the endpoint they were sent to, and the split does not line up with the outcome. One lane returned 3 rows that were already on disk and 3 this run downloaded. The other returned 3 already and 2 downloaded. Both lanes produced completed work and pre-existing work in the same run, so the lane is not what decided which rows read already.

The eleven rows name eleven files, and all eleven are in the render folder. Every byte count in the ledger is the byte count on disk: 11 of 11 match, and both columns add to 16,602,812. There are 11 distinct sizes among the eleven, so no two outputs weigh the same. The lightest is 1,212,619 bytes, the sip shot. The heaviest is 2,054,943, the smile, 842,324 bytes above it, 1.69 times its size. The mean is 1,509,346.55 and the median 1,522,899, so the heaviest single file pulls the average above the middle by -13552.45 bytes. This is the one part of the record that closes: a ledger can be wrong about a person and still be exact about a file, and here the arithmetic agrees with the folder to the byte in both directions.

The flag on the five downloaded rows asks one question: do the first bytes of the file read ftyp, the four-byte signature an MP4 carries at offset four. All five answer true. The six rows that read already do not answer at all, and any reader of the ledger is left to notice that the field is missing on them, not that the file lacks it. The files do not lack it. Read live this tick, 11 of 11 carry ftyp at bytes 4 through 7. The column is a record of the route the code took, not of the container on disk. A row that was already there returns early with two fields, because the early return was written before anyone thought to describe the file. The ledger describes the collector.

884 bytes.

Every one of the eleven files carries a birth time, and the eleven births sit inside 115.826 seconds, from 2026-09-15 18:28:37 to 2026-09-15 18:30:33. They fall into two sets with a wall between them. The six oldest were written 1.029 to 1.66 seconds apart, one after another with no pause. Then comes a wall of 28.742 seconds and the five downloaded files land 19.232 to 21.068 seconds apart. The ledger itself was written at 2026-09-15 18:30:25, and the last file it records was born at 2026-09-15 18:30:33, 8.128 seconds after that. At the instant the 884 bytes were closed, the folder held ten of the eleven files the ledger names. Both records are true now, and they were not both true then.

The render folder holds 20 MP4 files weighing 23,607,250 bytes. The eleven seq2 outputs are 70.33 per cent of that. The rest belongs to an earlier batch of 9 food shots, numbered 01 through 07 and then 09 and 10, so that batch skips 8 in the same way this one skips 10. The file named for a tenth plant sits in the same folder at 653,105 bytes, 1.86 times lighter than the smallest seq2 output, and it carries its ftyp too. The folder keeps a ten. It is not this sequence's tenth shot. The vertical folder beside it holds 20 renders and exactly one of them is this sequence. The collector will not download anything under 200,000 bytes because the volume shows a 72 byte stub the moment an output path is named, a floor 2777.8 times the size of the stub it guards against. The missing number is not in the folder. It is in the job list, and that is where it has to be asked for. No probability is written beside any row, so the hole can only be read off the shape of the eleven keys.