CriteriaDeskAn evidence-backed decision system
Search
Open calculator

Methodology — How CriteriaDesk Works

CriteriaDesk uses criteria maps, evidence logs, trade-off analysis, hidden-cost checks, and disclosure standards to help users make better buying decisions.

CriteriaDesk exists to help people make buying decisions by criteria, not hype.

Most buying content starts with a list of products. CriteriaDesk starts earlier: with the decision itself.

Before a product can be recommended, compared, or mapped to a use case, we want to understand:

  • what the buyer is trying to solve;
  • which criteria actually change the decision;
  • which claims are mostly marketing noise;
  • what hidden costs may appear after purchase;
  • what trade-offs are involved;
  • what buyers commonly complain about later;
  • what evidence is strong, weak, or incomplete.

The goal is not to make buying feel exciting. The goal is to make buying less confusing.

The basic principle

A CriteriaDesk page should be useful even if every affiliate link is removed.

This is the central test.

If a page only exists to push a product link, it does not belong here.

A useful page should help the reader understand at least one of the following:

  • what criteria matter;
  • what trade-offs exist;
  • what hidden costs to expect;
  • what to verify before buying;
  • what common mistakes to avoid;
  • what kind of product fits a specific use case;
  • when not to buy.

Scope and precedence

This is the governing publishing method for all CriteriaDesk decision-support content.

Topic-, vertical-, platform-, retailer-, and affiliate-specific documents are supplements. They may add requirements that are genuinely necessary for that context, but process volume is not evidence quality. If a supplement, program rule, or source conflicts with this method, the owner and the AI-assisted review must resolve or expose the conflict before publication. If an unresolved conflict could materially change the decision, the claim should be narrowed, removed, or left unpublished.

Every product-related publication should leave the smallest reviewable record that explains:

  • a problem and publication-value brief;
  • a criteria and decision-rule map;
  • a source map and evidence log;
  • a claim-to-evidence record for material claims;
  • the planned decision asset;
  • a completed editorial, usability, rights, and compliance preflight;
  • a named maintenance owner, review date, and update triggers.

These elements may be combined in one short publication card or evidence note. Separate files are justified only when they make the work easier to verify or maintain. Empty templates, repeated summaries, and documentation created only to prove that a process happened should be removed.

Foundation and non-product pages may omit product-universe and product-mapping work when it is genuinely not applicable. They may not omit a clear user problem, an evidence basis, visible uncertainty, useful decision value, a recorded review outcome, or a correction and maintenance path.

The CriteriaDesk process

CriteriaDesk is a solo, AI-assisted publisher. The default publishing path is deliberately short:

  1. Define the reader’s decision, direct answer, and useful no-buy alternative.
  2. Gather enough appropriate evidence for the material claims and stop when further likely sources are unlikely to change the decision.
  3. Write the page in reader-first order: answer, decision help, then evidence and detail.
  4. Run an AI-assisted solo review covering claims, sources, language, uncertainty, rights, disclosure, and fake-experience risk.
  5. Run the technical build and a practical usability check.
  6. Give the owner a Polish brief covering the publishing goal, business direction, monetization boundary, and unresolved risk; record pass, revise, or reject.

The detailed sections below are a library of checks, not a requirement to create sixteen stages or sixteen artifacts for every page. Apply only the checks that can change the decision, prevent a material error, satisfy an external rule, or make maintenance meaningfully easier.

Additional work is required when the page names or ranks current products, uses affiliate links, makes fast-changing price or availability claims, relies on original hands-on testing, or enters a high-stakes area. CriteriaDesk normally avoids medical, legal, financial, and safety-critical recommendations that would require specialist judgment it does not have.

1. Niche thesis and exclusion filter

A topic must first pass the project’s basic filters.

CriteriaDesk avoids categories where honest, low-hype decision support is difficult or where the commercial incentives are too likely to distort the content.

We generally avoid:

  • fake hands-on reviews;
  • claim-heavy health, supplement, or weight-loss products;
  • beauty claims that depend on subjective or hard-to-verify outcomes;
  • crypto, gambling, dating, or manipulative funnels;
  • aggressive urgency marketing;
  • topics where the only viable angle is “best product” without enough evidence;
  • topics that require lab testing we cannot perform.

