Editorial Policy and Methodology
What our findings are based on, how pages are made, and what this method can and cannot tell you.
Start here: what this site is
CompatGrid is a research desk, not a review blog. Our pages are built from published specifications, certification records, protocol documentation, and other sources we cite on the page. They compare what manufacturers and standards bodies have documented.
We do not test products by hand. We have not personally used, installed, or lived with the products described on this site, and we never write as though we have.
That sentence is the honest description of our method, and it is also a rule we enforce with software rather than good intentions. Our publishing system rejects first-person experiential language — "I installed", "we tested", "in our testing", "after three weeks of use" — before a page can go live. If you ever find a sentence on this site claiming hands-on experience, it is a bug, and we would like to know about it: email [email protected].
What "specification-based" actually means
Matter and Thread are unusually well suited to research of this kind, because the interesting facts are documented rather than felt. A device either is certified for a given Matter device type or it is not. It either exposes a particular cluster or it does not. It either acts as a Thread router or it is a sleepy end device. It either supports multi-admin pairing to more than one ecosystem or it does not.
Concretely, our sources are:
- Certification records — the Connectivity Standards Alliance's certified product database, and equivalent registries for related standards.
- Manufacturer specifications and documentation — spec sheets, manuals, firmware release notes, developer documentation, and support articles.
- Standards and protocol documents — the Matter and Thread specifications themselves, for what a given feature is required to do.
- Ecosystem compatibility lists published by the platform vendors.
- Documented reports from other people — published reviews, support forums, and issue trackers. When we use these, we say who reported it and how many reports there were. We present them as reports, never as findings of our own.
What this method is good at, and where it fails
A method that cannot fail at anything is being oversold. Here is the honest split.
| Specification research answers this well | It cannot answer this at all |
|---|---|
| Whether a device is certified for a Matter device type | Whether it feels responsive in your house |
| Which ecosystems a device can be paired to, and how many at once | How reliable pairing is in practice, or how often it drops |
| Whether a device routes Thread traffic or only consumes it | Real-world mesh range through your particular walls |
| Which features the standard requires versus which are vendor extensions | Whether the vendor's implementation of a feature is any good |
| What firmware release notes say changed, and when | Build quality, noise, finish, or how it looks on your wall |
| Contradictions between a vendor's claims and its own documentation | Long-term reliability and what happens after two years |
For the right-hand column, go and read people who have actually owned the thing. We will often link to them. We are not a substitute for that, and we are not trying to be.
How a page is produced
Our pages are produced by an automated research pipeline that uses AI. We say so on every article and we are saying so here. What matters is not that software wrote the draft but what constrains the draft, so here is the whole process:
- Sources are gathered first. A page starts from certification records and vendor documentation, not from a blank page. The retrieval date of every source is recorded.
- Claims are extracted and attributed. Every factual and comparative claim about a product must resolve to a cited source. A paragraph of product claims with no citation does not publish — this is a build failure, not a style note.
- Every number carries a citation. We do not publish a measurement unless we can point at where it was published. We never present a number as something we measured.
- Conflicts are surfaced, not smoothed over. When a manufacturer's spec sheet contradicts its own manual, or when a certification record contradicts marketing copy, we say so and cite both. Those contradictions are frequently the most useful thing on the page.
- Automated checks run before publication. They reject first-person experiential claims, uncited numbers, product claims without sources, unsupported superlatives, missing affiliate disclosures, and untagged monetised links. Any one of these stops the page.
- Disclosures are inserted by the publishing system, not written by the model. A system asked to remember a legal disclosure will eventually forget one; a template cannot.
- Generation inputs, sources, and timestamps are logged for every page. If a claim turns out to be wrong, we can find every other page that relied on the same source and fix them all.
Who is responsible
Michael Joshua Makhool is the publisher and editor of record for CompatGrid. That is a real, accountable role and it means exactly this: responsibility for the editorial standards on this page, for the rules the pipeline enforces, and for correcting what turns out to be wrong.
It does not mean that this person has used, tested, or handled the products described. The byline on our articles is a publisher's byline, not a reviewer's. We think that distinction matters enough to spell out rather than let a photograph imply otherwise.
We do not invent staff writers, personas, or contributor names. There is one real person behind this site.
How we select and rank products
When we call something a "top pick" or put it first in a comparison, it is against stated criteria, applied in this order:
- Certification and standards compliance. Certified for the relevant Matter device type, with the capabilities the page is about.
- Documented capability match. The device actually documents the feature the page is about — not a marketing claim, a documented one.
- Ecosystem breadth. How many platforms it works with, and whether multi-admin pairing is supported.
- Documented support record. Firmware update history and how long the vendor has kept older devices current.
- Availability. Whether you can actually buy it in the region the page is written for.
Commission rates are not one of the criteria and are not consulted when a ranking is built. Products with no affiliate program are included on the same terms as products with one. Where a page's criteria differ from the defaults above — a page about battery-powered sensors weighs different things than one about mains-powered hubs — the page says what it weighed.
What we will not publish
- First-person reviews of products nobody here has used.Our pages are comparisons, buying guides, explainers, and research roundups. If you see the word "review" used as though we had one in our hands, that is an error.
- Invented measurements or test results. No benchmark we did not run, no number we cannot cite.
- Star ratings of our own. We do not score products on a scale we invented to imply testing we did not do.
- AI-generated user reviews, testimonials, or comments.Ever, in any form, under any name.
- Sponsored content or paid placement. None, at any price.
- Prices we cannot verify live. Prices change hourly; a stale price is a false statement. Where we cannot show a current price from an authorised source, we show none.
Advertising and affiliate relationships
This site is funded by display advertising and affiliate commissions. Both are disclosed — see the Affiliate Disclosure. Neither advertisers nor affiliate programs see pages before publication, and neither can influence what a page says. We are not sent free products; if that ever changes we will disclose it on the page it affects, because receiving one is a material connection.
Corrections and updates
Specifications change, firmware adds features, and certification records get amended. A research site that never revises anything is a research site that is quietly going stale.
- Tell us: email [email protected]. Include the page and, if you have one, a source. You do not need to be polite about it.
- We aim to acknowledge within five business days and to fix substantive errors promptly once confirmed against a source.
- Substantive corrections are noted on the page, with the date and what changed. We do not silently edit a page to make an error disappear.
- Pages can be withdrawn. If a page turns out to be wrong in a way that cannot be fixed by correcting it, we unpublish it rather than leave it up.
- Every page shows when its underlying sources were last checked, so you can judge how current it is.
If we ever do test something
If we ever publish a genuine hands-on finding, it will be marked as such, it will name the person who did the testing, it will describe what was measured and how, and it will disclose how the unit was obtained — bought, borrowed, or supplied by the manufacturer. Our publishing system will not accept a hands-on claim from the automated pipeline at all; it requires a human-authored change. Until you see that marking, assume — correctly — that the page is specification research.
Comments and user contributions
We do not currently accept comments or user-submitted reviews. If we ever do, the rules will be: we remove spam, abuse, and illegal content, applied evenly; we do not remove a comment for being negative or for disagreeing with us; we do not filter contributions by sentiment; and we never generate or fabricate them.