Screenshots and version numbers rot first

What it is

Volatile visual and version dependencies are the tight couplings between a screenshot, recording excerpt, or hard-coded version number and one product state; a UI, platform, or release-channel change can invalidate them before adjacent prose. “Rot first” signals maintenance risk, not a universal ordering. A stable hardware image may last years while a price, policy, or command changes sooner. The aim is to expose dependencies, prefer durable semantic instructions, and give necessary visuals and version claims an update path.

Why it happens

A screenshot freezes layout, labels, data, language, authorization state, and device chrome at once. A change to any one can send readers toward a control that no longer exists. A literal version can similarly collapse an applicability range into a misleading point. Text paths are not inherently stable either: renamed controls and moved information architecture also rot. Describing task, object, and control semantics; maintaining structured applicability; and generating necessary visuals from a tested product state make change dependencies traceable rather than pretending change has disappeared.

Studying it

Build an asset-or-claim × product-surface/version/locale/platform dependency table and replay recent releases to see which changes invalidate images, paths, callouts, or version statements. Compare screenshot-only, semantic-instruction, and combined guidance on visual location and task completion, recording search time, misselection, zoom need, and screen-reader access. Interpret by task: spatial orientation and visual-state diagnosis may genuinely require an image, while a routine procedure in a familiar interface may not.

Where it stops holding

Screenshots may be necessary evidence for complex spatial relations, visual inspection, gesture regions, graphics tools, and platform differences; maintenance cost is not a reason to eliminate them. Versions can determine correctness in API, compatibility, security remediation, migration, and regulated guidance. State a support range, condition, or release date rather than vaguely saying “current version.” Alternative text communicates an image's purpose and key information, but cannot make a visually located interaction accessible by itself; provide an operable textual or structural route too.

Applying it

• Register source surface, build or release, locale, platform, state, semantic anchors, owner, and invalidation triggers for every screenshot, recording, and version claim. Product changes generate an impact manifest from these links.
• Prefer task, object, and stable control names, and keep version applicability in structured metadata. Do not make color, pixel position, or one unqualified version number the only instruction.
• When visuals are necessary, capture them from a specified build with controlled test data, separate translatable callouts, generate alternative text, and use visual diffs as review signals rather than automatic proof of error.
• Validate image and prose across target language, theme, text size, authorization state, and responsive breakpoint. Withdraw or mark an asset as an old version when it cannot be updated promptly, supplying current semantic steps or support.

Related

• Same group: T3.03.1 Outdated docs do more harm than no docs · T3.03.3 Content needs an owner and a review cycle
• Adjacent: T3.01.2 Headings, lists, and code blocks carry the scan anchors · T3.04.2 Multi-channel content needs a single source of truth
• Search terms: screenshot maintenance · version applicability · semantic annotation