How we research
The value of a recommendation site is entirely in whether you can trust the numbers. So here is exactly how ours are produced, including what we get wrong and what we refuse to publish.
Nothing enters the database without a source
There is deliberately no code path in our pipeline that writes a specification without naming the document it came from. Every value is stored as a claim: this source, on this date, asserted this number about this product, with this extraction confidence.
That is why each specification on a product page shows its source, its authority tier, and how many other sources corroborate it. If we cannot show you where a number came from, you do not see the number.
Sources are ranked by authority, not convenience
| Tier | What it is | Examples |
|---|---|---|
| 1 | Regulatory and certification bodies | AHRI Directory, ENERGY STAR, DOE, IRS |
| 2 | Independent technical organisations and labs | NEEP, NREL, CEC, DSIRE |
| 3 | Manufacturer published documentation | Submittal sheets, engineering data |
| 4 | Independent editorial | EnergySage, trade press, installer comparisons |
| 5 | Retail listings | Pricing only — never performance |
When a higher-tier source becomes available it automatically replaces what we had. Manufacturer figures are treated with particular caution for efficiency claims, because marketing selects favourable numbers — we prefer AHRI or NEEP wherever both exist.
When sources disagree, we say so
Multiple sources frequently assert different values for the same specification. Our resolver picks a winner by source tier, then extraction confidence, then recency — and records the disagreement either way.
Sources that agree within tolerance count as corroboration and raise the published confidence. Sources that disagree beyond tolerance open a conflict record. If the disagreement exceeds 25%, the product is withheld from the site entirely and sent to a human review queue, because a gap that large usually means one source is describing a different product.
Tolerances vary by field. Lab-measured performance figures are held to 3%; installed prices are allowed 60%, because they legitimately vary enormously by market.
Validation runs in four layers
- Plausibility envelopes. Every numeric field has a declared minimum and maximum. A value outside it is an error, and errors block publication.
- Cross-field physics checks. This is the layer that catches real problems. A SEER2 of 20 is plausible; a SEER2 of 20 on a unit whose EER2 is 14 is not, because the seasonal figure cannot sit that far above the peak-condition figure. We check that COP falls as temperature falls, that a unit claiming 5°F capacity does not also claim to shut down at 20°F, that a UEF above 1.0 is accompanied by the ambient temperature limit that makes it meaningful, and that a pump's rated flow and head are physically compatible with its motor.
- Required fields. Each category has specifications without which a recommendation would be irresponsible. A heat pump with no capacity figure is not published, however good its other numbers look.
- Unresolved conflicts. Anything awaiting human review is withheld.
4 products are currently withheld by these checks. We would rather have a smaller database than a wrong one.
We show you what we do not know
Every product page carries a data completeness score — the share of specifications we track for that category that we actually have sourced values for. A product we know less about should not outrank one we know well on the strength of a couple of flattering numbers, so completeness and average source confidence both feed into recommendation scoring.
Validation warnings that do not block publication are printed on the product page rather than hidden. If a specification looks odd to our checks, it should look odd to you too.
How recommendations are produced
In two stages. First we choose a system type — the decision that actually determines your outcome, and the one contractors typically answer by defaulting to whatever they install most. That uses your climate zone's winter design temperature, your ductwork, and a fuel-cost comparison computed from your state's current residential energy prices.
Then we rank products within that type, weighting specifications according to what you said matters. Cold-weather capability is weighted by how cold your zone actually is. In a cold zone we exclude equipment rated above your design temperature from the shortlist entirely — it cannot do the job being recommended.
Every recommendation shows its reasoning. If we cannot explain why, we do not show it.
What our load estimate is and is not
The recommender estimates your design heating load from floor area, stated insulation level and climate zone, then applies the degree-day method to estimate annual energy. This is a standard first-order approach and it is not a Manual J calculation. It ignores solar gain, internal gains, and infiltration specifics.
It is useful for two things: comparing fuels against each other, where the omissions cut the same way for every option, and sanity-checking a contractor's proposal. If a contractor proposes equipment at double our estimate, ask to see their load calculation.
Known limitations
- Climate zones are assigned by state. Large states span several zones, and elevation shifts this considerably. If you are near a boundary, use your county's designation.
- Natural gas prices are seasonally distorted. Monthly residential gas prices divide fixed service charges by low summer usage, which inflates the per-therm figure. Our EIA adapter uses annual averages when run with network access.
- Installed cost ranges are wide and market-dependent. Treat them as a sanity check on a quote, not a price to expect.
- We do not test equipment. We aggregate, verify and cross-check published data. Where we express an opinion it is labelled as ours.
The pipeline itself
Runs in five stages: reference data, ingestion, conflict resolution, validation, export. Ingestion adapters pull from the ENERGY STAR Socrata open-data API, the NEEP cold-climate product list, the AHRI Directory and the EIA price API. Every fetch is stored with a content hash, so a parser change can be re-run against the exact bytes that produced the current numbers, and unchanged documents are not reprocessed.
Each run is logged. Data drift is attributable to a specific ingestion at a specific time.