verification.completed

Body of GET /verify/status/{task_id}.

Five shapes keyed on status, and only the fields belonging to the current one are present —processing carries progress, needs_input carries reason, claims and hint, completed carries result, failed carries failure, and cancelled (the run was stopped with POST /verify/{task_id}/cancel) carries nothing more: it was not charged and has no verification. Branch on status and read the fields for that branch; absent is meaningful, so do not treat a missing key as an empty one.

task_id is echoed on every shape, so a caller polling several verifications in one loop can tell the replies apart without threading the id through their own call site.

Whether this verdict carries a warranty, and if not, why not.

Present only when covered verification is enabled. It describes the pair (this account, this analysis), not the analysis alone: two accounts can hold two certificates over one cached verdict, so the block one customer sees is never the block another sees.

reasons is empty exactly when status is not uncovered. The vocabulary is closed and deliberately smaller than the set of rules behind the decision: plan and depth are actionable, account means the account turned certificates off (Pro and Scale), verdict is a product rule callers design around, quality covers everything a caller can neither act on nor define, and withdrawn / issue_failed are statements about Lenz rather than about the caller's claim.