UNDERSTAND
Reading the evidence
Three separations this product makes on purpose. Each one is easy to read as the other, and each one changes what you conclude.
Completed is not passed
A run answers two questions and they never share a box: whether it executed, and what it concluded. A run that completed perfectly can conclude that your app missed a checkpoint — that is the run working, not the run breaking.
Which is why a completed run with a failing verdict is kept for the full window rather than swept up early as a failure. It is usually the most useful thing in the gallery.
Sealed is not verified
Sealed means the contents of the package were checked against the hashes the run declared on close: these bytes are these bytes, and nothing was swapped afterwards.
It is a claim about integrity, and that is exactly the claim the product makes: which is why no screen shows a package as verified. Sealed answers whether anybody touched the contents; who signed it is a different question, and the product does not confuse the two.
Who can read a package
Being in the organization is not enough, and being an admin does not help. Reading a sealed package is something another person recorded, naming you, while the session was still open.
So a gallery with less in it than you expected is not broken. It holds the sessions you were part of, and nothing else.
The clocks are not the same clock
Several run side by side and it is easy to assume they are one. An enrollment code lasts minutes. An invitation lasts days. The links that fetch the pictures inside a package are short-lived and are renewed when you reload the page — the pictures themselves are not going anywhere.
And the last one is not a clock at all: where a screen shows an expiry, it is the latest date a package could survive — a ceiling, not a countdown. Nothing deletes evidence on a schedule today.