Verify

POST /v1/decision-machine-1/verify takes a field and a value you already have. The model reads the text and pulls what the text says for that field. It then compares that against your value. You get a boolean matches, a probability, and found, the raw spans the model pulled. Use it as the check step after an extraction, an OCR pass, or a form submission. No API key is required during the launch period.

When to use it

• You hold a value from another system and must confirm the source document supports it.
• You want a cheap second opinion on one field of an extract result before you write it to a database.
• You need the spans behind a disagreement, not only a verdict: found shows the competing values.
• Use extract instead when you have no value yet and want the model to produce one.
• Use answer instead when you want the value plus its character offsets in the text.
• Use yes-no instead when the claim is a sentence, not a field and value pair.

Three example decisions

1. An OCR pipeline read invoice number 4471. Does the invoice text say 4471?
2. A payment record holds a total of 2676. Does the invoice support that total?
3. A CRM row says the customer is Acme Corp. Does the contract name that customer?

Request

text and texts are mutually exclusive. Write field.description in English, even for non-English text. See Languages.

curl -X POST https://api.milliseconds.ai/v1/decision-machine-1/verify \
  -H "content-type: application/json" \
  -d '{
    "text": "INVOICE #4471 - Acme Corp. Issued 2026-03-02. Net 30. Subtotal $2,500.00. Tax $176.00. Total due $2,676.00.",
    "field": {
      "name": "invoice_number",
      "description": "The invoice number printed on the document"
    },
    "value": "4471"
  }'

Response

{"matches":true,"probability":0.689,"found":["4471"]}

• matches — boolean. It is true when probability is 0.5 or more.
• probability — number from 0 to 1, rounded to 3 decimals. It is the confidence of the span that matched your value. It is exactly 0 when nothing the model found matches.
• found — string array. Every span the model pulled for that field, match or not. Use it to debug a disagreement.

Two headers come back on every call: x-input-chars, the number of input characters, and x-input-tokens, the input tokens billed for this call. The call above returned x-input-chars: 107 and x-input-tokens: 27. See Pricing.

Reading the numbers

Send the same invoice with value set to 4417, a transposed digit:

{"matches":false,"probability":0,"found":["4471"]}

probability is 0 and found still holds 4471. That pair is the useful signal. The model did read the field, and the text disagrees with your value. Route this case to a person.

Now ask the same invoice for shipping_address, a field it does not carry:

{"matches":false,"probability":0,"found":[]}

Both results say matches: false with probability: 0. Only found separates them. An empty found means the model saw no such field, so your value is unconfirmed, not contradicted. A populated found means the text states something else.

A match on a strong span looks different:

{"matches":true,"probability":0.997,"found":["$2,676.00","$2,500.00","$176.00"]}

That is total_due against the value 2676. The model pulled three money spans, and $2,676.00 matched. probability therefore reports that span’s confidence. The other two spans are noise from the same field. They do not lower the number.

Practical bands for a financial field: act on matches: true above 0.9, and confirm between 0.5 and 0.9. Review every matches: false that has a non-empty found. Raise the bar with the blast radius. See Thresholds and confidence routing.

Batching

Pass texts to check one value against up to 32 documents in one call. The response is always {"results":[...]}, one entry per text, in input order.

curl -X POST https://api.milliseconds.ai/v1/decision-machine-1/verify \
  -H "content-type: application/json" \
  -d '{
    "texts": [
      "INVOICE #4471 - Acme Corp. Total due $2,676.00.",
      "INVOICE #8812 - Globex Ltd. Total due $940.00."
    ],
    "field": {
      "name": "invoice_number",
      "description": "The invoice number printed on the document"
    },
    "value": "4471"
  }'

{"results":[
  {"matches":true,"probability":0.849,"found":["INVOICE #4471"]},
  {"matches":false,"probability":0,"found":["INVOICE #8812"]}
]}

field and value apply to every text. To check several fields, send one call per field. Each text costs one inference call, so a batch of 32 costs 32 calls. See Batching.

Limits and gotchas

The matching rule. The API lowercases both sides and removes every non-alphanumeric character. It then accepts an exact match, or containment when your canonical value is 3 or more characters. So $2,676.00 matches the value 2676. A one or two character value must match exactly.

Containment cuts both ways. Against the same invoice, the value 471 returns matches: true with found: ["4471"], because 471 sits inside 4471. The value 47 returns matches: false, because two characters need an exact match.

Input limits. text accepts 1 to 20,000 characters. texts accepts 1 to 32 items, each 1 to 20,000 characters. Send one of the two, never both.

Field limits. field.name needs at least 1 character. field.description has no cap. A missing field returns {"error":{"code":"invalid_request","message":"field: Invalid input: expected object, received undefined"}}. A missing value returns {"error":{"code":"invalid_request","message":"value: Invalid input"}}. Both are 400. See Errors.

Write a real description. field.name alone often works, but a description narrows the search. "The invoice number printed on the document" beats "number". See Writing good statements and labels.

Long text. Past 2,000 characters the text is split into overlapping windows and the spans merge. Cost is linear in characters. See Long text and chunking.

Latency. One verify call measured 0.48 s end to end over a short input on 2026-09-16.

Next