> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/medcrypt-documentation/msi/review-and-correct-device-knowledge/trace-an-ai-claim-to-its-source.md).

# Trace an AI claim to its source

Every claim MSI makes about your documents is labeled by how well it's supported: a quote found word for word in your document, a reasoned inference, or a quote that couldn't be found. Use these labels to decide what you can rely on and what to check before it goes into a submission.

## Before you begin

* Upload your documents to a collection attached to the device. See [Review and correct device knowledge](/medcrypt-documentation/msi/review-and-correct-device-knowledge.md#add-documents-to-the-device).
* Have an analysis or conversation to check, such as an Ask MSI chat, an audit report or a device's architecture.

## Understand the labels

MSI checks each quote against your document's own text with an exact text match, not with another AI model, so anyone re-running the check gets the same result.

| Label                  | Meaning                                                                                           | What to do                                                               |
| ---------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| **Verified**           | The quote was found word for word in the source document.                                         | Rely on it, after a quick read of the passage.                           |
| **Corroborated**       | Matches a reviewer-approved or closely matching claim. A strong signal, but not a verbatim quote. | Check the source if the claim matters.                                   |
| **Figure description** | Matches MSI's description of a figure or diagram, not the document's own words.                   | Open the figure and confirm it.                                          |
| **Justified**          | A model inference with its reasoning recorded. Honest, but not traceable to a quote.              | Judge the reasoning. Add evidence if you need the claim to be traceable. |
| **Unverified**         | A quote was claimed but couldn't be found in the source.                                          | Treat as suspect until you confirm it.                                   |

**Justified** and **Unverified** are deliberately different. A justified claim says "this is reasoning, not a quote". An unverified claim says "a quote was given but isn't there".

Some claims also carry a note instead of a label: **Not verified yet** (the quote hasn't been checked), **Rejected by a reviewer**, or **Retracted** (the source document was removed or no longer contains the quote).

## Open the source of a quote

Wherever a verbatim quote appears, select the quote or **Show in document**. The document viewer opens with the quote highlighted and the **Cited passage** pinned above the document.

## Check an Ask MSI answer

1. In an Ask MSI chat, select **Traceability** at the top of the chat.
2. The **Claim Traceability** panel opens. Its header counts the claims by label: verified, corroborated, figure description, justified and unverified.
3. Review each claim and its source quote. Start with unverified claims.

To see what Ask MSI actually did, expand **Sources & Actions** under an answer. It lists **Actions taken**, with each tool's **Arguments** and **Response**, the activity of each specialist step, and **Documents referenced**.

## Check an audit finding

In an audit report, select **Traceability** to open the same **Claim Traceability** panel for the whole audit.

Each finding also has an **Evidence integrity** section. Expand it to see the finding's evidence by label. Findings add one more label:

* **Missing — expected but not found in the submission**: evidence the auditor looked for and didn't find. This is a gap to close, not a claim.

Excerpts shown as **claimed (ungrounded)** haven't been checked against the source, so don't treat them as verified.

See [Run a regulatory audit](/medcrypt-documentation/msi/check-estar-readiness/run-a-regulatory-audit.md).

## Check where device knowledge came from

On the **Device Knowledge** page, each architecture element and profile value shows where it came from.

1. Select **Device Knowledge** in the sidebar, then the **Architecture** tab.
2. Look at the **Provenance** column in the register:

| Provenance            | Meaning                                              |
| --------------------- | ---------------------------------------------------- |
| **From documents**    | Traced to a verbatim quote in a named document.      |
| **From a figure**     | Matches MSI's description of a figure in a document. |
| **Inferred**          | MSI concluded it, with reasoning but no quote.       |
| **Unverified**        | A source was claimed but couldn't be found.          |
| **Added by a person** | Someone on your team created it.                     |
| **Imported**          | Stated in an imported workbook.                      |
| **You set this**      | You set the value yourself.                          |
| **Not established**   | Nothing supports it yet.                             |

3. Select an element to see its **Evidence** (the documents and quotes behind it) and its **History**. Select **View history** to open its full timeline on the **Change tracking** tab.

## Follow a fact through the knowledge base

The **Explore** tab shows what MSI knows about any part of your device.

1. On **Device Knowledge**, select the **Explore** tab.
2. Search for a component, data type or interface.
3. Review the entity's facts. **Not sure about** lists the facts to check first, such as those that are **Not a verified quote** or **Matched by name only**.
4. Select a fact to see its **Source**, its **Review** state, and what it's **Relied on by** (threats, requirements and other records).
5. Open a trace to follow the chain in either direction: **Rests on** shows what a claim depends on, down to the document, and **Used by** shows what depends on it.

**Used in** shows where the entity appears in the architecture, threats, controls and requirements.

## Fix a weak claim

* If the source is right but MSI got it wrong, correct the element or value. See [Review and correct device knowledge](/medcrypt-documentation/msi/review-and-correct-device-knowledge.md).
* If the evidence is missing, add the document to a collection. MSI reads it automatically.
* If two documents disagree, settle it on the **Contradictions** tab.

## Next steps

* [Ask MSI a question](/medcrypt-documentation/msi/get-started/ask-msi.md): use traceability as you chat.
* [Run a regulatory audit](/medcrypt-documentation/msi/check-estar-readiness/run-a-regulatory-audit.md): check the evidence behind each finding.
* [Review and correct device knowledge](/medcrypt-documentation/msi/review-and-correct-device-knowledge.md): fix what you find.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.medcrypt.com/medcrypt-documentation/msi/review-and-correct-device-knowledge/trace-an-ai-claim-to-its-source.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.