📝 Notebook · All Roles · Beginner

Build Log Entry Guide

Build log entries are the orange EDP slides — written after every hardware or code change. They're the most frequently written entries in any notebook and the most commonly written wrong. This guide shows you exactly what to include.

🔧 What a Build Log Entry Is

A build log entry documents one change — not a whole session, not a whole week. Every time something physically changes on the robot or in the code, that's a new entry. The goal is to give a judge enough information to understand what you changed, why, and what happened.

⭐

One entry per change. If you changed the intake compression AND updated the PID constants in one session — that's two entries. One for the hardware change, one for the code change. Grouping them together makes it impossible for a judge to follow your iteration.

❌✅ Bad vs Good Examples

❌ Too vague — scores Developing

Oct 4 — Fixed the intake. It was jamming so we changed some parts. Seems better now. Written by: Alex

✅ Specific — scores Proficient to Expert

Oct 4 — Increased intake roller gap from 0.5" to 0.75" (intake compression adjustment). Cause: blocks were stalling at roller entry in 3/5 trials during testing (see Test Entry Oct 3). Change: replaced both 2.5" standoff spacers with 3" spacers on both sides of the roller mount. Result: zero jams in 10 follow-up trials. Next: run a formal cycle time test to confirm intake speed is unchanged. Written by: Alex · Witnessed by: Jordan

📋 The Required Fields

Date The date the change was actually made — not when you wrote it up. If different, note both.

Subsystem Which part of the robot: Drivetrain · Intake · Lift · Endgame · Code · Wiring · Sensors

What changed Specific. Include measurements, values, part numbers. "Increased roller gap from 0.5" to 0.75"" not "adjusted the intake."

Why What evidence or observation drove this change? Reference a test entry or a match result.

Result What happened immediately after the change? Quick observation — not a full test. "Zero jams in 10 follow-up trials."

Next step What do you do next because of this change? Links the entry to what comes next in the notebook.

Written / Witnessed By Both required on every entry. Witnessed By can be a coach, mentor, or another team member not listed as author.

📖 Code Change Entries

Code change entries follow the same structure but have one extra required field: the before/after constants. Judges cannot read your code — they need the values written in plain language.

✅ Code change entry — Programming log format

Oct 9 · Drive Code · PID Constants Update

Changed: Drive kP from 0.45 → 0.62, kD from 0.08 → 0.14. No change to kI.
Why: Robot was oscillating on straight-line drives during Oct 7 auton practice — overshooting target by 4–6 inches consistently.
Result: Oscillation eliminated in 8/8 test runs. Straight-line accuracy within 1 inch of target.
Git tag: v1.3-pid-drive-oct9
Next: Test with full match simulation to confirm behavior under load.
Written by: Riley · Witnessed by: Coach T

Related

🔬 Testing System → 📝 Notebook Guide → 🗺 Pathway → 💾 Git & Version Control →

⚙ STEM Highlight Engineering: Engineering Change Orders & Design Documentation

A build log entry is the student equivalent of an Engineering Change Order (ECO) — a formal record in professional engineering that documents what changed, why it was made, and the outcome. ECOs exist because undocumented changes create ghost states: the physical system no longer matches the design record, making future debugging impossible. The RECF build log requirement mirrors this professional standard exactly.

🎤 Interview line: “We write a build log entry every time we make a hardware change. "Increased roller gap from 0.5 to 0.75 inches because blocks jammed 3 times in practice — jam rate dropped to zero in next 20 cycles." This is the engineering change order format. Judges can trace every physical change to a specific data-driven decision.”