---
title: Receipts
description: Trace an answer to established inputs and executed rules. Keep the model, original case and receipt together.
icon: receipt
---

Every completed execution returns a full receipt alongside `answers`. Your application keeps that
evidence with the case; no follow-up lookup call is needed. The preview does not retain a receipt history
or offer retrieval by receipt id.

## Read the recorded invoice result

This is an **excerpt** of the receipt recorded for the $25,000 invoice in the walkthrough. It omits
answers, timing and accounting fields, and some detailed table trace fields.

```json
{
  "receipt": "59a65525-1478-4173-99ee-547f8f533b7c",
  "state": {
    "kind": "json"
  },
  "given": {
    "approved": true,
    "invoice_amount": 25000,
    "invoice_date": "2026-10-01",
    "payment_on": "2026-10-11"
  },
  "read": {},
  "decisions": {
    "payment_action": {
      "value": "discount",
      "rule": 2
    },
    "payable_amount": {
      "value": 24500,
      "rule": 2
    },
    "discount_by": {
      "value": "2026-10-11"
    }
  }
}
```

- `given` contains the typed facts supplied directly. `read` is empty here: no AI extraction was needed.
- `discount_by.value` is the calculated October 11 deadline.
- `payment_action.rule` and `payable_amount.rule` identify the second rule in their respective tables.
- `payable_amount.value` is $24,500, calculated under the 2% discount policy.

The receipt records what ran, not whether the policy itself is right. Use boundary tests to check the
rules against your requirements.

## The explanation belongs to the rule

The model's `# why` column contains the rationale written with each rule. The receipt identifies which
rule fired and records the values used. It does not ask a language model to invent a reason after the
result. Keep the submitted model so you can interpret those rule references later.

## Keep three things together

1. **The complete model** that supplied the rules and answer contract.
2. **The original state** submitted for this case, including any text evidence.
3. **The full receipt** returned by the execution.

`state.kind` in the receipt is input metadata, not the original case. `given` and `read` describe the
established inputs; they do not preserve all submitted evidence. A receipt id identifies this execution
but cannot retrieve a server-side copy later.

The receipt also includes latency, usage and settled billing. `provider_usage` describes extraction work
inside the receipt; response-level `provider_usage` covers the whole call, including any generation.
`usage` and `billing` describe API accounting and the charge. See [Pricing and limits](/docs/resources/pricing-and-limits).

The console can show and download the current receipt. Save the files before refreshing or leaving.
Use your application's access controls and retention policy for decision evidence; account billing
records are separate.

## Compare a policy change

Keep test cases with expected answers. Execute the same inputs against original and revised models,
compare the answer values and investigate unexpected changes before switching. You select the cases;
aityx does not select them from a stored receipt history.

See [Compare revised rules](/docs/guides/revise-and-replay) for a complete client script.