01
Keep the observation narrower than the concern
A concern might be that a visitor cannot complete a form. A screenshot may show only that the submit button is covered by another element. RiskSeen could record those as separate fields: the visible condition and the possible consequence to investigate. That separation prevents a review note from claiming a failed submission when nobody attempted one. It also helps the next reviewer choose an appropriate action, such as checking the interaction at the affected viewport rather than repeating an unrelated visual inspection.
02
Make absence of evidence visible
An unreviewed page should not inherit a passed status from a neighbouring page. RiskSeen could use explicit labels such as captured, interaction checked and not observed. Each label needs a defined meaning. A capture at one width does not establish the layout at another width, and a result from an older release may no longer apply. The name works best when the product makes those gaps easy to locate. A quiet empty cell can otherwise look reassuring even though it contains no evidence at all.
03
Use visual marks that describe the review
An eye or frame motif could support the name, but the working interface should avoid giving every captured item a success checkmark. Use a frame for a saved image and a separate status for a reviewed behaviour. RiskSeen reads as two words with the capital S preserved. Pair colour with text so readers can distinguish not observed from failed without relying on hue. The design should make it easy to open the source capture and understand exactly which statement that capture is being used to support.