From patent records to AI use-case pages

The page was never the whole product

Use Case Library looks like a website full of small static pages. That is true, but it is an incomplete way to understand the project. A page starts with a patent record. Patent title, abstract, source citation. By the time it reaches the site, it has become a plain explanation of an applied computer-vision use case.

The page says what problem the patent points at, what AI task it maps to, how the mechanism might work, and what benefit the invention claims. But I did not spend most of the work on the visible page. The page was where the pipeline landed.

The harder part was earlier. Which records should enter the system. What should be extracted from them. How far the model could translate dense patent language before it started inventing a cleaner story than the source allowed. What had to be checked before the result became static HTML. The public page is just where the pipeline becomes visible.

Why patents were useful, but easy to overread

Before Use Case Library existed, I was still looking for startup ideas from finished products. Product Hunt, Reddit, Show HN. The loop was simple. Look at what someone had built, then work backward to the problem they thought was worth solving. It was useful practice, but I kept running into the same problem. A launch page is already trying to sell. By the time I saw the product, someone had already chosen the words around it. I was not looking at the problem directly. I was looking at someone else's shaped version of it.

Patents entered the system for that reason. Not because they were more true. Not because they proved demand. They were rawer. A patent usually starts closer to a technical problem than a launch page does, even when the useful part is buried under legal language. That made it good input for translation, and also easy to overread. If I turned a patent into a clean use-case page, the page could start to feel more validated than the source really was. A patent does not tell me that a market exists. It only says someone thought the mechanism was worth claiming.

The pipeline in one pass

Once patents became the source material, the practical question moved upstream. How far could one record travel before it stopped being anchored to the original source? In the end, the pipeline looked roughly like this.

• Patent filtering. I did not want the model browsing a giant patent corpus and deciding for itself what looked interesting. The input had to be narrowed before any page writing happened. Candidate records came from a patent export, then passed through industry and computer-vision filters. Some queries pulled records in. Other queries existed only to keep noisy matches out.
• Patent processing. This was still not page generation. The system checked whether a record was relevant, cleaned it enough to use, pulled out the problem it seemed to describe, and mapped it to a computer-vision task. Only then did it become a reasonable input for a generated page. This is the part that sounds like data plumbing, but it mattered because every later step inherited the shape of that decision.
• Use-case generation. After that, generation became a translation layer. A processed patent record, plus industry and task metadata, turned into structured content for a use-case page. The model had to move from legal and technical language into something a reader could scan as a problem, a possible mechanism, and an implementation shape. It also produced the boring site objects around the page, including the slug and object key. That detail mattered because a page had to become an addressable object in the site, not just a block of text in a database.
• Metadata and vendors. Then the page needed more than article text. The metadata step made it usable as a web page, with a canonical URL and the surrounding search data. Vendor discovery did a different job. It tried to move from "this use case might be possible" toward "these companies might be relevant to it." The system looked for provider domains, removed obvious non-vendors, and judged whether a match belonged on the page. I would not call that market validation. It was more like a first attempt to connect a technical pattern to the outside world.
• Evaluation. The evaluator came later as a different kind of check. It read the generated content and scored it for technical accuracy and problem-solution fit, then wrote back fields such as PASS, REVIEW, or REJECT. I cannot honestly describe it as a hard publishing gate for every page. The better claim is that the evaluator gave the pipeline a second opinion. A page could sound fluent and still carry technical drift, so I needed a place where that doubt was stored instead of just felt.
• State and publishing. Supabase held each intermediate object, so the pipeline did not have to live inside one long script run. The static builder pulled eligible rows, joined the page content with its metadata, and rendered the site as plain HTML. Deployment went through a staged Cloudflare R2 flow. This was the part that made the output inspectable. If something looked wrong, there was at least a record of where it had entered the system.
• Build validation. I also ended up surrounding the HTML build with checks. Pre-build validation looked for broken source state, missing metadata, malformed JSON, and records that should not move forward. Post-build validation checked that the finished output actually looked like a site, not just a folder of generated files. Upload verification went down to hashes and R2 ETags before stage or production promotion. This was probably overbuilt for a small static site, but it reflected the actual fear in the project. Generated content can look complete while the site around it is quietly broken.

Fluent output was the failure mode

The clearest example was a page called Accurate Food Sizing. It came from a patent for a food material size detection method and cooking equipment. As a generated page, it looked usable. It did the surface job. A reader could understand the manufacturing problem, the depth-estimation angle, and why better sizing might improve cooking consistency. If I only looked at the page as a reader, I could believe the pipeline had done its job.

The evaluator did not reject it, but it did not pass it either. It marked the page REVIEW, with 6/10 for technical accuracy and 7/10 for problem-solution fit. That distinction mattered. The output was not nonsense. The problem was quieter than that. The page had taken a technically plausible idea and made it sound more complete than it was.

The main drift was around depth estimation. The page talked as if estimating depth from camera images was almost the same thing as measuring the exact physical size of a moving food item. In practice, that crosses into 3D measurement and process control. A depth map is useful input, but it is not the whole system. You still have to deal with motion blur, overlapping items, camera calibration, lighting, and the machinery that would actually change cooking parameters.

That was the useful failure mode to catch. The page sounded finished because the sentences were fluent and the structure was clean. But the missing work was exactly the kind of work that decides whether an AI use case would hold up in an actual food-processing line. This is why I stopped treating generation as the success condition. A generated page was only a candidate.

The unfinished part

The pipeline could produce more pages. That was not the hard part anymore. One local build already had 184 use-case pages and 8 algorithm pages in a 226-file static output. The system could take more patent records, push them through the same stages, and publish another batch. At some point, adding pages became the easiest way to feel like the project was moving.

The harder question was what happened after publishing. Would Google index the pages in a useful way? Would the right readers trust a generated use-case page enough to keep reading? Vendor discovery could still point to companies that matched a query more than companies that cared about the problem. Those loops were designed more than they were proven. The site was live, but the distribution side was still thin.

That is the boundary I would keep visible if I described Use Case Library today. The useful part was not that patents magically became startup ideas. They did not. The useful part was that messy source material could move through a system without losing every trace of where it came from, while human judgment stayed in the loop. Someone still had to decide what was good enough to leave the system, and what still needed evidence from the outside world.