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

# The Seven-Gate Baseline

> The pass-or-fail checks Nito runs over attestation evidence, enumerated, with the hardware-verification scope limit stated plainly.

Nito runs a fixed sequence of checks over attestation evidence, called the **baseline**. The result is a single `verified` flag on the evidence handed back to you.

The baseline is a **pass-or-fail contract**. Every gate that applies must pass for the evidence to be marked verified. There is no partial credit: one failed gate means the evidence did not pass.

## The Seven Gates

**Gate 1: Evidence present and parseable.** The evidence must be present and parseable as a structured object.

**Gate 2: Self-declared verification.** If the evidence's own contents declare that it did not verify, the result is marked unverified.

**Gate 3: Proof metadata present.** The proof format, the signing algorithm, and the model public key must all be present. If you specified a signing algorithm, it must match the one the evidence declares.

**Gate 4: Nonce match.** The nonce you supplied must match the nonce observed in the evidence.

**Gate 5: Report-data binding.** Nito recomputes the binding and checks that the stamped report data equals the signing address combined with your nonce, and that the observed signing address matches the address you asked about. Mechanics: [the report-data binding](/privacy/tee-attestation/freshness-binding).

**Gate 6: Nested model-attestation binding.** The evidence carries a nested model attestation. Nito checks the binding within it: the model ID, the algorithm, the model signing identity, the model public key, and the nonce. The invariant governing this gate is on [address-only model binding](/privacy/tee-attestation/address-only-model-binding).

**Gate 7: Nested payload nonce for accelerator envelopes.** For evidence wrapping a hardware accelerator (GPU) proof, the nonce inside the nested payload is checked as well.

## What the Baseline Does Not Do

The baseline does **not**:

* verify the CPU-side hardware quote against a root of trust;
* verify the accelerator (GPU) device-level cryptographic proof;
* validate certificate chains;
* check certificate revocation lists (CRLs);
* evaluate Trusted Computing Base (TCB) policies.

These are the checks that establish full hardware trust, and they are deliberately out of scope. The baseline confirms the evidence is structurally sound, internally consistent, freshly bound to your nonce, and committed to a signing identity. It does not confirm that the hardware quote chains back to a genuine, up-to-date root of trust.

That is yours to complete, on the raw evidence Nito returns, through the [verify-yourself path](/privacy/tee-attestation/verify-yourself-recipe). So the precise meaning of a verified result is: **the evidence passed Nito's baseline contract.** Read it as baseline-verified.

## Send a Fresh Nonce Every Time

Gates 4 and 5 both depend on the nonce, and nothing stores nonces between requests. Send a fresh random one every time and those gates enforce that the evidence was produced for this request. Omit it and an empty-binding report is permitted, which means no replay protection. See [the report-data binding](/privacy/tee-attestation/freshness-binding).

## Related Resources

<CardGroup cols={3}>
  <Card title="Attestation Pipeline" icon="arrows-left-right-to-line" href="/privacy/tee-attestation/attestation-pipeline">
    The flow these checks sit inside.
  </Card>

  <Card title="Report-Data Binding" icon="connectdevelop" href="/privacy/tee-attestation/freshness-binding">
    Gates 4 and 5 in full.
  </Card>

  <Card title="Verify It Yourself" icon="memo-circle-check" href="/privacy/tee-attestation/verify-yourself-recipe">
    Completing the hardware verification.
  </Card>
</CardGroup>