Editorial and AI Standards

CriteriaDesk uses AI carefully.

AI may help with research, structure, clustering, and drafting. It may not replace evidence, judgment, disclosure, or editorial responsibility.

The purpose of this page is to make the standard clear:

AI can assist the process. It cannot invent the experience.

CriteriaDesk exists to help people make buying decisions by criteria, not hype. That means our editorial process must be slower, more transparent, and more evidence-aware than a typical AI-generated affiliate page.

The short version

CriteriaDesk may use AI to help:

• summarize official documentation;
• identify decision criteria;
• cluster recurring complaint patterns;
• draft outlines;
• prepare checklists;
• compare trade-offs;
• structure evidence logs;
• check whether claims need stronger support.

CriteriaDesk should not use AI to:

• invent hands-on testing;
• invent product experience;
• invent expert authority;
• create final product judgments without review;
• remove uncertainty;
• hide affiliate intent;
• mass-produce thin pages;
• publish automatically.

Every public page remains the responsibility of CriteriaDesk.

The editorial standard

A CriteriaDesk page should help the reader understand a decision.

That means each decision-support page should answer at least some of these questions:

• What problem is the buyer trying to solve?
• What criteria actually matter?
• Which criteria are secondary?
• What trade-offs are involved?
• What hidden costs may appear later?
• What do buyers commonly complain about?
• What should be verified before buying?
• What evidence supports the page?
• What remains uncertain?
• Is this research-based guidance or hands-on testing?

If a page cannot answer those questions, it should remain a draft.

AI is not the source of truth

AI-generated text is not evidence.

AI can help process sources, but the source of truth should be:

• official documentation;
• product specifications;
• manufacturer support pages;
• warranty terms;
• subscription terms;
• independent third-party testing, if available;
• public customer feedback used carefully;
• recurring complaint patterns;
• documented CriteriaDesk analysis;
• hands-on testing only when it actually happened.

A statement should not be treated as true merely because an AI system produced it fluently.

How AI may be used

Research assistance

AI may help identify questions worth asking.

Examples:

• What criteria might matter for this purchase?
• What hidden costs might be relevant?
• What trade-offs should be checked?
• What user complaints appear repeatedly?
• What claims require verification?
• What would a buyer need to know before purchase?

This helps create research direction. It does not replace source verification.

Source summarization

AI may summarize official documentation, support pages, public reviews, forum threads, or product information.

However, summaries must be checked against the source when they support an important claim.

A summary is useful for orientation. It is not enough for a final claim.

Complaint clustering

AI may help group recurring user complaints into themes, such as:

• connectivity;
• app reliability;
• battery life;
• customer support;
• setup difficulty;
• subscription confusion;
• durability;
• compatibility;
• false expectations.

These clusters are signals. They do not prove that every product has the same issue.

Outline and structure

AI may help turn research notes into:

• page outlines;
• section structures;
• comparison frameworks;
• checklist drafts;
• decision matrix drafts;
• editorial briefs.

The final structure should still be reviewed against the CriteriaDesk method.

Drafting

AI may help draft text.

Drafting is allowed only if the text is reviewed for:

• evidence basis;
• overclaiming;
• fake certainty;
• misleading language;
• affiliate pressure;
• implied hands-on experience;
• unclear disclosure;
• missing uncertainty;
• thin content.

AI-assisted drafting is not automatic publishing.

Compliance preflight support

AI may help run a first-pass review for risk signals.

Examples:

• Does this page imply hands-on testing?
• Does it use unsupported “best” claims?
• Are affiliate disclosures visible?
• Are prices or availability claims risky?
• Are there vague or exaggerated claims?
• Does the page have independent value without links?

This is a support step, not a legal guarantee.

How AI may not be used

AI may not be used to create fake product experience.

CriteriaDesk should not publish sentences like:

• “We tested this product…”
• “In our hands-on use…”
• “After weeks of testing…”
• “Our lab found…”
• “We personally verified…”

unless those statements are true and documented.

AI may not invent:

• tests;
• measurements;
• ownership;
• product handling;
• expert credentials;
• user testimonials;
• quotes;
• ratings;
• awards;
• prices;
• availability;
• product comparisons;
• source conclusions.

AI may not remove uncertainty simply to make a page sound more confident.

AI may not mass-produce pages primarily to capture search traffic.

AI may not rewrite product marketing as if it were independent analysis.

Research-based guidance vs hands-on testing

CriteriaDesk distinguishes research-based guidance from hands-on testing.

Research-based guidance

Research-based guidance may use:

• official specs;
• official documentation;
• manufacturer claims, labeled as such;
• support pages;
• public customer feedback;
• recurring complaint patterns;
• independent third-party tests;
• comparison logic;
• use-case analysis.

This type of page may be useful, but it should not imply direct product testing by CriteriaDesk.

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.

Hands-on testing

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

If hands-on testing is ever used, the page should explain:

• what was tested;
• when it was tested;
• how long it was used;
• what conditions were used;
• what was measured;
• what was not tested;
• what limitations apply.

Until then, CriteriaDesk should avoid hands-on review language.

Claim policy

CriteriaDesk uses cautious language because buying advice can easily become misleading.

Avoid on v0.1 unless directly proven

• tested;
• hands-on;
• best overall;
• editor’s choice;
• top pick;
• proven;
• guaranteed;
• perfect;
• safest;
• cheapest;
• must-have;
• ultimate;
• unbeatable.

Use carefully and only with context

• recommended;
• best for;
• top-rated;
• reliable;
• worth it;
• budget-friendly;
• premium;
• safe;
• secure.

These phrases need clear criteria and evidence.

Preferred language

