Hey teams. Judging got an update this season, and the new materials are written for you, not just for judges. The big question has not changed: can someone read your notebook and follow how your team thought?
What is different is that you now hand judges a little more than the notebook, and the rubric asks harder questions about showing your thinking. That is good news, because thinking is the part you are already doing every meeting. You just have to write it down.
Here is what is new, what stayed, and what you can start doing this week.
📝 The biggest change: you now submit three summaries
This is brand new. Nothing like it has been part of the judging process before, so nobody has a head start on you.
Along with your notebook, your team submits up to three short summaries:
1. The Season Summary (one page). Your account of what your team learned, what skills you built, and what your robot can do, with pointers to the parts of your notebook that back it up.
2. The Code Summary (one page). An overview of how your code works and how it flows, written so that someone who does not program can follow it. If your team does not have code, you skip this one.
3. The Credit Summary (one list). A list of the outside sources you used, both on the robot and in the code.
Here is the part most teams will miss
The summaries are not scored. They are not extra criteria, and no points hang on them directly.
So why do they matter? Because judges are told to read your Season Summary first, and to treat it as your team pointing at the parts of the notebook you want them to look at closely.
Think about what that means. You get to hand the judge a map of your own season before they turn a single page. If your best work is a three week fight to get an intake working, and it lives on pages 40 through 55, your Season Summary can say so, and the judge will go there knowing what they are looking at.
A weak summary wastes that. A good one makes everything else in your notebook easier to find and easier to credit.
How to use them well:
- Keep the Season Summary to a page, and spend it on your best evidence, not on adjectives about how hard you worked.
- Point to actual pages. "Our testing on the lift is on pages 22 to 31" is worth more than "we tested a lot."
- Write the Code Summary for a person who has never seen your program. If you can explain it to a teammate who does not code, you have it right.
- Start the Credit Summary now and add to it all season. Rebuilding a list of every video and every team you learned from, in February, from memory, is miserable. Adding one line the day you use something takes five seconds.
📖 Go read the rubric yourself
The updated rubric lives here, and it is genuinely readable:
Grab the Student-Friendly edition. Every line starts with "We did this..." so you can score your own notebook honestly before a judge ever sees it.
One note, straight from the top of that document: the student-friendly version is a teaching tool, not the exact sheet judges fill out. Use it to get ready, and do not treat anything it leaves out as something that stopped counting.
⭐ Four levels, and no zeros
You used to be scored in three bands. Now there are four:
Exemplary (we did this all the time and very well), Proficient (most of the time), Developing (sometimes, but we need more detail), and Beginning (rarely, or we forgot).
Here is the encouraging part: there are 16 criteria, each worth 1 to 4 points, so scores run from 16 to 64. The floor is 1, not 0. Every criterion you attempt at all earns something.
That extra level matters more than it sounds. "Developing" is an honest place to be in October. It means you are doing the thing, just not consistently yet. The gap between Developing and Proficient is almost always detail and regularity, not talent.
Where the points live:
| Section | Points |
|---|---|
| Notebook Organization | 16 |
| Define the problem | 12 |
| Develop Solutions | 16 |
| Optimize | 12 |
| Reflection and Iteration | 8 |
🆕 The genuinely new asks
These are the ones worth changing your habits for.
Write down your scoring plan, and what you gave up. The rubric wants to know what you planned to score and why, including what you decided not to chase. Every strategy trades something away. If you built for stacking and gave up on speed, say that out loud. "We chose X because Y, which means we gave up Z" is one sentence and it earns real credit.
Write tests someone else could repeat. It is no longer enough to say you tested something. Top marks go to entries where you wrote what you measured, how you measured it, and the conditions. Ask yourself: could another team pick up our notebook and run this exact test? If not, add the missing piece (how many trials, from where, with what battery, on whose field).
Record numbers and what you noticed. The rubric asks for both. Times, counts, and measurements on one side, what you saw with your eyes on the other. "7.2 seconds average over 5 runs, but it drifted left every time the battery got low" is worth far more than either half alone.
Say who was in on the decision. The strongest entries name what you decided, how you decided it, what evidence you used, and who was part of it. A quick "Maya and Dev compared the two intakes and we went with the wider one" does it.
Your code gets its own spotlight. Code documentation is now its own line item, on top of the Code Summary. Pseudocode, a flowchart, labeled screenshots, or good comments all count. If your notebook shows a beautiful robot and no explanation of how it thinks, you are leaving points on the table.
Show the loop in all three areas. The rubric asks to see you go through the design process again and again, not just on the build, but on strategy and code too. Many teams iterate hard on the robot and treat the program as something they finish once. That gap is now visible.
Reflection is its own section. Stopping to ask "how is this going?" is worth points on its own, and the top level is for teams whose reflections actually changed what they did next. Reflecting once, at the end, in a summary paragraph, is specifically called out as the weakest version.
Sign your entries. Your team number on the notebook, and every entry signed or initialed by whoever wrote it. It is a five second habit that is now its own criterion.
✅ What still matters just as much
None of this is new, but it is still where a lot of teams lose easy points.
- Page numbers, entries in order, and a table of contents that points to the exact page. A stranger should be able to find something.
- Writing all season, not all at once. Dated entries spread across the whole season. Entries that all look written the same night are the lowest level, and judges can tell.
- Saying where an idea came from, right where you used it. If you got a mechanism from a video or another team, credit it on that page, and add it to your Credit Summary. That is not a penalty. It is honesty, and it is a normal part of engineering.
- More than one idea, and more than one version. Top marks want three or more versions of a solution, with each one visibly leading to the next.
- Explaining the "why" behind decisions. Still the heart of it.
💡 What judges are actually told about you
This part might take some pressure off. Judges are trained to:
- Score the record, not the robot. A team with a simple robot can document its process exceptionally well, and a team with an impressive robot can leave that process undocumented. The notebook is what is being scored.
- Not treat longer notebooks as better. Volume does not earn points.
- Not penalize younger students for simpler language. Write like yourself. You are not supposed to sound like an engineering textbook.
- Not assume polished formatting means better engineering. Neat is nice. Neat is not the point.
- Treat paper and digital notebooks identically. Use whichever your team will actually keep up with.
Judging also runs on two ideas that are worth saying plainly: students do the work, and students can explain the work. Your coach and your mentors help you all season, and that is exactly what they are there for, but the decisions about the robot, the code, the strategy, and the notebook are yours. That is also why the notebook should sound like you wrote it, because you did.
🎯 Why this is good news for you
New requirements can feel like more homework. Read them again, though, and most of these changes hand something to students that you did not have before.
You get a say in how your notebook is read. Judges look at a lot of notebooks in a day. Before, all you could do was hope they turned to your best pages. Now the Season Summary lets you point straight at them. That is the difference between hoping your best work gets noticed and telling someone where it is.
Programmers finally get a fair shot. Code has always been the hardest work to show on paper. A judge flipping past screenshots of blocks cannot tell how much thinking went into them. Now you get a full page to explain your code in plain language, plus code documentation as its own scored criterion. If your job on the team is the program, your work is visible in two places instead of buried in the middle of the build story.
Borrowing ideas has an official home. Crediting a source used to feel a little like confessing to something. Now there is a summary whose entire purpose is listing what you learned from other people. That is how engineering actually works. Nobody builds from nothing, and saying where an idea came from marks a strong team, not a weak one.
There is a rung between "not yet" and "good." With three levels you were basically either doing a thing or you were not. "Developing" names the honest middle: you are doing it, just not every time yet. And because the lowest score is one point instead of zero, a section you are still figuring out cannot wipe you out.
Your notebook score does not depend on your budget. Judges are told plainly to score the record and not the robot. A team with a simple robot can document its season exceptionally well, and a team with an impressive robot can leave that process undocumented. Spare motors, years of experience, and a big parts bin do not help here. Writing down your thinking does. This is the most level playing field in the whole competition.
You do not have to sound like an engineer. Judges are told not to penalize younger students for simpler language, and not to treat longer notebooks as better. Write like yourself, at the length the work actually took. Padding is not a strategy.
Honesty scores now. Reflection has its own section, and the top level goes to teams whose reflections actually changed what they did next. The test that failed and taught you something is worth more on this rubric than a page of things that went right.
Quiet contributors become visible. Writing down who was part of a decision means the teammate who ran the numbers, or the one who spotted the pattern nobody else saw, gets credit by name. And because iteration now counts in strategy and code, not just the build, teammates who rarely pick up a wrench have a documented place in the team's story.
You can grade yourself before anyone else does. The student edition exists so you can sit down with your own notebook and score it honestly, line by line, weeks before an event. You never have to guess what judges are looking for.
🚀 Start at your next meeting
You do not need to redo anything. Try these six:
- Number your pages and start a table of contents if you do not have one.
- Sign and date every entry from here on.
- Start your Credit Summary today and add a line every time you borrow an idea.
- Next time you test something, write down what you measured, how, and the conditions before you run it. Then record both the numbers and what you noticed.
- Write one tradeoff sentence about your scoring plan this week.
- At the end of each meeting, write two lines: how did that go, and what are we changing next time?
Do those consistently and you will move up a level in several criteria without adding a single "notebook night" to your schedule.
💬 One last thing
Judges are not looking for a perfect team. They are looking for a real one. Setbacks, failed tests, and ideas you abandoned are worth writing down, because they are the evidence that you actually went through the process. A notebook that shows only wins reads like a story someone shaped after the fact, and the rubric says so directly.
Your notebook is the record of your team's thinking. Make it easy to follow, keep it honest, and write in it while the work is happening.
Questions about judging, or want a second pair of eyes on your notebook or your Season Summary before an event? Reach out any time at [email protected]. We are happy to help.