The question at this stage is:

Can we help the user make a better decision without pretending to know more than we know?

If the answer is no, the topic should be rejected or parked.

2. Monetization fit

A topic may have search volume and still be a poor fit for CriteriaDesk.

A good topic should allow honest monetization without forcing the content into manipulation.

We ask:

  • Is there a natural product decision?
  • Are there real alternatives to compare?
  • Can the page remain useful without affiliate links?
  • Would monetization distort the guidance?
  • Are the products available through a legitimate affiliate route?
  • Is the category too dependent on exaggerated claims?
  • Would the page pressure the user to buy before understanding the decision?

If monetization requires hype, the topic is wrong for CriteriaDesk.

3. Demand check

Demand check asks two separate questions:

  1. Are people actually looking for help with this problem?
  2. Is this the right problem for CriteriaDesk to work on now?

Before expensive research begins, CriteriaDesk runs a short demand scan. It records the region, date, seed query cluster, sources checked, and one of three outcomes: produce now, small experiment, or park.

The scan combines several kinds of signal:

  • Existing-site demand: Search Console queries, impressions, and pages for related material. This becomes the strongest source once the site has enough data.
  • Search scale and direction: Google Ads Keyword Planner or Bing Keyword Research for estimated volume and variants; Google Trends for relative direction, seasonality, and regional differences.
  • Problem language: autocomplete and related searches, public questions, forums, product Q&A, support communities, and recurring phrases such as “is it worth it”, “how many”, “without subscription”, “hidden cost”, or “problems with”. These reveal language and decision conditions, not reliable market size.
  • Channel-specific demand: Pinterest Trends for search, save, and shopping patterns; YouTube Analytics Trends and content gaps when a channel exists; comparable first-party channel data where available.
  • Opportunity: the current result set and content formats, the quality of existing answers, and whether a criteria map, calculator, checklist, scenario comparison, or other decision asset would make the answer materially better.

Google Trends is not an absolute-volume tool. Its values are normalized and low-volume queries may appear as zero, so a zero is not proof that nobody has the problem. Keyword Planner provides estimates rather than guaranteed traffic and may omit very low-volume phrases. Search suggestions and public discussions are evidence of wording or recurring problems, not a frequency estimate.

The default decision rule is deliberately light:

  • Produce now: at least one meaningful quantitative signal or two independent recurring-problem signals, plus clear decision depth and a feasible original contribution.
  • Small experiment: demand is plausible but volume is uncertain, while decision value or cluster value is high. Publish the smallest useful page, avoid a large research package, and let impressions and engagement decide whether to expand it.
  • Park: the only signal is our own idea, the likely intent does not fit the page we can create, or the research and maintenance cost is disproportionate to the plausible value.

No universal monthly-search threshold is required. A narrow question may have modest direct volume but still deserve a page when it supports a valuable topic cluster, prevents an expensive mistake, or leads naturally to a useful comparison or tool. Conversely, a high-volume query may still be a poor fit if the user only wants a price, retailer, or short factual answer.

Demand alone is not enough. A topic must also have decision depth, an honest evidence path, and a distinct contribution.

CriteriaDesk does not search for one magic keyword. Before writing, it records a one-line intent contract: the query cluster or channel promise, the user’s actual job, the answer promised by the title, and the page format most likely to satisfy that job. The same contract applies to Google, an LLM citation, Pinterest, YouTube, or another referral: the landing page must deliver what the entry message promised.

Before a topic passes this gate, the brief should also state the original contribution CriteriaDesk intends to make. That contribution may be a clearer criteria map, a narrower scenario, a hidden-cost analysis, a complaint synthesis, a decision tool, or another concrete improvement over the material already available.

If the proposed page would merely rephrase specifications, search results, or existing articles without adding decision value, it should be rejected or narrowed before research begins.

4. Search intent and format check

CriteriaDesk should not publish against the wrong intent.

