# Found on the first try. > Search and Discovery is the CommerceClarity area that works the layer a search engine reads. Two agents run here: Taxonomy Mapping, which puts every product in a valid category, and On-site Search Enrichment, which fills the attributes and synonyms an index needs to reason on. It does not replace Algolia, FactFinder, Coveo or a platform’s own search: the relevance ceiling is set by the catalog underneath, and that is what the agents raise. Agents working the layer your search engine reads: every product in the right category, and the attributes and synonyms the index needs to reason on. Algolia, FactFinder, Coveo or the search that came with your platform, the relevance ceiling is set by the catalog underneath it. ![A shopper standing still with her phone while the supermarket aisle around her streaks past.](https://cdn.sanity.io/images/xd4hrbt2/production/5ed42dfefc8284243213d0374dddb3da838635a1-1774x887.jpg) [Book a demo](/book-a-demo) ## The engine can only match what the catalog says The queries that fail are the ordinary ones. Asked for the worst searches on their own site, a grocery retailer sent back 4: still water, soft bread, yellow peppers, tuna. Plain words, and 3 of them a product name with no attribute attached to it. What goes wrong is a matching failure rather than a search failure. Ask for red trousers and a product named carrot comes back, because the word matched. Ask for an elegant shirt and you collide with a brand that is literally called Elegant. The engine did exactly what it was told, on the only thing it was given. Underneath both sits the taxonomy, and it is usually two taxonomies. One retailer handed us their tree and told us which half of it was real: 1,000 live leaf categories against 3,000 counting the disabled legacy ones, plus a set of leaves still alive under a parent that had been switched off. Search filters, SEO landing pages and marketplace acceptance all read that tree, so a category that does not resolve costs you all three at once. ## The jobs on discovery A few of the ones that run here, and the area is not limited to them. Each is a single workflow with its own output and its own numbers, reading the same records the rest of the catalog reads. - Taxonomy Mapping · Classify every product into the right category automatically. · Continuous - On-site Search Enrichment · Fix on-site search relevance with better attributes, on Algolia, FactFinder and the rest. · Continuous ## The category, and the words around it *Findability* What decides whether a product surfaces sits underneath the query, and that is where the agents work. The category comes first: every product classified at the right depth of your own tree, continuously, with the drift between the tree you designed and the tree you actually use reported back to you. A boundary call stays a category argument rather than a keyword one, so a fixed balcony solar kit is a different product from a portable panel however similar the words look. Products with no valid slot come back as the list of categories your taxonomy is missing. Then the attribute layer the index reads: missing attributes generated, existing ones normalized, and the synonym and variant lists the engine needs, so a search for red trousers returns trousers. Algolia, FactFinder, Coveo or an agentic engine, that layer is the ceiling on all of them. ## What retailers ask us ### Do you replace our search engine? No. We work on the layer it indexes. Algolia, FactFinder, Coveo or the search that came with your platform: the agent improves the attributes, synonyms and categories the engine reasons on, and the engine stays where it is. ### How do you know the classification is right? It is measured, not asserted. Correctness is scored against an evaluation set your own experts sign off, and reported as a percentage with the errors listed product by product. ### What happens to products with no valid category? They are surfaced, not forced. The run hands back the categories your taxonomy is missing as a decision for you to take, kept separate from the products that were genuinely put in the wrong place. ### Our taxonomy keeps changing. Does that break it? No, it is the normal condition. Classification runs against the tree that is live, and when the tree moves the evaluation set and the agreed bar get re-pinned rather than assumed to carry over. ### Who decides the edge cases? You do. Where a product type belongs is a merchandising decision, so the boundary you draw is encoded as an explicit rule. ### Whose data is it? Yours. The corrections your team makes are what the agents learn from, and both the data and the corrections stay exportable at any point. ## Related areas - [SEO & GEO](/solutions/seo-geo) - [Catalog Foundation](/solutions/catalog-foundation) ## Proven by - [1000Farmacie](/customers/1000farmacie) · How 1000Farmacie reorganized its catalog and grew revenue thirty per cent a month ## Every correction makes the next run better *The feedback loop* Your team judges the output. A value is right, or it is wrong and gets fixed once. Each verdict changes the next run: the score on your own sample moves, and the agent starts from what the last one learned. So the share of values that need a person keeps falling, measured on your catalog and your rules rather than on an average of everybody else. ![The platform flagging a product description as too generic for the brand tone, with the suggested rewrite and the two answers.](https://cdn.sanity.io/images/xd4hrbt2/production/30815d23ee4d132352d037d84d401a32a7b48eec-2880x1620.webp) ## Live on your catalog in weeks, not months *How we work* We run all four phases with your team, on the stack you already have, and each one ends with a number you agreed in advance. - Design · We map how your data comes in and how the result goes back out, then agree the business KPI the agent has to move. - Implement · We build the agent and test it on a sample of your own catalog, agreed with you. Every change is scored against that sample, so the tuning runs on numbers. - Prove · Done means the KPI reached target on the full catalog, and you have seen the numbers yourself. - Evolve · We stay on the account. Your corrections keep improving the agent, the KPI holds where you need it, and the next use case starts from the context this one already built. ## Enterprise, on a catalog you cannot break ![A department store floor.](https://cdn.sanity.io/images/xd4hrbt2/production/61ee81a3eeab3410935b61002f453008efebb032-943x628.jpg) [Book a demo](/book-a-demo) - It runs on the stack you have · It reads your PIM, ERP and DAM through their APIs and writes the result back to them. - A person approves everything that publishes · Every value is checked against your rules, and anything uncertain goes to review before it reaches a channel. - Your data stays yours · Your own isolated workspace. It is never pooled into shared models, and you can export it at any point. - Every run is logged · Each value carries its source, its run and its score, so you can see why a wrong one went wrong. ## Start with one use case One use case, run end to end on your own catalog. That is enough to see what it moves and what it costs per product, before you commit the rest. [Book a demo](/book-a-demo) ## Entities - [Algolia](https://www.algolia.com) · Organization, mentions - [Coveo](https://www.coveo.com) · Organization, mentions - [FactFinder](https://www.fact-finder.com) · Organization, mentions ## Sources - [Ecommerce search query types](https://baymard.com/blog/ecommerce-search-query-types) · Baymard Institute - [Product structured data](https://developers.google.com/search/docs/appearance/structured-data/product) · Google Search Central - [Product data specification](https://support.google.com/merchants/answer/7052112) · Google Merchant Center - [Product](https://schema.org/Product) · Schema.org --- Canonical: https://commerceclarity.com/solutions/search-discovery Every page of this site is available as markdown: append `.md` to its path. Index: /llms.txt