Build Log
Cache Keys Are Part of Publishing
Publishing an image is not the same as replacing it on every screen where it may appear. The v6 social-card refresh made cache behaviour part of the release design, not an afterthought.
The stale-image problem
A social preview is usually fetched by another system, stored, and reused. Updating the bytes behind an old filename can therefore leave a platform showing the previous card long after the website itself is correct. That is not a rendering bug in the page. It is a mismatch between the site’s release model and an external cache’s lifetime.
The release answered that uncertainty with a new asset path: images/og-image-v6.png. Every Open Graph and X card reference moved to that path. The filename became a simple cache key, giving crawlers a resource they had not seen before instead of asking them to notice changed bytes at an old address.
One visual system, four crops
The card pack covers Open Graph, X, square-feed, and story proportions. Each version uses the same berries-and-cream palette, Public Sans wordmark, Bitter campaign headline, and exact umbrella mark as the website. The layouts are regenerated from a script so a future identity change can propagate without manually redrawing four unrelated files.
An image audit checks dimensions, modes, and expected outputs. The HTML then points to one designated Open Graph image while the broader pack remains available for channels with different crops. This separates generation, verification, and publication into explicit stages.
What became standard
Immutable-looking assets need versioned names or query keys when external systems cache aggressively. Visual QA also belongs beside technical QA: a file can be the right size and still crop a headline, overlap a logo, or lose contrast at thumbnail scale.
The public evidence is visible in the current homepage metadata, the matching About page identity, and the consistent mark throughout the Build Log.