A folder full of screenshots can feel like research until someone asks which claim each screenshot supports. Build the note around a question instead. A useful record lets another person find the same source, understand what you observed and see where your interpretation stops. It should remain readable even when the product changes its name or the original dashboard gains a new layout.
Make the question small enough to answer
Replace “Is this tool good?” with a question such as “Does the documented export include the fields needed for this sample workflow?” The narrower question tells you what evidence to look for. It also makes room for a limited answer. A tool can satisfy that export requirement without being the best choice for every other task.
Write the desired output and the conditions that matter: platform, model, version, plan or network. For a fictional tool comparison, specify that you are reviewing a desktop CSV export for ten sample rows. Without that scope, a statement about a premium mobile feature might accidentally become evidence for a free desktop workflow.
Keep the claim beside its source
Use fields for claim, source URL, publisher, publication or update date, checked date and relevant scope. The checked date records when you looked; it is not necessarily when the source was written. If no publication date is available, record that fact rather than substituting today’s date as though it belonged to the document.
Prefer an original source for a product specification, then distinguish that published statement from your own observation. “The manual says the export contains these fields” and “I exported the sample and inspected these fields” are different kinds of evidence. Do not mark the second as completed when you have only done the first.
Separate observation from inference
Create an interpretation field after the evidence field. Suppose a document describes an external data dependency. Your observation may concern the stated source and update method. A broader conclusion about reliability requires more evidence. Ethereum’s oracle documentation is a useful example of why the origin and delivery of external information deserve their own questions.
Avoid compressing uncertainty into a numerical confidence score unless you have a defensible method for that score. “Not established by the available documentation” is often more informative. It distinguishes missing evidence from a negative finding and prevents an incomplete page from becoming proof that a feature does not exist.
Reconcile differences before choosing a winner
When two sources appear to disagree, compare their dates and scope. They may describe different plans, models, software versions or network support. Write down the specific difference and the source that could resolve it. Do not choose the statement that best fits a preferred conclusion simply because it is easier to quote.
Finish with a dated decision note: what the evidence supports, what it does not establish and what would trigger a review. A product rename, changed export format or revised plan limit might be such a trigger. Keep source links attached to individual claims instead of hiding them in an undifferentiated list. The result is a small research record that can be challenged and updated, rather than a polished paragraph whose supporting trail has already disappeared.
Crypto Research Evidence Desk helps you organise your own notes in this browser. Keep credentials and recovery material out of your project.