Operations · Guide
The same filename does not mean the reviewed file arrived
Check controlled file versions and actual byte digests while keeping integrity, content review and authorization separate.
The same filename does not mean the reviewed file arrived
Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.
English transcript · Simplified Chinese Mandarin transcript · Taiwan Mandarin transcript · Macao Cantonese transcript
A handoff sheet before the print run
Imagine a small U.S. print shop. AI helps assemble a brochure; a designer reviews the exported PDF. After upload, another file with the same name replaces it. “Uploaded” says an action happened, not that the receiver has the reviewed bytes. This is a hypothetical handoff exercise, not a customer incident or product announcement.
- Same PDF name ≠ reviewed bytes
- Export → controlled handoff → received file
- Hypothetical print shop · No customer incident
Unchanged original source explanatory diagram.
Freeze the bytes, then write the receipt
Our suggested handoff record identifies the completed export, its version, byte count, algorithm and full digest, such as SHA-256. The receiver recomputes that digest over the actual downloaded file. A filename or screenshot is not the comparison. S3 documents checksum-based upload and download integrity verification.[1] That illustrates a mechanism, not a promise that every tool enables it by default.
- Object: completed export
- Receipt: version + size + algorithm + full digest
- Receiver: recompute and compare
Unchanged original source explanatory diagram.
Three results, three routes
A matching digest advances to content review, not straight to printing. A mismatch preserves both copies and stops this handoff for investigation of transfer or conversion. A missing digest means unverified, not “looks identical.” These are our proposed operating rules. The trustworthiness of the expected value remains a separate question.
- Match → content review
- Mismatch → stop and preserve evidence
- No trusted expected value → unverified
Unchanged original source explanatory diagram.
A string is not an identity badge
If both the file and expected digest come from an untrusted source, someone could replace both and still produce a match. A digest is not proof of authorship, correctness or permission to act. RFC 9530 separates integrity mechanisms from authentication, authorization and privacy; digest fields can be combined with signatures.[2] Keep expected values in an authenticated, controlled handoff channel.
- Digest: integrity evidence
- Not identity, correctness or authority
- Expected value: authenticated and controlled
Unchanged original source explanatory diagram.
A conversion creates a new object
Compression, re-export or metadata changes can alter bytes. Our recommendation is to retain separate digests for the original and derivative, with a conversion relationship—not change the file and reuse its old receipt. HTTP also distinguishes message-content digests from representation-data digests; encoding and the selected object matter.[2] The integration team must specify exactly what is being compared.
- Original digest → conversion → derivative digest
- New bytes need a new receipt
- Define the layer and algorithm
Unchanged original source explanatory diagram.
Rehearse with synthetic files
Try four acceptance cases: an unchanged copy passes; a one-byte change stops; an authorized conversion receives a new record; and a missing trusted expected value is marked unverified. This is a proposed test, not one performed on a customer system. Keep “bytes verified” separate from “content approved.” AAHouse’s versioned-approval guide explains why the decision must still identify a specific version.
- Unchanged copy passes; changed byte stops
- Conversion: new record; missing value: unverified
- Byte check ≠ content approval
Unchanged original source explanatory diagram.