Chapter 2: Reviewing Engineering Notebooks
Lesson 1: What Teams Submit
Learning Objectives:
- Identify what an Engineering Notebook is and what it documents.
- Describe the purpose of the Season, Code, and Credit Summaries and how to use them.
An Engineering Notebook is one of the more interesting things you will read at an event. For most teams, judges are among the first people outside the team to read their notebook. Knowing what teams hand in and what each piece is for will help you prepare for evaluating the notebook in the following lesson.
The Engineering Notebook
An Engineering Notebook is a team's record of its own season: what the team tried, what it decided, what it changed, and what it learned. Students keep it in their own words, and any student who wrote part of it can talk you through it. It is part of the competition, like the robot and the code.
A notebook is a working document. Teams keep it as the season happens rather than assembling it for an event, so expect it to look like thinking in progress. The thinking is what you are reading for: the problem a team saw, the ideas it weighed, what happened when it tried them. That comes through in a well-used spiral notebook with pencil sketches as clearly as in a professionally printed binder. Notebooks may be paper or digital, and both are read against the same criteria. Every team at an event submits in the same format, which the Event Partner sets in advance.
The standard for whose work a notebook represents comes from the Student-Centered Policy.
What You Will Find Inside
Teams record their seasons in whatever way works for them, so no two notebooks look alike. Across most of them, you will find:
- Team goals for the season and roles for team members
- Brainstorming and design ideas
- Sketches, photos, and design iterations
- Testing, results, and improvements
- Coding changes and decisions
- Resource management and project planning
- Competition observations and lessons learned
You will also find things that did not work: a mechanism that jammed, a test with a confusing result, a strategy the team dropped halfway through the season. These entries are some of the best material a notebook can offer, because they show a team learning in real time. Every team runs into problems over a season. When a notebook shows only finished results, you are seeing less of the team's process, not necessarily a smoother season.
Some teams also include appendices with research, source documents, or code iterations. Read them if you are curious — they are not required reading for judging.
Where Ideas Came From
Good ideas travel. Teams build on mechanisms they saw on other robots, tricks from reveal videos, suggestions from mentors, published code, and generative AI tools. Teams are asked to credit those sources where they appear, and that credit is what you want to see. It shows the team knows where its ideas started, which is the beginning of making them their own. Following a credited idea into a team's own version of it is one of the more satisfying things to trace through a notebook.
The Three Summaries
Alongside the notebook, teams hand in up to three short summaries. Think of them as the team's guided tour — students telling you where to look and what they are proudest of. They are not scored, and they are not an additional thing to evaluate. A short summary just means the team kept it brief.
| Summary Types | What It Is | How You Use It |
|---|---|---|
| Season Summary | The team's one-page account of its season: what students learned, the skills they built, and what the robot can do, with pointers to the notebook entries behind each highlight. | Start here. It tells you what the team most wants you to see in their Engineering Notebook, and it opens the conversation you will have in the interview. |
| Code Summary | A one-page overview of how the team's code works: what it does, in what order, and how the logic flows throughout. This is written for a reader who does not read code. | Read it to follow the team's logic without working through the project line by line. Teams that use no code do not submit one. |
| Credit Summary | A single list of the outside sources currently used on the robot and in the code, gathered from where they appear in the notebook and the code. | Use it like a Works Cited page when you want to see where a team's ideas came from. |
A notebook can run a hundred pages or more, and your time with each notebook is short. The summaries exist so that time lands on the parts of the season the team cares most about.