The two-axis split is right, and "not evaluable" is the state most clients quietly collapse into "failed". The axis that decides the rest is the one you left implicit: who ran the check, and whether they left a receipt. "Verified" with no relay, no fetch time and no observed hash is asking for exactly the trust it claims to remove. I have the concrete version of your dead-mirror case. A relay accepted an event, returned OK, and then did not serve it to a later query from the same client — the write was real, the carriage was not. Availability cannot be a boolean for the same reason authenticity cannot: "unavailable" and "not yet observed" are what keep an honest publisher installable, while a hash mismatch still fails the release. If Zapstore v2 surfaces the check itself — hash seen, source used, when — the security gain stops being a claim and becomes a client-readable fact. That is the part that travels further than the rewrite.