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

# Prove

Every priced request is a receipt in your organization's hash chain under recovea-chain-v1. Export a period and re-derive every hash yourself.

Prove is the record you can check without trusting us. Every request the gateway meters and prices is written as a receipt, and every receipt is chained to the one before it by a published recipe, `recovea-chain-v1`. Export a period and you can recompute every hash with nothing but SHA-256.

## What the request carries

Nothing. The receipt is written from the metering of an ordinary request. The response's `x-recovea-request-id` is the receipt's `request_id`, so a response in your logs and its row in the ledger join on that one value.

## What a receipt holds

Twelve fields, and no content:

| Field | What it is |
| --- | --- |
| `request_id` | the `req_` id the response carried |
| `timestamp_ms` | the request's timestamp, Unix epoch milliseconds |
| `provider` | `openai`, `anthropic`, or `openai_compatible` for a declared upstream |
| `model` | the model that answered |
| `route` | the path, such as `/v1/chat/completions` |
| `tokens_in`, `tokens_out`, `tokens_cached` | the token counts your provider reported |
| `cost_micro_usd` | the cost in integer microdollars; 1000000 is one dollar |
| `price_list_version` | the reference price list that priced it |
| `basis` | `measured` or `applied` |
| `mandate_id` | a reserved field; an absent value is hashed as the empty string |

## What the chain does

Receipts are chained per organization, in order. Each row's hash is the lowercase-hex SHA-256 of fourteen values joined by U+001F: the recipe id, the previous row's hash, and the twelve receipt fields in the order above. The first row's previous hash is sixty-four zeros. A row's own hash is never part of its input.

So each row's hash is an input to the next. A ledger row altered after the fact fails re-derivation at that row, and every hash after it fails too. [The hash-chained ledger](https://docs.recovea.ai/concepts/hash-chained-ledger/) walks through re-deriving one receipt from the previous hash.

A request is chained once it is priced. A request that could not be priced is still on the platform's **Requests** page, with no cost, and it is not in the chain.

## What comes back: the export

On the platform's **Ledger** page, choose a period and a format, JSONL, JSON or CSV, and export it. The page calls the same route your own session can:

```http
GET /platform/v1/ledger/export?period=2026-09&format=jsonl
```

The file opens with a header: the recipe id, your organization, the period, the genesis, the chain head (the hash of the last row at or before the end of the period), the row count, the price-list versions the period used, and the line *the meter measures; the provider invoice is the bill*. Then one row per receipt, in chain order, each carrying the recipe id, `previousHash`, the twelve receipt fields in camelCase, and its `rowHash`. The fields `ts`, `cost` and `lever` follow as display companions; they are not hash inputs.

A period that starts partway through your chain starts from its first row's stored `previousHash`, not from genesis, so any one month re-derives on its own. The **Ledger** page re-derives the period's chain in your browser from the same export and compares the result with the export's chain head.

Receipts and the export are on for every plan, Free included, with no flag and no tier gate.

## What a receipt proves, and what it does not

- **It proves the record has not been changed.** A receipt is the provider's reported counts, priced at a named price-list version, in a sequence where any later edit breaks every hash after it.
- **It does not prove the counts are true.** The token counts are the ones your provider reported on its own response.
- **It covers routed traffic only.** A call that never reaches the gateway has no receipt.