증거는 제품의 일부입니다.

A unit test can show that a function obeyed its contract. A browser test can show that a user journey rendered and completed. Neither one automatically proves that a camera recovered an optical transfer, that a model is calibrated, or that a physical device will behave outside the tested environment.

The useful question is therefore not simply whether a check passed, but which observation it actually covers. Evidence becomes easier to trust when the type of observation is named next to the result.

I find it helpful to separate software correctness, synthetic or replay evidence, live deployment evidence and physical measurement. These layers can support one another, but they should not silently promote one another.

A replay can validate a decoder. It cannot establish the camera distance or angle that produced the frames. A deployment smoke can establish a route and header. It cannot establish that the product is useful to every user.

A visible NOT_VERIFIED or PARTIAL state is not a weakness in the product. It tells the next person what experiment, review or data collection would actually reduce uncertainty.

This is especially important for systems that cross software and hardware boundaries. The boundary is part of the design because it determines what action is justified next.

When a result matters, the surrounding interface should preserve enough context to interpret it: version, source, conditions, method, validation status and known limitations.

That does not mean exposing every internal log. It means refusing to present a conclusion without the small amount of provenance needed to use it responsibly.