The Diagnostic
Provenance Ledger.
One verifiable ledger that seals every clinical-AI decision the moment it happens, then hands you the evidence to prove it. It attests the decision. It never makes it.
The Diagnostic Provenance Ledger seals a digest of the model, the inputs, and the output to an externally-anchored, post-quantum-signed transparency log at decision time, then emits the outputs you need from it: evidence packages with a verify recipe, a clinical AIBOM, and post-market reporting feeds. PHI is rejected at the guard, so only digests are ever sealed.
Sealed the
instant it happens.
At decision time, the ledger captures digests of the model, the inputs, and the output, then seals them to an append-only transparency log, signs with composite ML-DSA-65 and Ed25519, and anchors the log root externally. The PHI never enters: raw identifiers are rejected at the guard. What remains is a tamper-evident record pinned in time.
Proof you
hand over.
Each sealed decision produces an evidence package: the digests, the signed inclusion proof, the signed log root, and a verify recipe. Anyone holding it can recompute the hash chain and confirm the post-quantum-signed root with standard tools, without your systems and without trusting us. Tamper with the model, the data, or the record, and verification returns false.
A clinical AIBOM,
from what it sealed.
From the same baseline and digests it already holds, the ledger emits a clinical AIBOM in CycloneDX form, aligned with the CISA-led G7 guidance: model hash, datasets, framework, and lineage in one structured inventory. No AIBOM is FDA-mandated; it is a voluntary best practice. The ledger produces it as a by-product of sealing, not a separate manual effort.
Reporting feeds,
already signed.
The ledger emits standards-based exporters: an FDA Section 524B(b)(1) postmarket monitoring feed as a signed decision and integrity log, and an EU AI Act Article 72 post-market monitoring report with counts, breakdowns by modality, and an AIBOM reference. Each is derived from sealed records, so it supports your reporting with evidence you can verify.
Give every decision
a receipt.
Register a model baseline, seal decisions through the ledger, and verify the evidence with your own tools. Per decision, verifiable, PHI-free, non-device. The evidence package, the AIBOM, and the reporting feeds come out of the same sealed record.
What is the Diagnostic Provenance Ledger?
The Diagnostic Provenance Ledger is RankShieldMD's flagship product: an append-only, externally-anchored, post-quantum-signed transparency log that seals a digest of the model, inputs, and output for each clinical-AI decision at the moment it is made, and emits standards-based evidence outputs from what it seals. As clinical AI moves from the research bench into triage, imaging, documentation, and early autonomous pilots, a new class of risk appears that traditional security never addressed: not the theft of data, but the unprovable decision. A recommendation reaches a patient, and weeks later no one can confirm which model produced it, on which version, or whether the inputs were intact. Conventional audit logs cannot answer that, because they can be edited and usually sit beside the very data they are meant to protect. The ledger closes the gap by sealing digests, not contents, the instant a decision happens, signing each record with composite ML-DSA-65 and Ed25519, and anchoring the log root to an external record so the whole structure is pinned in time. Two principles govern the design, and we hold to both honestly: attest, don't decide, so the ledger proves provenance and never makes clinical judgments, which keeps it non-device under the FDA clinical-decision-support criteria, and prove without exposing, so verification never requires revealing protected health information. The ledger is the fabric. The evidence package, the clinical AIBOM, and the reporting feeds are what that fabric emits.
What is in an evidence package, and how do you verify it?
An evidence package is the portable proof the ledger produces for a single sealed decision, and its whole purpose is to be checkable by someone who does not trust the ledger. Inside it you get the sealed digests for that decision, a signed inclusion proof that places the record inside the append-only log, the signed log root, the signing algorithm identifier, and a verify recipe written for standard tools. Verification runs in three moves, and none of them touch patient data. First, recompute the hash chain from the sealed digests and confirm it matches what was recorded, which proves the model, inputs, and output digests are exactly what was sealed. Second, check the inclusion proof, which proves this specific record genuinely sits in the log rather than being a loose claim. Third, confirm the post-quantum signature over the log root, which proves the root itself was issued by the ledger and has not been forged or rewound. If any of the model, the data, or the record was altered after sealing, the recomputed chain no longer matches and verification returns false. An auditor, an FDA reviewer, or opposing counsel can run all three without access to your systems and without a live connection to RankShieldMD, because the package carries everything the check needs. The medical data stays where it belongs, governed by the clinical systems built for it; the evidence package holds only the cryptographic proof about the decision, which is exactly why it is safe to hand over.
What is a clinical AIBOM and how does the ledger emit one?
A clinical AIBOM is a structured, machine-readable inventory of an AI model used in a clinical setting: its hash, the datasets it was built and validated on, the framework it runs in, and its lineage. It is the AI equivalent of the software bill of materials that supply-chain security teams already rely on, and it is sometimes called an ML-BOM. The ledger emits one in CycloneDX form, aligned with the CISA-led G7 guidance on AIBOM content, and it does so from material it already holds. Because the ledger registers a cryptographic baseline of the approved model and seals digests for every decision, the model hash, the framework, and the lineage are already captured. Generating the AIBOM is therefore a by-product of sealing rather than a separate manual documentation exercise that drifts out of date. That distinction matters, because an AIBOM and per-decision provenance live at different layers and answer different questions. An AIBOM describes a model at the supply-chain level, a static inventory of what went into the system, while per-decision provenance attests an individual runtime decision, the finer layer that survives the question prove this one. The ledger produces both from one fabric. One honest boundary belongs here in plain sight: no AIBOM is FDA-mandated. It is a voluntary best practice that many device makers and hospitals are adopting ahead of any requirement, and the ledger makes producing one nearly free once decisions are already being sealed.
How does the ledger feed FDA Section 524B and EU AI Act Article 72 reporting?
By turning the records it already seals into the reporting artifacts those regimes ask for, so the evidence is a by-product of operation rather than a scramble at deadline. On the United States side, Section 524B(b)(1) asks makers of cyber devices to monitor, identify, and address postmarket cybersecurity concerns. The ledger emits a signed decision and integrity feed built from its sealed records: a tamper-evident stream a device maker can point to as evidence that decisions and model integrity were continuously monitored. On the European side, Article 72 of the EU AI Act requires providers of high-risk AI systems to run post-market monitoring and document it. The ledger emits an Article 72 style report with decision counts, breakdowns by modality, and a reference to the emitted AIBOM, assembled from the same sealed decisions. In both cases the language we use is deliberate and we hold it every time: the ledger produces evidence that supports these obligations. It does not make you compliant, and it is not a clearance or a certification. Section 524B compliance is the device maker's overall submission and security posture; Article 72 compliance is the provider's overall monitoring program. The ledger gives each of them signed, verifiable inputs so that the parts of those programs that depend on decision integrity are backed by proof anyone can check, rather than by assertion. That is the whole value: evidence that stands up when the reporting is questioned, without overclaiming what a piece of software can do on its own.
How is the ledger PHI-free and non-device?
Both properties are structural choices, not settings, and they are what make the ledger safe to adopt and safe to verify. PHI-free by construction means the ledger seals digests, never contents. At decision time it captures cryptographic hashes of the model, the inputs, and the output; raw patient identifiers are rejected at the guard before anything reaches the log, so protected health information never enters the ledger and cannot leak from it. A stolen copy of the ledger is useless to an attacker, because there is no protected data inside it to steal. That design also shrinks your PHI footprint rather than growing it, which is the opposite of what a new audit system usually does. Non-device by design means the ledger attests decisions and never renders them. Under the FDA clinical-decision-support criteria, software becomes a regulated device when it produces or drives the clinical decision itself, which is the fourth criterion. The ledger is engineered to stay on the attestation side of that line: it proves that a decision was genuine, that a given output truly came from a given model, on a given version, with intact inputs, at a given time, and it never scores, recommends, or makes the decision. That boundary is not modesty. A provenance layer that quietly positioned itself as a decision-maker would invite the over-reliance that makes clinical AI dangerous and would misrepresent what the technology does. Keeping the ledger bounded to verifiable attestation also gives clinical-AI and device vendors a direct benefit: an independent integrity signal for their model without inheriting the ledger's regulatory burden, and without the ledger entering the clinical pathway.
What we are careful never to claim.
We didn't invent the concept
Verifiable AI audit is a published academic idea. RankShieldMD ships the commercial, externally-anchored, post-quantum, per-decision implementation and its standards-based exporters, not the invention of the concept.
It supports compliance, it is not compliance
The ledger produces evidence that supports FDA Section 524B and EU AI Act Article 72 reporting. It is not an FDA clearance, not a certification, and it never makes a medical claim. And no AIBOM is FDA-mandated.
It never sees PHI
Model, input, and output are reduced to digests. Raw identifiers are rejected at the guard. The ledger is useless to anyone who steals it, because there is no protected data inside. Quantum-safe, never quantum-proof.
Ask RankShieldMD about the Diagnostic Provenance Ledger.
What is the Diagnostic Provenance Ledger?
It is RankShieldMD's flagship product: an append-only, externally-anchored, post-quantum-signed transparency log that seals a digest of the model, inputs, and output for each clinical-AI decision at the moment it is made. It also emits standards-based evidence outputs from what it seals. It attests decisions and never renders them, which keeps it non-device, and it holds only digests so it is PHI-free by construction.
Is the ledger a medical device?
No. It attests that a decision was genuine; it never produces, scores, or drives the clinical decision. Under the FDA clinical-decision-support criteria, software becomes a regulated device when it produces or drives the decision itself (the fourth criterion). The ledger stays on the attestation side of that line by design.
What does the ledger seal for each decision?
A digest of the model and its container, digests of the inputs and the output, a model fingerprint, and a per-decision credential. Raw patient identifiers are rejected at the guard before anything is sealed, so only cryptographic digests enter the log.
What is in an evidence package?
The sealed digests for a decision, the signed inclusion proof, the signed log root, the signing algorithm, and a verify recipe. The recipe lets any holder recompute the hash chain and confirm the post-quantum-signed root using standard tools, without access to your systems and without trusting RankShieldMD.
How do you verify an evidence package?
Recompute the hash chain from the sealed digests, confirm the inclusion proof places the record in the log, then confirm the post-quantum signature over the log root. If any of the model, data, or record was altered after sealing, verification returns false. Verification needs no PHI and no live connection to us.
What happens if a model is swapped or data is poisoned?
The sealed digests will not match the approved baseline, and verification returns false, surfacing the discrepancy. Tampering with the model, the inputs, or the record after the fact is detectable rather than deniable.
What is a clinical AIBOM and how does the ledger emit one?
An AI bill of materials (AIBOM, sometimes ML-BOM) is a structured inventory of a model: its hash, datasets, framework, and lineage. The ledger emits one in CycloneDX form, aligned with the CISA-led G7 AIBOM guidance, built from the same baseline and digests it already seals. No AIBOM is FDA-mandated; it is a voluntary best practice.
Is an AIBOM the same as per-decision provenance?
No. An AIBOM describes a model at the supply-chain level, a static inventory of what went into the system. Per-decision provenance attests an individual runtime decision. The ledger produces both: the sealed per-decision records, and an AIBOM export derived from them.
How does the ledger feed FDA Section 524B reporting?
Section 524B(b)(1) asks device makers to monitor and address postmarket cybersecurity. The ledger emits a signed decision and integrity feed that supports that monitoring obligation with tamper-evident evidence. It produces evidence that supports your submission; it is not itself an FDA clearance and makes no medical claim.
How does the ledger feed EU AI Act Article 72 reporting?
Article 72 requires post-market monitoring of high-risk AI systems. The ledger emits an Article 72 style report with decision counts, breakdowns by modality, and a reference to the emitted AIBOM. It supports the report; it does not make you compliant or certified.
Will the ledger make us compliant or certified?
No software does. The ledger produces verifiable evidence that supports specific FDA and EU AI Act requirements. Compliance is your organization's overall posture and remains your responsibility. We never claim otherwise.
Did RankShieldMD invent verifiable clinical-AI audit?
No. The concept of verifiable AI audit exists in published research. RankShieldMD ships the commercial, externally-anchored, post-quantum, per-decision implementation and its standards-based exporters. We are careful never to claim we invented the idea.
Is the ledger quantum-safe?
Yes. Every record is signed with composite ML-DSA-65 and Ed25519, so evidence stays defensible as cryptography evolves toward resisting quantum attack. It is quantum-safe, not quantum-proof: no quantum computer capable of breaking today's cryptography exists yet, and we never claim otherwise.
Turn "trust our model" into "verify our model."
Register a baseline, seal a decision, and hand your buyer, your auditor, or your regulator proof they can check.