These are sanitized demonstrations of how the assistant behaves — not production customer logs.
Anonymized commercial system · governed multi-channel conversational commerceCLIENT-SANITIZED
Persian Conversational Commerce
A governed sales assistant that separates what a model may interpret from what the catalog and deterministic policy are allowed to assert — it sells consultatively, refuses unsafe or fabricated answers, and serves customers across web widget, Telegram, and Instagram DM. The public surface below is a sanitized representative replay of the product experience, not a live production endpoint.
- Owns
- Grounds conversational selling in approved catalog facts and policy
- Status
- Production-ready release · sanitized public case study · live activation not claimed
- Stack
- Python · FastAPI · Redis · RAG · WooCommerce · Telegram
Anonymized commercial system · contribution: product architecture, backend, Persian NLU/NLP, evaluation, conversational UI, release hardening
Client identity and commercial internals are withheld; the public surface is a sanitized replay, not a live production endpoint.
Hard problem
Models interpret language; approved catalog and policy decide what is true, safe, and allowed to sell.
Question · How can an AI sales assistant guide customers toward suitable products without inventing facts, ignoring safety, or improvising commercial policy?
APPLIES TO
Commerce Product Teams · AI Backend Teams · Persian-language digital commerce · Teams operating grounded product assistants
PROOF
600/600 persona+behavior offline gates · 420/420 planner fixtures · 114/114 grounded-response fixtures · production-ready, activation not claimed
CAPABILITIES
12 declared in the project record
- Interpretation and truth separation
- Explicit commercial relationships
- Deterministic eligibility gating
- Validated commerce lookups
- Approved catalog grounding
- Semantic planner
- Grounded response gate
- Persona style gate
- Selling eligibility gate
- Recent-turn memory
- Continuity integration
- Candidate corpus
Architecture
The operating path.
- 01Request
Persian natural language
- 02Interpret
intent · context · constraints
- 03Ground
approved catalog authority
- 04Policy
eligibility · clarification · safety
- 05Recommend
bounded commerce relationships
- 06Respond
structured conversational output
Product surface
Sell when evidence allows it. Refuse when it does not.
A live, sanitized replaySix conversations from the real system · no production logs
Numbers come from representative WooCommerce snapshots, not live checkout. In the product, the store remains the authority for price and stock.
Medical-adjacent wording is softened here. This is product-selection evidence, not medical advice.
Engineering decisions
The constraints that matter.
Separate language interpretation from product truth
The model may interpret intent and context, but approved catalog records remain factual authority.
Keep commercial relationships explicit
Cross-sell, upsell, bundles, and substitutes come from approved relationships rather than improvised model preference.
Gate selling eligibility deterministically
Approved selling edges are required before offers; caller-provided IDs are necessary but never sufficient.
Require valid commerce lookups for prices and links
A missing or failed WooCommerce source produces a stated failure and a labeled prior snapshot — never an estimated fact.
Measurement contract
What would make the preferred answer fail?
EVALUATION METHOD
Conversation quality is bounded by grounding, policy correctness, persona consistency, continuity, and the absence of invented product facts.
Persian intent fixtures, grounded-response suites, persona/style gates, golden behavior constraint cases, multi-turn replays, eligibility and injection boundary tests, and catalog mutation tests.
Planner accuracy
intent + constraint extractionPersona / style gate
offline renderer-persona suiteGolden behavior constraints
forbidden claims · invented prices · off-policy offersGrounded response
claims backed by catalog authoritySelling eligibility
approved edges only, IDs not sufficientContinuity
bounded recent-turn state preservationValidation
What the evidence actually supports.
Semantic planner dry-run
VERIFIED420 / 420 fixture cases passed
Dry-run contract coverage; not live-model NLU accuracy.
Grounded-response gate
VERIFIED114 / 114 provider-free cases passed
Provider-free fixture gate; not production rollout evidence.
Persona / style gate
VERIFIED600 / 600 offline renderer-persona cases passed
Offline deterministic runtime gate; not proof of frontier-model naturalness.
Golden behavior constraint eval
VERIFIED600 / 600 offline cases passed · forbidden output claims 0 · unapproved record usage 0 · static price/link invention 0 · selling-offer invention 0
Provider-free local validation; not production conversion evidence.
Selling eligibility gate
VERIFIEDApproved selling edges gated before offers · non-approved candidates blocked · caller-provided IDs necessary but not sufficient
Deterministic policy property; scope is the tested catalog fixtures.
Recent-turn memory
SUPPORTEDBounded prior-turn context · transcript remains untrusted · context/session isolation enforced
Runtime design constraint; not a long-term memory claim.
Unsupported factual claims
VERIFIED0 in the 114-case provider-free gate
Scoped to the tested fixtures and approved catalog data.
Continuity / commerce integration
SYNTHETIC8 / 8 provider-free cases passed · 4 multi-turn · 4 mocked commerce
Mocked commerce path; no revenue or conversion claim.
Runtime candidate corpus
SYNTHETIC36 approved catalog records · 325 generated retrieval chunks
Catalog scale only; not production traffic scale.
Boundaries
— No medical diagnosis or treatment authority— No production customer conversations or raw logs— No private client identity or commercial internals— No unsupported traffic, conversion, or revenue claims— Displayed commerce values are representative snapshots, not current prices