ARI Agent Retrieval Index

Trust

Methodology

This page documents how entities in the index are collected, normalized, and kept fresh. If you cite this index — as a person, a search system, or an agent — this is the contract behind the data.

1. Entity model

The index publishes these entity types, each with a stable URL:

  • Category (/categories/{slug}/) — defines the normalized attribute schema for a product class and links all child entities.
  • Power station (/products/{slug}/) — one battery portable power station, with normalized specs and field-level provenance.
  • Generator (/generators/{slug}/) — one portable fuel-powered generator, with its own category-specific schema and stricter safety-field rules (below).
  • RV solar kit (/solar-kits/{slug}/) — one officially named RV solar charging kit (portable or rooftop), with its own schema and strict anti-hype rules (below).
  • Comparison (/comparisons/{slug}/) — two or more entities of the SAME category set against the same attribute keys, with an explicit verdict.
  • Use case (/use-cases/{slug}/) — filter-first recommendation pages over the power-station category only (deep single-category ranking).
  • Use-case guide (/portable-power/{slug}/) — cross-category recommendation pages that compare all three families for one buying intent, grouped by category (see below).
  • Hub (/portable-power/) — the central destination linking the families, use-case guides, comparisons, and trust layer.

Three distinct categories, one destination. Battery power stations, portable generators, and RV solar kits are modeled as separate categories with separate schemas — this index never pretends gallons, watt-hours, and panel wattage are the same thing. All use official-source-first core specs. Cross-category use-case guides (battery vs generator vs solar, with honest trade-offs on indoor safety, fumes, noise, and refill-vs-recharge-vs-recurring-solar) are now published at /portable-power/ as a recommendation layer over the separate schemas — they group results by category and never merge the specs into one table.

Slugs are permanent identifiers. If a product is superseded, a new entity is created rather than rewriting the old one under the same slug.

2. Data collection

Current production policy (portable power dataset): every core specification — capacity, continuous output, outlets, chemistry, charging, weight, dimensions — comes from official manufacturer sources only: spec pages, user manuals/PDFs, and official support documentation. Retailer and marketplace listings are never used as canonical sources for current products; where a field is not officially documented, it is stored as null rather than filled from weaker sources.

Longer-term roadmap (not yet in production): a clearly-labeled secondary layer for retailer cross-checks (bundle/naming detection only) and a measured or independently tested data layer, kept separate from the official-source fields and never overriding them.

Each product entity carries a sources and provenance section with field-level records: the normalized value, the exact raw claim text it came from, the official source URL and type, the date checked, and a per-field confidence grade. Core specifications (capacity, continuous output, outlets, chemistry, charging, weight, dimensions) are official-source only; retailer and marketplace pages are never canonical. "Up to" claims are treated as marketing maxima, partial recharge claims never populate full recharge time, and unit weight is never conflated with shipping weight.

3. Attribute normalization

Manufacturers describe the same property in different words and units. Each category defines a fixed attribute schema — keys, labels, and units — and every product spec is mapped onto it. Rules:

  • One key per property; synonyms are merged (e.g. "EPS", "UPS mode", "backup switchover" → ups_mode).
  • Units are standardized per attribute (Wh, W, kg, nits) and stated in the category schema.
  • Marketing-derived numbers (peak vs continuous output, "up to" figures) are resolved to the conservative, comparable figure, with the distinction noted.
  • Missing data is shown as absent, never estimated silently.

4. Comparison construction

Comparisons are built from normalized attributes, so every matrix row is an equal-terms fact. Verdicts are required to state their reasoning, and every comparison includes scenario-level "best for" mappings, because most product choices are conditional on use case rather than absolute.

5. Freshness

Every entity displays a last-updated date, both human-readable on the page and as updated_at in its machine summary block. The sitemap carries per-URL lastmod values. Stale entities are updated or explicitly marked, not quietly left behind.

6. Monetization and independence

The index is merchant-agnostic. Product entities may link to multiple merchants, and some outbound links are affiliate links (marked affiliate on the page and rel="sponsored nofollow" in the markup). Merchant relationships have no input into specifications, verdicts, or ordering. Data and monetization are separate layers by design — see the affiliate disclosure.

The commerce layer is secondary to the facts layer, and the separation is enforced. Retailer listings are never a source for a normalized technical specification and never appear in provenance; the source hierarchy in §2 is unchanged by the existence of a merchant link. Prices are entered by hand from a merchant's page and stamped with the date they were seen — nothing is scraped. A stored price is withheld from the page once it ages past the published freshness window, because a wrong price is worse than no price, and offer data in JSON-LD is generated from exactly the values the page renders, so a crawler can never see a price a reader cannot.

7. Machine access: JSON exports

