Reading one control-protocol PDF is an afternoon's work. Reading them for every controllable device in the AV industry, and keeping each one current as manufacturers ship new models and new firmware, is not a project that ends. It is a process that has to run on its own, because no person is going to transcribe fifteen thousand devices by hand and then do it again next year.

AI4AV is a free catalog of those control protocols, one structured spec per device. This post is about the machine that fills it. The design target is three things, in order of importance. The specs have to be correct, because a control app built on a wrong command is worse than no app at all. The catalog has to be broad, ideally every device with public documentation. And it has to be fresh, a new product's spec available within days of release. Correctness comes first. A catalog that looks comprehensive and is quietly wrong is a liability, not an asset. The rest of this is how the pipeline chases those three, and where it currently falls short.

Finding the gear #

The pipeline starts from a roster of manufacturers, not from a crawl of the open web. A manufacturer is added once there is evidence of where it publishes official documentation.

From there the pipeline does the part I find most interesting. Every manufacturer's site is laid out differently, so no single scraper reads all of them. Rather than hand-write one scraper per site, which does not scale past a handful of vendors, the model writes the scraper itself for that manufacturer, then checks that the generated scraper actually works before trusting it. The interesting part is not that AI reads the manuals. It is that it writes the tools that find them. Once a scraper is trusted it runs on a schedule, and a new model usually shows up within days of release.

This is the part that is most deliberately incomplete. The catalog today covers more than 2,200 devices across 230-plus manufacturers. The continuous watch for newly released products, the part that keeps the catalog fresh on its own, runs for only about two dozen of those manufacturers so far. Breadth here is the current bottleneck, and it is mostly a question of onboarding manufacturers one at a time. Nobody has an exact count of the industry. Our working estimate is somewhere between thirty thousand and a hundred thousand controllable devices, and the spread is honest: it depends entirely on where you draw the line on what counts as controllable.

Finding the documents #

A device is not a spec until the pipeline finds the document that describes its control protocol. Sometimes that is a clean PDF on a product page. Sometimes it is a support download three clicks deep, or a wiki page last edited a decade ago. The pipeline looks first in the places a given manufacturer is known to publish, falls back to searching when it has to, and retries through the Wayback Machine when a link has rotted.

Every document it accepts keeps its source URL and the date it was retrieved, so the provenance of a spec is always visible and you can judge how stale it might be. Marketing pages and brochures are rejected here. A document has to actually contain a command set to go further.

From document to spec #

Turning a protocol document into a usable spec is the step an AI model does well and a human does slowly. The pipeline extracts the commands, the transport, the parameters and the feedback frames into one structured file per device. Then it does the step that matters more than the extraction: it checks the result against the source.

A spec is marked verified only when each command in it traces back to a command in the original document. The check is built to catch fabrication specifically, because a model that invents a plausible-looking hex string is more dangerous than one that admits it does not know. Safety-relevant values that are not present in the source, things like baud rate or supply voltage, are flagged as unresolved rather than guessed. Specs are graded, and only the verified tier is treated as trustworthy.

When validation fails #

Most specs do not pass cleanly the first time, and the interesting engineering is in what happens then. A spec can come out incomplete, drift from a source that has changed, or fail the fabrication check. Each failure routes to a different repair path.

An incomplete spec gets a second pass with more context and is re-checked before anything merges. A drifted or suspect spec is regenerated from scratch. A spec that fails repeatedly stops looping and is recorded as a known gap, rather than retried forever in silence. A bad spec is a state the pipeline moves through, not one it ships.

The bar keeps rising #

A spec that passed verification last month is not automatically good enough this month, because the verifier itself keeps changing. The pipeline and its verification system have been rewritten four times so far, most recently this week, and each rewrite raises the standard a spec has to clear. When the bar moves, nothing gets grandfathered in. As I write this, the entire catalog is being re-verified against the newest verifier. That work ships no new feature, but it is most of what separates a catalog you can trust from one that merely looks full.

The raw material fights back. Manufacturer documents are inconsistent, occasionally wrong, sometimes a scanned image of a table rather than text. Two things push quality up against that: scrapers that get better at reading bad documents, and language models that get better at the extraction underneath. Both improve on their own schedule, and the pipeline inherits the gains without being rebuilt around them.

How autonomous it actually is #

The discovery, generation, verification and repair loops run continuously with nobody watching them. People stay in the loop only at the decisions that need judgment: onboarding a new manufacturer, accepting a newly discovered product into the catalog, and curating the profiles that tell the scrapers where to look. No spec reaches the public catalog without passing verification first.

None of the three targets is fully met yet. Freshness has two halves: detecting that a watched manufacturer shipped a new model happens within days, and that half works; turning the existing backlog into verified specs is the other half, and at the current pace that is at least a year of work. Breadth is further behind, two dozen manufacturers on continuous watch against an industry of tens of thousands of devices. Quality, by its nature, is never finished, because the bar keeps rising. The pipeline is built for the day all three hold at once, and that is not today.

If your gear is not in the catalog, the fastest way in is not to wait for the scraper to reach that manufacturer. Send the link to its control document at /contribute, and the pipeline takes it from there.