📝 Notebook · Judging · Awards

Engineering Notebook &
Design Process

πŸ—ΊοΈ Flowchart β€” What belongs in a notebook entry

Every entry has the same shape: date, author, sprint, what happened, what next. This is the entry workflow students should internalize.

flowchart TD
    Start([Notebook entry time]) --> Header[Header:
Date + Author + Sprint number] Header --> Context[Context:
What problem were we solving?] Context --> What[What happened:
Decisions made, things built,
experiments run] What --> Data[Evidence:
Sketches, photos,
measurements, data] Data --> Reflect[Reflection:
What worked? What didn't?] Reflect --> Next[Next steps:
What's the next action?] Next --> Sign([Sign + initial
entry complete]) style Start fill:#1e293b,stroke:#22d3ee,stroke-width:2px,color:#e2e8f0 style Sign fill:#1e293b,stroke:#22c55e,stroke-width:2px,color:#e2e8f0

The engineering notebook is not a journal — it is evidence of disciplined thinking. Testing data, decision matrices, and STEM connections are what separate a Design Award winner from a team that just competed hard. This guide teaches you how to build that evidence all season long.

Spartan coaching: These examples and prompts teach a method; they are not entries to copy or a required notebook format. Record your team's actual work, including uncertainty and failed tests, in students' own words. Never invent earlier decisions or results. See our student-centered policy guidance and current notebook rubric reference. The official GRSF rubric controls if this guide conflicts with it.

// Section 01
The Engineering Design Process
Your notebook records the engineering your team actually performed: what you considered, built, measured, changed, and learned. Use the six teaching steps below flexibly; they are not six official scoring rows.
📝
!=
Not a Journal
Notebook = evidence of disciplined thinking, not daily diary.
📊
EDP
Design Process
Document the reasoning behind design and iteration.
🎯
Quality
Beats Length
Judges score content + clarity, not page count.
📚
6
Sections
EDP, testing, decision matrix, docs, STEM, interview.

The Six EDP Steps — Click Each to Explore

Spartan coaching: These examples and prompts teach a method; they are not entries to copy or a required notebook format. Record your team's actual work, including uncertainty and failed tests, in students' own words. Never invent earlier decisions or results. See our student-centered policy guidance and current notebook rubric reference. The official GRSF rubric controls if this guide conflicts with it.

📝
New to the notebook? Read Getting Started with the Engineering Notebook first. That guide covers entry structure, common mistakes, and your first three entries. Come back here for the deep dive on testing protocols and decision matrices.
🔎
1. Define the Problem
→
🔎
2. Research
→
💡
3. Brainstorm Solutions
→
✅
4. Select Best Solution
→
🔧
5. Build & Program
→
🔬
6. Test & Iterate
📝
Iteration follows evidence. Revisit the problem, alternatives, or implementation when results call for it. Record the actual sequence and why it changed; there is no prescribed number of complete cycles for an award.

How These Practices Map to the Current Rubric

The current rubric has 16 criteria scored on four levels, totaling 64 points. See our rubric reference for the scoring structure. This table maps coaching practices to evidence areas; it does not assign scores.

Current rubric areaSpartan coaching: evidence to capture
Notebook Organization β€” 16Date and attribute entries, number pages, maintain a useful TOC, and credit sources where used. Organize chronologically or by section while preserving the sequence of work.
Define β€” 12Explain the problem, criteria and constraints, strategy, research, and distinct ideas your team considered. Keep sketches and comparisons.
Develop Solutions β€” 16Connect prototypes, repeatable test methods, qualitative observations, measurements, and decisions. A weighted matrix can help explain a choice; it is a coaching tool, not a mandatory format.
Optimize β€” 12Annotate mechanism and code documentation. Link each change to results and design intent.
Reflection & Iteration β€” 8Explain lessons and show how they influenced subsequent work, including failures and decisions to change direction.

🔬 Check for Understanding

When your team uses a weighted decision matrix, which record best explains how it informed your choice?
Choose a design and briefly say you liked it best
List the pros and cons of each option in a paragraph
A decision matrix with weighted criteria and a written conclusion explaining the choice
Build all three options and pick whichever works best
// Section 02
Testing Protocol
Make tests repeatable: state the procedure, conditions, comparison target, observations, measurements, and conclusions. Document failures as carefully as successes.
πŸ“Œ Quick Take Testing data is the #1 missed notebook section. Build, test, document the result, change one thing, retest. Combine measurements (cycle time, error rate, range) with observations and explain what the evidence supports.
💡
The three-part testing rule: every test entry must have (1) a clear hypothesis — what you expect to happen and why, (2) a procedure — exact steps so someone else could repeat it, and (3) results with a conclusion — what actually happened and what you will do because of it.

