# Verify a clinical AI proof: live demo | RankShieldMD

> Try a live, in-browser demo that verifies a clinical AI proof. Check the model fingerprint, data digest, and log root, tamper them, and watch verification fail.
>
> Source: https://rankshieldmd.com/tools/verify-a-proof-demo/ · RankShieldMD (verifiable AI & post-quantum security for healthcare)

Live demo // Verify a clinical AI proof
# Verify a clinical AI proof.

**To verify a clinical AI proof, you recompute its cryptographic evidence and check it against an anchored record: the model fingerprint, the data digest, the ML-DSA-65 signature, and the transparency log root.** If any value was altered, the recomputed root no longer matches and verification returns false. This page does it live in your browser, with real SHA-256 and no patient data.
Run the demo →   How it works       Runs in your browser  Real SHA-256  PHI-free  Non-device          RankShieldMD ledger · PHI-free                  Model fingerprint  onco-v4 · approved baseline   Sealing…      Data digest  sealed input · PHI-free   Sealing…      Transparency log root  externally anchored   Sealing…           Scroll to the demo
Interactive
## Verify the proof. Then try to break it.

Below is one clinical-AI evidence record. Press **Verify** and the page recomputes the data digest and the transparency log root with real SHA-256, then compares them to the anchored values. Press **Tamper** to alter the sealed digest or swap the model fingerprint, and verify again. The recomputed root will no longer match, and the check returns FAILED. Everything runs locally, on digests, never on patient data.
Clinical-AI proof verifier  runs in your browser · PHI-free                 Evidence · onco-v4 decision  RS-201     record  clinical-decision · onco-v4     sealed input  sealed-input model=onco-v4@2.3.1 study=CT-CHEST site…     model fingerprint  d7705ef0ca…01106b11     data digest  19244bc3f7…bec2e459     algorithm  ML-DSA-65 · Ed25519     log root  0d89d124f0…0ec41d11       ✓  recompute data digest from sealed input     ✓  rebuild transparency log root     ✓  post-quantum signature (illustrated)      Press Verify to recompute and check this record.
This demo computes real SHA-256 locally to show the recompute-and-compare mechanic. The ML-DSA-65 signature step is illustrated, not executed. It uses no patient data. It is educational, not clinical, legal, or regulatory advice, and it is not a clearance, a certification, or a medical device.
How verification works
## What does it mean to verify a clinical AI proof?

**Verifying a clinical AI proof means recomputing its cryptographic evidence and confirming that the result still matches an anchored record, without trusting the vendor and without touching patient data.** A proof is not a screenshot or a log line that says the model ran. It is a small evidence package sealed at the moment a decision was made. Verification is the act of independently reproducing the math in that package. You hash the sealed input again and check it against the stored data digest. You rebuild the transparency log root from the model fingerprint and the digest and check it against the root that was anchored externally. If every recomputed value matches, the record is intact. If one does not, the record was altered after it was sealed, and the check returns false. The whole point is that anyone holding the evidence can run this, using standard tools, without access to your systems.

## What is inside a clinical-AI evidence record?

An evidence record is four fields, and none of them is protected health information. Each one is a digest, a fingerprint, or a signature, so verification is a comparison of one-way values rather than an inspection of clinical contents. The table below is the exact record used in the demo above.

| Field | What it is | Why it matters to verification |
| --- | --- | --- |
| Model fingerprint | A hash of the approved model and its container image. | Fixes what "the validated model" means, so a swap changes the fingerprint and breaks the log root. |
| Data digest | A one-way hash of the sealed, de-identified input, never the input itself. | Lets you recompute the digest and detect any change to the input, PHI-free. |
| Signature | A composite post-quantum signature over the record, ML-DSA-65 paired with Ed25519. | Keeps the evidence defensible as cryptography evolves, so it stays checkable for decades. |
| Log root | The append-only transparency log root, anchored to an external record. | Binds fingerprint and digest and pins the record in time, so a later edit no longer matches. |

Because the record holds only cryptographic statements about a decision, the clinical data stays where it belongs, governed by the systems built for it. RankShieldMD holds the proof, not the patient data.

