Rudra-JS gives a language model control over a product-recommendation block’s layout and wording, but keeps prices, product names, images and links out of the model’s output fields. The model selects products by SKU, and React fills in their details from the retailer’s catalog when rendering the page. The MIT-licensed library offers a concrete pattern for reducing fabricated commerce claims without asking an LLM to become a reliable product database. (GitHub repository)
The repository describes version 0.8.3 as early and pre-1.0, with public APIs that may change between minor releases. Its documentation also openly identifies ways unsupported claims can survive its text filters. This analysis examines those published mechanisms and limitations; it is not an independent test of the library.
The useful distinction is between controlling where product facts come from and checking whether generated prose is truthful. Rudra-JS provides a stronger boundary for the first problem than the second.
How the SKU-Based Specification Works
Rudra-JS asks the model for a constrained specification instead of raw HTML. The model can choose a layout, write a headline and supply descriptive copy. It references products only through SKUs drawn from the candidate list supplied by the application.
The specification has no field for a product’s price, name, image or link. The React renderer resolves those details from the catalog. Model-authored text is rendered as escaped text, so it cannot directly become arbitrary HTML. (Repository documentation)
That division gives each part of the system a limited job:
- The application supplies candidates: the products the model is allowed to select.
- The model proposes presentation: a layout, product selections and accompanying wording.
- The library checks the specification and copy: generated fields are checked against its rules.
- React renders product facts: catalog entries provide titles, prices, images and destinations.
I’d treat this separation as the project’s most useful design choice. A prompt asking an LLM to copy a price accurately still leaves the model responsible for reproducing that price. A renderer reading a catalog field removes that copying step.
It also creates a practical freshness benefit. If an application passes updated catalog entries to the renderer, the displayed product facts can reflect those entries without requiring the model to rewrite them. That is an implication of the documented rendering design, not a measured result.
Catalog grounding still depends on catalog quality. An incorrect price in the retailer’s data remains an incorrect price on the page. The library establishes the source of the displayed fact; it does not independently verify the retailer’s inventory or pricing system.
Where the Three Text Filters Fall Short
Rudra-JS checks model-authored wording in three passes. A field that fails a pass is dropped. The checks cover several common forms of misleading commerce copy, but their mechanics leave documented gaps. (README)
| Check | What it looks for | Documented limitation |
|---|---|---|
| Commerce patterns | Prices, discounts, ratings, delivery dates and stock counts | Rewording outside the recognized patterns can pass |
| Digit check | Every digit in a sentence must come from supplied product categories or tags | Numbers spelled out as words escape this check |
| Number-free claim list | Claims such as popularity or preferred-product assertions | Unlisted wording can evade the list |
The README gives an explicit example that passes all three:
“Four and a half stars from other hikers”
That sentence communicates a numerical rating without using digits. Its wording also avoids the other checks. The repository says its tests retain examples of rewordings that still pass, making the known gap visible to developers. (Documented filter bypass)
The digit check has another important boundary: it checks whether a digit comes from permitted input, not whether every sentence containing that digit is semantically justified. Matching an allowed number and proving a claim are different tasks.
This matters because an interface can display an accurate catalog price beside unsupported generated praise. Escaping the text makes it safer to render as HTML; escaping cannot make a fabricated rating true.
My view is that teams should evaluate the fields separately. A catalog-backed price field and a free-text recommendation explanation have different assurance levels, even when they appear in the same card. Treating the whole block as verified would obscure the exact weakness the project documents.
Structural Constraints Reduce the Scope of Failure
Rudra-JS’s strongest protection is the absence of model-controlled fields for critical product details. A generated specification cannot insert a fabricated image URL into a field that does not exist. Product selection is also constrained to the supplied SKU list. (Repository)
Free text remains more permissive. A model can still imply a discount, popularity, quality or availability through language that the filters miss. The resulting boundary is specific: structured product details come from the catalog, while generated claims receive incomplete text-level screening.
For a retailer, that suggests a useful integration review:
- Identify every customer-visible field whose value comes from the catalog.
- Identify every field the model can write.
- Review the second group for claims that could affect a purchase decision.
- Avoid treating a passed text check as proof that the wording is supported.
These are practical implications of the documented design. They also explain why structural constraints are valuable even when filters remain imperfect: they reduce the number of places where a model can invent consequential details.
The architecture does not need to solve every language problem to improve on unrestricted generated HTML. Its benefit comes from assigning authoritative facts to application data and limiting the model’s role.
Replay Mode Separates UI Testing From Model Spending
The example shop demonstrates another useful separation: a model-generated response can be recorded once and played back without another model call.
According to the project website, the demo replays a saved answer for one product page. Opening another product uses a block built by the core library without a model, because no answer was recorded for that page. (Demo behavior)
Replay and no-model generation serve different purposes:
- Replay presents a previously recorded model answer, allowing the surrounding integration to be examined without repeatedly buying inference.
- No-model mode builds the block directly. The documentation describes this as a fully supported setting, with the same input producing the same block.
Neither mode measures how a live model will behave on new requests. A successful replay can help a team inspect rendering and page integration, but it cannot reveal new wording failures, response variability or live-provider behavior.
Frequently Asked Questions
3 questions
1Does Rudra-JS Eliminate Hallucinated Claims?
No. It sources structured product details from the catalog, but unsupported claims can still pass through generated copy when they evade the text filters.
