# Model Cards Are Not Proof: Documents vs Provenance

> Model cards and frameworks describe an AI system. They do not prove what it did. Learn the difference between transparency documents and verifiable provenance.
>
> Source: https://rankshieldmd.com/resources/model-cards-vs-verifiable-provenance/ · RankShieldMD (verifiable AI & post-quantum security for healthcare)

Resources // AI transparency
# Model cards are not proof: transparency documents versus verifiable provenance.

A model card describes your AI. It cannot prove what your AI actually did on a specific patient, on a specific day. This piece draws the line between documenting a model and proving a decision, and shows why healthcare needs both.
Read the guide →   Ask a question       Documentation vs proof  Model cards · CHAI · BRIDGE  PHI-free · non-device
Published July 30, 2026 · Last updated July 30, 2026

**Model cards, and the frameworks built around them like CHAI and BRIDGE, describe an AI model: its intended use, its data, its performance, and its limits. They are valuable for governance and procurement. But they are written before any specific inference, so they cannot prove what a model did on a specific input at a specific time. Documentation describes a system; proof shows what it actually did and lets a third party check. Treating a model card as if it settles what happened in a disputed case is a category error, and it is the error at the center of how healthcare talks about AI trust.** The stakes are real: 81 percent of physicians use AI professionally and 76 percent believe it improves care, [1] so these tools are shaping decisions that get reviewed, and description is not the same as evidence.

