A catalogue gives buyers 40 technical fields. Which five facts actually help them purchase?

The client problem

A procurement catalogue can be technically complete and still be difficult to use. Product pages arrive from many suppliers. One description is a marketing paragraph, another is an abbreviation, and a third is little more than a manufacturer reference. Specifications may be present but scattered across dense metadata.

The buyer does not always need another search result. They need a rapid explanation of what the product is, how it is purchased and which details deserve attention before adding it to a request.

We built an AI-generated procurement summary for Medusa product pages to solve that reading problem. The model receives a bounded view of canonical catalogue data, returns five concise bullets and stores the result until the product or generation contract changes.

The AI does not invent price, stock or fit. It turns existing product facts into a more accessible purchasing view.

The client problem is comprehension at catalogue scale

In a multi-supplier marketplace, content quality varies by source. A buyer may encounter a clear product title followed by a description written for a manufacturer website, variant names designed for an ERP and specifications imported as key-value pairs.

The information can be correct but cognitively expensive. A facilities buyer comparing several parts must determine:

• the product's practical purpose;
• the relevant purchasing form or variant;
• the most important technical characteristics;
• distinctive features stated in the catalogue;
• details that affect procurement.

Manually rewriting every product page would improve readability but create an enormous editorial workflow. Generative text is useful here because the task is constrained summarisation, not the creation of new commercial truth.

Begin with canonical product data

The endpoint retrieves the Medusa product and its variants, then builds one explicit text prompt from fields the marketplace already owns.

The input can include title, subtitle, description, handle, variant SKUs, variant titles and bounded specifications or details stored in product metadata. Arrays and objects are normalised into readable key-value phrases. Empty values disappear.

This matters because the model cannot distinguish a trusted product fact from a convenient assumption unless the application controls its context. Giving it the entire database record would expose irrelevant fields and make output behaviour harder to reason about. Giving it only a product name would encourage generic completion from prior knowledge.

The bounded prompt creates a middle path: enough catalogue evidence to explain the item, but no invitation to improvise beyond it.

Keep volatile commercial facts out of the summary

Price is deliberately absent from the canonical prompt. Stock, delivery availability, promotions and tax are absent too.

Those facts change by market, property, seller relationship and time. Baking them into generated prose would create a stale statement that might remain visible after Medusa calculates a different current price or inventory state.

The normal product page can display live commercial components beside the summary. The generated copy focuses on product comprehension: what it is, which form it takes and which catalogue specifications matter.

This separation prevents a helpful reading aid from becoming an unofficial quote. It also means the summary can be cached longer than volatile pricing without misleading the buyer.

Give the model one small editorial job

The generation instruction asks for exactly five brief bullets aimed at procurement professionals:

1. value proposition for procurement;
2. product and purchasing highlights;
3. key technical specifications;
4. distinctive product features;
5. important procurement notes.

It also instructs the model to use only the supplied canonical information.

A narrow format improves consistency across an uneven catalogue. Buyers know what kind of information to expect and the product page does not expand into a generated essay. The token budget bounds generation cost and latency.

The architecture is intentionally modest. We are not asking a general agent to decide whether the product suits a particular building or to infer regulatory compliance. We are asking a language model to compress existing facts into a predictable reading surface.

Store the result instead of regenerating on every visit

Calling a model every time a shopper opens a product page would be slow, expensive and inconsistent. Two buyers could receive different wording for an unchanged product, while a provider outage could break an otherwise valid page.

The product-summary module stores one generated result per product together with the product update timestamp, model identity and prompt version.

When a request arrives, the service checks the stored record first. If the content exists and all three provenance values still match, it returns the stored summary without calling the model.

The first visitor pays the generation latency. Later visitors receive a stable database-backed explanation. Observability indicates whether the response was stored or newly generated without making logging part of the shopper response.

Invalidate when the source or generation contract changes

A summary should survive repeated page views, but not a meaningful product update.

The stored record includes the updated_at value of the product used to generate it. When that timestamp changes, the next request regenerates and replaces the summary. Changing the selected model or prompt version also invalidates the old result.

This covers two distinct causes of staleness:

• catalogue facts changed;
• the editorial generation contract changed.

The strategy is broader than a digest of just the selected prompt fields: any product update can trigger regeneration. That may produce occasional extra work, but it errs toward refreshing copy when the catalogue record evolves.

