Start with what verification means
Document verification can refer to several different questions. Has a file changed? Who issued it? Is the issuer authorized? Has the document been revoked? Is its content true?
A good verification interface keeps these questions separate. One green status should not silently claim to answer all of them.
Keep the document private
A common reference design stores the document in an appropriate private system and records a cryptographic digest, or hash, in a tamper-evident log. A recipient can hash the file they received and compare the result with the recorded digest.
A match provides evidence of integrity relative to the anchored version. It does not establish that the underlying claim is accurate.
Even hashes need careful handling. Predictable or low-entropy information can be vulnerable to guessing. The design should assess what an observer could infer from any published proof or metadata.
Give the issuer a clear identity
The verification result should explain who issued the record and how that identity was established. Key ownership, issuer permissions and key rotation belong in the architecture rather than being hidden behind the interface.
Plan for revocation and correction
Real business records expire, change and sometimes contain mistakes. Define how an issuer withdraws or replaces a record, and make that status visible to recipients. Preserving an old proof should not make an outdated document appear current.
Design the result for a person
A useful result identifies the file checked, the issuer, the integrity outcome and the current status. It should also explain unavailable information and failures, such as a network request that could not complete.
Uncertainty is a valid result. An interface that cannot verify a claim should say so.