How we work: experience, expertise and limits

What our hardware guidance is based on, what we have direct experience of, and what we deliberately do not claim to have tested.

Anyone can publish hardware advice. This page sets out what our advice is actually based on, so you can judge how much weight to give it.

Experience

IT Edits is written by Vlad, who has spent years building, upgrading and troubleshooting desktop PCs. That is hands-on experience with assembly and diagnosis: seating coolers, routing cables in cases with not quite enough room, updating firmware on a board that will not post, and working out which component is at fault when a machine does something strange.

That experience shapes what this site emphasises. The compatibility problems covered by the builder are the ones that actually come up, in roughly the order they come up, which is not the same as the order a specification sheet would suggest.

Expertise

The technical material here comes from manufacturer documentation, published standards, and the specifications that manufacturers themselves release. When we explain how PCIe lane allocation affects which M.2 slot disables which SATA port, that is read from board manuals, not recalled from memory.

Where a topic has genuine uncertainty or disagreement, we say so rather than picking a side and sounding confident about it.

What we do not have

We do not have a test bench, thermal chamber, power analyser, or a shelf of loaned review samples. We have not measured the frame rate of any graphics card, the temperature of any cooler, or the efficiency of any power supply.

This means that when you want to know how two cards compare in a specific game at a specific resolution, we are not the right source, and we will point you to someone who has actually measured it. What we can do is explain what the specifications mean, what will and will not physically work together, and which questions are worth asking before you buy.

We think being clear about this is more useful than the alternative. A site that implies testing it has not done is asking you to trust figures that do not exist.

How that shows up in the work

Every hardware record in our database stores where its figures came from and when they were last checked against that source. Those details are shown next to the component, not buried in a policy page.

Where a specification is missing, the builder reports that it cannot verify the check rather than assuming the parts are fine. Several of the compatibility rules exist specifically to say “we cannot confirm this, here is what to check yourself”.

Articles distinguish between what is specified, what follows from the specification, and what is our judgement. Those are three different kinds of claim and they deserve different levels of confidence from you.

Accountability

Articles carry the name of whoever wrote them and the date they were last reviewed against current hardware. A review date only changes when someone has actually re-read the page; it does not move because a stylesheet was updated.

If we get something wrong, tell us at [email protected] and we will correct it. Significant corrections are noted on the page rather than made silently.

Before publishing: This page states that no physical testing is performed. If that changes, update it here and on the methodology page at the same time, and be specific about what was tested and how.