Methodology

1. Situation before hardware

Every evaluation begins with a declared use case — home outage, 72-hour family readiness, fridge and freezer, router and PC, CPAP, van or RV, jobsite, outdoor. Brand is never an entry point, and brand plays no role in ranking.

2. Load modeling

Loads come from an appliance library combined with user input. For each device the engine needs continuous watts, startup peak, hours of use, whether it runs at the same time as other devices, and its priority level.

• Continuous watts drive energy consumption over time.
• Startup peak is a separate pass/fail gate on inverter output.
• Simultaneity determines the worst-case concurrent draw.
• Priority decides what is protected when something must be dropped.

Runtime is never derived from nominal watt-hours alone. A label figure is an upper bound under manufacturer test conditions, not delivered energy.

3. Energy need

The required energy is built up conservatively, in this order:

• Target duration for the declared scenario.
• Energy demanded by the prioritized load set across that duration.
• Conversion and inverter losses applied against the user.
• A safety reserve retained rather than spent.
• Required continuous output and required peak output, evaluated separately.

Calculations are deterministic: identical declared inputs always produce an identical result, and every intermediate figure is shown.

4. Recharge

A power architecture must survive a complete use-and-recharge cycle. The engine takes the available recharge paths (wall, solar, vehicle), the time actually available, whether pass-through or UPS behavior is needed, and whether expansion is possible. Architectures that cannot close the cycle are eliminated, regardless of capacity.

5. Constraints

Budget, weight, noise, portability, indoor or outdoor use, temperature range, connector requirements and warranty are hard filters, not preferences to be traded away silently. A constraint may eliminate a higher-capacity model, and when it does, the verdict says so.

6. Dated catalog policy

The catalog separates stable specifications from volatile commercial data.

• Specification record: estimated usable capacity, continuous and peak watts, wall and solar recharge, UPS / pass-through behavior, expansion options, weight, warranty — each with a source reference and an evidence-quality rating.
• Commercial record: price and stock, always time-stamped, never merged into the specification record and never presented as current unless it is.
• Unknown is a value. Missing, unknown, zero, not applicable and contradictory are distinct states and render differently.

6b. Architecture before product, evidence before commerce

For the refrigerator check the order of operations is fixed and published: the sizing engine produces a verdict; the architecture is chosen from the declared situation (dedicated refrigerator unit, general portable station, or no product at all); the exact-SKU catalogue is gated on dated evidence and ranked; only then is a destination resolved. The architecture that was not selected is always named, with the reason, and the units that belong to it stay visible rather than being hidden.

Each catalogue row is one exact US SKU, in one of four states. QUALIFIED means the evidence is sufficient for that verdict and gate context. NOT YET QUALIFIED means one or more critical facts are missing: the missing fields and the action that would close them are published, and nothing adverse is claimed about the unit. EXCLUDED is reserved for an affirmatively proved veto — a failed measurement, an exact-SKU conflict, a proved incompatibility, or a product that is not available in the US. NOT SELECTED is a presentation state only: a technically admissible unit that another option or architecture beat for this situation. A missing measurement is never published as an exclusion. Manufacturer claims from an official US page may establish nominal capacity, rated continuous output and stated transfer or recharge behaviour; independent measurements are labelled separately. A marketing surge figure is never accepted as proof that a compressor will start. Nominal watt-hours are never presented as runtime: the conservative planning method above is applied first, and only about 87% of nominal capacity is treated as usable for planning, rounded down.

What a unit must hold to be admitted, revised 12 August 2026: exact-SKU identity and US availability, nominal energy, rated continuous output, and a compatibility ceiling for the declared startup load — dated, and from the official US page for that exact SKU. Official manufacturer evidence is accepted for these, clearly labelled as a claim. Independent measurements of delivered AC energy and idle draw improve the evidence grade and the confidence behind an order, but they are not universal admission blockers: the same conservative planning factor is applied to every unit and no exact runtime is ever promised. When such a measurement is missing, it stays published as a limit on the unit's own card. Evidence about automatic switchover blocks only when the declared situation requires automatic transfer — and for a dedicated refrigerator-backup product, documented automatic transfer and exact-SKU refrigerator compatibility are inherent, so they always block. Nothing here is a reason to raise the bar selectively: the same set is applied to every brand, and a commercial relationship changes neither the state nor the order.

An accepted affiliate program can never change a technical state or a rank. It never rescues a SKU that is excluded or not yet qualified. A not-yet-qualified unit may still show its exact official product page for information only — labelled “Official product page — not a recommendation; evidence gate still open”, with no affiliate parameter and no click event — and only when its exact SKU identity, US availability and official URL are all verified. Where a qualified unit has no accepted program, the site links to its exact official product page and says so.

