The Vulkan-Docs commit e4e53e4 added three entries to the registry: the APEX author tag, VK_VENDOR_ID_APEX at 0x10009, and VK_DRIVER_ID_APEX at 32. The Mesa fork on GitHub carries 229,391 commits. The .clang-format file in that repository is empty, zero bytes.

The 20x speed claim and the 10 W power figure appear only in the company's own description. No independent measurement sits in any of the documents. What the registry entry proves is that the driver is far enough along to request a permanent vendor slot, and that the Mesa fork is a full upstream clone rather than a thin wrapper. The absence of a PCI-SIG vendor ID, stated in the pull request, means the FPGA board has not entered the PCI enumeration path. For a buyer evaluating edge inference hardware, the constraint is not the driver architecture but the unverified performance envelope. The document does not establish that the FPGA prototype meets the stated wattage or throughput.

No benchmark run, no power draw reading, no cost comparison against the Jetson reference appears in any page. The Mesa fork has zero stars and zero forks. The driver ID is reserved but the hardware has not been tested against a Vulkan conformance suite. The 20x figure and the one-fifth cost figure remain assertions with no supporting measurement.

The registry entry confirms the driver is in active development but says nothing about the FPGA's actual power draw or inference throughput. The buyer's constraint is the unverified performance envelope, not the software stack.

A full Mesa fork with 229k commits and an empty .clang-format indicates the driver is in early integration, not a production-ready layer. The reserved vendor ID (0x10009) and driver ID (32) are administrative, not performance signals. The lack of a PCI-SIG vendor ID means the board cannot be enumerated by standard system tools. Until a conformance run or independent benchmark appears, the 20x and 10 W figures are marketing claims with no engineering basis in the available documents.