Transport custody ACK
What the ABSENT stage refers to — and what it would have proved.
In the Governance Trace, the fourth stage — transport custody ACK — is shown as ABSENT. This page describes the thing that is absent: the OT-04 exact-artifact transport custody acknowledgement. It defines no custody object of its own and mints nothing; every field and distinction below is transcribed from the implementation that landed in thelaplage/arcs-srs.
this specimen · NYT-OPENAI-LITIGATION-0001
custody ACK: ABSENT — No OT-04 transport custody ACK has been produced into Counterpedia for this specimen. Exact-artifact custody is therefore not claimed. ABSENT is not FAILED (the transport did not fail), not NOT_EVALUATED (no custody property was evaluated and left open), and not REFUSED (nothing was denied). No custody ACK is synthesized from the capture digest.
1. What it binds
The eight required fields
A custody ACK cannot be an operation-only or peer-only receipt, because its required fields bind the exact artifact itself. All eight must be present.
- The specific transfer this acknowledgement is for.
- The exact receipt whose bytes were received.
- sha256 of the exact received bytes — recomputed by the receiver, not copied from the sender's claim.
- The announced issuer of the receipt bytes.
- The declared SRS profile of the receipt (carried, not validated here).
- The peer that actually holds the exact bytes.
- The receiver's recorded observation time only — NOT trusted chronology for the underlying action or proposition.
- The exact size of the received bytes.
2. Where it sits
One link in a chain of non-equivalences
The OT-04 module keeps these facts strictly distinct. Custody acknowledgement is exactly one of them — it is not the ones before it, and it is not the ones after it.
- receipt_emitted≠
- receipt_announced≠
- receipt_fetched≠
- exact_bytes_received≠
- transport_custody_acknowledged≠
- profile_valid≠
- action_authorized≠
- output_true≠
- evidence_admitted
3. What minting requires
The receiver recomputes; it does not trust a flag
Requires
- The receiver independently recomputes sha256 over the exact received bytes.
- That recomputed digest equals the announced digest.
- The caller-supplied digest_valid flag is NOT trusted on its own — the mint boundary recomputes, closing the forged-result path.
Does not require
- profile_valid === true: a receiver can truthfully acknowledge custody of exact bytes that later fail, or have not yet undergone, SRS profile validation. Custody and conformance stay separate.
4. What it proves
Custody of exact bytes — and nothing more
Custody of those exact bytes at that receiver, and nothing more — a named peer holds the exact announced artifact.
It does not prove:
- That the receipt's profile is valid (that is a separate, later evaluation).
- That the underlying action was authorized.
- That the output or proposition is true.
- That the evidence is admitted to any standing.
- Any chronology of the underlying action — accepted_at is only the receiver's observation time.
5. The case it refuses
Why an operation-only ACK is impossible here
OriginTrail V10's #1778-class failure: a sender requires a complete assertion seal locally while the wire handoff omits it, so the acknowledgement binds the share operation/peer rather than the exact sealed artifact.
Because the ACK's required fields bind the exact digest, receipt id, declared profile and announced issuer alongside the receiver and transfer id, an operation/peer-only ACK is structurally impossible: there is nowhere to put a 'the operation succeeded' claim that is not also a claim about these exact bytes.
6. Where this contract lives
Provenance
- Repository
- thelaplage/arcs-srs
- Program
- ORIGINTRAIL-EXTRACTION0 / OT-04 TRANSPORT-CUSTODY0
- PR
- #60
- main commit
- e4878869226cbcfcc1f37bae54f52cb0ba0b72b2
- implementation
- tools/receipt_mesh.py (blob d64c0523376737d4dbddabc43795941d6b45c7be)
- contract doc
- docs/integrations/SRS_EXACT_ARTIFACT_TRANSPORT_CUSTODY_v0_1.md (blob 75c45983046168aeb8c803af91e867bafba9d966)
- status
- IMPLEMENTATION DRAFT / TRANSPORT-ONLY
- authority movement
- 0
What this drill-down does not claim
- This page describes an external contract; it defines no custody object and mints nothing.
- A custody ACK proves a named receiver holds these exact bytes — not truth, not conformance, not authorization, not admission.
- accepted_at is the receiver's observation time only, never trusted chronology for the underlying action.
- For this specimen the custody ACK is ABSENT, and ABSENT is not FAILED, NOT_EVALUATED, or REFUSED.
- AUTHORITY_MOVEMENT is 0.