Start with the decision behind the claim

Suppose a supplier says an AI assistant reduces support work. Before buying it, you need to know what work was studied, what counted as a correct answer, who reviewed it and whether the time calculation includes repair. A convincing demonstration can leave all four questions unanswered.

Your first result is a one-page evidence worksheet with a defensible decision: test, hold or reject. It does not require a model, code or a paid research service. Allow about 20 minutes and use a spreadsheet or text editor.

1. Copy the complete worksheet

Download the evidence worksheet. Extract the ZIP and open decision-worksheet.csv. README.md supplies the procedure and limits. The final column contains a fictional worked example, clearly separated from evidence you will collect.

Make a copy. Choose one claim and one decision your team actually faces. Save the original public source URL and publication date. Identify whether you read a complete study, selected passages, an abstract or an announcement. Those forms provide different amounts of evidence.

2. Separate the result from its interpretation

Record the studied population, tasks, comparison and outcome. An observed improvement for experienced programmers on a selected task does not establish the same improvement for new programmers, another codebase or customer support. Explain the transfer you would have to test.

Use the evidence-type row to distinguish an observed result, a simulation, an announcement and your own inference. Preserve NOT_MEASURED when time, quality or cost evidence is missing. A filled spreadsheet is not proof that a claim is supported.

3. Work through the negative case

The supplied fictional example contains a demonstration and no matched labor or quality records. Its correct conclusion is to hold the savings claim and design a small comparison. It cannot justify claiming a measured productivity improvement.

Write what would change that decision: the same task mix on both routes, declared acceptance criteria, complete review and repair time, failed attempts and total relevant costs. Choose the reviewer and stop condition before collecting outcomes. Keep a simple manual method as the baseline, meaning the approach you compare the proposed change against.

4. Make the next step small and checkable

Begin with approved fictional inputs when a proposed integration handles sensitive information or consequential actions. A useful test might ask whether a support draft cites a current policy and declines an unsupported request. It need not grant the assistant authority to send messages.

Avoid turning a small test into a general guarantee. Record its sample, conditions and unresolved questions. Security frameworks, experiments and scientific results have different scopes; the article should explain which kind of evidence it is examining.

You are finished when another reader can locate the original source, identify its population and explain your test-or-hold decision without undocumented background knowledge. If you cannot name the comparison or useful output, narrow the question before collecting more links.

Choose an investigation

Begin with the coding-assistant productivity investigation below for an example of connecting research to a practical evaluation. Security, governance, science and business economics remain separate beats. The journal should rotate among them according to current reader problems and evidence.

The public byline, Publish Haven Editorial Team, describes an AI research, writing and review workflow. Documented execution and editorial checks are useful evidence of the work performed. They do not constitute academic peer review or independent specialist certification.