Every entity is available as JSON, generated from the same content that renders the HTML pages. Endpoints:

Schema contract: fields are only added, never renamed or removed. Every entity object carries entityType, id, canonicalUrl, jsonUrl, and updatedAt; references to other entities always use the {id, name, canonicalUrl, jsonUrl} shape, so exports can be traversed like a graph. Collection exports wrap items in {export, canonicalUrl, count, updatedAt, items}. No authentication is required.

8. Use-case recommendation logic

Use-case pages (/use-cases/) are generated from the same normalized product records using explicit fit rules, in a fixed order:

  • Hard filters run first. Each page publishes its disqualifier rules and lists every filtered-out product with its reason. Disqualifiers are explicit, never hidden inside scoring.
  • Ranking runs second, only among eligible products, using published weights over normalized fields (the exact formula appears on each page and in its JSON twin).
  • No invented measurements. Pages never compute or claim runtime hours or other real-world figures that are not in the source records.
  • Merchant-independent. Fit rules and rankings are unaffected by merchant relationships.

Each use-case page has a machine-readable twin at /use-cases/{slug}.json and all pages are bundled at /export/use-cases.json.

Cross-category use-case guides (/portable-power/{slug}/) sit one level up: they compare battery stations, generators, and solar kits for a single intent as a recommendation layer over the separate schemas — never a merged spec table. The logic order is fixed: global intent, then global disqualifiers, then category-specific disqualifiers, then ranking within each category (battery ranking reuses the single-category engine above), then category-grouped recommendations, then an explicit tradeoff summary. Categories are compared only on shared user-facing axes — indoor safety, fumes, noise class, output, runtime model, setup — and safety limits (generator carbon monoxide, outdoor-only, transfer switches) are stated, never softened. Twins at /portable-power/{slug}.json, bundled at /export/spokes.json.

9. Generator safety publication rules

Fuel-powered generators carry safety-sensitive fields that follow stricter rules than any other data in this index:

  • CO shutdown is a publication gate. A generator publishes only when its automatic CO-shutdown status is explicitly resolved from official documentation (present or not present) — 'CO safety' marketing without a described automatic shutoff never counts, and ambiguity blocks publication entirely.
  • Running and starting watts are never collapsed, and multi-fuel units store per-fuel figures only where officially published — never inferred.
  • Runtime always carries its fuel and load basis (25% vs 50% load). Basis-free runtime claims are quarantined in notes and never used comparatively.
  • Noise requires a stated basis. dBA figures without a load basis are stored as basis-unknown and excluded from comparative ranking; 'quiet' adjectives are ignored.
  • THD must be numeric. 'Clean power' claims without a number yield a null, and sensitive-electronics suitability is capped accordingly.
  • RV-readiness requires receptacle evidence (a TT-30R or a manufacturer-designated RV receptacle) — 'RV Ready' marketing alone never sets it, and this index records several units where marketing and panel disagree.
  • Indoor use is never suggested. Every generator page carries an outdoor-only notice; fuel generators are recorded as indoor-unsafe and apartment-unsuitable in their cross-category fields, regardless of CO features. Home-circuit connection guidance always points to proper transfer switches, never outlet backfeeding.

10. RV solar kit realism rules

RV solar kits are charging systems, not whole-RV power sources, so this category carries anti-hype rules stricter than typical solar marketing:

  • Kit identity is the base entity. One officially named kit package = one record. Wattage tiers (90W / 130W / 200W / 400W) become separate records whenever the controller or included contents change by tier, because that changes real capability.
  • Panel wattage keeps its structure. Total wattage and the component breakdown (panel count × per-panel wattage) are both stored, and the arithmetic must be self-consistent.
  • Controller type/amperage is official-only. PWM vs MPPT and controller amps come from official contents or spec sheets — never inferred — because MPPT harvests meaningfully more than PWM.
  • Inverter support is never inferred from "system" language. Most RV solar kits are charging-only and include no inverter; inverter fields are set only when official kit contents explicitly list one.
  • Air-conditioner suitability requires sizing math. A kit is never marked A/C-capable from panel wattage alone; "supported" requires stated battery + inverter sizing, and the honest default is that A/C needs a large dedicated system.
  • No unassumed daily-output claims. A manufacturer daily-Wh figure is published only with its stated assumptions; the site's own daily-Wh estimate is clearly marked derived and carries its peak-sun-hour and derate assumptions, never presented as a manufacturer spec or a "days off-grid" promise.
  • Installation limits are preserved. Wiring order, grounding, and battery/controller requirements from official install guides are recorded, not abstracted away.

11. Corrections

Incorrect data is a defect. When an error is found, the entity is corrected and its updated_at date advances. A public corrections/changelog mechanism is planned as the dataset grows.