What Makes Testing “Original”

Document tests your team actually performed. This means:

Types of Tests for a VRC Robot

Performance Tests
  • Cycle time: how fast does the intake collect one element?
  • Autonomous consistency: how many of 10 runs land within 2 inches of target?
  • Drive speed: time to cross the field
  • Scoring rate: elements per 30 seconds of driver control
Reliability Tests
  • Stall detection: does it trigger in under 200ms?
  • PID repeatability: standard deviation across 20 runs
  • Battery impact: does performance change at 60% vs 100%?
  • Mechanical stress: runs without failure over 10 matches

Interactive Testing Log — How to Format Entries

This is what a well-documented test entry looks like in your notebook. Every row tells the complete story:

DateTest & HypothesisResultTarget?Next Action
Oct 14Intake cycle time. Hypothesis: intake will collect one cup in under 0.8s based on 600rpm roller speed.0.94s avg (n=10)❌ MissIncrease roller voltage cap; retest
Oct 17Intake cycle time v2. Hypothesis: 12V voltage cap will bring cycle time below 0.8s target.0.71s avg (n=10)✅ PassDocument in notebook; move to drive testing
Oct 21Auton consistency. Hypothesis: robot will land within 2 inches of goal in 8/10 runs after IMU recalibration.6/10 within 2 in⚠ PartialTune kP up 0.1; retest at competition tiles
Oct 28Auton consistency v2. Hypothesis: kP=1.3 will reach 8/10 target on competition-spec tiles.9/10 within 2 in✅ PassLock in; document final PID constants
STEM Highlight
The Science of Measurement & Statistics

Every test entry above uses sample size (n=10), average, and comparison to a benchmark. These are core scientific measurement concepts. Being able to explain them to a judge demonstrates genuine STEM understanding — not just robot building.

σ
Standard Deviation
Measures consistency. A PID with σ = 0.3in is more reliable than one with σ = 1.5in. Calculate it across repeated autonomous runs.
n
Sample Size
Why n=10 matters: one good run could be luck. Ten consistent runs is evidence. The more trials, the more trustworthy your conclusion.
H
Hypothesis
A hypothesis is a prediction with a reason: “If we increase kP, then the robot will reach its target faster because the proportional response is larger.”
Δ
Change Variables
Change one variable at a time. If you change kP and the tile surface, you cannot know which caused the improvement.

💬 Interview answer: “We use controlled experiments — changing one variable at a time — and record n=10 trials per test so our conclusions are based on data, not luck. We compare results to pre-set benchmarks to decide whether a change is actually an improvement.”

🔬 Check for Understanding

Your teammate ran the autonomous 3 times, it worked all 3, and wrote “auton works” in the notebook. What is the biggest problem with this testing approach?
The test should have been run on a different field
The sample size is too small, there’s no benchmark, no procedure, and no conclusion — judges can’t evaluate it
Autonomous results should not be documented in the notebook
The test passed, so it doesn’t need more documentation
// Section 03
Decision Matrix
A decision matrix turns a subjective team debate into a structured, documentable, defensible decision. It helps the team compare options using explicit criteria and examine assumptions.
πŸ“Œ Quick Take Decision matrices: list options as rows, criteria as columns, score each cell. Multiply by criteria weights, sum, pick highest. Document a matrix when you actually used one. If you evaluate an earlier decision later, date that analysis honestly rather than presenting it as the original process.

How a Decision Matrix Works

  1. List your design options — typically 3–4 alternatives being compared (e.g., three different intake designs)
  2. Define criteria — the specific factors that matter for this decision. For an intake: speed, consistency, part count, ease of build, risk of jamming
  3. Assign weights — not all criteria matter equally. Speed might be 3× more important than part count. Weights make this explicit
  4. Score each option — each option gets a score (1–5) for each criterion. Multiply by weight to get weighted score
  5. Total and conclude — the highest total does not automatically win. Write a paragraph explaining the result and whether you agree with the matrix
ℹ️
Always define your scoring scale in the notebook. Write: “5 = Excellent, 3 = Acceptable, 1 = Poor” before the matrix. Judges need to know what a score of 4 means for each criterion — otherwise the matrix is subjective and unconvincing.

Interactive Decision Matrix — Fill It In

