This page describes the architecture behind the preview: what it is designed to guarantee, how a question becomes an answer, and where the honest limits are. Everything here describes the running system, stated so it can be checked rather than taken on trust.
Whether a payment is allowed is checked in code against the buyer's mandate at the moment of payment: total limit, per payment ceiling, allowed merchants, categories and methods. A refusal comes back as a structured reason, and the demo shows which check refused it. Prompt injection cannot move this boundary, because the boundary is not in the prompt.
The chat box classifies each question with patterns, not a model call, so routing costs nothing and behaves the same every time. Each route gets the material that can actually answer it.
| Kind of question | Answered from |
|---|---|
| Shopping: a product, a price, EMI, an offer | the catalogue and the commerce tools, so every number is the backend's |
| Mandate behaviour across a book | the mandate risk tools, scored in code |
| This product: endpoint, keys, models | our own documentation only, so it cannot answer from someone else's API reference |
| Payments, protocols, integration | document retrieval, with the passages cited under the answer |
| Anything else | the model's general knowledge, with no sources claimed |
Time sensitive questions additionally trigger a live web search on any route, because a trained model cannot hold a current price or score.
| Step | What happens |
|---|---|
| 1 | The buyer asks to buy. The router hands the turn to the merchant agent and its tools. |
| 2 | The model searches the catalogue. The price arrives with the time it was fetched. |
| 3 | Stock and mandate balance are checked as needed, each by a tool. |
| 4 | The payment tool takes the product code and quantity. The backend prices the cart, computes GST, and checks the mandate's scope, ceiling and remaining limit. |
| 5 | The gate returns an authorised order with its breakdown, or a structured refusal naming the failed check. The model reports whichever happened. |
One hardening detail: if the model runs out of steps after a payment has already been authorised, the answer is rebuilt from the record of what the tools returned. A buyer is never told a purchase failed when the money was taken. That case came up in testing and is now pinned by a regression test.
Around 1,200 documents indexed as roughly 8,500 retrievable passages, after duplicates and boilerplate are stripped. Most of the corpus was fetched from its publisher, and each of those passages carries the URL it came from and the moment it was read. No single corpus may fill more than 40 percent of one answer, so the largest documentation set cannot crowd out the specification that actually answers.
The offer rates and mandate histories in the preview are sample data. The engines that compute over them are real and run in the backend, and every answer that uses them says the data is illustrative.
The model is served with vLLM on TPU hardware in Mumbai, reachable only
over a private network. The public entry point is one application
machine, also in Mumbai. Serving capacity is spot, which the cloud can
reclaim, so a second node stands by and takes over when that happens.
During a failover window inference may run outside India while logs,
keys and data stay in Mumbai. Rather than hide that,
/v1/health reports
model_serving_region and a
serving_in_india flag, so the residency
claim is checkable in one request at any moment, by anyone.
The pages, key issuing and demos keep working through a model outage. Chat returns a plain unreachable message, and nothing is charged.
| Surface | How it is protected |
|---|---|
| API keys | issued instantly, shown once, stored only as hashes. Per key rate limits, five keys per email, usage tracked per key |
| Open chat box | rate limited per visitor address, with a tighter window on key signups, so the free box cannot be farmed |
| Prompt injection | instruction override attempts are refused before the model runs. A jailbreak can change tone, never money, because the payment boundary is in code |
| Money | no amount ever crosses from the model to the payment tool. There is no field for it |
| Audit | every turn is logged as JSONL in the Mumbai region, so any answer can be reconstructed later |
| Load | What happens | The fix, already known |
|---|---|---|
| Preview traffic today | first words in one to two seconds, measured | nothing |
| Several conversations at once | time to first word stretches as the model batches | a second serving node behind the same configuration |
| Hundreds of active keys | the file based key store strains | move keys and usage to a database |
| Corpus grows tenfold | index builds slow down | incremental indexing, a managed vector store |
A test suite of 21 checks runs before every deploy, including the adversarial corpus checks and the payment regression above. If something that worked stops working, the deploy does not go out.
The full endpoint reference, quickstart and instant keys are on the API docs page. The merchant flows, including a payment refused by its mandate, are live on the demos page.
Preview, not a product. Built around P3P, the Pine Labs Online agentic payments protocol, and the open agentic commerce standards.