Our summary
A merchant may want products with low stock and a particular status without clicking through several filter menus. Demirhan Aydin describes a Fabrikatör feature that turns a written request into proposed filters. People review the proposal before it changes the product list, using the page's existing filtering rules.
Code lists possible fields, comparisons and values found in the user's words; Jev chooses among them and checks the proposal. Another model splits requests with several conditions. If one condition is unclear, understood filters stay in the proposal beside a question. Apply remains disabled until each open question is answered or removed.
Supplied model answers test the code, live calls test interpretation, and browser checks test the interaction. Aydin reports one confidently wrong filter in twenty new test cases; the cutoffs are hand-set, not calibrated. Providers receive descriptions and field definitions, reportedly not product records. Users must still inspect proposals, including confident ones.
Key takeaways
- Keep understood conditions visible instead of discarding a whole request, but do not silently apply a partial meaning.
- Use existing filter choices and values from the user's words. A model cannot choose a value the code failed to find.
- Count confident mistakes separately from unresolved requests. Passing tests with supplied answers does not show that the live model understands customers.