The question a page could not answer
Use Case Library has a page about automating content moderation with image classification. Near the bottom, after the implementation section, there is a block called "Vendors That Might Help You" with four company cards. Sightengine, Surveily, Hive Moderation, Amazon. This note is about the layer that fills that block.
A use-case page starts from a patent record and describes a possible applied-AI system. I wrote about that pipeline in the previous note. The page answers a narrow question, what a system like this might look like and why someone might want it. A reader who takes the page seriously usually has a next question, and the page cannot answer it. Who actually builds or sells things like this?
Vendor discovery was the attempt to answer that question with a pipeline instead of by hand. It was also the point where the project stopped being purely an archive. A library of possible use cases is one product shape. Pages that connect a technical pattern to named companies point at a more commercial one. I did not know whether that shape would work, and building the layer was the only way to find out.
What the layer does
For every use case, the layer runs the same sequence.
- Query extraction. Gemini reads the use-case content and writes a search objective plus five queries. The queries aim at companies rather than concepts. For a forestry use case about sorting wood by region and color, one of them came out as
"Image Segmentation" "wood color identification" forestry "case study" "automated sorting". - Search. The queries go to Parallel.ai, which returns the top ten results for the use case. A small personal note here. Parallel is one of my favorite services for this kind of research and data work. It gets out of the way and gives the pipeline useful raw material.
- Cleanup. Results collapse to registrable domains, so several links from one company become a single candidate. A curated exclusion list then removes domains that are never vendors before any model spends time on them.
- Judgment. A second Gemini pass reads each remaining domain and answers two separate questions. Is this a commercial vendor at all, and how relevant is it to this specific use case, scored from 0.0 to 1.0. It also writes a short rationale for the decision.
- Display. Matches are sorted by relevance. The top three or four are flagged for display, and the static build renders them as the cards on the page.
Supabase holds the state. A vendor exists once, keyed by its domain, while each use-case-to-vendor pair keeps its own relevance, rationale, and display order. Reprocessing a use case keeps the higher of the two scores.
The search mostly returned the wrong things
In one run, the wood-sorting use case returned ten results. After deduplication, eight domains went to the judge, and seven came back as non-vendors. All seven were academic or institutional. One was a research paper from 1991 hosted on the U.S. Forest Service site. Another was a university news story about lumber-evaluation research. The rest were journal pages on publishers like BioMed Central and Oxford Academic. The single vendor in the batch was dac.digital, a software house with a case study on depth-enhanced segmentation in forestry.
That made sense once I looked at it. The people who write most precisely about image segmentation and wood identification are researchers, so queries built from technical phrasing rank their papers first. The exclusion list grew out of that. When the same publisher or university kept coming back run after run, I added its domain to a YAML file by hand, so the pipeline would stop paying the judge to re-reject the same journals. It never felt like design work. It was closer to weeding.
Getting rid of the papers was the easy half. The results that survived were real companies, and being a real company was still not enough. In a construction use case built around depth estimation, the search surfaced Epiroc, a maker of heavy mining equipment. The judge confirmed it was a commercial vendor and scored the relevance at 0.35. The page it had found was about a collision avoidance system. Right industry, adjacent safety topic, wrong task. In an agricultural use case, an integrator scored 0.7 while the rationale itself admitted the company does not explicitly mention depth estimation. Both matched the vocabulary around the problem more than the problem.
Those two cases are why the judge scores relevance separately from vendor status, and why its rationale goes into the database next to the score. When a card on a live page looks off, I can read what the model believed it was looking at. That does not make the judgment correct. It means that when a match is wrong, I can see how it went wrong.
What the cards add
The layer shipped. The vendor cards on published pages come from this pipeline running end to end.
They change what a page is. Before, a use-case page ended at "here is what might be possible," which is interesting and a dead end. Now it ends with companies that do this kind of work, so a reader who takes the use case seriously has somewhere to go next. For a library of generated pages, that is the difference between plausible and useful.
The boundary I would keep visible is simple. A match is a researched suggestion, not proof that a market exists. Testing whether the vendors themselves care about pages like these is the next experiment, and I have not run it yet. What I would take into other projects is the design underneath. Separate what a model retrieves from what it judges, and write the reasoning down where a person can check it later.