## What does a failed verification tell you, and what does it not?

A failed verification is a precise, narrow statement: the evidence in front of you is not the evidence that was sealed. It is not an accusation and not a diagnosis. When you tamper the data digest in the demo, the recomputed digest of the sealed input no longer equals the stored digest, and the record fails on the first check. When you swap the model fingerprint, the digest still checks out, but the recomputed transparency log root no longer matches the anchored root, and the record fails on the second check. Two different tampering vectors, one honest outcome: the check returns false and the discrepancy is surfaced rather than hidden.

- **What a failure proves.** That the model was swapped, the sealed input was altered, or the record was edited after it was anchored. Tampering is detectable, not silent.
- **What a failure does not prove.** Who changed it, why, or whether the underlying clinical decision was right or wrong. Provenance is a factual record, not a verdict.
- **What a pass proves.** That this specific record is the one that was sealed at decision time, verifiable independently, without exposing protected health information.

RankShieldMD attests that a decision, access, or device was genuine. It never renders the clinical decision, it is not a medical device, and the evidence it produces supports FDA and HIPAA obligations without being, on its own, compliance.
Answer engine
## Ask the founder.

Straight answers about verifiable healthcare AI. Tap a question, or type your own.
Jamie Kloncz, founder  verified human  ✓                         Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it.              How do you verify a clinical AI proof?  You recompute the proof and compare it against an anchored record. A clinical-AI proof is a small evidence package: a model fingerprint, a one-way digest of the sealed input, a post-quantum signature, and a transparency log root. To verify it you hash the sealed input again, rebuild the log root from the fingerprint and digest, and confirm the recomputed root equals the anchored one. If any value was altered, the recomputed root no longer matches and verification returns false. None of this requires access to patient data, because only digests are checked.  What is inside a clinical-AI evidence record?  Four things, and none of them is protected health information. The model fingerprint is a hash of the approved model and its container, so there is a fixed reference for the validated model. The data digest is a one-way hash of the sealed, de-identified input, never the input itself. The signature is a composite post-quantum signature over the record, pairing ML-DSA-65 with Ed25519. The log root is the append-only transparency log root that binds the fingerprint and digest together and is anchored externally so it is pinned in time.  Is this demo actually computing anything, or is it a mockup?  It computes real SHA-256 in your browser. The evidence values on this page were hashed at build time, and when you press Verify the page recomputes the same digests locally and compares them, so a PASS or a FAILED reflects a genuine hash comparison, not a scripted result. The one part that is illustrative is the post-quantum signature step: verifying an ML-DSA-65 signature needs a signing key and library that do not belong on a public marketing page, so that step is shown for context rather than executed.  Does the demo see any patient data?  No. The sealed input shown here is a de-identified statement of indicators and a model tag, and only its digest is ever compared. RankShieldMD is PHI-free by construction: raw identifiers are rejected at the guard and never enter the ledger, and verification works on one-way digests, credentials, and posture evidence rather than clinical contents. Adopting it shrinks your PHI footprint rather than growing it.  What does a failed verification actually prove?  It proves that the evidence in front of you does not match what was sealed. If the data digest was altered, the recomputed digest of the sealed input no longer matches it. If the model fingerprint was swapped, the recomputed log root no longer matches the anchored root. Either way, verification returns false and the discrepancy is surfaced rather than hidden. It does not tell you who changed it or why. It tells you, checkably, that the record is no longer the one that was sealed.  Is RankShieldMD making a clinical or compliance decision here?  No. This tool attests, it never renders. It proves that a decision, an access, or a device was genuine; it does not make, score, or recommend a clinical decision, and it is not a medical device. The proof it verifies supports FDA and HIPAA obligations by producing checkable integrity evidence, but it is not itself a clearance, a certification, or compliance. This demo is guidance and illustration, not clinical, legal, or regulatory advice.               Early access
## Verify a proof sealed from your own environment.

The demo runs on a fixed record. In early access, bring a decision, an access flow, or a telehealth order from your systems. We seal it, and your team verifies the evidence, without PHI, and without trusting us.
Request early access →   See decision provenance