Where the project stands before you read the long version. The peculiar fact that a manufacturer hands you, for free, the exact bits that drive every machine it has ever sold. The ThinkPad is one of the few mass-market PC product lines that has accumulated a parallel open-source culture around it: long-running coreboot ports for a handful of Sandy Bridge and Ivy Bridge classics, Linux quirks tables for every model since the T20, Hackintosh ports for the GoBook generation, a quietly enormous body of forum knowledge about exactly which kernel option calms which Lenovo BIOS bug. The reasons are not mysterious — ThinkPads ship with field-replaceable parts, decent keyboards, and BIOSes that the firmware team actually maintains for years — but the consequence is that a lot of independent engineering value lives downstream of Lenovo's "Drivers & Software" pages. That archive is the part most people forget about. Lenovo Support publishes every BIOS update for every supported model, every driver bundle, every flash utility, organized by machine type and chronological. For a model still under support you get the complete historical chain — every microcode bump, every Intel ME revision, every SMM hardening, every CVE fix — downloadable as a string of.exepackages. For models that have rolled out of support the binaries remain mirrored and discoverable. The same site indexestens of thousandsof binaries that, taken together, are a near-comprehensive record of how Lenovo built each board. Inside each BIOS package is the part that matters: the device tree the OS sees (ACPI), the firmware volumes (PEI, DXE, SMM), the embedded controller firmware, the Intel FSP remnants, the microcode files, the VBT, the flash descriptor on some models. Everything a coreboot porter needs to bring a new board up; everything a security auditor needs to map a CVE to a binary fix; everything a Hackintosh ports project needs to drive a sensibleconfig.plist. The bits are public. They have been public the whole time. What isnotpublic is a reproducible pipeline that says: "give me a model number and a BIOS version, and you get back structured JSON describing every device, every GPIO it touches by name, every firmware-internal change since the previous revision, every CVE the changelog mentions, every privacy-sensitive GPIO and its lock posture, every SMI-routable input, every UEFI module that grew or shrank between the last two updates, every signal of where a fix landed in the binary." That is the gap this project sets out to close. The output of the pipeline is not a beauty-contest reverse engineering of one board. It is a coverage statement:across the archive, the toolchain produces structured data on every model whose firmware can be carved — and as the archive grows, the model count grows with it. Bug-for-bug, the per-model output may still need a human pass before it can drive a real port; but the cost of preparing that human pass drops by an order of magnitude when you start from a clean auto-generated baseline. ACPI / DSDT, Intel's GPIO architecture, and the GpioLib indirection — just enough to read the rest. TheDifferentiated System Description Table(DSDT) is the central ACPI table. Firmware compiles it from ASL (ACPI Source Language) into AML (ACPI Machine Language) at build time, and the OS interprets the AML at runtime to discover devices, power states, GPIO connections, EC commands, and thermal zones. Every ACPI-capable OS — Linux, Windows, macOS, the BSDs — reads the same DSDT. The DSDT is therefore the most reliable single description of what hardware is present on the board, more reliable than PCI enumeration (because it includes non-PCI devices like the EC, GPIO-attached buttons, sensors), and more reliable than Linux DMI tables (which only carry strings). Secondary System Description Tables(SSDTs) compile separately and load at runtime to extend or override pieces of the DSDT. Boards with multiple variants typically ship a generic DSDT plus per-variant SSDTs that patch in the right chunks; AcpiPlatform decides which SSDTs to load based on hardware identifiers it reads at boot. A modern ThinkPad commonly ships ten SSDTs alongside the DSDT. Every device with a hardware GPIO connection has a_CRS(Current Resource Settings) method that returns a serialized list of resource descriptors. For GPIO that descriptor is either aGpioIo(the device can drive or read the pin) or aGpioInt(the pin is wired to the device as an interrupt source). Each carries a controller path (e.g.\_SB.PCI0.GPI0), a pin number, an edge/level/polarity selector, and a pull configuration. On AMD and Qualcomm ThinkPads, the pin number inGpioIo/GpioIntis a direct integer that maps straight onto an AGPIO or GPIO pad. On Intel it is often a method call — and that is where the trouble starts. Each Intel PCH (from Skylake / Sunrise Point onwards) carries one or moreGPIO controllers(community controllers), each owning a number ofgroups(banks of about 24 pins each). Pins inside...