Before writing, we check what kind of pages search engines and users appear to expect:

  • guides;
  • product roundups;
  • comparison pages;
  • forums;
  • videos;
  • marketplaces;
  • official product pages;
  • calculators;
  • checklists;
  • troubleshooting pages.

The question is:

Is there room for a criteria-first decision-support page?

If the search results are dominated by giant hands-on review brands, marketplaces, or transactional pages, the topic may still be possible, but only through a narrower angle.

After publication, intent fit is checked with real entry data rather than the original keyword guess. Google Search Console is used to compare query → page → impressions → clicks. Referrer and UTM data from server logs are used for social, video, and detectable LLM referrals. Unexpected queries or high impressions with weak CTR trigger a title, description, format, or scope review; they do not justify adding unrelated text to chase traffic.

5. Evidence sufficiency check

This is one of the most important steps.

CriteriaDesk should not write a page unless there is enough evidence to help the user honestly.

Evidence may include:

  • official product documentation;
  • product specifications;
  • manufacturer support pages;
  • warranty and return policies;
  • public customer feedback;
  • recurring complaint patterns;
  • independent reviews and tests;
  • technical standards;
  • pricing structures;
  • subscription terms;
  • compatibility requirements.

The question is:

Do we have enough evidence to help the user without pretending to have tested the product?

If not, we should not publish the page in that form.

Before research begins, the source plan should define:

  • the material questions and claims that must be resolved;
  • the source types needed for each question;
  • freshness, model, region, version, and date constraints;
  • which unknowns would require hands-on testing;
  • what would make the evidence sufficient to stop researching.

Research may stop only when:

  • every material claim is supported by an appropriate source, weakened, clearly marked as uncertain, or removed;
  • meaningful source conflicts are resolved or explicitly preserved as uncertainty;
  • the remaining unknowns are unlikely to change the decision, or the page clearly explains that they might;
  • further likely sources are unlikely to materially change the conclusion;
  • update triggers have been identified for facts likely to change.

This is an evidence-based stop rule, not a fixed source count. If a material uncertainty still changes the recommendation, the page should remain a draft, be narrowed, or avoid making that recommendation.

6. Competition reality check

CriteriaDesk should not try to imitate large review laboratories.

Large testing brands may have:

  • test labs;
  • purchased products;
  • benchmark data;
  • large editorial teams;
  • established domain authority;
  • years of backlinks;
  • brand trust.

A solo, evidence-backed decision system needs a different edge.

CriteriaDesk can compete better through:

  • narrower problems;
  • clearer criteria;
  • better checklists;
  • hidden-cost analysis;
  • use-case fit;
  • recurring complaint synthesis;
  • decision tools;
  • transparent uncertainty.

The goal is not to beat a lab at testing. The goal is to help the user think through decisions the lab format may not fully clarify.

7. Criteria map

A criteria map identifies what actually changes the decision.

It may include:

  • core criteria;
  • secondary criteria;
  • deal-breakers;
  • hidden costs;
  • maintenance requirements;
  • compatibility issues;
  • setup constraints;
  • buyer skill level;
  • use-case differences;
  • recurring problems.

A criterion only belongs in the map if it changes the decision.

If a feature sounds impressive but rarely changes the choice, it should not dominate the page.

For every recommendation or fit statement, the map should show which criteria support it, for which scenario it applies, and what condition would change the conclusion. A weighted score is optional; a traceable decision rule is not.

8. Decision asset design

Whenever possible, a CriteriaDesk page should include a practical decision asset.

Examples:

  • checklist;
  • decision matrix;
  • calculator;
  • comparison brief;
  • fit quiz;
  • printable buyer brief;
  • hidden-cost worksheet.

A decision asset should help the user do something, not merely read more.

Good assets help users:

  • reject a poor fit;
  • compare trade-offs;
  • estimate hidden costs;
  • verify requirements;
  • understand risk;
  • prepare before purchase.

For v0.1, the preferred assets are checklists and simple decision matrices. Calculators can come later when the data model is clear.

9. Product universe definition

Before mapping products, we define the product universe.

This prevents a page from pretending to cover “the best products” when it only covers a small or arbitrary subset.

