QKV Institute keeps this page on qkv.org because many student teams treat the verification log as a scrapbook of success and then invent a glamorous next demo. That habit breaks the QKV sequence. Question. Knowledge. Verification. is a chain: the log records what the last test could and could not support, and the next experiment must shrink to that boundary. STEM innovation training here means the student can point to a dated anomaly and explain why the new protocol exists.
Read this page if you already have a log—or if a mentor has asked you to stop polishing and start reading what you wrote. Project verification is slower than a highlight reel. Robotics and AI student research are welcome when the next trial is sized to the instrument, the safety envelope, and the open node on the knowledge map. If the next experiment cannot lose, it is still decoration.
What a verification log is for
A verification log is not a diary of feelings about the project. It is a time-stamped record of setup, result, anomaly, and the decision taken after each trial. When a reviewer opens it, they should be able to reconstruct whether the pass line and fail line were written before the run, and whether failed runs were kept. Without that, “we improved the model” is a story, not a claim.
Students working from a log should treat every row as a possible fork. Some forks say “repeat under tighter control.” Some say “the question is still decorative.” Some say “the map is empty where the claim is loudest.” The next experiment is the fork you can defend in one sentence.
- Keep time, setup, result, anomaly, and next decision on the same page as the trial.
- Refuse to delete a run that missed the pass line before review.
- Separate instrument noise from a genuine falsifier.
- Write the next protocol only after the current test is recorded.
Read the log before you redesign
Teams often skip reading. They open CAD, change a sensor, or regenerate a chart because the last demo felt incomplete. QKV asks for the opposite order. Sit with the log. Mark every place where the result surprised the claim. Circle every place where the setup drifted from the protocol. Underline adjectives that outran the measurement.
Then ask three review questions aloud. What result would force a rewrite of the claim? Where is the knowledge map still empty? What can this evidence not support? If the only answer is a better video, the verification has not started. Mentors should refuse a redesign session until those answers exist as short notes beside the log.
From anomaly to a narrower claim
Anomalies are the curriculum. A motor that overshoots once, a classifier that fails on one lighting condition, a temperature reading that drifts after ten minutes—each is a candidate for a smaller claim. The honest move is not to hide the anomaly and keep the original slogan. The honest move is to rewrite the claim so a later test could show it false.
Example shape, without inventing results: “Under this bench setup and this load, the controller stays within X of the target for Y minutes” is smaller than “the robot is stable.” “On this labeled subset, the model’s miss rate is below Z when lighting is controlled” is smaller than “the AI works.” Size the claim to the log, then size the experiment to the claim.
- Rewrite the claim as a sentence a skeptical reviewer could embarrass.
- Name the population, time window, and instrument that bound the claim.
- Move unsupported adjectives off the title slide and into a limits paragraph.
Write the next protocol before touching the bench
Protocols before trials remains the QKV rule. The next experiment needs a pass line, a fail line, a stop condition for safety, and a note about what will stay constant from the previous setup. If the team cannot write those lines, they are not ready for another run. They are ready for a knowledge-map session.
The protocol should also say how the log will be updated: who writes, when, and where raw notes live. Memory after a demo is a poor instrument. Keep the log close to the bench or the console so the next decision is dated, not improvised for a showcase.
Keep failed runs in the chain
Failed runs are how a later mentor trusts a later success. Deleting them turns verification into theatre. When you design the next experiment, list which previous failures remain visible and how the new test addresses one of them. Addressing “all failures at once” is usually another decorative question. Pick one binding constraint.
Families and school reviewers can ask a simple question without becoming specialists: which failed trial is still in the log, and how does the new protocol respond to it? If the answer is only a polished success clip, QKV will slow the demo until the pack exists.
Maps, limits, and the next object
After reading the log, the honest next object is often not a bigger apparatus. It may be an updated knowledge map with empty nodes, a limits statement that names what the last test cannot show, or a narrower question sheet. Celebration is optional. A limit statement is not. Robotics evidence and AI checks fail the same way when adjectives outrun instruments.
Use the map to decide what the next experiment is allowed to ignore. If a node is empty and the claim depends on it, the next trial should illuminate that node or the claim should shrink. Filling every cell for a poster is not a knowledge map.
A worked next-experiment scene
Imagine a reviewer who opens the raw notes before watching any demo. They find three timed trials, one miss, one drift note, and a claim that still sounds global. The student rewrites the claim to the bench conditions, writes a new pass and fail line for a single variable, and schedules one more trial. That sequence is STEM innovation training at QKV: not a larger story, a harder local test.
The pack for that scene includes the updated question sheet, the knowledge map with the empty node marked, the protocol with pass and fail lines, and the log page reserved for the coming run. It does not include a habit of starting with a robot or model because it photographs well.
What this page refuses
QKV will not treat polish as a substitute for an evidence pack. Mentors must refuse calling a single successful run verification. They may not run the trial for the student, beautify the data, or delete the run that missed the pass line. Ownership includes the ugly pages of the log.
This page also refuses inventing customers, prices, awards, or testimonials. The proof of method is inspectability: a stranger can follow question, map, and test without trusting a speech. If a claim cannot lose, QKV is not yet interested in how impressive the apparatus looks.
Practical next step
Open the latest log. Mark anomalies. Rewrite one claim so it can fail. Write pass and fail lines for one next trial. Update the knowledge map. Then schedule the experiment. Return to the insights index or enter a curriculum track if you need a longer sequence on questions, maps, and tests.
- Name the next protocol only after the current test is recorded.
- Keep raw notes instead of rewriting memory after the result.
- Ask: what can this evidence not support?
- Bring the claim and the missing test to review, not only the demo video.