When your team is judged at an event, you submit three short summaries alongside your Engineering Notebook: a Season Summary, a Code Summary, and a Credit Summary. This article covers what goes in each one, how to submit them, and what judges do with them.
It is written for students and coaches on competing teams.
Definitions of the terms used here are maintained in the central glossary.
For how judges review your notebook, see Judging Engineering Notebooks. For what happens in the interview your Season Summary sets up, see Judging Team Interviews.
Note: The summaries come from the Student-Centered Policy, and this article summarizes what that policy says about them. Read the policy itself for the full context on why the summaries exist and how they fit with everything else that makes your work your own. It is written for students as much as for coaches, and the more familiar your team is with it, the easier judging becomes.
Why Summaries?
A judge has only a short time with each team, and an Engineering Notebook can run to a hundred pages or more. The summaries let you point judges to what matters most, in your own words, before the interview starts.
The summaries are not scored. They are not a fourth thing to be judged on, and a short summary does not cost your team points. The summaries' job is to make the judging that follows better, so write them to be useful rather than impressive.
Season Summary
The Season Summary is your team's one-page overview of its season: what you learned, the skills your members built, and what your robot can do. For each highlight, point to the notebook entries behind it so a judge can go straight to the detail.
Judges read this one first, and it sets the agenda for your interview. Because it is your own account of your season, it also works well as a handout for anyone else who asks about your team.
Code Summary
The Code Summary is a one-page overview of how your code works: what it does, in what order, and how it decides between paths. Its job is to let someone who does not read code follow your logic without reading your code line by line.
You choose how to show it. Pseudocode, a diagram, a labeled field map, or a plain list of steps all work. What matters is not the form, but that someone outside your team can follow what your code does and why.
Cover the code your team runs, whether autonomous, driver control, or a Coding Skills project. If you run several projects, this is still one page: show how the projects fit together and how your team chooses among them, rather than walking through each one in turn.
If your team uses no code, you do not submit a Code Summary.
Credit Summary
Whenever your team builds on an outside source, such as a design, a mechanism, or code, you credit where it came from. A credit names the source. It does not need to record what you did with it. List what you know: a video title, an event and date, a team name and number, a website. Using outside sources is expected, and crediting them is not an admission of anything. The Student-Centered Policy explains how an outside idea becomes your team's own.
Those credits already appear where they occur in your Engineering Notebook and inside your code. The Credit Summary gathers them in one place, like the Works Cited page of a research paper, so a judge reads one list instead of searching for them.
List the outside ideas currently used on your robot and the outside code currently in your project. This is a picture of what you are competing with, not a record of everything you tried.
Writing and Submitting Your Summaries
The summaries are students' work. They are held to the same standard as your notebook and your code. No adult and no generative AI tool can write them for your team.
Draft them in your notebook. We recommend writing them there as the season goes, rather than assembling them the night before an event.
Submit them as a separate document at the event. They are handed in alongside the notebook, not buried inside it.
Keep the Season Summary and Code Summary to one page each. The Credit Summary is a list, so its length depends on how many sources you used.
How Judges Use Your Summaries
Knowing what judges do with each summary helps you write it well.
Judges read the Season Summary first and use it to shape the interview, following its pointers into your notebook.
They use the Code Summary to understand what your code does and why without reading the project line by line.
The Credit Summary is used as a single list of the outside sources you are currently using, instead of searching your notebook and code for them.
Judges do not score the summaries. They use them to spend the time they have on the parts of your season you most want them to see.
For what each award recognizes, see Award Descriptions. For eligibility rules and the full award structure, see Awards and Recognition Structure.
Everything here comes from the Student-Centered Policy. Reading it start to finish is the best preparation your team can do for the season, from judging to interviews to robot design and more.