Build a Delivery-Aware AI Diamond Ring Advisor with UCP

“My marriage day is 01-Aug. Suggest me diamond rings.”

An ordinary search engine answers that with hundreds of rings. A generic AI chatbot answers it with a few attractive-sounding suggestions that may be out of stock, over budget, or impossible to deliver in time. Neither has actually helped.

The customer is not asking to browse. They are asking a set of specific questions and expecting the store to answer them: which rings suit the occasion, which fit the budget, which are available in their size, which are certified, and — the one everything else hinges on — which can safely arrive before 1 August.

This article shows how to build that experience with three parts kept firmly in their lanes: deterministic commerce services that own the facts, an LLM that understands language, and the Universal Commerce Protocol (UCP) as an optional layer for exposing the same engine to external AI surfaces later.

The customer is not asking for search results

A query returns documents. A buying decision needs answers. The phrase “suggest me diamond rings” is thin on detail but rich in intent: an occasion, a relationship context, a deadline, a product category, and real urgency.

The mistake is to respond by asking ten questions. The right move is to ask the smallest number that removes the highest-impact uncertainty, and to start showing safe options immediately. A good first reply:

Congratulations. I can help you find rings that can arrive before 1 August. What’s your budget, and which postcode should I deliver to?

Budget and destination come first because they decide whether a product is feasible at all. Metal finish and setting style can wait — they reorder a shortlist; budget and delivery decide what is even on it.

What the assistant must understand

The language layer’s job is to turn free text into a structured intent object that the commerce services can act on.

export type ShoppingIntent = {
  query: string;
  occasion?: "wedding" | "engagement" | "anniversary" | "gift";
  eventDate?: string;
  budget?: {
    max?: number;
    currency: string;
  };
  category?: string;
  metal?: string;
  diamondType?: "natural" | "lab_grown" | "moissanite";
  ringSize?: string;
  deliveryCountry?: string;
  deliveryPostalCode?: string;
  readyToShipOnly?: boolean;
};

A few edge cases matter here. 01-Aug has no year, so the system resolves the next valid occurrence in the customer’s timezone. “Marriage day” might mean the wedding, the engagement or an anniversary; the assistant proceeds with a safe default and only asks when the answer would change which products are eligible. The principle: the LLM converts language into structured intent, but it never decides whether a product is actually available.

Language intelligence over deterministic commerce

The architecture is a thin language layer sitting on top of ordinary commerce services. The LLM interprets and explains; the services decide and calculate.

flowchart LR
    A[Customer message] --> B[Intent extraction]
    B --> C{Enough information?}
    C -- No --> D[Ask one useful question]
    D --> B
    C -- Yes --> E[Catalogue candidate search]
    E --> F[Variant and inventory validation]
    F --> G[Price and promotion service]
    G --> H[Delivery promise service]
    H --> I[Eligibility and ranking]
    I --> J[Explanation generator]
    J --> K[Product cards]
    K --> L[Cart and checkout]

The split of responsibility is the whole design:

• The LLM may handle intent extraction, synonym and style interpretation, query reformulation, choosing the next clarification question, and explaining why a product is recommended.
• Commerce services must handle product IDs, variant availability, price, promotions, inventory, ring-size availability, tax, shipping method, delivery estimates, cart totals, payment and order state.

Candidate retrieval and hard constraints

Retrieval runs in two stages. First, cast a wide net; then, validate every result against reality.

Stage A — retrieve possible matches using category filters, keyword or full-text search, attribute filters, optional semantic or vector search, and popularity signals. A dedicated search engine earns its place here; if you are standing one up, our Meilisearch production setup covers the operational side.

Stage B — validate every candidate against tenant ownership, product visibility, a sellable variant, the actual price, current stock, the requested ring size, country eligibility, the delivery deadline, and any customisation requirement.

Semantic similarity is a soft signal. It may reorder results, but it must never override a hard constraint. A ring that is a perfect stylistic match but two sizes short, or that cannot arrive before the event, is not a candidate — no matter how close the embedding.

const candidates = await searchProducts(intent);

const validated = await Promise.all(
  candidates.map((product) => validateProduct(product, intent)),
);

const eligible = validated.filter((item) => item.eligible);
const ranked = rankProducts(eligible, intent).slice(0, 5);

