> ## Documentation Index
> Fetch the complete documentation index at: https://docs.redpill.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Reading TCB and Claims

> How to interpret typed claims on a verified upstream: status, source, and reason, including TCB freshness.

A confidential response carries a fixed set of **typed claims** about the upstream that served it. They
appear in the receipt's `upstream.verified.claims` and in the
[attested session](/confidential-ai/attested-sessions). A claim never just says "trusted": each one
states its own assurance level. This page is the reference for reading them.

Each claim is an object with a `status`, a `source`, and a plain `reason`:

```json theme={null}
"tee_attested": {
  "status": "asserted",
  "source": "hardware_proven",
  "reason": "verified the TEE quote and bound the request channel"
}
```

## Claim status

| `status`   | Meaning                                                                                      |
| ---------- | -------------------------------------------------------------------------------------------- |
| `asserted` | The verifier's evidence backs this claim.                                                    |
| `refuted`  | The evidence contradicts the claim (for example a stale platform TCB). Recorded, not hidden. |
| `unknown`  | The claim was not established. This is transparency, never a silent pass.                    |

## Claim source

The `source` states who vouches for an asserted or refuted claim, so a hardware fact and an assertion
never look alike.

| `source`            | Assurance                                                 |
| ------------------- | --------------------------------------------------------- |
| `hardware_proven`   | From the verified TEE quote or its collateral. Strongest. |
| `verifier_derived`  | Computed by the verifier from verified evidence.          |
| `provider_asserted` | Published by the provider, not independently proven.      |
| `operator_asserted` | Declared by the gateway operator. Weakest.                |

## The claim vocabulary

| Claim                         | Asks                                                              |
| ----------------------------- | ----------------------------------------------------------------- |
| `tee_attested`                | Is this a genuine CPU TEE with an identity bound to the channel?  |
| `tcb_up_to_date`              | Is the platform's Trusted Computing Base current?                 |
| `os_known_good`               | Does the OS or platform image map to reviewed source?             |
| `serving_software_known_good` | Does the serving software map to reviewed source?                 |
| `gpu_attested`                | Is a genuine confidential-computing GPU attested and nonce-bound? |
| `model_weights_provenance`    | Are the served weights and quantization what they claim to be?    |

Which provider asserts which claim is on the [Providers](/confidential-ai/providers) page.

## TCB freshness

`tcb_up_to_date` is an honest tri-state read from the verifier's reported TCB status:

* An up-to-date platform **asserts** the claim.
* A stale platform **refutes** it. The quote proves a stale TCB, so the gateway records the refuted
  claim rather than silently treating the platform as current.
* An absent status is `unknown`.

Freshness comes from the verified evidence, never from policy.

## How to read GPU attestation

`gpu_attested` becomes `asserted` (with source `verifier_derived`) when a provider's NVIDIA
confidential-computing GPU attestation is verified and bound to the verification nonce. It proves a
genuine confidential GPU exists for that nonce. It does **not** prove that GPU is bound to the serving
CPU TEE for your specific request. That is why its source is `verifier_derived` rather than
`hardware_proven`, and why it never gates a session. Absent or unverified GPU evidence leaves the claim
`unknown`.

## Using claims in a decision

1. Require `tee_attested` to be `asserted` with source `hardware_proven`.
2. Treat `serving_software_known_good: asserted` as a stronger statement than a `provider_asserted`
   claim about software.
3. Decide your own policy on `tcb_up_to_date: refuted` (serve with a recorded stale TCB, or reject).
4. Read `gpu_attested` as supplemental, not as a gate.
5. Treat any `unknown` as "not proven", and weigh it accordingly.

## Next

<CardGroup cols={2}>
  <Card title="Attested sessions" icon="link" href="/confidential-ai/attested-sessions" />

  <Card title="Providers" icon="server" href="/confidential-ai/providers" />
</CardGroup>