sol. / home

Retrospective

Proof is not the same thing as a screenshot

Archive date marks the period this retrospective looks back on.

A useful image documents a specific state; it should not be asked to prove more than it shows.

A screenshot can be true and still support the wrong conclusion. It can show that an interface rendered, but not that the underlying action completed. It can show a game open in an emulator, but not that automation controlled it. It can show a concept with thoughtful composition, but not a shipped runtime. The image is evidence only when the claim stays inside the frame.

I have started treating project media as different kinds of proof. An official product image documents a released interface. A runtime capture documents a state that was actually launched. A redacted runtime can preserve that state while removing account identifiers, resources, chat, notifications, or device information. A concept communicates direction. These categories are not a ranking; they are a way to keep one kind of image from impersonating another.

Context matters as much as the pixels. A caption should say what the image is, when necessary, and what has been removed. Source paths, hashes, access dates, and commit identifiers can make later verification possible, but they still do not turn a partial capture into end-to-end proof. If the required state cannot be captured safely, the honest result is to mark the evidence incomplete rather than build a convincing substitute.

This discipline can make a portfolio less dramatic. A locked visual or a work-in-progress note does not fill space as easily as a polished mockup. I think the restraint is worth it. The purpose of evidence is not to decorate a claim; it is to make the claim inspectable. A screenshot becomes useful when I can say exactly what it demonstrates, exactly what it does not, and why it belongs beside the project.