A product universe should state:

  • what category is included;
  • what category is excluded;
  • what price range is considered;
  • what use cases are included;
  • what minimum criteria apply;
  • what was not evaluated;
  • what may require future review.

A clear product universe is more honest than a vague “top products” claim.

10. Evidence log and product mapping

Product mapping should not happen from memory, hype, or AI output alone.

A product mapping should rely on an evidence log.

The evidence log should track at minimum:

  • each material claim or decision-relevant question;
  • direct source links;
  • publication date or date checked;
  • source type;
  • whether the source supports, limits, or contradicts the claim;
  • evidence strength and limitations;
  • the strongest public wording the evidence allows;
  • unresolved conflicts and uncertainty;
  • product name and model, when relevant;
  • official specifications;
  • key criteria;
  • use-case fit;
  • trade-offs;
  • hidden costs;
  • recurring complaints;
  • uncertainty flags;
  • last checked date;
  • update triggers.

The preferred language is:

  • strong fit if;
  • conditional fit if;
  • weak fit if;
  • avoid if;
  • verify first.

The discouraged language is:

  • best overall;
  • perfect;
  • guaranteed;
  • editor’s choice;
  • tested and approved;
  • ultimate pick.

Unless there was actual hands-on testing, CriteriaDesk should not use hands-on review language.

11. Content brief

A content brief turns the evidence log and criteria map into a page plan.

A brief should be as short as the decision permits. For a routine qualitative guide it may be a few bullets in the publication card covering:

  • user problem;
  • original CriteriaDesk contribution;
  • direct answer and conditions that change it;
  • material evidence and blocked claims;
  • decision asset and next step;
  • research stop and update triggers;
  • review outcome and monetization boundary;
  • maintenance owner and next review date;

Add product universe, complaint synthesis, hidden-cost analysis, detailed claim mapping, or separate research artifacts only when the page actually needs them. A draft should not be written before the core brief is clear, but completing an elaborate template is not a prerequisite.

Reuse evidence before commissioning more research

The default unit of substantial research is a shared user problem or decision cluster, not necessarily one URL. A later page may reuse an existing source map and claim record when the model, region, version, conditions, allowed wording, and update status still match.

Before starting another research package, the publication card records the delta: which material claims are new, what changed, and whether the missing evidence can change the answer. If there is no material delta, the page uses the existing claim record and proceeds to drafting and review. If the delta changes the recommendation, it is researched, narrowed, or blocked.

Evidence reuse does not justify thin pages. A separate URL still needs a distinct entry intent, a complete answer, an original decision asset or next step, and a reason to exist beyond increasing page count. Product selection always requires a current product universe and product-specific evidence even when the category guide already exists.

12. Compliance preflight

Before publishing, a page should pass a compliance preflight.

The preflight checks:

  • real user problem and original decision value;
  • completion of the evidence-based research stop rule;
  • direct claim-to-source support for every material factual claim;
  • visible treatment of unresolved source conflicts and uncertainty;
  • affiliate disclosure;
  • review basis;
  • claim language;
  • Amazon-related restrictions if relevant;
  • use of price, availability, or promotion claims;
  • use of product images or third-party content;
  • Google people-first quality;
  • avoidance of scaled low-value AI content;
  • link attributes for paid links;
  • no fake hands-on statements;
  • a task check confirming that a reader can find the main answer, understand what changes it, and identify a sensible next step;
  • a recorded review date, reviewer type, scope, and outcome: pass, revise, or reject.

For routine, low-stakes, research-based pages, an AI-assisted solo pass is valid when the record identifies the sources checked, blocked claims, unresolved uncertainty, language or usability checks, and the owner’s Polish publishing decision. It must not be described as independent or expert review.

External human review is optional unless a law, contract, or program rule explicitly requires it. It should be sought or the claim should be removed when specialist interpretation is necessary, an unresolved conflict can materially change a high-impact recommendation, original testing supports a performance or safety claim, or the subject is medical, legal, financial, or otherwise high-stakes. The absence of an unavailable reviewer must not block an ordinary qualitative guide that can be responsibly narrowed and transparently sourced.

