AI Field Validator

A product custom option takes free text – an engraving, a tax number, a licence reference, a gift message – and Adobe Commerce and Magento Open Source will check that it is present and short enough, and nothing about what it says. The malformed value is found later, in production or in accounting.

Encoding each format costs a developer ticket, and there is a new format every few months. This extension replaces the ticket with a sentence: the merchant writes the rule in plain language on the option itself, and a language model, reached through the companion WebRamos LLM Provider gateway, decides whether the shopper's input satisfies it. The shopper gets a verdict as they leave the field, with a reason and often a suggested correction; the server checks again at add to cart, so the answer cannot be bypassed from the browser.

• The rule is about meaning, not shape. An engraving brief that a workshop must be able to execute, a gift message that has to read as one, a delivery instruction a courier can act on. This is the case the extension is built around, and no regular expression expresses it. Nothing on the Adobe Marketplace covers it today either – a search for profanity filtering, run 2026-09-08, returns no listings.
• A rejection has to be explainable. The verdict carries a reason in the customer's terms and, where the model can produce one, a corrected value shown as "Did you mean …?". A pattern match can only colour the field red.
• Your custom options take formats that have no library. A licence key layout, a supplier's part-number scheme, a national identifier no package covers. Write the format into the rule – but see the next question first, because a format alone is the weakest case for this extension.
• New formats arrive faster than releases. Adding a rule is a form in the admin, not a deployment.
• You want strictness to differ per field. Strict blocks the add to cart, soft warns and lets the customer through, advisory only hints. Each rule also carries its own confidence threshold.
• You already run another extension in this range. The LLM Provider gateway is configured once and shared, so a second AI extension adds no second key, no second budget and no second log.

• Buy Swissup's Vat Number Validation for EU VAT. At USD 99.00 on every edition, measured 2026-09-08, it checks the number against VIES and can zero the tax when it is valid. A model can tell a well-formed VAT number from a malformed one; it cannot tell you the company is real. Where a registry exists, integrate with the registry.
• Buy a telephone or postcode validator for those. Telephone Validation is USD 70.00 and Product Zipcode Validation USD 129.00 on Magento Open Source. They solve one format each, in the browser, with no per-call cost. Do not pay a model to answer a solved question.
• Do not buy it to enforce a character pattern. If the rule can be written as a regular expression – exactly sixteen characters, six letters then two digits – then a pattern in your theme answers it for free and instantly, and a model asked to enforce a format tends to explain a rejection by restating the pattern, which is not a sentence a shopper can act on.
• Buy a form builder if you need forms. Amasty Custom Forms – USD 249.00 the first year, 155.00 a year after – gives you a drag-and-drop builder, fifteen input types and file uploads, with format-or-regex validation included. This extension builds no forms.
• Do not buy it if customer input may not leave your servers. Validation sends the field's value to the LLM provider you configured. The gateway supports a local Ollama server, which keeps it on your own infrastructure, but that is a decision to make before purchase, not after.
• Do not buy it for checkout fields. Today it validates catalog custom options only.

• Plain-language rules bound to a product's custom option, of type Field and Area, managed from the option itself or from a Validation Rules grid with mass enable, disable and delete.
• An inline verdict on the storefront, at blur time, on both Luma and Hyvä Theme: valid, or the reason it is not, plus a "Did you mean …?" correction when the model supplies one.
• Authoritative server-side enforcement at add to cart, so the storefront badge cannot be worked around.
• Three strictness levels – strict, soft, advisory – and a per-rule minimum confidence, so an unsure verdict is handled as unsure.
• Two model tiers, junior for everyday rules and senior for hard ones, resolved to actual models in the gateway's configuration rather than in code.
• Cost control in four places: a verdict cache keyed on the input, with a per-rule TTL; a per-session rate limit; a per-IP rate limit; and a daily spend cap for this module on top of the gateway's own.
• Three declared fallbacks for an outage or an exhausted budget – accept with a warning, reject, or use the last cached verdict – so checkout has a stated behaviour rather than an exception.
• Prompt-injection hardening both ways. The merchant's rule and the shopper's value are fenced apart when the prompt is built, and a suggested correction that echoes injection-style imperatives is dropped while the verdict is kept. Reasons and suggestions are length-capped before they reach a page.
• A Test with sample value button on the rule form, so a rule is tuned against real input before a customer meets it.
• Two new tables, three ACL resources, six configuration fields of its own plus three in the gateway's section. No core table is modified.

• It does not validate checkout fields, customer attributes or admin forms. Catalog custom options of type Field and Area, and nothing else. Options that are dropdowns, dates or file uploads are outside it by construction.
• It does not run without the gateway and your own provider key. WebRamos LLM Provider is a hard dependency, published free of charge, and the provider account and its bills are yours. Nothing is resold here and there is no bundled quota.
• It does not keep the customer's input on your server alone. The value in a validated field is sent to the provider you configured. Disclose that in your privacy policy; the extension will not do it for you.
• It cannot promise the model is right. A verdict is a judgement, not a registry lookup. Confidence thresholds and the three strictness levels exist because of that, and a rule that must never be wrong belongs with an integration that queries an authority.
• The daily spend cap is a soft ceiling, inherited from the gateway: a call's cost is known only once it has been answered, so the call that crosses the cap completes and the next is refused.
• It prunes nothing on a schedule. There is no console command and no cron job; cached verdicts persist until their rule is deleted, which cascades them away.
• The rules grid filters by column, not by free text. Entity, status and the other columns filter; there is no keyword search across rule prompts.
• It never writes copy. It reads what a shopper typed and answers a question about it. Generating descriptions or metadata is a different extension.