Manual Handoff with Provenance Round-trip

1. The problem: “sent to the editor” is not provenance

Assume a digest-bound media package is handed to an editor and three days later a file named final-v2.zip returns. If the record contains only that filename, a “done” message, and the editor's name, we still cannot prove which exact bytes the result derives from, what changed outside the automated pipeline, whether the returned manifest verifies, or who accepted the result. CON-021 turns that gap into an auditable round-trip.

2. The owned CON-021 boundary

This lesson owns the manual handoff, return lineage, and bounded acceptance/V06-exit record. Durable vault retention belongs to CON-019 and presigned transfer capability semantics belong to CON-020. We do not mint URLs or redefine retention policy here; we establish which artifact left, which Agent received it, what artifact returned, and which facts remain unknown or unresolved.

3. Bind the outbound entity before it leaves

Record at least outbound_artifact_id, outbound_digest, outbound_manifest_id, and, when applicable, outbound_package_digest. A filename is not enough. If the file is renamed tomorrow, the digest can preserve content identity; if bytes change, the returned object must be represented as a distinct Entity.

4. What PROV-O gives us

W3C PROV-O supplies Entity, Activity, and Agent concepts plus relations such as prov:used, prov:wasGeneratedBy, prov:wasDerivedFrom, prov:wasAssociatedWith, and prov:wasAttributedTo. A handoff can therefore represent the outbound package as an Entity, sending/editing as Activities, and sender/editor as Agents. These terms make lineage and responsibility expressible; they do not verify that a human declaration is truthful.

5. A handoff event needs an Agent and a receipt

An auditable handoff records a handoff_id, sender, recipient, timestamp, declared scope, and transfer_receipt_id. If the recipient is unknown or the receipt is missing, the system must not infer custody from a chat message. A correct state may be DEFER until the evidence is repaired.

6. Represent external work as its own Activity

Manual editing, format conversion, compositing, or asset replacement should be represented as an external-work Activity. Record the external tool or process when known. When it is not known, preserve UNKNOWN rather than inventing a tool or workflow. The goal is to make the off-pipeline boundary reviewable.

7. The change note is human evidence

A change_note states what work is claimed to have been performed. A checksum cannot replace it. A bag may be perfectly valid for integrity while the workflow still lacks evidence about what changed or whether new source material was introduced. If policy requires the note and it is missing, package validity alone does not close the round-trip.

8. What BagIt proves

RFC 8493 defines a valid Bag as complete with every manifest checksum successfully verified against the corresponding file. BagIt is therefore useful for package completeness and integrity on outbound and return. A valid Bag does not prove authorship, rights, approval, semantic correctness, or that the editor performed the claimed work.

9. Give the returned entity its own record

Even when final-v2.zip is byte-identical to the outbound package, record a separate returned_artifact_id and receipt event. The content digest can be the same while custody history differs. When bytes changed, bind the returned_digest and returned manifest to a distinct Entity and verify its integrity independently.

10. Record derivation explicitly and narrowly

When evidence supports it, the returned Entity may was_derived_from the outbound Entity and the edit Activity may use that outbound Entity. Do not infer that relation from a filename or vague statement. If the chain is incomplete, preserve unresolved_provenance=true or a typed gap; an absent relation is safer than fabricated lineage.

11. A new asset creates multi-source lineage

An editor may introduce a source asset that was never in the outbound bundle. The return is then not derived only from the outbound Entity. Represent the new ingredient as its own Entity with its own provenance. If that source cannot be traced, disclose the gap and keep the decision RESTRICT or DEFER; valid checksums do not erase provenance uncertainty.

12. Complete provenance is not acceptance

Even when outbound, return, and derivation evidence are complete, a human reviewer may reject the result. acceptance_state is a separate decision. The pipeline must preserve “provenance verified + reviewer rejected” and keep V06 exit blocked. Provenance answers where it came from; acceptance answers whether it may continue.

13. Preserve typed non-success states

UNVERIFIED, DEFER, RESTRICT, and BLOCK are meaningful states. A missing receipt, manifest mismatch, ambiguous outbound entity, missing change note, untraced new source, and reviewer rejection are different failure classes. One green workflow status must not flatten them into success.

14. Lab: Manual Handoff Round-trip Dossier & V06 Exit Record v1

lab://CON-021/CON021-LAB1 contains eight synthetic fixtures: a valid baseline, a byte-identical renamed return, a valid package without a change note, checksum failure, ambiguous outbound identity, missing receipt/recipient, an untraced new source, and reviewer rejection. For each case, derive eight evidence/decision fields. The objective is to keep integrity, provenance, and acceptance separate.

15. Transfer: disclose the new source and bound the lineage claim

In the transfer scenario, the returned package is checksum-valid and has a detailed change note, but one source asset was independently replaced outside the outbound bundle and its provenance cannot be traced. Declare that asset as a separate Entity, keep was_derived_from limited to supported lineage, preserve the open gap, and restrict V06 exit until the missing evidence is repaired. No filename or checksum should silently promote that uncertainty to PASS.

Official sources and claim boundary

• W3C PROV-O Recommendation: https://www.w3.org/TR/prov-o/
• RFC 8493 — The BagIt File Packaging Format (V1.0): https://www.rfc-editor.org/rfc/rfc8493.html

K1 and K2 are sourced facts rechecked on 2026-09-17. K3 (the digest-bound round-trip model) and K4 (keeping V06 blocked when decisive evidence or provenance remains unresolved) are MAKNOW design rules and are not presented as W3C or BagIt requirements.