Judges do not score your FTC engineering notebook on how polished it looks. They read it to reconstruct the decisions your team made and why: which parts you tried, what failed, and how the robot in front of them came to be. A notebook that shows that reasoning clearly, in the students' own voice, will out-score a beautiful one that only lists what the robot does.

What the notebook is really for

The engineering notebook, which recent seasons frame as an engineering portfolio, is the record of your design process across the season. Several judged awards in FIRST Tech Challenge lean on it. The Think Award recognises engineering-process documentation directly, and the Inspire Award, the top honour at an event, goes to the team that is strong across the board: robot, documentation, outreach and interview. Inspire judges are not hunting for one trophy fact. They want a team that can explain its own journey, and the notebook is where that journey lives on paper before anyone walks into the room.

Decision evidence beats decoration

Every meaningful entry should answer a why. Why gears instead of a belt on the arm? Why did the intake move to the front? Show the options you weighed, the constraint that decided it (weight, time, budget or reliability), and the evidence you used, whether that was a quick test, a match observation or a rough sketch. Photos and diagrams help only when they support a decision. A page of glossy renders with no reasoning tells a judge very little. A hand sketch next to two honest sentences about a tradeoff tells them a great deal.

Show the iteration trail, including what failed

Judges trust teams that admit dead ends. If your drivetrain went through three versions, document all three: what broke, what you measured, and what you changed. A clean straight line from first idea to final robot reads as fiction, because real engineering is messy. Dated entries that show the same problem revisited over several weeks are some of the strongest evidence you can offer. Do not tidy away the failures. They are the proof that a design process actually happened.

Keep the team's voice

The notebook should sound like your students, not a coach, a parent or a consultant. Judges cross-reference what they read with what the team says in the interview, and a mismatch is easy to spot. If the writing is far more polished than the team can explain in person, it works against you. Give every student a section to own, whether that is build, programming, outreach or team management, so the voice is genuinely plural. Include the human side too: how you divided the work, how you recruited members, and what you did in your community. Inspire judges weigh all of that.

Templates help, substance wins

A consistent structure makes a notebook easy to navigate: dated entries, a table of contents, a one-page summary at the front, and clear dividers for build, software, outreach and business. Use a template to get that skeleton in place, but do not let the template write your content. Judges have seen the popular templates many times, and the teams that stand out are the ones who fill them with specific, honest detail rather than generic headings.

How judges actually read it

It helps to picture the room. A judging panel may have many notebooks and a tight schedule, so they often skim first and read closely only where something catches their attention. That is exactly why a front summary, clear headings and dated entries pay off: you are guiding a busy reader straight to your best evidence. In the interview, judges pull threads from the pages. They will ask about a particular version, or why you changed a mechanism. Treat the notebook and the interview as one story, and make sure the students who wrote the pages are ready to defend them.

A quick self-check before your next event

• Does every major design entry answer a why, not just a what?
• Can a judge find at least one clear failure-and-fix trail?
• Is there a dated record that shows the robot changing over time?
• Does the writing sound like your students rather than an adult?
• Is there a front summary that points to your strongest pages?
• Has each team member contributed a section they can talk about?
• Are photos and sketches attached to the decision they explain?

Building the documentation habit early

Teams that write strong notebooks usually built the habit long before they reached FTC. Keeping a short log of what you tried and why is a skill in itself, and it carries over from a first programmable board to a full competition robot. Younger builders can start on an entry-level platform such as the sheenbot∞ board, writing a line or two after each project about what worked and what they would change next time. At our Cape Town academy we treat that reflection as part of every build, and the July holiday workshops give newer students a low-pressure place to practise it. The tools matter far less than the habit.

The takeaway

Judges read your notebook to understand how your team thinks. Give them decision evidence over decoration, an honest iteration trail, and pages that sound like the students who will sit across the table from them. Good formatting helps judges find their way, but substance is what wins the award. For more practical guides for teams and teachers, keep an eye on our newsroom.

Notebook FAQ

Notebook or portfolio, which do we submit?

Recent FTC seasons ask for an engineering portfolio, a focused summary of your design process, while many teams still keep a fuller notebook as their working record. Check the current season's rules for the exact requirement and any page limit, and treat the portfolio as the curated view of the notebook behind it.

How often should we write entries?

Little and often beats a rewrite the night before an event. A short dated entry after each build or programming session captures the reasoning while it is fresh, and it is that running record, not a polished retrospective, that reads as genuine.

Do judges expect professional design software?

No. Hand sketches, phone photos and clear handwriting are all acceptable. Judges care that a diagram explains a decision, not which tool drew it.