A documented proxy task check may be used for routine pages and small updates. New page patterns, high-impact recommendation formats, and templates intended for broad affiliate rollout should be tested with people unfamiliar with the content before that pattern is scaled. A proxy check must not be presented as user research.

A page should be revised or rejected if it contains:

  • fake experience;
  • hidden affiliate relationship;
  • unsupported “best” claims;
  • misleading pricing;
  • copied product data without added value;
  • thin affiliate content;
  • unclear evidence basis.

13. Publish

Publishing is not the start of thinking. It is the result of enough thinking.

A published page should include:

  • clear title and description;
  • visible method or review basis;
  • useful decision-support content;
  • appropriate disclosure;
  • last updated date;
  • correction/contact path;
  • no fake certainty;
  • no hidden affiliate intent.

If a page is not ready, it should remain a draft.

14. Index and UX verification

After publishing, we verify the page technically and practically.

Checks include:

  • is the page crawlable?
  • is the title clear?
  • is the description clear?
  • are internal links working?
  • is the page readable on mobile?
  • are disclosure blocks visible?
  • are tables usable?
  • are checklists readable or printable?
  • is the page too thin?
  • is there any placeholder content?

A page that is technically published but not useful is not complete.

15. Measure

CriteriaDesk measures a four-level sequence:

  1. Intent fit: did the search query, LLM citation, social post, video, or other entry promise match the page the user received?
  2. Comprehension: did the reader reach the short answer and decision callouts without the evidence layer blocking the conclusion?
  3. Trust: were the review basis, uncertainty, sources, and commercial disclosure available and used?
  4. Decision progress: did the reader use a tool, follow a sensible next step, or make a qualified commercial click after fit and disclosure?

Google Search Console provides query, page, impression, click, and CTR data for search acquisition. Minimized same-site events in ordinary server logs record aggregate answer_seen, callout_seen, review_basis_seen, disclosure_seen, source_click, next_step_click, the guarded decision lifecycle, and affiliate clicks. Tool values are never included; a completed decision and a successful copy are each emitted at most once per page load. No CriteriaDesk cookie or persistent visitor identifier is used, so these are aggregate signals rather than a person-level funnel. Ordinary hosting logs can still contain request metadata such as IP address and browser information under the privacy policy.

The first review happens after the page has enough evidence to interpret — normally after 28 days or 100 search impressions, whichever comes later. Change one material variable at a time and compare the next period. Do not rewrite a useful page because of a handful of visits, and do not treat raw affiliate CTR as proof of a good decision.

The operational procedure and interpretation rules are maintained in Docs/30_CONTENT_USABILITY_AND_ETHICAL_DECISION_ARCHITECTURE_2026-07-14.md.

16. Update, split, park, or remove

Not every page should live forever.

A page may need to be:

  • updated when prices, product lines, policies, or evidence change;
  • split when one page covers too many intents;
  • consolidated when multiple pages overlap;
  • parked when the topic is too costly to maintain;
  • removed when the page can no longer be kept accurate or useful.

CriteriaDesk should not keep pages just because they exist.

A page with high maintenance burden and low usefulness should be parked or removed.

What counts as evidence

CriteriaDesk may use several types of evidence.

Stronger evidence

  • official documentation;
  • manufacturer specifications;
  • warranty terms;
  • subscription terms;
  • independent testing sources;
  • regulatory or standards information;
  • direct hands-on testing, if actually performed.

Useful but limited evidence

  • public customer reviews;
  • forum discussions;
  • Reddit threads;
  • product Q&A;
  • retailer feedback;
  • recurring complaint patterns;
  • YouTube comments or demonstrations.

These can show patterns, but they should not be treated as definitive proof.

CriteriaDesk analysis

CriteriaDesk analysis may combine sources to explain:

  • trade-offs;
  • fit by use case;
  • hidden costs;
  • decision risks;
  • uncertainty;
  • what to verify before buying.

Analysis should be clear about its basis.

How conflicting evidence is handled

Conflicting sources should not be averaged into a confident conclusion.

