Distinguish a Tool Recommendation From an Actual Test

A recommendation can be based on documentation, a limited trial or a recurring personal workflow. These are different kinds of evidence. State which one you have before writing a conclusion about an AI tool.

Set up a practical example

Create three headings in your notes: Documented, Observed and Not checked. Under Documented, record inspected vendor statements and their scope. Under Observed, describe exactly what you did and what happened. Leave untested features in the third section.

For a fictional note-taking app, reading that export exists does not prove the export fits your destination. A useful test would open the actual exported file and inspect structure, missing content and formatting. Do not report that test as completed if you only saw the export button.

Verify before proceeding

Write the recommendation around the reader's task and the evidence you have. Use “The documentation states” for a documented claim and “In this trial” for an observed result. Avoid implying a broad comparison when only one candidate was tried.

Before publication, recheck volatile details directly and retain the test input where appropriate. A transparent, limited recommendation can still be useful. Its value comes from helping readers understand what remains to verify for their own workflow.