Practice using a real decision matrix. Score each intake design 1–5 and see the weighted totals update automatically.

Criterion Weight 🔁 Roller Intake 👉 Claw Intake ♠️ Suction Intake
Cycle Speed×3
Consistency×3
Ease of Build×2
Jam Risk×2
Part Count×1
TOTAL — — —
STEM Highlight
Mathematics: Weighted Scoring & Multi-Criteria Optimization

The decision matrix is a real mathematical tool called Weighted Sum Model (WSM) — used by engineers everywhere from NASA to software product teams. Each total is calculated as: Total = ∑(criterion score × weight). This is a dot product of two vectors.

∑
Weighted Sum
Total score = sum of (score × weight) for each row. This is the same operation as calculating a weighted average on a report card.
✦
Trade-off Analysis
Engineering is always about trade-offs. A faster intake that jams more often may score lower overall than a slower but more reliable one.
w
Weight Assignment
Weights encode your team’s priorities. If you decide speed matters 3× more than part count, you are making a mathematical statement about your strategy.
?
Sensitivity Analysis
What happens if you change one weight? If the winner changes, your decision is sensitive to that criterion — document this in your notebook.

💬 Interview answer: “We use a weighted decision matrix. We assign weights based on what matters most for this game, score each option 1–5, and multiply. The math makes our reasoning visible — judges can see exactly why we chose what we chose, not just that we chose it.”

🔬 Check for Understanding

Your decision matrix gives Intake Design B a total of 47 and Design A a total of 44. A teammate says “so we pick B, done.” What should you add to the notebook?
Nothing — the math speaks for itself
A written conclusion explaining the result, whether the team agrees, any factors the matrix may have missed, and confirmation of the final decision
Build both designs and test them before deciding
Re-run the matrix with different weights until Design A wins
// Section 04
Documentation Best Practices
Prioritize clear evidence over page count or decoration. A notebook entry that clearly records one design decision with labeled diagrams, a test result, and a conclusion beats 10 pages of photos with no explanation.
πŸ“Œ Quick Take Length is not a category. A 30-page notebook with clear evidence beats a 120-page notebook of daily updates. Use diagrams, photos, decision matrices, and testing data — not paragraphs about what happened today.

The Anatomy of a Notebook Entry

Every entry should have these elements. Build them into a template your whole team uses so documentation is consistent even when written by different members:

1. Header
Date · Team member(s) present · Entry title · Which EDP step this entry covers. Example: “Oct 21 · Alex & Jordan · Intake v3 Build Log · EDP Step 5: Build & Program”
2. Context
Why this entry exists. What problem or question prompted this work. Link to the previous entry that led to this decision. “After testing showed intake cycle time was 0.94s (above our 0.8s target), we redesigned the roller geometry.”
3. Labeled Diagram or Code Snippet
Drawings must have labels. Photos must have annotations. Code should be shown alongside its purpose — not dumped in without context. “Figure 3: New intake geometry with 45° angle showing how cups now self-center”
4. Test Results
A data table or measurement. What was the specific result? Include n= (how many trials). Compare to your benchmark. “Cycle time: 0.71s avg (n=10). Target: 0.8s. PASS.”
5. Conclusion & Next Step
What did you learn? What will you do next? This creates the chain between entries that judges look for. “New roller angle solved the timing issue. Next: test whether the new geometry causes any jam risk with misfed cups.”

Physical vs Digital Notebooks

Choose paper or digital based on how your team records and retrieves its work. Follow the event submission instructions. Spartan recommendations:

🏆
The “5-minute rule” for notebooks: after every build or coding session, spend 5 minutes writing what you did and why. Do not wait until the end of the week. Memory fades, details are lost, and the notebook starts to sound reconstructed rather than genuine. Judges can tell the difference.

📝 Practice: Build a Notebook Entry

Fill in these fields as if documenting today’s session. The completed entry appears below.

STEM Highlight
Engineering: Traceability & Design History

Professional engineers maintain design history files — every decision, test, and change is traceable forward and backward. Your notebook is your design history file. In aerospace, medical devices, and automotive engineering, this documentation is legally required.

↔
Traceability
Each entry links to a previous one. “This arm redesign was triggered by test data from entry Oct 14.” Judges can follow the chain of reasoning.
↻
Iteration Loop
Real engineering is iterative: design → build → test → analyze → redesign. Your notebook should show multiple passes through this loop, not just one.
📋
Change Log
Document every meaningful change. Even failed attempts are valuable — they show you explored the problem space thoroughly before committing to a solution.
👥
Team Attribution
Note who was present for each session. Judges verify that students (not coaches) did the work. Each member’s contribution should appear across multiple entries.

