The problem with good-sounding claims
Student innovation projects often end with sentences like “our filter makes water cleaner,” “the app helps students focus,” or “the design is more efficient.” These sound reasonable, and they may even be true. The trouble is that nobody can check them. Cleaner by what measure? Focus compared to what? Efficient under which conditions? A reviewer reading such a claim has only two options: trust the team, or ignore the claim. Neither is verification.
A verifiable claim is one that tells the reader exactly what was measured, what it was compared with, under what conditions, and how they could repeat the check. Writing that kind of claim is a learnable skill, and it is worth practising before the experiment, not after.
Edit 1: Name the quantity
Replace the adjective with something you can count or measure. For the filter, “cleaner” might become “lower turbidity, read with the class turbidity tube” or “fewer visible particles per sample under the microscope at the same magnification.” Choose a quantity your team can actually measure with the equipment you have. A claim about bacterial counts is not verifiable if you cannot culture bacteria safely.
Edit 2: Name the comparison
Every improvement is relative to something. Say what. The filtered sample compared with the unfiltered sample from the same source. The new design compared with the previous prototype. Students using the app compared with the same students on days they did not use it. Without a comparison, a number is just a number. With one, it becomes a difference someone can examine.
Edit 3: Name the condition
State the conditions under which the claim holds. Water from the school pond after rain, three samples, poured at the same rate. A fan design tested at one speed setting in a closed room. An attention task done in the same period of the school day. Conditions are not excuses; they are the boundary of what you tested. Claims without conditions quietly expand to cover situations you never tried.
Edit 4: Name the test someone could repeat
Finally, write how another student could repeat the check. List the equipment, the steps, the number of trials, and what result would support the claim. If the description is too long, put it in the verification log and refer to it. The test should be decided before you run it. A pass condition written after seeing the data is easy to bend without noticing.
Before and after
Before: “Our filter makes water cleaner.” After: “Across three trials with pond water collected after rain, water passed through our sand-and-charcoal filter read lower on the class turbidity tube than unfiltered water from the same jar; method and readings are in the verification log.” The second sentence is longer, but every part of it can be checked, challenged, or repeated. It also makes no claim about drinking safety, which the team did not test.
That last point matters. Writing a verifiable claim often shows you what you are not entitled to say. Drinkable, safe, or better than commercial filters would each need different tests and expertise. Leaving them out is not weakness. It is accuracy.
How mentors use verifiable claims
When claims are written this way, mentor feedback becomes specific. A mentor can ask whether three trials are enough, whether the turbidity tube is precise enough, or whether the comparison is fair. Those are the questions that improve a project. With vague claims, feedback tends to stay at the level of encouragement, which feels kind but teaches less.
A second example: an app claim
Before: “Our study app helps students focus.” A first edit names the quantity: the number of correct answers on a short arithmetic task, or minutes spent on the task before switching away. A second edit names the comparison: the same volunteers on a day with the app and a day without it, in a different order for different students. A third edit names the condition: a ten-minute task in the same lesson period, in the same room. A fourth edit names the test: the task sheet, the timing method, the number of volunteers, and what difference would count as support. After: “Among twelve classmates, average correct answers on a ten-minute arithmetic task were higher on the app day than on the no-app day; order was alternated, and the task sheets and timing method are in the log.”
Even this version is limited. Twelve volunteers who know the team are not a random sample, and a single task is not focus in general. The point is that the limits are now visible, which means a reviewer can discuss them instead of guessing.
Words to watch
Some words almost always signal an unverifiable claim: better, improved, efficient, smart, effective, revolutionary, and proven. They are not banned, but each one should trigger the four edits. If a sentence still needs the word after the edits, keep it and attach the measurement. If the measurement makes the word unnecessary, drop the word. Reviewers tend to trust the measurement more than the adjective.
Doing it as a team
In a team, have each member rewrite the claim separately before comparing versions. Differences usually reveal disagreement about what was actually measured. Settle that disagreement before the experiment, not after the results arrive.
A short practice routine
Take the main claim from your current project and write it on a card. Apply the four edits one at a time. Ask a teammate to read the final version and describe exactly how they would check it. If their description differs from yours, the claim needs another edit. For related reading, see how a hypothesis becomes a protocol, building a verification log, and why mentors challenge claims.