The copy had to become permission to delete.
Moving a golf video off the iPhone was easy. Proving that the phone copy could be safely removed was the real system.

The physical iPhone held 32 Swing Trainer recording packages. We copied them to the marked Mac data root, checked every transfer receipt and hash, decoded every movie, and only then cleared the application recording directory on the phone.
That supervised recovery freed the storage. It did not prove that a future recording could safely remove itself.
Sending bytes was never the hard part. The hard part was deciding what evidence could authorize destruction after a network connection, app process, or phone failed at any instruction boundary.
A completed upload is not permission
Transfer progress cannot authorize deletion. Neither can a connection closing cleanly, an unsigned acknowledgement, or a file merely appearing on the Mac.
The receipt now has to bind the exact transfer, session, capture, package hash, manifest hash, file set, byte count, atomic Mac commit, and trusted Mac signing key. Only the production verifier can mint it, and only after the local archive is complete.
The iPhone keeps a crash-recoverable journal with distinct pending-transfer, pending-deletion, and removed states. Before unlinking anything, it reopens the exact movie, manifest, and annotations without following symbolic links and rechecks length and SHA-256 against the receipt. If anything changed, the phone keeps its copy and reports failure.
That means uncertainty has one safe outcome: retain the data.
The policy defaults off
The user-facing switch says Delete iPhone copy after verified Mac archive. It defaults off and remains visible while disconnected. Changing it later cannot rewrite the history of packages already queued; each recording snapshots its own keep-or-delete choice.
Older recordings get a separate one-row action, Archive to Mac & Remove from iPhone. That request covers one exact app-owned package. It is not a remote file browser, a generic delete capability, or authority over the Photos library.
The Mac has its own independent switch, Accept iPhone offloads, also defaulting off. Pairing alone grants nothing. With the switch enabled, the Mac revalidates the chosen local root and admits one exact authenticated capture identity. It requests no video bytes until that authority exists.
The evidence is still bounded
The full iOS suite executed 285 tests with one physical-only skip. The Mac suite executed 504 with zero failures. Those tests cover forged or early receipts, mutated files, interrupted cleanup, relaunch recovery, replay refusal, identity mismatch, and exact review reconciliation.
They are automated evidence, not the physical end-to-end result.
The supervised recovery proved that the existing 32 packages were preserved on the Mac and removed from the phone. It did not exercise the new automatic policy or the one-row archive action through a trusted paired iPhone and Mac. Those gates remain open.
That boundary is the point of the design. A system that handles original media should not ask, “Did the transfer look finished?” It should ask, “Can this exact signed receipt prove that this exact package is safely committed somewhere the user chose?”
Only then does a copy become permission to delete.