💬 Interview answer: “Our notebook is structured like a professional design history file. Every entry has a date, who was there, what EDP step it covers, and a link to what came before. You can trace any design decision from the problem statement all the way to the final robot.”

🔬 Check for Understanding

A teammate suggests going back to your October entries and adding more detail before submitting the notebook to judges next week. How can the team preserve an honest record?
It’s encouraged — judges want to see thorough entries
You can edit digital entries any time since there’s no paper trail
Retroactively editing past entries is not appropriate. Instead, add a new current-date entry that references and supplements the earlier one
Only physical notebooks need to stay unedited; digital ones can be revised
// Section 05
STEM Connections Across Your Robot
Every system on your robot is a live STEM lesson. Judges want to hear you connect what you built to what you learned. This section maps the real science, math, engineering, and technology behind the things your team already does.
πŸ“Œ Quick Take Judges ask "what STEM concept does this teach?" Be ready: gear ratio → mechanical advantage, PID → control theory, odometry → coordinate geometry, pneumatics → ideal gas law. Make these connections in the notebook explicitly.
🏫
Why STEM connections matter in the interview: judges are often STEM professionals. When a student says “we chose a 4-bar linkage because it maintains a constant angle through its range of motion — that’s conservation of angular relationships” instead of “we built an arm,” the judge hears someone who actually understands engineering. This depth is what separates Design Award winners at State and Worlds.

Click a System to See Its STEM Connections

🔬 Check for Understanding

A judge asks: “Tell me about the math behind your PID controller.” Which answer best demonstrates STEM understanding?
“PID stands for Proportional, Integral, Derivative. We tuned it until it worked.”
“We used EZ Template which has PID built in, so we didn’t need to do math.”
“The P term produces a correction proportional to the current error — like a spring force. When error is large, correction is large. kP controls how aggressive that response is. We tuned it by measuring overshoot and settling time, which are control theory metrics.”
“Our PID scored 9 of 10 autonomous runs so it’s working well.”
// Section 06
Interview Preparation
The pit interview is your chance to show judges the thinking behind the notebook. Every team member should speak. The EDP should structure your presentation. SigBots: “Practice, Practice, Practice.” This section gives you the questions to practice with.
πŸ“Œ Quick Take Interview = notebook in conversation form. Bring the notebook, open to the page that proves your answer. If a judge asks about your gear ratio choice, flip to the decision matrix you used. Evidence-based answers always score higher than verbal-only.
🏆
Two types of interviews: the pit interview (every team gets this — broad overview of your whole season) and the secondary interview (judges pull you aside for deeper questions on specific topics). Scoring high on the rubric earns you the secondary interview. Nail the secondary to win the award.

The Six Interview Rules

  1. Every team member speaks — assign each person a topic. Judges verify that all members understand the robot, not just one programmer.
  2. Follow the EDP structure — introduce the problem → research → options considered → why you chose your design → how you tested → what changed → where you are now.
  3. Bring data — hold the notebook open to a test table or decision matrix when discussing it. “As you can see here...” is stronger than reciting numbers from memory.
  4. Mention iterations — tell judges when things failed and what you learned. Failure + learning = engineering. Judges specifically look for this.
  5. Tie back to STEM — connect at least one technical decision to a math or science concept. This one moment often changes how judges see your team.
  6. Practice with a timer — pit interviews are short. Covering everything in 5 minutes requires deliberate practice, not improvisation.

Practice Questions — Click to Reveal Answer Frameworks

