Receipts

Trace an answer to established inputs and executed rules. Keep the model, original case and receipt together.

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.

{
  "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.

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 for a complete client script.