• may fit;
• good fit if;
• conditional fit if;
• weak fit if;
• avoid if;
• verify first;
• based on specifications;
• based on public user feedback;
• recurring complaints suggest;
• this trade-off matters when;
• this may create hidden cost;
• not hands-on tested unless stated.

The tone should help the reader think, not pressure the reader to buy.

Product scoring and ratings

CriteriaDesk should not use star ratings or arbitrary numerical scores in v0.1.

Scores can look objective even when the underlying evidence is weak.

Instead, CriteriaDesk should use fit-based labels:

• Strong fit;
• Conditional fit;
• Weak fit;
• Avoid if;
• Needs verification.

These labels are more honest because they preserve context.

A product may be a strong fit for one use case and a poor fit for another.

Use of public customer feedback

Public customer feedback can be useful, but it is not perfect evidence.

Reviews and comments may be:

• biased;
• fake;
• emotional;
• incomplete;
• outdated;
• context-dependent;
• based on user error;
• based on unusual product defects;
• based on expectations the product never promised to meet.

CriteriaDesk may use customer feedback to identify recurring patterns.

It should not treat a single review as proof.

The preferred approach is:

We observed recurring complaints about this issue in public user feedback. This does not prove every unit has the problem, but it is a signal worth checking before purchase.

Evidence logs

Product-related pages should be based on an evidence log.

An evidence log should track:

• page topic;
• user decision problem;
• core criteria;
• sources reviewed;
• official specifications;
• public feedback patterns;
• hidden costs;
• trade-offs;
• product universe;
• uncertainty flags;
• update triggers;
• claims that require evidence;
• disclosure requirements.

If an evidence log is too thin, the page should not become a confident product guide.

Publication review requirements

Before publication, a page should be reviewed for:

• factual claims;
• evidence basis;
• claim language;
• affiliate disclosure;
• implied product experience;
• unsupported comparisons;
• exaggerated certainty;
• outdated information;
• missing limitations;
• useful decision value.

A page should not be published just because it is well written.

A fluent page can still be wrong, misleading, thin, or commercially biased.

CriteriaDesk operates as a solo publisher supported by AI. For routine, low-stakes, research-based pages, the review may be completed as an AI-assisted solo pass: the agent checks claims against sources, performs language and usability checks, records uncertainty and blocked claims, and gives the owner a Polish brief for the business and publishing decision. This review is not described as independent human or expert review.

External review is a risk-triggered option, not a universal publishing requirement. If a material claim needs specialist judgment that CriteriaDesk does not have, the default response is to narrow or remove that claim. High-stakes medical, legal, financial, safety, or lab-style performance claims should not be published merely because AI produced a fluent answer.

Affiliate independence

CriteriaDesk may earn affiliate commissions.

That must be disclosed.

Affiliate links should not determine the method, criteria, or conclusions.

A product should not be included only because it has a better commission.

A page should still be useful if all affiliate links are removed.

If that test fails, the page is not ready.

Disclosure standards

Affiliate disclosure should be clear, visible, and close to relevant links or recommendations.

A separate disclosure page is useful, but it is not enough by itself.

CriteriaDesk should use:

• a general Affiliate Disclosure page;
• footer links to disclosure;
• local disclosure blocks near affiliate links;
• plain language that users can understand.

Disclosure should not be hidden in small text, vague wording, or a distant policy page.

Pricing, availability, and promotions

Prices, availability, and promotions change often.

CriteriaDesk should be cautious with them.

On v0.1, CriteriaDesk should avoid displaying dynamic Amazon prices or availability unless there is a compliant technical and editorial process for doing so.

Preferred alternatives:

• price bands;
• typical spend ranges;
• hidden cost profiles;
• ownership cost examples;
• subscription cost over time;
• “check current price at retailer” without presenting stale numbers.

Do not create urgency around temporary promotions unless the information can be kept accurate and compliant.

Images and product media

CriteriaDesk should not use product images, logos, screenshots, or third-party media unless usage is allowed.

Avoid images that imply hands-on testing if the product was not actually handled.

Do not use staged images that create a false impression of direct product experience.

If product images are used later through an allowed affiliate/API route, they must follow the applicable program rules.

Corrections and updates

CriteriaDesk should be willing to correct itself.

Readers should be able to report:

• factual errors;
• outdated product information;
• broken links;
• unclear disclosure;
• missing limitations;
• methodological problems;
• product changes;
• confusing language.

When a correction is made, the page may include an update note if the change is meaningful.

What CriteriaDesk refuses to publish

CriteriaDesk should refuse to publish:

• fake reviews;
• fake hands-on claims;
• fake expert claims;
• fake testimonials;
• invented product experience;
• thin affiliate pages;
• AI-generated rankings without evidence;
• unsupported “best overall” claims;
• hidden affiliate relationships;
• manipulative urgency;
• pages that exist only for affiliate links;
• product scores without methodology;
• content that cannot be maintained responsibly.

Refusing weak content is part of the brand.

Page-level review checklist

Before publishing, ask:

1. Does the page solve a real decision problem?
2. Are the criteria clear?
3. Are trade-offs visible?
4. Are hidden costs addressed if relevant?
5. Are recurring complaints handled carefully?
6. Is the evidence basis clear?
7. Is uncertainty visible?
8. Does the page imply hands-on testing?
9. Are affiliate relationships disclosed if relevant?
10. Would the page still be useful without affiliate links?
11. Is the page maintainable?
12. Is the tone helpful rather than promotional?

If the answer to the final value test is no, the page should not be published.

The operating standard

CriteriaDesk should publish fewer pages with stronger decision value.

The site should not chase every keyword, every product category, or every affiliate opportunity.

The operating standard is:

clear criteria; honest uncertainty; visible disclosure; recorded, proportionate review; no fake experience; no hype-driven rankings.

AI can help maintain this standard only if it is used under the standard.

It cannot replace the standard.