A visible attachment card and an AI statement that it read the file still leave the question of what was actually read. In Northstar's recorded ZIP analysis, file-specific information was compared with the reply. Another path failed to read the ZIP, retained that failure and used selected sources converted to text for a separate check.
Do not declare reading success at the attachment stage
Native selection, service attachment readiness and a new answer are different events. Earlier articles separated selection receipts from server processing; this question comes afterward: did the AI actually handle information inside the material? Repeating the filename or saying it was uploaded is insufficient evidence of content analysis.
I chose comparison evidence beforehand, retaining local size and digest and comparing file-specific information with the reply. A few matching values still do not establish a meaningful review of the entire file. The scope of checked information must accompany the result if another worker is to reuse the evidence responsibly.
The ChatGPT case compared internal-file information
The historical public-source ZIP record compares manifest file count, one source entry's byte length and a SHA-256 prefix with the actual reply. During this writing task I reread the original ZIP locally, checked its saved size/digest and compared that entry with the expected values and recorded reply proof. This was not a fresh remote request.
Archive entry count and the manifest's source-file count need not be identical; their denominators must be named. The comparison supports particular internal information observed in the reply, not execution or semantic review of every source. A model's static evaluation score was likewise not promoted into an empirical success rate.
Do not overwrite the Gemini ZIP failure with success on another input
Another record reports Gemini being unable to read internal ZIP files. The visible attachment card was not used to label analysis successful. A separate Markdown input then packaged selected sources, with a file-only verification code and CSV calculation compared against the answer.
That material contained eight selected code files, two metadata files and an inventory of other paths. Listing a path differs from including its source body. Success with selected text was not relabeled as successful whole-ZIP handling or an audit of the latest entire source. Keeping the failed format and successful selected material distinct makes the record useful for later work.
State what is omitted when converting the input format
Conversion should not end with pasting everything because one format failed. Select files needed for the question and state their version and which entries are inventory only. The preparation script separates material creation from actual service delivery. This task read that code without executing its delivery portion.
Questions and conclusions must fit the supplied subset. A few selected functions cannot establish absence of defects in the entire program; matching a verification value does not prove a proposed fix without reproduction. Making input smaller should not make the resulting claim larger. The handover needs both the useful representation and its missing scope.
Reviewing records differs from testing the current service
Evidence here consists of historical reports, proof JSON, preparation code and a local ZIP comparison. The ChatGPT and Gemini outcomes belong to those versions and inputs. They are not introduced as a controlled claim about every current account or service. The purpose is an inspectable account of which file-specific facts were compared with which reply.
The separate generation observer compares new responses and media readiness; it does not unpack ZIPs or authenticate content reading. Passing its tests cannot establish successful file analysis. Attachment, response, material understanding and execution outcome need distinct evidence if the automation is to explain what it actually accomplished.
Leave a verifiable question after the statement that a file was read
A program accepting customer material should explain what it checked after saying received. File-specific values, calculations, version and inclusion scope make review more concrete than a vague summary. A single matching sentinel remains evidence of that check, not a certificate of complete understanding.
I want failed input formats to remain useful work material. Recording what could not be read and which alternative subset was confirmed helps choose preparation precisely next time. A maker account preserving verification scope is more useful for another workflow than an introduction collecting only successful outcomes.