Until last week the public verify endpoint at GET /api/v1/verify/{signature_id} returned a single boolean: {verified: true} or {verified: false} . That works for the buyer's first-glance UX. It does not work for a regulator or a court trying to figure out what actually went wrong. An older trust-data-infrastructure design we read for context lays this out: their verify can return Valid Document, Invalid Signature, Incorrect Hash, Invalid Receiver Public Key, or Valid Document (Adulteration Not Detected). Each label is a different forensic story. Invalid Receiver Public Key means substitution or man-in-the-middle. Incorrect Hash means transit corruption. Invalid Signature means key compromise. A boolean cannot carry that. What we added { "verified" : true , "verification_detail" : { "signer_key_match" : true , "signature_valid" : true , "algorithm_match" : true , "agent_active" : true , "validation_label" : "valid" } } Enter fullscreen mode Exit fullscreen mode Four sub-checks plus a stable label.…