Delivery-aware recommendations are the real differentiator

The event date is what turns product discovery into a fulfilment problem, and fulfilment is where most “AI shopping” demos quietly fall apart. For each candidate, compute an honest estimate:

processing time
+ resizing or customisation time
+ warehouse cut-off
+ carrier transit time
+ operational safety buffer
= estimated delivery date

Model the result explicitly rather than as a loose string:

export type DeliveryFeasibility = {
  eligible: boolean;
  estimatedDeliveryDate?: string;
  confidence: "guaranteed" | "high" | "medium" | "low";
  reasonCodes: string[];
};

Products fall into classes that behave very differently against a deadline: ready to ship, available after resizing, made to order, customised or engraved, and backordered. For an urgent event, rank a ready-to-ship ring above a made-to-order one even when the latter is a slightly better stylistic match — arriving on time is the constraint the customer cannot flex.

Label the outcome honestly, and never manufacture urgency:

• Guaranteed by 29 July — only when a contract genuinely backs it.
• Estimated delivery by 29 July — calculated, but not guaranteed.
• May not arrive before your event — when the risk is material.

Ranking and explaining recommendations

Ranking should be a transparent, weighted score, not a black box:

Delivery confidence       35%
Budget fit                20%
Occasion/style match      15%
Size availability         10%
Product quality signals   10%
Popularity/conversion      5%
Commercial priority        5%

Those weights are a starting point, not gospel. They should be configurable per tenant and tested against real behaviour. And commercial priority must never let a sponsored or high-margin product bypass suitability — a ring that misses the deadline does not get promoted because it earns more.

The output is a short set of options with clear trade-offs, each with a one-line reason:

Classic Solitaire Ring — the safest choice. ₹79,900. 0.50 ct lab-grown diamond, IGI certified, available in size 12. Estimated delivery 29 July. Recommended because it is within budget, ready to ship and suited to everyday wear.

Halo Diamond Ring — stronger visual impact. ₹1,24,900. 0.75 ct centre appearance, IGI certified. Estimated delivery 30 July. Recommended when visual size matters more than minimal styling.

Three to five options with meaningful differences beat a twenty-product grid. The assistant’s value is in narrowing, not listing.

The conversational search interface

The interface is a conversation with products embedded in it, not a form. It carries the running exchange of messages, quick-answer chips, and recommendation cards inline — each with image, key specs, price, delivery status, and the obvious actions (view, compare, shortlist, add to cart). A persistent natural-language input sits at the bottom, with a clear line on what data is used.

Progressive disclosure keeps it pleasant: don’t ask for ring size before showing anything when size is not yet needed; let the customer browse while they answer; keep extracted preferences visible and editable; and preserve the conversation when they open a product page and return. On mobile, that means a single column of cards, a sticky input, large tap targets, and no modal questionnaire.

Where the Universal Commerce Protocol fits

Only now — with the internal flow working — does UCP become relevant.

The Universal Commerce Protocol is an open standard for connecting commerce businesses with AI platforms and other consumer surfaces through shared capabilities for catalogue, cart, checkout, payment and post-purchase operations. It was co-developed by a group including Google, Shopify and Amazon; the current specification is dated 2026-04-08. It gives external surfaces a common way to discover and use your commerce services — nothing more.

A UCP integration for a platform like Litekart should be an adapter over existing services, not a new brain:

flowchart TB
    A[Google AI surface or other shopping agent] --> B[UCP]
    B --> C[Litekart UCP gateway]
    C --> D[Catalogue service]
    C --> E[Cart and checkout service]
    C --> F[Payment service]
    C --> G[Order service]
    D --> H[(Tenant commerce data)]
    E --> H
    G --> H

The verifiable mechanics of the current specification: a business publishes a profile at /.well-known/ucp declaring a protocol version, its services (the spec defines a dev.ucp.shopping service over REST, MCP and other transports), its capabilities (Cart, Checkout, Order, Identity Linking and Catalog, with extensions such as Fulfillment and Discounts), its payment_handlers, and a set of signing_keys as a JWK set. Platforms read that profile and configure themselves against it.

