Concepts

Languages

decision-machine-1 reads non-English text, but you must write the labels, statements and descriptions in English.

decision-machine-1 has no language gate. Every capability accepts text in any language and answers with the same fields. The accuracy you get depends on two separate things: the language of the input text, and the language of the instructions you send with it.

Instructions mean the parts you write yourself: labels, label descriptions, scale levels, statements, when_true and when_false hints, questions, schema field descriptions and entity type descriptions.

Keep the text in its original language. Write every label, hint and description in English. Every probe below follows that rule, except one. That one probe measures what a translated label set costs you.

What each capability does with other languages

CapabilityModel familyBehaviour on non-English text
yes-no, classify, rateClassifierWorks. The training languages are not documented.
answer, extract, entities, verifyExtractorWorks. The extractor is a multilingual build.

The extractor returns spans copied from your text, so the answers come back in the source language. The classifier returns your own label strings, so the output language is whatever you sent as labels.

Measured: seven languages, one intent

We sent the same billing complaint in seven languages, against the same three English label descriptions. classify returned billing every time.

Languagelabelprobability
Frenchbilling0.998
Spanishbilling0.991
Germanbilling0.995
Italianbilling0.997
Portuguesebilling0.986
Japanesebilling1
Arabicbilling0.973

All seven are correct. Treat this as a smoke test, not a benchmark. Run your own golden set before you trust a language in production.

English descriptions beat translated ones

The same French sentence, the same three labels, twice. The first call sends English descriptions. The second sends French labels and French descriptions.

curl -s -X POST https://api.milliseconds.ai/v1/decision-machine-1/classify \
  -H 'content-type: application/json' \
  -d '{
    "text": "Bonjour, ma carte a été débitée deux fois ce mois-ci. Pouvez-vous me rembourser ?",
    "labels": {
      "billing": "A question about an invoice, a payment or a refund",
      "technical": "A bug report or a product that does not work",
      "sales": "A question about buying or upgrading a plan"
    }
  }'

The English descriptions above return:

{"label":"billing","probability":0.998,"confidence":0.988,"scores":{"billing":0.998,"technical":0.002,"sales":0}}

The French set facturation, technique and commercial, with French descriptions, returns:

{"label":"facturation","probability":0.983,"confidence":0.919,"scores":{"facturation":0.983,"technique":0.017,"commercial":0}}

Both calls pick the right label. The English version is more certain on both numbers: probability 0.998 against 0.983, and confidence 0.988 against 0.919. A translated label set costs you headroom on your thresholds. Map the English label back to your display language in your own code.

Your own wording changes these numbers. Treat the gap as a reason to measure, not as a fixed penalty.

Extraction keeps the source language

extract fills an English schema from German text and returns the German spans untouched. The input is "RECHNUNG Nr. 2291\nKunde: Hoffmann GmbH\nGesamtbetrag: 3.480,00 EUR\nFällig am: 12.05.2026".

{"data":{"invoice_number":"2291","customer":"Hoffmann GmbH","total":"3.480,00 EUR","due_date":"12.05.2026"}}

entities behaves the same way. The offsets stay correct across accented characters. The input is "Contactez Marie Dupont de la Société Générale à Paris.".

{"entities":[{"type":"person","text":"Marie Dupont","probability":0.999,"start":10,"end":22},{"type":"organization","text":"Société Générale","probability":0.992,"start":29,"end":45},{"type":"location","text":"Paris","probability":0.999,"start":48,"end":53}]}

answer returns the span in the source language, with offsets into your original string. The input is "Votre commande est expédiée. La livraison est prévue le 3 avril.".

{"question":"What is the delivery date?","answer":"3 avril","probability":0.999,"start":56,"end":63}

Normalise dates, amounts and separators yourself. The model copies 3.480,00 EUR and 12.05.2026 exactly as written. It does not convert formats.

Where confidence drops

Graded judgments are the weakest case. An angry Japanese complaint on the scale ["Calm","Annoyed","Angry","Furious"] returns a split verdict:

{"score":2,"level":1,"confidence":0.208,"scores":[0,0.333,0.333,0.333]}

The model splits its mass evenly across the top three levels. The printed scores tie because the API rounds to three decimals, so level can land on any of the three. Read score and confidence here instead. The score of 2 is defensible. A confidence of 0.208 is a case for review, not for an automatic action. Use rate on non-English text with a confidence floor, and route the uncertain cases to a person.

Do not assume a threshold tuned on English transfers to another language. Probabilities shift per language. Tune one threshold per language, or set a single conservative floor across all of them.

Checklist for non-English input

  1. Send the text unchanged. Do not translate it first.
  2. Write labels, levels, statements, hints and field descriptions in English.
  3. Use descriptive label text, as on writing good statements and labels.
  4. Measure the language you actually receive with 50 real examples.
  5. Set the threshold from that measurement, not from your English numbers.

Next