A Still And A Clip Score Differently

The cutlist reads 14.6 seconds, 6 beats, 1080x1920 at 30 fps, -14.0 LUFS, 0 gaps. Then read what each beat actually is. The HOOK arrives as video at 768x1364 for 2.4 seconds off a 5.875 second source. The TURN arrives the same way, 768x1364 for 2.4 seconds. The 4 beats between them - BUILD, BUILD, PAYOFF, RELEASE - arrive as 1280x720 stills held for 2.4, 2.2, 3.2 and 2.0 seconds. So 2 of the 6 pieces are portrait and 4 are 16:9, and the frame they are all going into is portrait. Add the clock: both moving sources run at 24 fps and the delivery runs at 30. 4 of the 6 pieces do not match the frame they land in, and every moving piece does not match the clock it is cut to. The cutlist does not flinch on any of it. The FCPXML writes the same arithmetic in frames: 72/30, 72/30, 66/30, 72/30, 96/30, 60/30, which is 438/30 of picture, which is 14.6 seconds.

Every pick carries 1 number next to it. HOOK 6.2. context 4.612. proof 7.613. TURN 6.2. payoff 7.609. release 4.614. Sort them. The 2 highest scores in a 6 beat cut sit at position 3 and position 5 - the middle and the payoff. The hook, which is the beat that decides whether anything after it is watched, reads 6.2 and ties for 3rd. That ordering is the whole argument. A hook is not a good asset in the abstract, because the same 768x1364 file that scores 6.2 here is the hook of a second cut in the same tree and scores 6.2 there too. Nothing about the file changed. What changed is what it was asked to do. The score is a property of the pair, the asset and the beat, and the moment a filename gets reused across 2 cuts with different jobs, any score stored on the filename alone stops meaning anything.

The parallel cut ran those same 6 beats off the same underlying assets and delivered 4 of them as 848x480 clips instead of 1280x720 stills. context 5.942 against 4.612, a delta of 1.330. proof 8.942 against 7.613, a delta of 1.329. payoff 8.942 against 7.609, a delta of 1.333. release 5.942 against 4.614, a delta of 1.328. Four swaps, 4 deltas inside a band 0.005 points wide. The still is not worse because it is a still. It scores lower because a held still has no movement in it, and the movement is already in the library - the same scene exists as motion at 848x480, and the engine priced that at roughly 1.33 points per beat. Which means the interesting question is never whether a frame is good. It is whether this beat was ever a still in the first place. 4 beats here were answered with a still when a moving version of the same shot was sitting in the same library, and the cost of that choice is measurable, per beat, to 3 decimal places.

The cut was assembled from 6 distinct sources out of 2 projects, with 0 of the 6 used in earlier content and 0 frames filmed for it. The hook and the turn come off a TikTok Short-Film project at 942,435 and 514,670 bytes. The 4 stills come off 4 Sal_y_Miel images at 200,513, 148,250, 165,134 and 181,048 bytes. That is 2,152,050 bytes of source carrying 14.6 seconds of delivery, cut against a library of 303 indexed assets, with the bed taken from a single 4,524,124 byte music file that runs 206.160979 seconds at 175556 bps and gets trimmed to 14.6. Now the number that matters more than any of them: 0 gaps. Every beat in the map was filled. The parallel cut opened 10.0 seconds and reported 2 gaps, context and proof, both for the same reason - no reusable asset matches this beat - and it shipped 4 beats instead of 6. So the same library answered 6 of 6 beats in 1 folder and 4 of 6 in the other. Coverage is not a property of the library. It is a property of the map you bring to it.

Same asset. Same beat. 7.613 as a still. 8.942 as a clip.

Now the receipt, because a cutlist is a claim. The output block names 1 master: 03_Finals/v1.0/tiktok_short_film_social_hook_02_final.v1.0.mp4. Measured this tick, that file does not exist. What does exist is the paperwork around it - REVIEW.md at 2,690 bytes, a cutlist, an EDL at 1,927 bytes, an FCPXML at 3,438 bytes, and 2 text files at 30 bytes and 34 bytes holding the hook and the call to action. 01_Images, 02_Video and 04_Archive are all empty. So the folder carries a complete and correct decision record and 0 frames. Walk the 7 cut folders in the refinery and the same split shows up: 3 have no final master at all - sal_y_miel_social_hook_01, tiktok_short_film_social_hook_01 and this one - and 4 carry a full publish package. Every number in this article is real and every beat was cut, and none of it can be posted by anybody, including the person who made it. The probability that a folder with no master gets assembled again 6 months from now is not 1, and 3 of 7 folders are sitting in exactly that state right now.

Run the same test on the people side. Entrade built 200 wood-gasification machines across the UK and Europe, and 200 is a count somebody can walk and check. A EUR 75 million industrial group was restructured and 210 energy systems were deployed, and both are numbers a counterparty can recount from their own records. The book published on 8 April 2026 runs 393 pages, and anybody holding it can confirm that in 1 minute. Now apply the test to a cut. Either the master exists, or the arithmetic that would assemble it exists, and the difference between those 2 states is 1 file and a caption. 4 of the 7 folders here have crossed that line and 3 have not, and the 3 that have not are not missing the taste. The beat map in this folder is better than 2 of the 4 that shipped - 0 gaps against 2 gaps on a 10 second cut. What they are missing is the last 1 per cent of the work that turns a decision into an object. Keep more of yourself, for longer. A decision record is where that gets protected, and it is worth exactly nothing until the master sits beside it.