“Walk me through your design process this season.”
This is the big EDP walkthrough question. Structure: problem → options → decision → build → test → iterate.
Start at the beginning of the season: “We began by analyzing the game manual to define what a high-performing robot needed to do. We identified three key challenges: [X, Y, Z]. We then brainstormed and sketched three different approaches for our intake mechanism, evaluated them using a decision matrix weighted for speed and consistency, and chose [option] because it scored highest while also being within our build timeline. We built a prototype, tested it against our benchmark of [number], found it [passed/failed], and iterated by [change]. By October we had completed [n] full design cycles on the intake alone.”
“Why did you choose this drivetrain?”
Reference your decision matrix. Mention physics. Show you considered alternatives.
“We evaluated three drivetrain options in a decision matrix using criteria: speed, maneuverability, pushing power, and ease of build. We weighted maneuverability 3× because the game rewards quick positioning changes. [Chosen drive] scored highest weighted total of [X]. From a physics standpoint, our 4-inch wheels with a 36:48 gear ratio give us a theoretical top speed of [value] while maintaining enough torque to push opponents off scoring positions. We tested measured speed at [X in/sec] and confirmed it matched our calculation within 8%.”
“How did you develop your autonomous?”
Testing methodology + iteration + data. Mention PID tuning approach and consistency metrics.
“We use EZ Template’s PID system. We tuned kP for the drive by running 20 trials at 36 inches and measuring overshoot and settling time using data logging to an SD card — which is in our notebook here [show table]. Our benchmark was landing within 2 inches in 8 of 10 runs. We reached that after three tuning iterations. We also document our autonomous consistency rate across practice matches — currently we succeed in [X]% of qualification matches, which we track in our competition log.”
“What failed, and what did you learn?”
This is your chance to shine. Every judge wants to hear about failure and recovery — it shows genuine engineering.
“Our first intake design jammed constantly in testing — we documented [X] failures in 30 trials. We analyzed the failure mode in the notebook: the cup was catching on the bottom edge of the roller housing. We redesigned with a 15° chamfer on that edge, retested 30 trials, and got zero jams. This is on page [X] of our notebook. The lesson was to test edge cases, not just typical operation — our benchmark now always includes deliberate stress tests at the design’s limits.”
“Tell me about a math or science concept in your robot.”
Pick one concept you understand deeply. Quality over quantity. Do not list five things superficially.
“Our PID controller implements closed-loop feedback control. The core math is: output = kP×error + kI×∫error dt + kD×(d/dt)error. The P term acts like Hooke’s Law — the correction force is proportional to how far you are from target. The D term acts like a damper in a spring-mass system — it reduces oscillation. We tuned these by treating it as a physics problem: we wanted critical damping, where the robot reaches the target without overshoot. Our data logs show the damping ratio we achieved.”
“How is your robot this year different from last year?”
Show growth. Reference notebook entries from early in the season vs now. Mention specific metrics.
“We have measurable improvements in three areas. Autonomous consistency improved from [X]% to [Y]% — documented across [n] competition matches. Our intake cycle time decreased from [A]s to [B]s after redesigning the roller geometry, documented with before/after test tables in the notebook. And our engineering process itself improved — last season we had [n] documented test entries. This season we have [n+X], with consistent benchmark targets in every entry. We learned that documentation is not extra work — it is what allows us to improve reliably instead of guessing.”
STEM Highlight
Technology: Systems Thinking & Feedback Loops

Your entire robot is a system — interconnected subsystems that depend on each other. The EDP itself is a feedback loop: you test, analyze, and redesign based on results. Systems thinking is one of the core competencies of engineering and computer science.

🌐
System Integration
A change to the intake affects autonomous timing, which affects scoring strategy, which affects your driver’s practice needs. Documenting these interactions shows systems-level thinking.
↻
Feedback Loop
The EDP is a feedback loop: design → test → result → analyze → redesign. This is the same structure as a control algorithm. Your notebook makes this loop visible.
📈
Performance Metrics
Choosing the right metrics to track is itself a technology skill. Cycle time, standard deviation, pass rate — each measures something different about your robot’s performance.
👥
Collaboration
Software engineering uses version control; your team uses a notebook with dated entries and named contributors. The parallels to professional team software development are direct.

💬 Interview answer: “We view the robot as a system where every subsystem affects the others. Our notebook documents not just isolated tests but how changes in one area rippled through to others — for example, when we sped up the intake, we had to re-tune our autonomous timing because the cycle was now shorter than the PID had assumed.”

🔬 Check for Understanding

During your pit interview, the judge asks “what science is in your robot?” and you have 60 seconds. Which approach will score the most points?
Quickly list every STEM concept you can think of: “there’s physics, math, programming, electricity, mechanics...”
Say “robotics uses a lot of STEM” and move on to describing the robot
Pick one concept you understand deeply and explain it with specifics: “Our drive PID implements feedback control — the correction is proportional to error, like Hooke’s Law. We tuned it by measuring settling time across 20 trials and targeting critical damping.”
Show the judge your test data table and let them figure out the STEM themselves
Related Guides
🏆 Judge Interview Prep →🔬 Testing System →📅 Season Timeline → 📄 Notebook Template Guide → 🗺 Notebook Pathway Overview →
← ALL GUIDES