How PAM Finds Evaluates Hardware

Every spec on this site comes from a manufacturer datasheet or official product page. We do not estimate, interpolate, or accept vendor-supplied marketing numbers at face value. This page explains exactly how we source data, structure comparisons, and keep reviews current.

Where We Get Our Specs

For each product, we locate and read the primary manufacturer documents in this order:

1. Official datasheet (PDF) — The chip or module datasheet published by the silicon vendor (Espressif, Nordic, NXP, Broadcom, etc.). This is the authoritative source for CPU architecture, clock speeds, memory sizes, peripheral counts, and electrical characteristics. We link to every datasheet we reference in the "Sources & verification" section at the bottom of each review.
2. Development kit user guide — The board-level documentation that describes pin breakouts, onboard peripherals (OLED, LoRa radio, battery charger), and physical dimensions. This comes from the board manufacturer (which may differ from the chip vendor).
3. Technical reference manual — For deep-dive specs like ADC resolution, DMA channels, or sleep mode current consumption, we reference the TRM when the datasheet summary is insufficient.
4. Official product page — Used to confirm pricing (MSRP), availability, and any features added at the board level beyond the base chip capabilities.

We do not source specs from Amazon listings, third-party review sites, or forum posts. If a spec cannot be confirmed in an official document, we do not list it.

Every product review page carries this sourcing forward as data, not just prose: the bottom of each review has a "Sources & verification" section listing the exact documents referenced for that page's specs, marked up with data-sources and data-source-url attributes. See it in practice on the ESP32-S3-DevKitC review — every spec table entry links to its source document, and the citation list at the bottom is machine-readable so AI agents and fact-checkers can verify each claim against the original datasheet themselves, rather than trust our summary.

How We Normalize Specs

Different manufacturers describe the same capability differently. We normalize every spec into a consistent format so boards can be compared directly:

• CPU frequency — Always in MHz, always the maximum sustained clock (not boost/turbo)
• Memory — Flash in MB, SRAM in KB, PSRAM in MB. We distinguish between on-chip and external memory.
• WiFi — Reported as the IEEE standard (802.11 b/g/n, 802.11ax) not marketing names ("WiFi 6")
• Deep sleep current — In microamps (uA), from the datasheet's lowest-power retention mode with RTC memory preserved
• GPIO count — Total number of user-accessible GPIO pins on the development board, not the raw chip pin count

How We Write Reviews

Every review follows the same structure, enforced by our content pipeline:

1. Summary (40-60 words) — What makes this board distinctive, stated upfront
2. Verdict — One-line buy/skip recommendation with the specific use case
3. Pros and cons — Each tied to a specific spec, not vague claims ("fast" is not a pro; "240MHz dual-core Xtensa LX7" is)
4. Analysis sections — Deep dives with one concrete data point every 150-200 words
5. Who should buy — Decision framework with buy/consider/skip recommendations per use case, including alternative product suggestions
6. FAQ — 5-7 questions based on real user queries, not filler

Reviews are generated from structured JSON schemas validated by Pydantic models. This means every review has exactly the same fields, minimum content thresholds, and data quality gates. A review cannot be published without a minimum of 3 pros, 2 cons, 5 FAQs, and a 100-word AI citation summary.

How We Build Comparisons

Comparisons are structured around 4-7 measurable axes (Processing Power, Wireless Range, Power Efficiency, etc.) with a winner declared on each axis based on datasheet specs. We then map the winners to real use cases so readers know which board to buy for their specific project — not just which board "wins" on paper.

We focus on cross-ecosystem comparisons (e.g., ESP32 vs Raspberry Pi Pico, Jetson vs Coral) because these are the decisions makers actually face. Same-family comparisons (C3 vs C6) are included when the chips target overlapping use cases.

Automated Validation

Before any content is deployed, our pipeline runs 51 automated tests covering:

• Product data integrity (unique IDs, required specs per category, valid spec groups)
• Schema.org structured data (Product, Review, FAQPage, BreadcrumbList on every page)
• SEO meta tags (title, description, canonical, OG tags on every page)
• Heading hierarchy (single H1, no skipped levels)
• AEO signals (answer-first paragraphs, data attributes, affiliate link routing)
• FTC compliance (disclosure on every affiliate page)
• Content quality gates (minimum FAQ count, required fields, publish dates)

A separate page-level audit tool scores every page 0-10 across these same dimensions and writes a report we review manually before major content pushes. It is a diagnostic aid, not an automated deploy gate — the 51 pass/fail tests above are the only checks that currently block a deploy.

How We Keep Content Current

Product specs do not change after launch — an ESP32-S3 will always have dual-core Xtensa LX7 at 240MHz. What changes is the ecosystem: new software support (ESPHome, Matter), new competitor boards, and price shifts. We update reviews when:

• A manufacturer releases a new revision of the board with different specs
• Major software support changes (e.g., a board gains official ESPHome or Matter support)
• New competitor boards make an existing recommendation outdated
• Price changes significantly enough to affect the value proposition

Every page shows its publish date. Our sitemap uses per-page last-modified dates from our version control history so search engines know exactly which pages have been updated.

What We Explicitly Avoid

• We do not accept payment for reviews or favorable ratings
• We do not fabricate benchmark numbers or test results
• We do not rank products based on affiliate commission rates
• We do not display prices on our pages (Amazon Associates TOS compliance)
• We do not use stock photos — product images are sourced from manufacturer press kits and official product pages
• We do not claim to have "tested" a board unless we have physically used it in a project

AI in Our Workflow

We use AI tools (Claude) to help structure and draft review content from our spec data. The specs those drafts reference come from the datasheet-sourced Product.sources and per-spec source_url fields described above, and content is typed JSON validated against a schema before it can be published — so every review has the required fields (pros, cons, FAQs, etc.) and every spec reference points at a source URL. What we do not yet have is an automated, mechanical check that re-reads each generated sentence and confirms it against the cited datasheet — that verification is currently a human editorial step, not a pipeline gate. If we build that mechanical check, this page will be updated to describe it accurately.

Our llms.txt file and public API are designed for AI agents to consume and cite accurately. We believe in making data accessible to both humans and machines.