Why AI4AV exists

A few months ago I tried to build a controller for a projector. The manufacturer’s control protocol PDF ran to one hundred and ninety-three pages. I fed it to an AI coding agent. It produced something that looked right and was wrong in subtle places. A human integrator was supposed to read that PDF. A language model reads it instead, on behalf of a freelancer shipping a control app.

That gap is what AI4AV is for. Every controllable AV device has a control protocol described somewhere, usually as a PDF on the manufacturer’s support site, sometimes buried in a longer product manual. The format is the problem, not the content. PDFs were not written with a language model in mind.

AI4AV catalogs those control protocols as machine-readable specs, free to use. One file per device. Transport, command list, parameters, feedback frames, safety notes. Every entry carries a source URL and a retrieval date, so you can see where the spec came from and how fresh it is.

The bet

Frontier AI coding tools will one-shot working control apps within a year or two. When they do, the binding constraint stops being model intelligence and becomes input data. A model that writes correct TypeScript is useless if the protocol facts feeding it are wrong. AV control commands fail silent: a wrong checksum returns nothing, a wrong terminator hangs the session. You do not get a stack trace. You get a quiet, broken installation.

Nobody else is building this. The universe of controllable AV devices is finite: tens of thousands, somewhere between thirty thousand and a hundred thousand by current estimates. Small enough to catalog. It is not a venture-scale market. It is a maintenance project that compounds.

I publish the catalog under the Open Database License. Anyone can clone it, fork it, use it commercially, embed it in their own tooling. The expectation is share-alike. AI4AV is infrastructure, not a product to defend.

What is live today

The catalog covers around two thousand devices, weighted toward what people need to control on real installations. The site is in early access, which the quotas reflect: three lookups per day anonymous, fifty with a free API key.

The ai4av-lookup skill is the fastest path. Install it in your AI coding tool, ask for a device by manufacturer and model, and the spec lands in context. The browser catalog at ai4av.net/devices works for humans.

How to help

The two contribution paths live at ai4av.net/contribute. Suggest a device: if something you use is missing, point to the manufacturer’s official control document. I review it, the pipeline ingests it. Report a wrong spec: command mismatches or protocol issues against a specific catalog entry.

I do not accept copied driver files, NDA material, or raw scrapes from other databases. The provenance chain has to stay clean, for licensing and for trust.

Limits

The catalog only covers protocols the manufacturer has published. If a vendor keeps its protocol behind an SDK or NDA, it does not appear. Specs are cross-checked against vendor documentation at ingest, not against your firmware on the rack. A spec that is correct on paper can still surprise you in the field.

If you build something on top of the catalog, let me know.