Create a Compatibility Record for a Custom PC
A useful compatibility record connects firmware, cables, drives, memory settings, and tested ports into one dependable baseline. I’ll show you how to document that information without turning routine maintenance into paperwork that nobody wants to update.
A compatibility record turns a working custom PC into a known system rather than a collection of parts you have to rediscover every time something changes. That distinction matters when you add a drive, replace a power supply, troubleshoot unstable memory, or hand the machine to another technician.
The goal isn’t to document every screw and setting. It’s to capture the relationships that affect compatibility, troubleshooting, and recovery. A good record tells you what is installed, which versions were used, what has been tested, and which assumptions still need confirmation.
Start with a useful baseline
Begin by recording the system as it exists in a stable state. Give the record a date, a system name, and a clear identifier such as the case asset tag or motherboard serial number. If the PC has several similar machines nearby, include the motherboard model and the last few characters of its serial number, while avoiding unnecessary exposure of sensitive information in shared files.
Record the major hardware first: processor, motherboard, memory kit, graphics card, power supply, CPU cooler, case, storage devices, and operating system. Include exact model numbers where possible. A product family name is often too broad to identify important differences. A memory kit’s rated speed and capacity, for example, may be shared by several revisions with different memory chips. Power supplies and storage devices can also have model variants that matter during troubleshooting.
For each part, separate what the component is from how it is currently configured. The motherboard model belongs in the hardware inventory; the installed firmware version belongs in the configuration section. The same principle applies to memory: record the kit’s advertised specifications, then separately note the speed, timings, voltage, and profile currently applied.
A compact baseline might contain these fields:
- System identifier, date, and record owner
- Motherboard model, revision, and serial or asset identifier
- Processor model and any configured power or boost limits
- Memory kit model, capacity, slot population, speed, timings, voltage, and profile
- Graphics card model and installed driver version
- Power supply model, wattage, connector types, and cable provenance
- Drives, their interfaces, capacities, firmware versions, and physical locations
- Cooling hardware and fan or pump connections
- Operating system version, boot mode, and storage layout
- Firmware versions and the settings that affect booting or device support
You don’t need to record every default motherboard setting. Focus on settings that explain behavior or determine whether a future part will work as expected.
Document the relationships, not just the parts
A list of installed parts is helpful, but compatibility problems usually occur at the boundaries between parts. Your record should therefore explain how the components connect and what those connections consume.
For storage, note whether each drive uses a motherboard M.2 socket, a SATA data connection, a PCIe add-in card, or an external connection. Include the socket or port location, the drive’s role, and whether installing it disables or shares another connector. Some motherboards route M.2 sockets and SATA ports through shared resources, while others support different interface generations or lane arrangements. You don’t need to reproduce the entire motherboard manual; record the specific arrangement in use.
For expansion cards, record the slot occupied, the slot’s physical size, and any relevant lane or clearance limitation. A card may fit mechanically while changing the availability of another slot, covering a small connector, or blocking airflow. Note those effects if they could influence a future repair.
Power connections deserve their own section. List the connectors in use for the motherboard, processor power, graphics card, drives, hubs, pumps, and other accessories. For a modular power supply, identify which cable is connected to which device and whether the cable is the one supplied for that exact power supply family. Modular cables can look similar while using different wiring at the power-supply end, so “fits the socket” isn't a sufficient compatibility test. Store this information alongside the power supply model rather than treating all spare cables as interchangeable.
A simple connection table can make this clear:
| Device or function | Connection | Location or cable label | Notes |
|---|---|---|---|
| CPU power | 8-pin EPS | Top-left motherboard socket; EPS-1 | Cable from current PSU |
| System drive | PCIe M.2 | M2_1 | Holds operating system |
| Archive drive | SATA | SATA_3; cable S-03 | Shares no disabled port in current layout |
| Graphics card | PCIe slot plus power | Slot 1; two separate GPU leads | Clearance checked against front fans |
The exact labels are up to you. Consistency matters more than the naming scheme.
Confirm the connection map before changing hardware: Check the motherboard manual and the power supply’s documentation for the installed socket names, shared ports, and cable compatibility. Record the result rather than relying on a cable’s appearance or a remembered slot layout.
Capture firmware and memory settings as a working state
Firmware versions are valuable because they establish what the system was running when it was known to work. Record the motherboard firmware version and date, graphics firmware if it is relevant to the repair, storage firmware when available, and any controller or dock firmware that affects the system. Include the update method or source only if it will help you reproduce the result later.
Firmware settings should be recorded selectively. Include boot mode, boot order, storage mode, virtualization settings, security features, fan-control mode, and any setting that affects memory or processor behavior. If the system uses a non-default configuration, explain why. “Enabled for the memory kit” is more useful than simply writing “XMP on,” especially if the platform uses a different profile name.
Memory settings are worth documenting in detail because they can appear stable under light use and fail under a particular workload. Record the total capacity, module locations, active data rate, primary timings, memory voltage, and the profile selected. If you manually adjusted subtimings, voltage, or controller-related settings, record those too. A future technician can then distinguish a problem with the memory hardware from a change in configuration.
Don’t describe a setting as validated merely because the system boots. Add the test used and its outcome. For example, note whether the system completed a memory test, a long compile, a storage transfer, or the workload that originally mattered to the machine. Include the approximate duration and date. This doesn't make the result a permanent guarantee; it identifies the conditions under which the configuration was checked.
When recording firmware versions, use the version shown by the relevant device or its vendor documentation at the time of inspection. Version naming and update procedures can change, and a newer release may alter compatibility or settings behavior.
Record tested ports and devices
A port inventory prevents a common repair mistake: treating an untested connector as a confirmed working connector. Test the ports that matter to the system’s intended use, then record the method and result.
For rear and front USB ports, note the physical location, connector type, and whether the test covered data, charging, or both. A port that supplies power to a device hasn't necessarily passed a data test. For video outputs, record which connector was tested, with which display or adapter, and under what operating system or firmware conditions. For network, audio, card-reader, and external storage connections, identify the device used for the test when the distinction could matter.
The result can be more precise than “works.” Use categories such as passed, not tested, intermittent, blocked by the current configuration, or requires a specific adapter. Add a short note for failures. “No link with known-good cable; device works on another port” gives a future technician a starting point. “Port bad” usually doesn't.
A port record is especially useful after case-front wiring changes or motherboard replacement. Front-panel ports depend on internal headers, cable routing, and sometimes separate hubs. Test them as assembled, not only at the motherboard header. If a port is inaccessible because of a graphics card, radiator, or installed cover, record that as a physical limitation rather than leaving it ambiguous.
Choose a record format you’ll actually maintain
A spreadsheet is often the best compromise for a single builder or small repair operation. Separate tabs or sections can hold the inventory, connections, firmware, settings, and test results. It is searchable, easy to duplicate for a new build, and flexible enough for notes. Its weakness is that an unstructured spreadsheet can become a pile of stale cells with no clear indication of what changed.
A plain text or Markdown record works well when the machine is managed alongside scripts, configuration files, or a repair repository. It is easy to compare between dates and can be copied with the system’s recovery materials. The trade-off is that tables and long test histories can become cumbersome without a consistent format.
Paper has a place for basic cable labels and a quick port map, particularly during disassembly. It is a poor sole record for firmware, settings, and test history because it is difficult to search, back up, or update after a repair. A practical arrangement is to keep the authoritative record digitally and place a short identifier or QR code inside the case only if your environment supports that securely.
Whichever format you choose, include a change log. Each entry should state the date, change, reason, affected components, and validation performed. This prevents a later reader from confusing the original baseline with the current state.
Keep sensitive and uncertain information under control
Serial numbers, asset identifiers, network details, encryption-recovery information, and service credentials shouldn't all live in the same general-purpose file. Record only what helps identify the hardware, and keep secrets in an appropriate password manager or secured system. A compatibility record should help someone repair the PC without becoming a convenient map of everything connected to it.
Mark uncertain information explicitly. Use “reported,” “not confirmed,” or “needs retest” instead of filling a gap with an assumption. If a drive’s firmware can't be read, say so. If a cable’s origin is unknown, don’t label it as manufacturer-approved merely because it fits. Uncertainty is useful when it is visible; hidden uncertainty becomes a troubleshooting trap.
Review the record after any change involving the motherboard, power supply, memory, storage layout, firmware, or case wiring. Retest only what the change could affect, but update related dependencies. Replacing a motherboard may require a new firmware baseline, a different M.2 arrangement, and a fresh port test even when the drives and operating system remain unchanged.
Use the record as a decision tool
The best compatibility record does more than preserve history. It lets you compare options before opening the case. If you’re adding a drive, you can see which sockets are occupied and which lanes or ports may be shared. If you’re replacing a power supply, you can count the required connectors and identify every modular cable that must be replaced. If memory is unstable, you can compare the current profile with the kit’s rated settings and the last known-good test.
Keep the record proportionate to the system. A heavily documented workstation or repair fleet benefits from connection maps, test evidence, and change history. A simple home build may need only a complete inventory, firmware baseline, memory settings, storage map, cable notes, and tested-port results. The right level of detail is the smallest amount that lets another person—or you several months from now—make a safe, informed change.
Create the initial record while the PC is working, then update it immediately after meaningful changes. Confirm the connections that matter, distinguish tested facts from assumptions, and preserve the last known-good configuration. That modest habit turns future upgrades and repairs from guesswork into controlled decisions.