State

Supply matching JSON or let the reader extract facts. Inspect given and read inputs in the receipt.

state is the data for the current case. The model declares the inputs it needs. Supply those typed facts as JSON, or send text or other JSON evidence for the AI reader to extract unresolved inputs.

Matching JSON goes straight to the engine

The response includes the model’s input schema (JSON Schema 2020-12). Values that satisfy it are used directly, without a language model. The receipt lists them under given.

These are the inputs from the recorded invoice example:

{
  "invoice_amount": 25000,
  "invoice_date": "2026-10-01",
  "payment_on": "2026-10-11",
  "approved": true
}

Dates are ISO strings, numbers are numbers, booleans are booleans, and choices match declared values. Nested objects and lists follow the model’s schema. Include dates explicitly when your policy depends on time, so later comparisons use the same facts.

Text needs input extraction

You can send the same facts as a string:

"Approved invoice for USD 25,000, issued October 1, 2026. Payment is scheduled for October 11, 2026."

The reader is instructed to establish each required input from the supplied evidence. Calculating the discount or deadline belongs to the model’s rules. Inspect read in the receipt to see extracted values and their distributions; inspect given for values supplied directly. Reader confidence does not prove that an extracted fact is correct. See Determinism and confidence.

Mixed JSON can supply facts and evidence

Valid values under the model’s input names are kept. The reader uses the original evidence to resolve other fields, including renamed keys or values that do not match the required types.

For example, with the invoice model:

{
  "approved": true,
  "supplier_note": "Invoice for USD 25,000 issued October 1, 2026. Pay on October 11, 2026."
}

approved is supplied directly. The remaining facts need extraction. Keep the original state in your application alongside the model and receipt. The receipt’s state.kind describes the input form; it is not a copy of the original text or JSON, and there is no receipt request field containing it.

Unresolved required facts stop execution

The service attempts to establish missing inputs from the supplied evidence. If a required fact remains absent, unsupported or below its threshold, the call fails with 400 invalid_state before the decision engine executes. errors[].path names the unresolved inputs as state.<input>.

Supply the fact explicitly or route the case for review. Use blank: true only when the written policy permits an absent input and your rules handle it. Do not make a required fact optional merely to make a failing request succeed.

State is evidence for the decision, not a place to change the policy. To change the rules, review a revised model and submit that definition instead.

Billing

Submitting the complete model selects System One execution pricing. Matching JSON skips extraction; text or unresolved JSON fields can add a separate System Two charge for the reader’s provider tokens. Questions-based requests are charged at System Two rates even when their model is cached. See Pricing and limits.