Two facts to state plainly. First, the merchant remains responsible for pricing, inventory, fulfilment, returns, support and the order lifecycle — UCP does not take any of that over. Second, the details above change; treat the official specification (opens in a new tab) and the protocol repository (opens in a new tab) as the source of truth, and use the current published schema rather than any hand-copied JSON.

On Google specifically, verified as of 23 July 2026: UCP-powered checkout is in early access for select merchants, gated behind Merchant Center onboarding and an interest form, limited to products eligible in the United States, Canada and Australia, and surfaced in AI Mode in Search and Gemini. Products opt in through a native_commerce(checkout_eligibility) attribute, and the merchant stays the seller of record. This is not yet a generally available feature — plan around that.

Native checkout versus embedded checkout

UCP supports a native REST/MCP checkout and an embedded flow (the business hands back a continue_url that carries the buyer into a merchant-controlled interface). Choosing between them is a product decision, not a box to tick.

Do not force a complex jewellery purchase into native checkout just to claim UCP support. When human or specialised configuration is genuinely required, route the customer into the merchant-controlled experience — that is what the embedded path is for.

A shared module, not a per-store integration

For a multi-tenant platform, the conversational layer and the UCP layer should each be one shared module, configured per tenant — not re-implemented per store. A shape that has held up:

src/modules/conversational-commerce/
├── intent/
├── recommendations/
├── delivery/
├── ranking/
├── sessions/
└── analytics/

src/modules/ucp/
├── profile/
├── checkout/
├── cart/
├── orders/
├── payments/
├── security/
└── adapters/

Tenant configuration then controls whether conversational shopping is on, supported countries and currencies, eligible categories, the delivery safety buffer, UCP capability flags, Merchant Center mapping, payment-handler configuration, and native-versus-embedded eligibility. One central adapter is far easier to secure, test and upgrade when the UCP schema moves — and it will. (This layout is a recommendation for a Litekart-style architecture, not a UCP requirement.)

Security and failure behaviour

A few rules keep an agentic flow from becoming a liability. Never send raw card data to the LLM, and redact personal data from prompts and logs. Use authenticated server-to-server requests, validate every protocol payload against the official schema, and recalculate price and availability at checkout rather than trusting anything the conversation carried in. Support idempotency on checkout completion to defeat replays, rate-limit per tenant, and keep correlation IDs across conversation, cart and order events so a session is auditable end to end.

Then decide, in advance, what happens when reality disagrees with the conversation:

What to build first

The sequence matters more than any single component:

1. A useful storefront assistant — natural-language search, structured intent, real catalogue filtering, live price and inventory validation, delivery feasibility, product cards, add to cart, basic analytics.
2. Better recommendation quality — a style and occasion taxonomy, compare and shortlist, customer feedback signals, improved ranking, multilingual input, logged-in preferences.
3. A UCP gateway — business profile, capability negotiation, cart and checkout adapters, payment-handler integration, order-lifecycle updates, conformance checks, Merchant Center preparation.
4. External onboarding — sandbox and production validation, product-eligibility configuration, Google approval where applicable, then a limited merchant pilot.

The storefront assistant delivers value on its own, long before any UCP onboarding is complete. That is the point: phase 1 is a shipping product, not a prerequisite.

How the three approaches compare

The jump that creates value is from column one to column two. UCP adds a third column — external reach — on top of an engine that already works.

How to measure success

Message count is a vanity metric. Track the funnel: assistant opened → first message → clarification completed → recommendation shown → product clicked → add to cart → checkout started → order completed.

The metrics that tell you whether it works: recommendation click-through, add-to-cart rate from recommendations, checkout conversion, revenue per assisted session, time to first suitable product, delivery-promise accuracy, recommendation rejection rate, zero-result rate, and the share of recommended products later found unavailable. Run it as an A/B test against your existing search, and do not claim an improvement before you have the data.

Build the engine, then open the doors

A conversational search box is easy to draw and easy to wire to an LLM. The difficult, valuable work is grounding every recommendation in real catalogue, variant, price, delivery and checkout data. Build that reliable internal capability first. Once it works, UCP can expose the same commerce engine to compatible AI shopping surfaces without you rebuilding the business logic for every platform.

Litekart is exploring this as a reusable conversational commerce layer for multi-tenant stores. The first target is not autonomous purchasing. It is helping a real customer confidently find a ring that fits the occasion, the budget and the deadline.