Prompt Atlas publishes practical AI tool reviews, comparisons, and guides. This page explains how to read the evidence behind a recommendation and where its limits apply.
What “hands-on” means here
A hands-on article describes actions performed in an accessible tool and the results observed. The article should identify the task, inputs, access level, and limitations. A completed workflow, a failed run, and a feature blocked by a paid plan are different results; none should be presented as interchangeable proof.
Official documentation, public demonstrations, and guided product tours can help explain a product. They do not establish that a live account, paid feature, or production workflow was tested. When coverage relies on those sources, the article should say so.
AI assistance and editorial responsibility
Prompt Atlas uses AI assistants for research, drafting, editing, and, where access permits, operating software through browser controls or connected integrations. In those cases, actions may be executed by an AI agent in an authorized account rather than manually by John Deris. First-person wording describes the Prompt Atlas evaluation; it should not be read as a claim that John personally performed every click.
John Deris selects and approves editorial work and publication, requests corrections, and remains responsible for the published articles. AI-assisted checks can still miss errors. Generated explanations are not test evidence: conclusions must be tied to observed outputs, records, screenshots, or received messages, and incomplete checks must remain identified as such. The method and scope in each article explain the work recorded for that evaluation.
Scope, dates, and access
Read the method and limitations in each article for the test scenario and the features actually available. A free plan, trial, paid account, and public tour may expose different capabilities. A result applies to the access used, rather than every plan.
Test dates and pricing checks describe different events. Updating a price does not mean the workflow was retested. Product versions, model names, and numbers of runs are reported when they were recorded; missing details should not be replaced with invented precision.
How comparisons should be read
Some comparisons use the same prompts and constraints across tools. Others compare separately documented workflows or combine hands-on results with official information. Check the article’s scope before treating it as a controlled comparison.
Differences in account access, integrations, setup, inputs, and test dates can affect results. A tool that was unavailable or blocked was not shown to fail at the task. A recommendation can therefore be conditional: useful for one workflow, unproven for another.
Results and recommendations
Useful evidence includes outputs, screenshots, execution records, errors, and the steps needed to reproduce a task. Conclusions should distinguish what happened during testing from expectations based on advertised features.
Small samples and fictional business scenarios help explore a workflow, but they do not establish long-term reliability, revenue gains, or performance in a real customer’s business. Recommendations are tied to the task and observed limitations, rather than a claim that one tool is best for everyone.
What we check in a task
Where the task allows it, we check factual accuracy against the supplied data or source, whether the tool follows the instructions, how clearly it presents the result, and how much correction or verification is needed before use. We also record whether the requested action actually completed. A polished draft is not proof that an email was delivered, a booking was confirmed, or a workflow ran.
How to read result labels
Pass: The requested action completed and the result met the checks described for that task. Pass with a caveat: The main action completed, but a stated issue still needed attention. Partial: Some useful output or steps were confirmed, while another requested part remained incomplete or unverified. Blocked: Access, account setup, a technical error, or another prerequisite prevented completion; this is not proof that the product cannot perform the task.
Older articles may use labels such as Strong or Mixed. Read their definitions and accompanying evidence rather than treating every article as part of one numerical scoring system.
Sample size and business data
Many checks use one observed execution per scenario and fictional business data. Multiple scenarios are not repeated runs of the same test. When repeat counts were not recorded, we say so rather than assuming a single run. Public demos, connected accounts, and fictional inputs should be identified separately. These samples do not measure long-term reliability, real-customer outcomes, or performance across all plans and model versions.
Pricing and changing products
Plans, usage limits, availability, and prices can change. Where an article provides a pricing check date, that date applies to the information checked then. Confirm current terms with the vendor before choosing a paid plan.
Affiliate links and editorial independence
Where an article includes an affiliate link, the commercial relationship should be disclosed in that article. Approval for an affiliate program does not mean every article contains affiliate links or that a commission has been earned. Prompt Atlas may earn a commission when a reader purchases through an eligible link, at no extra cost to the reader. An affiliate relationship does not turn an untested feature into a tested result. See our Affiliate Disclosure for details.
Corrections and further context
If an article contains an unclear test claim, outdated detail, or error, please use the Contact page and identify the article and the issue. Learn more about the author on About Prompt Atlas, or browse the AI Tools hub.