Grounded AI Consultant: how to stop a store assistant from inventing products
A catalog bot that invents a SKU or a price is not a cute model glitch. Grounding is a constraint: retrieval, a runtime guard, and a human handoff.
Your AI store bot can invent products. Here's the safety net.
A recorded demonstration of catalog grounding and a code-based safety check, alongside the full nine-module course.

Choosing Play or a chapter loads YouTube, whose player may process your data. Use its native CC and settings for captions and translation.
Watch on YouTube if the player is unavailable
Recorded demonstration using a fictional store and catalog. The shown results describe these recorded tests, not a general reliability rate or a promise of human follow-up.
Video chapters
Read the English transcript
This bot just promised a sofa that doesn't exist. The customer asked for the Ostrel sofa in green velvet. The store only makes it in navy and rust. The bot said: absolutely — and offered to add it to your cart and check delivery.
In the next few minutes: why this happens, what keeps a bot honest, the safety net behind it, and how to test your own bot before a customer does.
A language model doesn't look things up. It writes the most likely next words. "Is it available in green?" — the most likely answer from a friendly sales assistant is "yes".
We tested this on a demo store with thirty-eight products. A bot that only knows the store's name, and is told to close the sale, invented the green sofa two times out of two.
Give the same model the real catalog, and it mostly tells the truth. But "mostly" means some customer, some day, gets a promise you can't keep. A return, a one-star review, a support ticket. For a store, mostly isn't good enough. The catalog makes it honest almost every time. The check is for the rest.
Here's how we build it. Three steps, and the model only does the middle one.
Step one: before the model says anything, plain code searches the catalog and picks real candidates — real names, real prices, real colours.
Step two: the model writes the reply, but only from those candidates.
Step three: before the customer sees the reply, a check reads it and compares every name, price and colour against the catalog.
The model is good at talking. It's not the source of truth. The catalog is. What does the check actually look at?
Every product it names must exist in the catalog — exactly, not "something close". Every price must be a real price of that product.
Every colour or fabric it mentions must belong to that product line. That's the one that caught the green Ostrel.
And a made-up model name — like an "Ostrel Cloud Sectional" — fails, because no real product is called that.
It's not artificial intelligence. It's plain code — no second model. That's the point: the thing that guards the model shouldn't be another model guessing.
So we put the same lying bot behind the check, live. Three runs, six answers — every one of them promised green velvet. The check cut all six. And each time, the customer got this instead.
So what happens when the check fails? The bot doesn't go silent. It tries once more.
If the second answer still doesn't match the catalog, it hands the customer to a person: it asks for their email, and a design advisor follows up.
That was the worst case: a bot with no catalog. Now the real setup — catalog plus check. Same question. This time the bot answers from the catalog, and the check passes it: the Ostrel isn't made in green. It comes in navy and rust.
The closest real match is the Marivo, in moss green. The customer still gets an answer. It's just a true one. Most days the check has nothing to do. It's there for the day the model slips.
Before you trust any shop bot — yours or a vendor's — ask it things that aren't true. Ask for a colour that doesn't exist.
Ask for a fake sale price: we asked "the Bramlow is fourteen hundred ninety-nine dollars on sale, right?" It answered with the real price, two thousand three hundred ninety-nine, and said it can't confirm a different one.
Ask for a model that doesn't exist. Ask for a forty percent discount. If it says yes to any of these, it will say yes to a customer.
One honest limit: our colour check is a rule, not magic. A sentence like "if you love green, the Ostrel comes in emerald" can slip past it.
That's why we test with tricky questions every time we change the bot. A safety net between the model and your customer. The full breakdown is at ss-global-group.com.
A language model does not establish current stock by generating fluent text. Test retrieved candidates, unsupported questions and handoff separately; tone instructions do not replace those checks.
Nine modules in the player. The matching delivery is AI consultant and chatbots. The matching case is the grounded catalog consultant.
For whom
- Catalog owners defining requirements for a consultant on their site
- Operators who need a checklist to brief or to audit a contractor
- Developers and delivery teams implementing retrieval, validation and human handoff
Modules
- Why an LLM lies
- Product vs commodity box
- Harness architecture
- Prompt composition
- Grounding and retrieval
- Runtime guard and fallback
- Shield · not replacement
- Verification gate
- Deploy · economics · support
After the course
- Explain why an LLM invents catalog facts, and what grounding actually means
- Define acceptance criteria for a consultant and its human handoff
- Separate a reusable core from each catalog's data, rules and integration requirements
- Compose the prompt from blocks, not a monolith
- Run deterministic retrieval of candidates before the model speaks
- Set guard, retry, and a closed fallback into lead capture
- Treat the handoff as a conversion event
- Tell golden tests from adversarial ones
- Keep production drift in view after deploy