Plan one comparison
Before you touch the kart, write down a question — something narrow, like "Does this rear axle setting change how the kart rotates through the fast right-hander at the end of the lap?" Not "will this make the kart faster." A narrow question is the difference between a test you can read afterward and an afternoon of changes that leaves you no wiser than when you started.
A controlled comparison is simple in concept: one documented variable, tested at two settings, against a baseline you've defined ahead of time. You decide in advance what response you're watching for — a lap-time trend, how the kart behaves in one corner, driver feedback on one phase of the corner — and you hold other relevant observed conditions constant where you can and log those you cannot control.
Decide these things before you go to the track. If you wait until you're back in the paddock to work out what you were even testing, your memory will have already blended two laps into one.
This is a Motorsigma editorial workflow, built from general experimental-design guidance, not a validated kart-specific protocol. What it gives you is discipline — a way to keep one documented variable separate from everything else that happened that day.
And here's the limit worth holding onto from the start: even a clean, well-recorded comparison only tells you about the setting you tested, against the baseline you tested it against, on that kart, that day. It's local to the other recorded settings. Change the tyre compound, the track, or another setup element later, and you're in new territory — untested interactions may remain, because that combination hasn't been tested yet. One good comparison gives you a data point, useful for planning the next one.
Copy the worksheet
Fill this in before you go to the track, then work through it in order as the session runs. Keep every entry short and factual.
TEST QUESTION:
(One sentence. What are you trying to find out?)
SINGLE VARIABLE AND COMPARED SETTINGS:
Variable:
Setting A (baseline):
Setting B (change):
BASELINE CONDITION:
(What "normal" looks like before you change anything — kart state, driver, track as found.)
RUN ORDER:
(List the sequence you plan to run, e.g. A→B→A or A→B→B→A. Note it here before you start.)
CONDITIONS HELD CONSTANT OR LOGGED:
(Anything you're deliberately keeping the same, and anything you can't control but should record.)
TIMING OBSERVATIONS:
Run 1:
Run 2:
Run 3:
Run 4:
DRIVER-FEEDBACK OBSERVATIONS:
Run 1:
Run 2:
Run 3:
Run 4:
(Add or leave rows blank to match your chosen run order — the four slots above are a default, not a fixed length.)
ANOMALIES:
(Anything unusual — a moment, a noise, a change in the kart's behavior that isn't the thing you're testing.)
Stop the comparison if an anomaly suggests an unsafe condition, a mechanical concern, or a conflict with the applicable rules or instructions. Record it and treat the run as invalid rather than pushing on.
If a run slot goes unused, mark it explicitly — for example, "not run — comparison stopped, see anomaly" — rather than leaving it blank.
OUTCOME GRADE (circle one): CLEAR / TENTATIVE / INCONCLUSIVE / INVALID
These four grades are Motorsigma editorial labels, not statistical thresholds. They exist to help you describe what you found honestly, and to guide the next local decision — not to certify a result.
Use four outcome grades
Clear means the observations line up well enough, across the runs you recorded, to guide your next comparison on this kart, at this track, with these other settings unchanged. It doesn't prove anything beyond that.
Tentative means you saw something that looks like a pattern, but real uncertainty remains — maybe one run was odd, maybe conditions shifted, maybe you only had time for a short comparison. Remember it when you plan the next test; don't build a strategy on it yet.
Inconclusive means the observations don't separate the setting you changed from everything else that happened that day. The timing moved, but so did the track state, or the driver's feedback contradicted the clock. You can't tell what caused what.
Invalid means something broke the comparison outright: an anomaly, an unsafe condition, a mechanical concern, or a change you didn't intend. Whatever the lap times say, the test doesn't answer your question.
Choose the run order
Before you commit track time, decide how you'll sequence the runs. There are three editorial planning options worth knowing, and no sufficient kart-specific run count is established for any of them, so you're making a practical judgment about the time and consistency you actually have.
| Option | Likely use | Advantages | Trade-offs and operating burden | Poor-fit conditions |
|---|---|---|---|---|
| Baseline versus change | A short session with one safe, reversible change | Least running required; factor and response stay simple to describe | No closing baseline, so you can't check whether conditions drifted; one comparison says little about whether the pattern recurs | Conditions changing quickly; an anomaly on the opening run; you need to see the pattern repeat |
| Baseline/change/baseline | A session with time to restore the baseline and a real concern that conditions may shift | Adds a closing check that can reveal possible drift (conditions quietly changing over the session) | Takes another run and a precise reset; the closing baseline happens later, under whatever conditions exist by then | Not enough time to reset and recheck the baseline; the setting can't be reversed safely or consistently; a mechanical anomaly already occurred |
| Repeated comparisons | A longer session where you can restore the same setup reliably | Can show whether an observed pattern recurs; gives some sense of ordinary run-to-run variation | More track time, more resets, longer exposure to changing conditions | Kart state can't be reproduced consistently; observations are shifting too fast to compare; treating repetition alone as proof |
No design suits every situation, and this table isn't a ranking — it's a way to match the option to the time and conditions you have that day.
Baseline versus change
This is the shortest route: run the baseline, then run the change. Done. It suits a short, apparently stable session, where you can make one safe and reversible change and you're willing to accept a limited answer.
Picture a driver with one practice hour before the track closes. There's time for the baseline run and the changed run, but not enough left to reset and run the baseline a second time. That's fine — you write the worksheet in advance, log the run order as it happens, and grade whatever pattern you see as tentative, because there's no closing check for drift. The comparison stays useful as long as that missing check stays visible in how you describe the result.
This option becomes a poor fit when conditions are changing fast, when the opening run already has a relevant anomaly, or when you need evidence that a pattern recurs rather than just showed up once.
Baseline/change/baseline
This is a practical bracketed sequence, motivated by the general principle of running start-and-end checks under standard conditions to see whether a process has drifted. (A bracketed sequence just means running a check before and after the change, so the two ends can be compared.) Here, that means: run the baseline, run the change, then reset and run it again. If the closing baseline looks like the opening one, that's some reassurance the ground didn't shift under you. If it doesn't, you've learned something important before you over-read the changed run.
It checks for possible drift. It does not prove causation — matching baselines are a stability check, not evidence that the setting you changed caused whatever you observed. (A stability check here just means comparing the repeated baseline to itself — it doesn't show what caused any change you saw.)
Consider a session where the weather looks unsettled, or the track is visibly rubbering in as the day goes on. You set aside time to put the opening setup back and run it again at the end. If the closing baseline differs from the opening one in what you recorded, factor that difference into your interpretation alongside the changed setting. Downgrade or defer the conclusion rather than treating the changed run as clean evidence.
This option is a poor fit when there isn't enough time to reset and confirm the baseline, when the setting can't be reversed safely or consistently, or when a mechanical anomaly has already compromised the sequence.
Repeated comparisons
When a session runs long and you can restore the same setup combinations reliably, repeating the same comparison more than once can show whether what you saw the first time shows up again. It can also give you a rough sense of how much the timing or feedback naturally varies from run to run, independent of the setting.
The cost is track time: more resets, more chances for conditions to change underneath you, and — worth saying plainly — no sufficient kart-specific repetition count or confidence threshold is established here. You're making a judgment call.
This option is a poor fit when the kart's state can't be reproduced consistently, when weather, track, or mechanical conditions are shifting too fast for a coherent comparison, or when repetition alone starts getting treated as proof rather than one more piece of information.
Log conditions, then run
Once you've picked a design, the worksheet's condition-log fields do most of the remaining prep. Before you run anything physical, check that the plan is one you can carry out safely.
Separate three kinds of information
Keep three categories distinct as you log: the factor you changed, the response you're watching, and everything else. That "everything else" — the weather and track state, the tyres and mechanical condition, traffic and driver feedback, timing and run order — are conditions to record, not conclusions. Write them down because they're potential influences on what you observe. Their direction and importance are not established here; nothing in this method tells you that traffic slowed a given lap or that cooler track temperature explains a feedback change. It might have. It might not. The log lets you go back and ask the question later — it doesn't answer it for you.
Stay within limits
Before you make the physical change, stay within your current event organizer and governing authority requirements, the applicable class rules, and the relevant chassis, engine, tyre, and component instructions. Make only a change that's reversible and that you can complete safely. If it isn't — if you're not confident the change is safe or reversible, or if it touches something outside your competence — involve a qualified mechanic before you run anything.
Stop on an anomaly
Say a mechanic prepping the kart between runs notices something that shouldn't be there — an unusual noise, play in a component that wasn't there before, anything that reads as a mechanical concern rather than normal wear. The right move, whatever design you planned, is to stop the comparison. Record the affected run and the anomaly, mark that stretch of the worksheet invalid, and leave the question of whether the kart can keep running to the applicable instructions and, if it's beyond what you can assess yourself, to a qualified mechanic. A more careful test design doesn't rescue evidence gathered on a kart you can't trust.
Read only this test
With the runs recorded, resist the pull to make the result mean more than it does. Read what's on the page.
Check the record
Before you grade anything, go through the worksheet in time order. Check the transcription — did you write the right numbers against the right runs? Look for anomalous laps that don't fit the pattern of the rest, and for anything that reads as an obvious problem: a run where the driver was clearly off, a lap interrupted by traffic. If you ran a closing baseline and it has moved from the opening one, don't quietly correct for it with a formula you invented on the spot. Keep the shift — and the run order and conditions around it — in view. When the baseline has moved, downgrade the outcome grade or defer judgment rather than explaining the movement away.
Keep the conclusion local
Answer only the question you wrote at the start of the session. If you asked about rotation through one corner, don't let the worksheet answer a question about overall pace. That's a different question, and this test wasn't built for it.
One documented variable, cleanly tested against a baseline, may point to a possible local setup signal on this kart, at this track, with these other settings. That's real, and worth acting on for your next comparison. It is not proof that the setting caused the result, and it doesn't tell you how the kart behaves under settings or conditions you didn't test — untested interactions may remain, and unmeasured influences can't be ruled out from one comparison. The conclusion stays local to the other recorded settings until you test again.
Where to go next
This guide lives in the kart setup hub, alongside the broader method it draws on. For the pieces around it, see how to build a track baseline, how to compare karting sessions fairly, and what to record after every session. From there, the wider karting section covers everything from getting started to race weekends.
Your next step: write one bounded test question and the single variable you intend to compare in the worksheet before your session.
