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.…