How messages are understood
Intents, languages, notes, acknowledgements, and the rule that the model labels but never decides.
This is the part people ask about most, so it is worth being precise: what the language model does, what it is not allowed to do, and why the line is drawn where it is.
The model labels. Code decides.
Every inbound text message is classified into one of a fixed set of intents — a new order, an addition, a question about payment, a request for the catalogue, an address, a question about the customer's own history, and so on.
That classification is the model's entire contribution.
It does not choose prices. It does not decide whether a message should append to an open order or start a new one. It does not decide what is in stock. It does not compute a total, a balance, or a date. Every number a customer ever sees came out of your database.
An earlier version let the model decide append-versus-create. It caused a real bug, and the rule above is the fix.
Languages
Customers can order in:
- English, including the shorthand people actually use.
- Tamil, in Tamil script.
- Malay.
- Romanised mixtures of any of the above — "anna 5kg atta 2 packet pannunga" is a normal order, not an edge case.
Matching is against your catalogue and its aliases, so the vocabulary that matters is the vocabulary of your own products. See your catalogue and aliases.
Notes: text that was never a product
Real orders carry more than products. A customer's own name, their unit number, a delivery instruction, a thank-you.
Text is sorted three ways:
| Kind | What happens |
|---|---|
| A product attempt that could not be resolved | A clarifying question. Blocks confirm until settled. |
| Information for the shop | Saved as a note on the order and echoed back. Does not block. |
| A pleasantry | Nothing. Not saved, not echoed. |
So "Raji 22-7" above a real order — a name and a unit number, which is exactly how orders are written in a shop group — no longer blocks the order. Neither does "please deliver after 6pm", which becomes a note.
When the classifier is unsure between "product I could not match" and "note", it chooses the product question. A real product line filed as a note would be silently dropped from the order; a note filed as a question costs one needless question.
Acknowledgements
"ok", "thanks", "coming", "noted", a thumbs-up. These are answered with a read receipt and nothing else.
The rule is that every word must be an acknowledgement. "ok 2kg" is still an order. "thanks, when is delivery?" is still a question. And the vocabulary is a list of single words rather than phrases, so "Ok coming down" composes from three of them with no phrase table to maintain.
Emoji are a tight allowlist, not "any emoji". A lone angry or crying face is a customer who needs a person, and answering that with silence would be the worst outcome available.
There is one guard: if the bot has just asked a Yes/No question and the customer types "ok" instead of tapping, that message is not treated as an acknowledgement — silence there would strand them on an order that cannot confirm.
When the AI is unavailable
If the classifier cannot be reached at all — a network problem, an expired key, a quota — the customer is told there is a technical problem, and you get an alert saying the same. This is deliberately distinct from "I did not understand that": telling a customer their perfectly ordinary message was not understood, when in fact nothing read it, misinforms both of you.
Things it will not answer
Product questions with no data behind them. "Is this gluten free?", "what brand is it?", "is it organic?" — your catalogue holds a name, price, unit and stock, and nothing else. Those questions are handed to you rather than answered.
An allergen question answered by a guess, in your shop's voice, is the one failure mode here worth refusing outright.