How an answer is made
Built and tested, not yet deployed. Early access.
On this page
The steps
Your input is checked.
A field that’s wrong comes back as a 400 that names it.
Our engine adds facts.
The category’s description (981 codes), the gambling rule checks, and for receipts and refunds each candidate’s amount difference, time apart, name similarity and share returned, with the engine’s own pick.
Some answers need no model.
When a rule settles the decision, the answer comes back with probability 1 and a
rule_reason.One decision model call.
The model answers the question with a typed answer and a probability.
Your line.
Under it,
abstainis true and the case goes to a person. The default is 0.8, and you can move it per call: Abstain and your line.
Rules first
The engine validates every field before anything else runs. Then it puts what it knows beside the input, so the model reads the facts instead of guessing them from four digits or a descriptor.
- The merchant category’s description, from our table of 981 codes.
- Two gambling checks: the network’s gambling codes (7995, 7800, 7801, 7802, 7948, 9754) and a list of gambling brands.
- For receipts and refunds: each candidate’s amount difference, time apart, name similarity and share returned, and the engine’s own pick.
Some answers need no model
Two cases are settled by a rule, with probability 1 and no model call:
- Receipt to charge with no eligible charge:
"none",rule_no_purchases. - Refund to purchase with no refund after the purchase:
"none",rule_no_refunds_after_purchase.
Then one decision model call
A System One model for banking: one built to make one bounded decision in one step. It is pinned to one version, and a new version has to pass our published tests first. We plan to move to an open-weights System One model we can run ourselves. The model can change; the contract won’t.
# How an answer is made Built and tested, not yet deployed. Early access. ## The steps 1. Your input is checked. A field that’s wrong comes back as a 400 that names it. 2. Our engine adds facts. The category’s description (981 codes), the gambling rule checks, and for receipts and refunds each candidate’s amount difference, time apart, name similarity and share returned, with the engine’s own pick. 3. Some answers need no model. When a rule settles the decision, the answer comes back with probability 1 and a `rule_` reason. 4. One decision model call. The model answers the question with a typed answer and a probability. 5. Your line. Under it, `abstain` is true and the case goes to a person. The default is 0.8, and you can move it per call: [Abstain and your line](/api/docs/abstain). ## Rules first The engine validates every field before anything else runs. Then it puts what it knows beside the input, so the model reads the facts instead of guessing them from four digits or a descriptor. - The merchant category’s description, from our table of 981 codes. - Two gambling checks: the network’s gambling codes (7995, 7800, 7801, 7802, 7948, 9754) and a list of gambling brands. - For receipts and refunds: each candidate’s amount difference, time apart, name similarity and share returned, and the engine’s own pick. ## Some answers need no model Two cases are settled by a rule, with probability 1 and no model call: - Receipt to charge with no eligible charge: `"none"`, `rule_no_purchases`. - Refund to purchase with no refund after the purchase: `"none"`, `rule_no_refunds_after_purchase`. ## Then one decision model call A System One model for banking: one built to make one bounded decision in one step. It is pinned to one version, and a new version has to pass our published tests first. We plan to move to an open-weights System One model we can run ourselves. The model can change; the contract won’t. Source: /api/docs/how-it-works