A visual regression check fails in a CI pipeline with a message saying the screenshot comparison did not match. Which images does the job need to publish for someone to triage that failure, and why is the highlighted diff image alone not enough?

## What each artefact tells you A failing comparison produces three images, and each answers a different question: - **Baseline** — the stored expectation. Answers "what did we agree this should look like?" - **Actual** — the screenshot captured in this run. Answers "what did the code produce this time?" - **Diff** — a derived image, typically the baseline faded out with the differing pixels painted in a high-contrast colour. Answers "where exactly do they disagree?" The diff alone is a heat map of disagreement with no content. A block of red pixels where a button sits could mean the button moved, changed colour, gained a border, lost its label, or is simply anti-aliased differently. You cannot tell which without the two source images, and the difference between those cases is the difference between accepting the change and blocking the merge. Alongside the images, publish the numbers: how many pixels differed, and what the thresholds were. That turns "it failed" into "14,000 pixels differed against a budget of 100", which immediately distinguishes a whole-component change from edge noise. ## Why CI is the place this matters The screenshots that failed were produced by the CI environment, not by a developer's laptop. Re-running the suite locally to "see the failure" often produces a different image, or no failure at all, because the rendering environment is not the same one. That is why baselines are normally generated by the same environment that runs the checks, and why the run's own artefacts are the authoritative evidence. There is also a review dimension: the person deciding whether the change is acceptable is frequently a reviewer or designer, not the author, and may not run the suite at all. If the evidence only exists inside a container that was destroyed when the job finished, the practical outcome is that people accept changes they never looked at. ## Making the artefacts usable A few things separate artefacts people actually use from artefacts nobody opens: - **Name files by the test and screenshot**, not by a run-scoped counter, so ten failures are ten identifiable components rather than `diff-1.png` through `diff-10.png`. - **Keep the three images together** in one directory per failing comparison, so triage does not mean hunting through a flat archive. - **Surface a link in the build output or the pull request**, because an artefact that requires knowing where to look is one nobody looks at. - **Set a retention period.** Screenshots are large and produced in bulk; keeping every run's images forever is a storage bill for data that is worthless a week later. - **Do not gate on a report that only exists locally.** If the reviewer needs the images, the pipeline must publish them, not print a path inside its own container. ## Common shape in practice Most frontend runners already write these three images into an output directory on failure; the CI job's responsibility is to upload that directory as an artefact even when the step failed — which usually means the upload step must be configured to run regardless of the previous step's exit status. Forgetting that is the single most common reason a team has visual tests that fail with no evidence attached.