Prompt-version invalidation is equally important. If the brand later tightens tone, changes the five-bullet structure or adds stronger unsupported-claim guidance, incrementing the version prevents old summaries from living beside new rules forever.

Handle concurrent first requests

Two shoppers can open the same unsummarised product at nearly the same time. Both requests may find no stored row and generate content.

The database enforces one active summary per product. If one request wins the insert and the other receives a uniqueness failure, the losing request reloads the winner. If that record is current for the same product timestamp, model and prompt, it returns the stored result instead of failing the product page.

This is a small but useful production detail. AI features are often demonstrated in isolation, where only one request exists. Commerce traffic creates concurrency even for apparently simple enrichment.

The unique record makes the database the arbiter of the cache rather than relying on process-local memory.

Treat the summary as presentation, not catalogue truth

The generated bullets live in a dedicated product-summary module. They do not overwrite the product description, specifications or variants.

That preserves a clean direction of authority. Supplier and catalogue operations manage canonical facts. The AI layer derives readable copy from them. If the summary is unavailable, the original product data still exists. If the generated wording is poor, it can be regenerated or hidden without repairing the catalogue.

This also makes replacement straightforward. A future deterministic formatter, a different model or a human-authored summary can occupy the presentation layer without changing Medusa's product schema.

Derived content should be useful and disposable. Canonical product data should remain durable and reviewable.

Make missing facts visible through omission

A model tends to produce fluent prose even when evidence is thin. The application must resist the temptation to reward completeness over accuracy.

The prompt contains only non-empty canonical fields. If the catalogue provides no voltage, material or compatibility detail, the summary should not manufacture one to fill a bullet. The “important procurement notes” line can remain general to the supplied purchasing form rather than inventing warnings.

Output can also be checked before storage: exactly five bullets, bounded length, no prices or unsupported superlatives, and no claims absent from the prompt. A failed check should leave the page with canonical content rather than promoting weak generated copy.

That validation is a natural next layer around the implemented storage contract. The model produces a candidate; the application owns whether the candidate is fit to display.

Keep the voice useful rather than promotional

A procurement summary should reduce uncertainty, not add advertising language. “Industry-leading”, “perfect for every application” and “guaranteed performance” are especially risky when those claims do not appear in the supplier data.

The five roles in the prompt create a practical editorial frame, but brand tone still needs a gate. Prefer concrete facts such as voltage, pack size, material, compatible variant or stated feature. If the source says only “cordless drill”, the summary should remain modest rather than compensate with enthusiasm.

This is where a small content feature reflects the wider marketplace promise. Buyers return when the platform helps them make decisions, not when it restates every product as exceptional. Clear limitations and absent facts are often more valuable than another adjective.

Do not confuse authentication with product eligibility

The product-summary route is part of the store API and receives a product ID. Its own implementation retrieves that product directly from Medusa before generation.

That means surrounding authentication and product-visibility policy remain important. The summary endpoint should be reachable only in the same contexts where the shopper may view the underlying product. It should not become a way to request information about hidden supplier catalogue entries by guessing identifiers.

This boundary is easy to overlook because the output contains no price. Product titles, SKUs and specifications can still be commercially sensitive in a private catalogue.

A production review should therefore verify that middleware and route policy align the summary with the product detail page's actual visibility contract.

What the buyer experiences

The resulting product page adds one compact layer above dense catalogue facts:

1. The buyer opens a product they can view.
2. Medusa supplies the canonical product and variants.
3. A current stored summary returns immediately, or a new one is generated from bounded fields.
4. Five bullets explain the product for procurement.
5. Live components continue to show price, stock and delivery separately.
6. A later product or prompt update causes the explanation to refresh.

The buyer can understand the item faster without being asked to trust generated commercial promises.

Why Medusa is the right place to anchor the feature

Medusa owns the product and variant lifecycle, so it provides the update signal and canonical fields used for generation. A dedicated module stores the derived output without contaminating the core product description.

We chose this architecture because the client's need was not “put AI on the product page”. It was “make a large, uneven supplier catalogue easier for professional buyers to understand”. The useful solution combines catalogue authority, a narrow model task, persistent output and explicit invalidation.

This is a pattern that travels well: AI can improve the interface around commerce truth while the commerce engine continues to own the truth itself.

If your supplier catalogue is technically complete but difficult to buy from, WeAreSouk can design a Medusa enrichment layer that makes canonical product facts easier to understand without turning generated copy into commercial authority.