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

# Live Attestation

> A per-tenant, externally-verifiable runtime statement over Wardin's signed receipt chain — how many gateway-routed requests were policy-evaluated, that the chain verified end-to-end, and the packs in force — anchored by an RFC 6962 Merkle root you can reproduce yourself.

SOC 2 reports are annual PDFs. Trust pages are self-asserted uptime. A **live
attestation** is different: a statement about what your gateway actually did, for a
period, computed from the [signed receipt chain](/concepts/receipts) and anchored by a
Merkle root **anyone you authorize can reproduce** — without trusting Wardin, and without
seeing a single prompt.

<Note>
  An attestation is only as strong as its **stated scope**. Wardin attests to
  **gateway-routed traffic only** — requests it processed and signed. It does **not** cover
  AI activity that bypasses the gateway, and it is **not** a compliance certification
  (SOC 2 / ISO / EU AI Act) and **not** legal advice. The `scope` and `disclaimer` fields
  are returned with every attestation; surface them verbatim. Claim language is **draft,
  pending compliance-counsel review.**
</Note>

## What it states

For a period, [`GET /v1/compliance/attestation`](/api-reference/compliance/attestation)
returns:

* **receipts** — signed receipts produced for gateway-routed traffic;
* **chainVerified** — whether the hash chain recomputed end-to-end with no gap or break in
  sequence (a single altered field breaks every later hash);
* **signaturesVerified** — whether every receipt's ED25519 signature verified against the
  signing-key registry;
* **policyEvaluated** — receipts carrying signed in-path check records, and the percentage;
* **enforcementActions** — receipts where an in-path check blocked (budget / model-allowlist
  / guardrail) or redacted (PII);
* **checkCoverage** — per in-path check (AUTH, BUDGET, GUARDRAIL, PII, …), how many
  receipts carry it;
* **packsInForce** — the [framework packs](/concepts/framework-coverage) in effect;
* **merkle.root** — an RFC 6962 Merkle root over the period's receipt chain hashes.

```bash theme={null}
curl -H "Authorization: Bearer wardin_sk_..." \
  "https://api.wardin.ai/v1/compliance/attestation?range=30d"
```

See [`GET /v1/compliance/attestation`](/api-reference/compliance/attestation) for the full
response shape.

## Why it's trustworthy without trusting us

The Merkle root commits to **which** receipts exist and **their order** — using each
receipt's `this_hash` (its chain hash) as the leaf. The leaf is a hash, never prompt or
response content, so an inclusion proof reveals *structure, not content*. Two independent
facts make the root un-fakeable:

1. Each receipt is **individually ED25519-signed** — verify any leaf's signature against
   Wardin's published [signing-key registry](/concepts/offline-verification).
2. The leaves **chain** — each `this_hash` commits to the previous, so the set can't be
   reordered or padded without breaking the chain.

To prove one receipt is covered by an attestation, request
[`GET /v1/compliance/attestation/receipts/{id}/inclusion`](/api-reference/compliance/attestation-inclusion) —
a content-free audit path you verify against `merkle.root`.

## Reproduce the root yourself

The Merkle tree is **RFC 6962** (the Certificate-Transparency standard), SHA-256, with
domain-separated leaf and node prefixes. Any auditor can reimplement it in any language:

```
MTH([])       = SHA-256()                                  # empty
MTH([d0])     = SHA-256(0x00 || d0)                         # leaf: 0x00 prefix
MTH(D[0:n])   = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])) # node: 0x01 prefix
              where k is the largest power of two < n
```

Leaves `d0…d(n-1)` are the receipts' `this_hash` bytes, in ascending `seq` order (exactly
the order the [Evidence Bundle](/concepts/offline-verification) lists them). Inclusion-proof
verification walks the same split structure: reconstruct the root from your leaf, its
`index`, the `treeSize`, and the sibling `proof` path, then compare to `root`. The `0x00`
/ `0x01` prefixes are what stop the "duplicate the last node" forgery that plagues naive
Merkle trees.

<Note>
  Publishing the root to a public transparency log (CT-style), so the attestation itself is
  tamper-evident beyond "recompute from the receipts you were shown", is **in development**.
  Today the root is reproducible from the period's signed receipts, which is already
  un-fakeable without forging ED25519 signatures.
</Note>

## Where to see it

The **EVIDENCE** stage renders the live attestation for your tenant — receipts, chain
status, policy-evaluated coverage, enforcement actions, the Merkle root, and the packs in
force — alongside the [framework coverage map](/concepts/framework-coverage) and the
[Evidence Bundle](/concepts/offline-verification) export.