A lightweight tracking sheet is enough to document AI experiments well: one row per run, with columns for the data version, parameters, random seed, metric and a short note on what you learned. You do not need paid MLOps tools, only discipline about filling the row before and after every run. This guide gives USTM students the full sheet design, a worked illustrative example and a 14-day routine.
Why a spreadsheet beats memory and scattered notebooks
Most student AI projects fail to be reproducible for boring reasons. The notebook was edited after the good result, the seed was never saved, or the best score came from a configuration nobody can name. Three weeks later, you cannot explain your own report.
A spreadsheet fixes this because it forces a fixed vocabulary. Every run answers the same questions: what did I change, what stayed constant, what number came out, and what do I believe now? Paid platforms do this with dashboards, but the core value is the habit, and a shared Google Sheet or Excel file supports that habit at zero cost.
It is also easy to show others. A faculty guide, a teammate or an interviewer can open a sheet in seconds, which is rarely true of a folder of notebooks named final_v3_real.ipynb.
The experiment tracker: columns and what each one is for
Keep the sheet narrow enough to fill in under two minutes. The table below is the full design. Columns marked “before” are written before you run anything; columns marked “after” are written once results exist.
| Column | Filled | What goes in it | Why it matters |
|---|---|---|---|
| run_id | Before | Short sequential ID such as R001, R002 | Lets notes, plots and files refer to one run unambiguously |
| date | Before | Date and time of the run | Reconstructs the order of your thinking |
| question | Before | One sentence: what is this run testing? | Stops aimless tweaking |
| data_version | Before | File name, split ratio, cleaning step applied | Different data makes scores incomparable |
| model | Before | Algorithm or architecture name | Separates model changes from parameter changes |
| parameters | Before | Key settings, e.g. learning rate, depth, epochs, batch size | The main record of what you changed |
| seed | Before | The random seed used for splitting and training | Allows exact reruns and fair comparison |
| code_ref | Before | Notebook name plus a version label or commit note | Links the row to the code that produced it |
| metric_name | After | Accuracy, F1, RMSE, etc. | Avoids comparing unlike numbers |
| train_score | After | Score on training data | Gap with validation reveals overfitting |
| val_score | After | Score on validation data | The number you use to choose between runs |
| test_score | After | Score on the held-out test set, filled rarely | Keeps the test set clean for the final check |
| runtime | After | Approximate time taken | Helps judge cost against gain |
| notes | After | What you observed and what to try next | Turns numbers into reasoning |
| status | After | Keep, discard, or rerun | Makes the shortlist visible |
Rules that keep the sheet trustworthy
- One row per run, never overwritten. A bad run is still information. Mark it “discard” rather than deleting it.
- Change one thing at a time when you can. If you must change two, say so in the question column.
- Write the question before you run. This guards against inventing a story after seeing the score.
- Record the seed even if it is fixed. A constant seed written down is still a fact someone can check.
- Touch the test score column as rarely as possible. Choose models on validation data and use the test set for the final comparison.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
Setting up the sheet in ten minutes
- Create a new Google Sheet or Excel file and name it after the project, for example “SentimentModel_Experiments”.
- Paste the column names from the table into row 1 and freeze that row.
- Apply a data-validation dropdown to status (keep, discard, rerun) and metric_name, so spellings stay consistent.
- Turn on filters so you can sort by val_score or filter by model.
- Add a second tab called “Decisions” with three columns: date, decision, reason. This is where your final choices live.
- Add a third tab called “Data log” listing each dataset file, its source, row count and any cleaning you applied.
Two formulas are worth adding. A column for the train-validation gap (=I2-J2, adjusted to your column letters) flags overfitting at a glance. A MAX or conditional-format rule on val_score highlights your current best run.
Worked illustrative example: a small text-classification project
The rows below are invented for illustration only. They show how entries should read; they are not results from any real code run.
| run_id | question | model | parameters | seed | metric | val_score | notes |
|---|---|---|---|---|---|---|---|
| R001 | Baseline with default settings | Logistic regression + TF-IDF | max_features=5000, C=1.0 | 42 | F1 (macro) | 0.71 | Baseline. Weak on the minority class. |
| R002 | Does a larger vocabulary help? | Logistic regression + TF-IDF | max_features=20000, C=1.0 | 42 | F1 (macro) | 0.73 | Small gain. Training time rose slightly. |
| R003 | Does class weighting help the minority class? | Logistic regression + TF-IDF | max_features=20000, C=1.0, class_weight=balanced | 42 | F1 (macro) | 0.77 | Biggest gain so far. Keep this setting. |
| R004 | Is R003 stable across seeds? | Logistic regression + TF-IDF | Same as R003 | 7 | F1 (macro) | 0.75 | Score moved by 0.02 with a new split. Treat gains below this as noise. |
Notice what R004 achieves. Re-running the best configuration with a different seed shows how much of the improvement is real. Without a seed column, that check would not be possible, and the 0.77 might have been quoted in a report as if it were a stable result. The “Decisions” tab would then record something like: “Chose R003 settings; seed variation about 0.02, so differences smaller than that are not conclusive.”
Reading your sheet: turning rows into conclusions
A full sheet is only useful if you interrogate it. Ask these questions at the end of each work session:
- Which single change produced the largest movement in val_score?
- Is the gap between train and validation growing? If so, the model is memorising.
- Are my best results separated by less than the seed-to-seed variation?
- Which rows are marked “rerun” and why have I not rerun them?
- Can a stranger recreate my best row from the sheet alone?
The last question is the real test. If the answer is no, add the missing detail, usually the data version or the code reference.
Mistakes specific to experiment logging in AI projects
- Logging only the winners. This hides how many attempts it took, which makes the final number look more impressive than it is.
- Tuning on the test set. If you check test_score after every run, it is no longer a test set.
- Mixing metrics. Accuracy in one row and F1 in the next makes sorting meaningless. Use the dropdown.
- Vague notes. “Looks better” is useless later. Write what improved, by how much, and your guess about why.
- Forgetting data changes. If you re-clean the dataset, create a new data version name and log it in the Data log tab.
A 14-day plan for using the sheet inside a short project
A free two-week online internship, such as the one at CareerSwami (free offer letter, and a free completion certificate after successful completion, across 26 tracks), is short enough that undisciplined experimenting wastes most of it. The same sheet can structure the whole fortnight.
| Days | Focus | What the sheet should contain by the end |
|---|---|---|
| 1-2 | Problem, dataset, metric choice, sheet setup | Template ready, Data log filled, metric decided and written down |
| 3-4 | Baseline and sanity checks | R001-R003: a simple baseline, plus a trivial majority-class comparison |
| 5-8 | Controlled experiments, one change per run | 10-15 rows, each with a clear question and a note |
| 9-10 | Seed repeats on the top two or three configurations | Variation estimate noted in the Decisions tab |
| 11-12 | Final test evaluation of the chosen configuration | One filled test_score entry, with the row clearly marked |
| 13-14 | Write-up and clean-up | Summary table copied into the report; failed runs retained and labelled |
Aim for fewer, better-reasoned runs rather than dozens of random ones. A sheet of fifteen runs with clear questions reads better than one of eighty with empty notes.
Experiment records and the placement process for USTM students
USTM describes itself on its homepage as a NAAC A+ accredited state private university in Ri-Bhoi, Meghalaya, with 200+ programmes across 19 schools. For an AI student, the practical relevance of a tracking sheet is that it turns project work into something you can explain in a placement conversation.
The Training & Placement page says the division provides pre-placement training, recruitment drives, career guidance and internship facilitation. It also links to a Training & Placement Policy PDF and a separate T&P portal. In the policy document, an opt-out declaration mentions “Final Placement/Summer Internship”, which suggests that the division handles summer internships. However, the policy as published contains no internship duration, credit or evaluation rules. That means you should not assume that an online internship or a self-run project will be recorded for credit, or judged in any particular format.
The policy also describes a rolling placement process starting each August, with a limit of five selection-round attempts. Since interviews for AI roles often probe how you tested and compared models, a sheet that shows your reasoning is a quiet advantage. The policy text also contains a reference to another university’s student in one row, so treat it with some caution and rely on the T&P office for the current version of any rule.
Verification steps before you rely on any of this:
- Open the T&P portal linked from the Training & Placement page and check whether it lists current internship procedures.
- Email the T&P division asking in writing whether an online internship is accepted, and what proof (offer letter, certificate, report) they want.
- Ask your department or Dean’s office whether any internship or project regulation applies to your programme, and request its name or year.
- Ask your project guide whether an experiment log can be attached to your project report, and in what format.
- Confirm with the Placement Committee of your school how the current policy is applied this academic year.
Turning the sheet into portfolio and interview material
Once your project ends, the sheet becomes evidence. Export a cleaned version as a PDF or publish a read-only link, and keep three things visible: the baseline, the key experiments that moved the score, and a short honest paragraph on what did not work.
In an interview, a good answer sounds like: “My baseline scored this; the biggest gain came from handling class imbalance; I repeated the run with another seed and the difference held.” That answer is checkable because the sheet backs it. Do not quote numbers that are not in your records.
- Add a README tab explaining the columns in five lines.
- Link the sheet from your resume or GitHub project page only if it is clean and readable.
- Remove any private data, API keys or personal file paths before sharing.
Frequently Asked Questions
How many columns should an experiment tracking sheet have?
Around twelve to fifteen is practical. The essentials are run ID, question, data version, model, parameters, seed, metric, scores and notes. If filling a row takes more than two minutes, trim columns you never read.
Why is the random seed worth a dedicated column?
The seed decides your data split and often the model’s initial weights, so it changes results. Recording it lets you reproduce a run exactly and also lets you repeat a configuration with different seeds to see how much scores naturally vary.
Should I log failed or poor experiments?
Yes. Mark them “discard” with a note about why. Failed runs show what you ruled out, prevent you from repeating them, and make your final choice more credible.
How do I store parameters when there are many of them?
Put the key ones in separate columns if you vary them often, such as learning rate. Put the rest in a single text cell as a compact string like “lr=0.001; epochs=20; batch=32”. Consistent formatting matters more than the exact layout.
Can a spreadsheet really replace MLOps tools for a student project?
For small projects with a handful of people and dozens of runs, yes. Dedicated tools add automation, such as capturing parameters from code, but the core practice of asking a question, recording settings and noting conclusions works in a sheet.
How do I avoid overfitting to my validation set while using the tracker?
Limit how many near-identical configurations you try, watch the train-validation gap column, and fill the test score only for your final shortlisted model. If many runs differ by less than your seed variation, stop tuning.
How should USTM students present an experiment log in a project report?
Include a summary table of the baseline, the most informative runs and the final choice, and attach the full sheet as an appendix. Ask your guide whether the department expects a particular format, since no standard format was published in the placement policy.
Can I use this sheet during a two-week online internship project?
Yes, and the 14-day plan above shows how to pace it. Set the sheet up on the first two days, run controlled experiments in the middle, and use the final days for seed checks and write-up.
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Artificial Intelligence. The internship, the offer letter and the completion certificate are free.










