transfer-evidence
Reading transfer and recovery evidence
A receipt-v1 CLI pull now writes one transfer-evidence: {...} JSON line to stderr when it
returns after opening a valid receiver checkpoint. The record describes the latest successfully
persisted checkpoint, including on a failed command. A crash can prevent this log line; the
checkpoint remains the recovery authority. Legacy pulls do not emit this stronger evidence.
| Field | Meaning |
|---|---|
schema | Evidence format version, currently 1 |
phase | receiving, durable, restoring, failed, or restored |
expectedBytes | Source artifact size; omitted until an artifact descriptor is known |
durableBytes | Absolute count of the receiver prefix synced and checkpointed |
artifactVerified | Completed stream and reconciled artifact size/SHA-256 |
receiptAcknowledged | Receiver persisted confirmation of source acknowledgement |
restoreApplied | Restore command returned success and that result was persisted |
applicationVerified | Always false: this transfer path does not verify application recovery |
Replace byte gauges with each snapshot. Never sum them: retries can report the same prefix,
and reconnect alignment can shorten it to a complete frame. durableBytes == expectedBytes
alone does not imply a complete artifact: a completion trailer or digest check can still fail.
A failed restore can therefore have all bytes durable, an acknowledged receipt, and
restoreApplied: false. A lost ACK response leaves acknowledgement false until confirmed.
An explicit restore retry can finish without downloading the artifact again.
The library's PullDurablePinWithEvidence observer receives snapshots after successful checkpoint
publication. The CLI retains only the latest one and emits a final report, not a live progress
stream. The record contains fixed fields and no keys, endpoints, paths, artifact hashes, IDs,
raw errors, database names, or response bodies. Existing command logs have their own access
requirements. Sender-emitted counts and unsynced received bytes are unavailable here and are
not invented. No new persistent telemetry schema or metrics endpoint was added.
Dashboard proof levels
Restore-drill telemetry reporting files materialized into scratch storage now displays Files restored, with an explicit statement that database and application recovery remain unverified. Repository check results display Integrity only. Malformed counts, absent proof, and failed drills cannot upgrade these labels. A successful move-run status alone cannot mark missing phase evidence complete. Route checks are labelled separately from application recovery.
The native drill's byte/file counts describe observed scratch contents; they do not reconcile an expected application dataset. Full data recovery still requires a live fingerprint/digest comparison. H4's configured health checks remain separate local journal evidence; they are not automatically attached to a transfer or promoted into dashboard application verification.
No automatic DNS cutover, deployment, or production recovery certification follows from these reports. See ordered recovery for those checks and their limits.