Build artifacts are easy to blame. When a regression lands at 3 AM and the release manager wants to know what the UI looked like at 4 PM yesterday, a tidy folder of PNGs is not evidence — it is a rumor. I learned this the hard way reviewing a checkout-flow regression that turned into a three-day argument because nobody could prove which build produced the broken state. The fix was not a smarter diff algorithm. The fix was a trail: one PDF per change window, named, hashed, and linked to the commit that produced it.
This article is about the boring, repeatable discipline of turning PNG snapshots into a defensible PDF audit log without bloating your repo or your reviewers' inboxes. It assumes you already take screenshots during UI testing or manual QA, and it assumes those screenshots are not currently being archived in any structured way.
Why PNGs Alone Fail as Evidence
A PNG tells you what the screen looked like at one instant. That is fine for a bug report. It is not fine for a compliance review, a postmortem, or a "did this break between v3.4 and v3.5" question six months from now. Three things go wrong in practice.
First, naming drifts. Today it is homepage_v2_final_FINAL.png. Tomorrow it is homepage (1).png. By Friday nobody can reconstruct what each file represents. Without a naming convention that includes a build identifier and a target route, the screenshots become unsearchable.
