Season, Code & Credit Summaries

Before you start

Do we need them?

Judged teams submit the summaries. If you use no code, omit the Code Summary.

Where do they go? Are they notebook pages?

Draft in the notebook throughout the season; submit a separate document alongside it. Confirm the event's delivery method and deadline with its organizer.

How long? Are they scored?

Season and Code are one page each, even with multiple code projects. Credit length depends on sources. Summaries are not scored.

Who writes them?

Students. Neither adults nor generative AI may write the summaries for the team.

Use your browser's Print command for a paper preparation guide. This guide is not a team's submission.

How the materials fit together

Engineering Notebook

The detailed record of engineering decisions and changes over time.

Season Summary

Orientation to the season, with notebook pointers. Judges read it first to shape the interview.

Code Summary

An accessible view of program logic.

Credit Summary

One list of outside sources currently used in robot and code.

Team Interview

Students discuss learning and teamwork with specific experiences.

The summaries support the notebook and interview; they do not replace either.

Season Summary: choose meaningful moments

Use notebook entries to select highlights of learning, skills, and robot capabilities.

Questions to discuss

• Which change in our thinking best explains where the robot is today?
• What challenge helped a member develop a new skill?
• Which failed attempt would make a later decision easier to understand?
• What capability have we actually demonstrated? What remains uncertain?
• Which notebook entry lets a reader investigate each selected highlight?

Keep it useful

Choose a few meaningful developments rather than retelling every meeting. Keep claims proportionate to the evidence. Avoid an award pitch, marketing language, or a smoother story than the records support.

Code Summary: make the logic visible

Use steps, pseudocode, a diagram, or a field map to explain execution and decisions without a code dump.

Questions to trace through your running project

• Where does execution begin? Which modules or tasks handle which responsibilities?
• What happens during autonomous operation? Which sensor readings, conditions, or timeouts change the path?
• How do controller inputs become robot actions during driver control?
• What happens when an expected input or sensor result does not arrive?
• If we have several projects or routines, how do we select among them?
• Which programming choice changed after testing, and why?
• Where does a library or outside component fit into our logic?

Try a teammate walkthrough: can someone follow the program's decisions from your explanation? Remove implementation detail that hides the logic; do not replace it with impressive-sounding terminology.

Credit Summary: make the sources visible

Engineering does not happen in isolation. Credit demonstrates engineering integrity. Crediting a source does not count against a team.

Gather existing notebook and code credits into one current list. Name sources using what you know; an adaptation narrative is not required here.

Places to look — when applicable

• Library names and their documentation; example code retained in the project.
• Tutorials, community discussions, videos, and mechanism ideas still used.
• Other teams' work, identifiable by team name or number; an event and date may help locate a source.
• Ideas from mentors or coaches that remain in the design; distinguish teaching from producing the team's work.
• Spartan Design pages whose ideas or code you used.
• Retained generative-AI ideas or outside code, subject to the same ownership checks.

Credit and ownership are related, but different

The UNDERSTAND · ADAPT · TEST · CREDIT · EXPLAIN framework helps you review ownership. A citation alone does not make someone else's work yours. Keep the engineering explanation in its relevant notebook/code context and be able to discuss it.

Libraries can be used unchanged: choose and understand them, write the integrating code, explain their role, and credit them. Official VEX-provided code starting points need no credit; community code on a forum is different. Generative AI can teach, but cannot author these judging materials. Consult the policy for the full boundaries.

Questions for a source check

• Which outside elements are still present in our competition robot or project?
• Can we identify the original source rather than only the person who forwarded it?
• Do our in-code credits and notebook references agree with this list?
• Have we confused a historical experiment with something we currently use?

This is not a mandatory list of every lesson, conversation, or abandoned idea. The categories above are memory aids, not extra official credit requirements.

SPARTAN RECOMMENDATION

Student self-review

Use these questions while students prepare and revise their own work. They are not a form to fill in or a scoring checklist.

• Can the students responsible explain every statement and diagram?
• Do the selected events and program behavior match our records and current robot?
• Can a reader find the evidence behind our season highlights?
• Does the source list reflect what we actually use?
• Have we removed unsupported claims and text written for us?
• Have we checked the official limits and the event's submission instructions?

Revisit the drafts after a meaningful change, then review together before submission. Coaches can ask questions and identify unclear explanations; students choose the content and write the revisions.