When evidence conflicts, CriteriaDesk should:

  1. verify that the sources refer to the same product model, region, date, software or standard version, configuration, and test conditions;
  2. use primary documentation for what a product, policy, or standard officially states, while using independent measurements for real-world performance and public feedback for detecting issues worth verifying;
  3. check whether one source is newer, more direct, more transparent about method, or better matched to the user’s scenario;
  4. record the disagreement and narrow the public wording when the conflict remains unresolved;
  5. avoid a confident recommendation when the unresolved conflict could materially change the decision.

The evidence log should preserve the conflicting claims, sources, dates, limits, and the editor’s reason for resolving the conflict or leaving it open.

How CriteriaDesk uses public user feedback

Public user feedback can reveal useful patterns.

It can show what buyers often discover after purchase, such as:

  • app problems;
  • subscription surprises;
  • durability complaints;
  • misleading expectations;
  • setup difficulty;
  • compatibility issues;
  • customer support friction.

But user feedback can also be biased, incomplete, fake, emotional, or context-dependent.

CriteriaDesk uses it as a signal, not as final proof.

When recurring complaints appear, the better question is:

What should the buyer verify before purchasing?

Not:

How can we turn complaints into a dramatic product verdict?

Research-based guidance vs hands-on testing

CriteriaDesk must clearly distinguish research-based guidance from hands-on testing.

Research-based guidance may use:

  • specifications;
  • documentation;
  • public feedback;
  • third-party tests;
  • comparison logic;
  • use-case analysis.

Hands-on testing means the product was actually used or tested by CriteriaDesk under stated conditions.

If there was no hands-on testing, the page should not imply there was.

Standard wording:

This guide is based on product specifications, official documentation, public customer feedback, recurring complaint patterns, and use-case analysis. We do not claim hands-on testing unless explicitly stated.

How uncertainty is handled

Uncertainty should be visible.

Examples of uncertainty flags:

  • Not hands-on tested.
  • Needs verification.
  • Pricing changes often.
  • Specs vary by model or region.
  • Based on public user feedback.
  • Evidence is limited.
  • Product line may have changed.
  • Subscription terms may change.

Uncertainty is not a failure. Hidden uncertainty is the failure.

CriteriaDesk may earn money through affiliate links.

That does not change the method.

Affiliate links should be:

  • clearly disclosed;
  • secondary to the decision-support content;
  • placed only where context exists;
  • not disguised;
  • not the reason the page exists.

The reader should be able to use a CriteriaDesk page without clicking any affiliate link.

What CriteriaDesk refuses to publish

CriteriaDesk should refuse to publish:

  • fake reviews;
  • fake hands-on claims;
  • AI-generated product experiences;
  • unsupported “best overall” claims;
  • pages built only around affiliate links;
  • rankings without criteria;
  • product scores without methodology;
  • hidden disclosures;
  • manipulative urgency;
  • claim-heavy categories that cannot be evaluated honestly;
  • pages that require constant maintenance but have little user value.

Update policy

CriteriaDesk pages should be updated when:

  • product lines change;
  • subscription terms change;
  • pricing structures change;
  • recurring complaint patterns change;
  • evidence improves;
  • links break;
  • disclosures need revision;
  • a page no longer matches the method.

Each product-related page should define a maintenance owner, a next review date, and event-based update triggers.

The owner should record whether a review resulted in no change, updated, split, parked, or removed. A material correction should be visible to readers when the previous wording could have changed a decision.

If a page cannot be maintained responsibly, it should be parked or removed.

The final publication test

Before publishing any decision-support page, ask:

Would this page still be worth publishing if it had no affiliate links?

If the answer is no, the page is not ready.

Then confirm that:

  • the page solves a real decision problem and adds identifiable value;
  • its material claims can be traced to appropriate evidence;
  • its recommendations follow from visible criteria and conditions;
  • uncertainty, alternatives, and the option not to buy are clear;
  • the preflight has a recorded AI-assisted solo pass or a stronger review outcome, and the page can be maintained responsibly.

CriteriaDesk should publish fewer pages with stronger decision value, not more pages with weaker trust.

The standard is simple:

criteria first, products second, hype never.