This piece defines what model cards are, names the claim they cannot make, draws the line between documentation and proof, credits where transparency genuinely helps, and shows what provenance adds on top. RankShieldMD supplies that provenance layer and proves what a model did without rendering the decision . See how it works in [clinical AI provenance](https://rankshieldmd.com/clinical-ai-provenance) and how the three pillars fit in [governance, security, and provenance](https://rankshieldmd.com/resources/clinical-ai-governance-security-provenance/).

## What model cards, CHAI, and BRIDGE actually are

**They are transparency artifacts: structured documentation of what a model is, what it is for, and where it falls short.**

The model card began as a way to standardize how a model is described: intended use, training and evaluation data, performance across subgroups, and known limitations, in a consistent format. Healthcare has embraced the idea. The Coalition for Health AI has promoted model cards as a transparency standard for clinical AI, and frameworks such as BRIDGE, developed with industry partners, extend structured documentation and governance guidance further. These efforts are worth taking seriously. A shared format lets a health system compare tools fairly, gives a governance committee a real checklist, and pressures vendors to disclose weaknesses they might otherwise soften. The FDA's own direction on clinical decision support leans on transparency and the ability of a clinician to independently review the basis of a recommendation. [3] All of this is genuine progress. It is also, in every case, documentation: a description of the model in general, produced before it processes any particular patient.

## The claim they cannot make: what happened at inference

**Because a model card is written before any specific inference, it cannot attest to what the model did on a specific input in a specific case.**

This is not a flaw in model cards; it is their nature. A description of a tool, however thorough, is not a record of a specific use of that tool. When a clinical AI decision is questioned months later, the operative questions are concrete: did this output come from this model version, on these unaltered inputs, and did a clinician review it. A model card cannot answer any of them, because it existed before the event and says nothing about it. It can establish that the model is intended for the task and performed at a certain level in testing, which speaks to whether adopting it was reasonable. It cannot establish what occurred in the instance under dispute. Confusing these is consequential, because it leads organizations to believe they have accountability they do not have. They can show what the model is supposed to do. They cannot show what it did. That is the difference between having documentation and having evidence.

Keep your model cards. Add the proof they cannot provide.
Request early access →
## Documentation versus proof, in plain language

**Documentation states what a system is meant to do; proof is verifiable evidence of what it actually did, that someone else can check.**

Strip away the jargon and the distinction is simple. Documentation is a claim about intent and capability, authored by the people responsible for the system. Proof is evidence about a specific event, structured so that someone who does not trust the author can still verify it. A model card is documentation: useful, honest at its best, and unverifiable as to any particular decision. A tamper-evident provenance record is proof: it binds a model version, an input digest, an output, and a signer, sealed so alteration is detectable and ideally anchored externally so a third party can confirm it. The test that separates them is adversarial. Ask of any artifact: if someone disputed it in bad faith, could an independent reviewer still confirm it. A model card fails that test for a specific decision, not because it is dishonest, but because it was never about a specific decision. Provenance passes it, because that is exactly what it is for.

## Where transparency documents help, and where they stop

**Transparency supports governance, procurement, and evaluation; it stops at the boundary of per-decision evidence.**

It is worth being precise and fair, because the point is not that documentation is weak, it is that it is finite. Model cards and frameworks do real work at the front of the lifecycle: choosing whether to adopt a tool, evaluating its fit and risk, disclosing limitations, and giving a governance committee something concrete to assess. Standardization efforts raise the floor for the whole field, which is good for patients and buyers alike. Where they stop is the running system. Once the model is in production making decisions that get reviewed, the documentation cannot follow it into any specific case. That boundary is not a failure to fix within documentation; it is a signal that a second kind of artifact is required. Recognizing the boundary is how a serious program avoids a false sense of coverage. You keep the transparency work, and you add what it structurally cannot include: evidence of the individual decisions.

## Adding verifiable provenance on top of documentation

**Provenance is the layer that makes a documented, governed model also provable, one decision at a time.**

The resolution is not to choose between documentation and proof; it is to stack them. Keep the model cards and adopt the frameworks, because they do the front-of-lifecycle work well. Then add provenance so that the running system emits, for each consequential decision, a tamper-evident, PHI-free record binding the model version, the input digest, the output, and the verified signer, checkable by a third party. Now a reviewer has both: the description of what the model is meant to do, and the evidence of what it did. That is a genuinely stronger posture than either alone, and it aligns with where regulation is pointing, toward transparency plus the ability to independently review and reconstruct decisions. [3] RankShieldMD provides this provenance layer. It sits on top of your transparency work, never renders the clinical decision, and never claims to make you compliant. Documentation tells the reviewer what your AI is. Provenance proves what it did. Healthcare, of all fields, needs both.
Honesty
## What we are careful never to claim.

### Documentation is not the enemy

Model cards, CHAI, and BRIDGE do real work in governance and procurement. Provenance sits on top of them, not against them. Keep your documentation and add proof.

### We attest, we never render

RankShieldMD proves what a model did on a specific input. It never renders the clinical decision, which keeps it non-device, and it does not make an organization compliant on its own.

### It is proof, not the data

The provenance record holds model versions, digests, and identities, never the patient data. It is PHI-free by construction.
Sources
## References.

- [1] American Medical Association (March 2026). *More than 80 percent of physicians use AI professionally (physician sentiment survey; 76 percent believe AI improves care).* [ama-assn.org/practice-management/digital-health/more-80-physicians-use-ai-professionally](https://www.ama-assn.org/practice-management/digital-health/more-80-physicians-use-ai-professionally-ama-survey)
- [2] National Institute of Standards and Technology. *AI Risk Management Framework (transparency, accountability, and documentation practices).* [nist.gov/itl/ai-risk-management-framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [3] US Food and Drug Administration (2026). *Clinical Decision Support Software guidance (transparency and independent clinician review).* [fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software)
- [4] American Medical Association (2026). *Principles for AI development, deployment and use, and augmented intelligence governance.* [ama-assn.org/press-center/ama-press-releases/ama-issues-new-principles-ai](https://www.ama-assn.org/press-center/ama-press-releases/ama-issues-new-principles-ai-development-deployment-use)

Knowledge check
## Test your documentation versus proof understanding.

A quick check on the key points. Pick an answer to see whether it holds and why.
Question 1 of 5
What is a model card?
Answer: A model card documents a model in general: its purpose, training data, performance, and limitations. It describes the system, not a specific decision.    Question 2 of 5
What can a model card not do?
Answer: A model card is written before any specific inference, so it cannot attest what happened in a particular case.    Question 3 of 5
What is the difference between documentation and proof?
Answer: Documentation states what a system is meant to do; proof is verifiable evidence of what it actually did in a specific instance.    Question 4 of 5
Where do transparency documents help?
Answer: Model cards and frameworks aid governance and evaluation; they do not produce verifiable evidence of individual decisions.    Question 5 of 5
What does RankShieldMD add on top of documentation?
Answer: RankShieldMD adds verifiable per-decision provenance, which documentation assumes but does not provide, and never renders the decision.           Answer engine
## Model cards versus provenance: questions, answered.

Straight answers about verifiable healthcare AI. Tap a question, or type your own.
Jamie Kloncz, founder  verified human  ✓                         Ask me anything about the line between documenting a model and proving a decision, from what a model card can and cannot do to what provenance adds. I built RankShieldMD to be the proof layer on top of your transparency work.              What is a model card and what is it for?  A model card is a structured document that describes an AI model: its intended use, the data it was trained and evaluated on, its performance across groups, and its known limitations. The concept has been widely adopted, and in healthcare efforts like the Coalition for Health AI have promoted model cards as a transparency standard, with frameworks such as BRIDGE, developed with industry partners, pushing structured documentation further. Model cards are genuinely useful. They help a buyer understand what a model is for, help a governance committee evaluate fit and risk, and create a shared vocabulary for comparing tools. What they are is a description of a system in general. What they are not is evidence about any particular decision that system made, which is a different kind of artifact for a different job.  Do model cards prove what a clinical AI did?  No, and this is the crux. A model card is written before any specific inference happens, so by construction it cannot attest to what the model did on a specific patient input on a specific day. It can tell you the model is intended for a task and performed at a certain level in evaluation; it cannot tell you that this output came from this model version on these unaltered inputs and was reviewed by a clinician. When a decision is disputed months later, the model card is evidence of intent and capability, not of the event. Treating it as if it settles the what-happened question is a category error. The card describes the tool; the dispute is about a specific use of the tool, and only a per-decision record can speak to that.  What is the difference between transparency and provenance?  Transparency is about disclosure: telling people what a system is, how it works, what it is for, and where it falls short. Model cards, framework documents, and governance disclosures are transparency artifacts, and they matter for trust and accountability. Provenance is about evidence: a verifiable, tamper-evident record of what a specific system actually did in a specific instance, that a third party can check. Transparency answers what is this and how is it supposed to behave. Provenance answers what did it actually do here, and can you prove it. Both are part of trustworthy AI, and they are not interchangeable. A field can be highly transparent, with excellent documentation, and still be unable to prove a single decision, which is roughly where clinical AI sits today. The gap between the two is exactly the gap this piece is about.  Where do frameworks like BRIDGE and CHAI help?  They help in governance, procurement, and shared understanding, which are real and important. A common transparency format lets a health system compare tools on a like-for-like basis, gives a governance committee a checklist for evaluating a model, and pushes vendors to disclose limitations they might otherwise gloss over. Coalitions and frameworks that standardize this raise the floor for the whole field. None of that is diminished by pointing out its boundary: these are documentation efforts, and documentation stops at description. They tell you what a model is and how it is meant to behave, which supports a decision to adopt it. They do not, and are not designed to, produce evidence of what the model did once it is running. Recognizing where documentation ends is not a criticism of it; it is how you see what still needs to be added.  What does RankShieldMD add, and what does it not claim?  RankShieldMD adds the layer documentation assumes but does not provide: per-decision, tamper-evident, PHI-free proof that a specific output came from a stated model version on a stated input and was signed by a verified clinician. It sits on top of transparency, not against it. Keep your model cards and adopt the frameworks; then add provenance so the running system produces checkable evidence, not just a description of itself. RankShieldMD never renders the clinical decision, which keeps it non-device, and it never claims to make an organization compliant or to replace governance and evaluation. Its contribution is narrow and specific: turning what the model did from an assertion supported by documentation into a fact supported by evidence. Documentation describes; provenance proves; a serious program wants both.              Early access
## Keep the documentation. Add the proof.

Bring your model cards and frameworks. We'll show you how per-decision provenance proves what your AI did, how a reviewer verifies it, and how it stays PHI-free by construction. Evidence that documentation assumes but does not provide, verifiable, non-device.
Request early access →   See the platform