Lesson 4: Compatibility Lab

A compatibility mistake is cheapest before you touch the hardware.

That is the point of this lab.

You are not assembling first and troubleshooting later. You are using documentation to prove that the proposed motherboard, processor, memory, cooling, expansion, and firmware configuration belongs together before installation begins.

This is what professional planning looks like when the parts are expensive.

Treat compatibility like a set of claims

Suppose someone proposes this build:

motherboard: Board A
processor: CPU B
memory: Kit C
cooler: Cooler D
expansion: Card E

"Looks good" tells us nothing.

We need separate claims:

1. the board supports the processor;
2. the board and processor support the memory configuration;
3. the cooler mounts correctly and can handle the processor;
4. the expansion card has a supported slot, power path, and physical clearance;
5. firmware and security settings do not invalidate the intended configuration; and
6. the case and power assumptions still make sense.

Each claim should point to evidence.

Start with the motherboard because it defines the platform

Record the supplied motherboard model or reference profile first.

Then extract the constraints that matter:

• form factor;
• CPU socket;
• supported CPU families;
• required firmware revision when relevant;
• memory generation;
• maximum memory capacity;
• preferred DIMM population order;
• cooler and socket mounting standard;
• PCIe slot and lane information;
• required board and CPU power connections;
• relevant firmware settings.

You are building the rules before judging the parts.

That prevents confirmation bias.

If you start with the part you want, it is easy to go hunting for reasons it might work.

Start with the platform requirements instead.

Classify every proposed part

Use three states:

• compatible;
• incompatible;
• needs verification.

The third category matters.

Real technical work often includes incomplete evidence.

If the manual does not prove something, do not upgrade uncertainty into confidence just to finish the table.

Write what is missing.

Example:

Needs verification: CPU socket matches, but the supplied evidence does not include the motherboard firmware revision required by the CPU support list.

That is a strong answer because it separates what you know from what you still need.

One incompatible part is hidden in the build

Your assigned configuration includes at least one mismatch.

Possible failures include:

• wrong CPU socket;
• unsupported CPU generation;
• outdated firmware for the selected CPU;
• wrong DDR generation;
• SODIMM proposed for a desktop DIMM slot;
• unsupported memory capacity;
• incorrect DIMM population plan;
• incompatible cooler mount;
• insufficient expansion-card power or clearance;
• missing CPU power assumption.

Do not search for the "trick."

Follow the chain.

The mismatch should reveal itself when one required claim cannot be supported.

Build the compatibility matrix

Use a record like this:

The remaining question column keeps you from pretending the evidence is more complete than it is.

Verify firmware assumptions before installation

Record any settings or firmware conditions that could matter to the proposed system, such as:

• minimum firmware revision for the CPU;
• Secure Boot state;
• virtualization support;
• TPM availability;
• USB controls;
• fan and temperature monitoring;
• boot or setup passwords where relevant.

Do not change settings simply because they are listed here.

The goal is to recognize which settings belong to the configuration and which ones do not.

Predict what POST should show

If the configuration is corrected and installed properly, what evidence should appear during startup?

Possible verification points include:

• expected CPU identified;
• expected total memory detected;
• memory channels populated as intended;
• reasonable CPU temperature;
• CPU fan or pump detected;
• no CPU or memory diagnostic error;
• expected firmware revision present;
• intended boot device visible.

Compatibility is not complete when the spreadsheet says yes.

The installed system still has to prove the model.

Failure case: the build passes on paper but does not POST

Now assume your corrected build is assembled and fails to POST.

Do not throw away the compatibility work.

It becomes your baseline.

You already have evidence that the parts should be compatible under the documented conditions, so the investigation shifts toward:

• installation;
• power connections;
• component seating;
• firmware revision or state;
• damaged hardware;
• an assumption the documentation did not capture.

Planning does not prevent every failure.

It makes the failure easier to reason about.

Preserve the result

Your final compatibility record should let another technician answer:

• Which platform requirements were verified?
• Which proposed part failed first?
• What exact evidence exposed the mismatch?
• Which question could not be answered from the supplied documentation?
• What should firmware or POST show if the corrected build works?

If another person can follow the record without you explaining it verbally, the artifact is doing its job.

Safety boundary

Do not force a component, open a power-supply enclosure, or perform powered internal service for this lab. If the hardware is not approved for hands-on inspection, use the supplied system profile, diagrams, or documentation instead.

Next, we take the clean compatibility model and confront the messier case: a system that receives power but never completes POST.