6c. Calculation policy

• Usable energy, not nominal energy, drives every duration figure.
• Conversion losses and a safety reserve are applied before any runtime is shown.
• Peak output is treated as a pass/fail gate, evaluated independently of capacity.
• A full use-and-recharge cycle must close, or the architecture is eliminated.
• Missing, unknown and not-applicable are distinct states and are displayed as such.

6d. Architecture of the Decision Engine

One declared situation goes in. A ranked set of explainable verdicts — or a documented abstention — comes out. Every step is deterministic, conservative and inspectable.

• Deterministic. The same declared inputs always produce the same verdict. No model guesswork in the sizing path.
• Explainable. Each verdict lists the reasons that produced it and the limits that constrain it.
• Conservative. Losses and reserves are applied against the user, not in favor of a bigger sale.

7. Verdicts

Where justified, the engine returns three to five outputs — best fit, lower cost, lighter, expandable — each with the reasons that produced it and the limits that qualify it. When the declared peak, duration, recharge window and constraints cannot be satisfied together, the output is an explicit no-fit abstention. Abstention is a valid answer, and it is displayed differently from a rational “buy nothing yet” conclusion.

8. Decision Case and reproducibility

Every completed check produces a Decision Case: a controlled record of how one answer was reached, so it can be re-read, challenged or reproduced later.

• Structured intake. The declared situation is normalized into named fields rather than free text, so two people who declare the same thing are treated the same way.
• Explicit unknowns. Anything not declared is recorded as an unknown against the gate it blocks — energy, continuous output, startup surge, recharge, transfer or architecture — and is never silently assumed to pass.
• Exact-SKU dated evidence. A product action requires an evidence row tied to one SKU in one market, with its capture date, its sources, and a clear split between manufacturer claims and independent measurements.
• Startup peaks are judged per situation, not per product. A compressor peak is a property of the pair (your declared load × the station), so a unit is not written off just because no exact-SKU video shows it starting a refrigerator. The safe bound we use is the verified continuous output: a declared startup at or below it is treated as proved. Above it, extra headroom is credited only when a peak level and the duration it is held for are documented officially for that exact SKU, or measured independently on it. A marketing surge or "power lifting" figure without a duration is recorded for transparency and never credited. When your startup watts are unknown, the peak stays unproved and we ask for a measurement.
• Transfer behaviour is labelled by evidence type. An exact official page or manual can close the transfer gap, but it is published as a manufacturer claim. Only an instrumented independent measurement is presented as measured.
• Deterministic rules. The same normalized inputs and the same versions always produce the same output.
• Reason codes. Every verdict, limit and abstention carries at least one stable code, shown in plain English with the code next to it.
• Versions. Each record carries the engine, ruleset and catalog versions in force when it was produced, so a later change is visible rather than silent.
• Local record. The Decision Case is saved on your device and can be downloaded as JSON. It is not stored on a server, and what you declared is never sent to one. Usage measurement sees only the case reference, a short hash prefix, the version strings and the reason-code count.
• Instrumented next action. The recommended next step is recorded as a code, so the site can tell whether its own advice is actionable.

8b. Decision Engine vs Decision Updates

Two layers, two jobs. One answers a question now; the other would tell you when that answer stops being true. They are deliberately separate systems.

• Decision Engine — synchronous reasoning layer. Runs at the moment you ask, from your loads, duration, recharge window and constraints, and returns three to five verdicts with reasons and limits, or an abstention. No email is required to see the result.
• Decision Updates — future, asynchronous. The optional owner email and update loop that would run after a decision: price and stock moves, lineup changes, compatibility changes, expansion-path changes, dated catalog updates, and a re-check of whether the verdict still holds. No signup and no alerts are active; nothing is collected or sent.

9. Limits of this method

• Outputs are only as good as the declared inputs; bad load estimates produce bad sizing.
• Real appliances vary from library averages, especially older compressors and motors.
• Solar figures depend on conditions this system cannot observe.
• Nothing here is electrical, safety, medical or financial advice, and no performance guarantee is made. For life-supporting equipment, follow the manufacturer and your clinician.

The same arithmetic is published as a reproducible dataset in the refrigerator outage sizing table, with the 0.85 delivery factor and 0.90 retained reserve shown case by case and downloadable as XLSX or CSV.

Rule changes and corrections are logged on the updates page.