Defense

Individual, held as a team session·Every term·8% fall, 10% winter, 10% spring

• Individual DefenseWeek 7 or 9·Rubric

Tell your TA before the session and you're rescheduled that term, with no penalty. An unexcused no-show scores Missing.

Once per term, in week 7 or 9 (check announcements for the schedule), your team meets a Teaching Assistant (TA) or instructor who is not your team’s regular TA for a defense session separate from your TA check-ins, during which each student walks through something they own and answers live questions. Your own TA does not attend, so the account you give of your work has to stand on its own. The session is six minutes per student plus about ten minutes for setup and wrap, so a team of three runs a little under half an hour and a team of five runs about forty minutes. Per-student time doesn’t shrink on a larger team; the session simply runs longer. Sick or absent that week? Tell your TA before the session and you will be rescheduled.

You may present a pull request you drove, a subsystem you maintain, your RFC decision, or a test or deployment strategy you built. Expect questions like these: why this way and what you rejected, what breaks if X changes, where did you decide to stop and check the work yourself and why there, and what was the most useful thing you told someone whose work you reviewed.

Ground rules: your docs, your repo, and your AI tools are open for explaining (looking things up, walking through code) and closed for generating (no asking a model to produce the answer live). Here the AI policy narrows: what is measured is what you can account for without help. Notes are fine. Slides are unnecessary.

If you built and understood your work, the defense is a friendly conversation about it. If you can’t explain your own contribution, no artifact will cover for that, and your project partner will expect the same of you in every meeting.

Delegating work to AI tools is expected and is not penalized; the AI policy says what is assessed instead. In a defense that’s concrete: a student who let an agent drive a database migration unchecked and got lucky scores badly, and a student who stopped to validate an authentication change scores well even if some feature code has bugs.

How the Session Runs

The speaking order is drawn at random in the room, never published in advance, and each student gets a different artifact and a different “what breaks if X” question. Hearing a teammate answer first therefore tells you very little about what you will be asked.

Your teammates are the people who know whether your account of your own work is true, so claim only what they would co-sign.

If a score comes out borderline, or if your part of the session ran short for any reason, your assessor may ask you back for a brief individual follow-up. It is routine and it is not a penalty.

Scoring

TAs and instructors score each student live on a printed sheet (the scoresheet is public: you can see exactly what is scored). Scores and notes are entered per student in the gradebook after the session; the printed sheet is the live instrument, the gradebook is the record. Not every teammate holds one of the three named roles (Project Manager, AI Coordinator, Quality Owner) at a given time; “comparable ownership area” (a subsystem, the test suite, the deployment) satisfies the role criterion. The working agreement guide says what each of the three concerns covers. On a small team a student may own two of the three concerns, and speaks to both.

What You Submit

Nothing. The defense is live, so prepare by doing your work and being able to talk about it.

Rubric

Rubric: 100 points across 5 criteria

Criterion	Ratings
Ownership and delegation20 pointsOutcomes: SO2, SO4	Exceeds Expectations (20)Presents work they demonstrably own end to end (authored or drove it, responded to review, merged it); claims match the repo record when spot-checked. Explains what was and was not handed to AI tools, the checks that made that reasonable (tests, CI, review gates, staging, rollback), and the specific points where they stopped to validate, each with a reason tied to what was hard to reverse (schema, authentication, deployment, data migration). Meets Expectations (16)Claims match the repo record, but the student gives no account of what was or was not handed to AI tools, the checks are named only in general terms ("we had tests"), no specific point where they stopped to validate is named with a reason tied to what was hard to reverse, or the reasons given for the delegation do not match the RFC, the decision record, or the sprint notes. Does Not Meet Expectations (4)Cannot say what they authored, reviewed, or merged in the work presented, describes delegating a hard-to-reverse change with no checks and no validation, or makes claims about what they authored, reviewed, or merged that contradict the repo record. Missing (0)Unexcused no-show, or no meaningful attempt to present or answer; excused absences are rescheduled per the absence policy and not scored here.
Judgment: why this approach, what was rejected, what was hard to reverse20 pointsOutcomes: SO1	Exceeds Expectations (20)Explains why this approach was chosen, names at least two alternatives that were considered (doing nothing counts as one), each with the reason it was rejected, consistent with the RFC, the decision record, or the sprint notes where they cover it, and identifies which parts of the decision were hard to reverse. Meets Expectations (16)Explains the chosen approach, but names only one alternative, names alternatives without the reason each was rejected, gives alternatives or reasons that do not match the RFC, the decision record, or the sprint notes, or cannot say which parts were hard to reverse. Does Not Meet Expectations (4)Cannot explain why the work was done this way, or names no alternative that was considered. Missing (0)Unexcused no-show, or no meaningful attempt to present or answer; excused absences are rescheduled per the absence policy and not scored here.
Technical depth: "what breaks if X"20 pointsOutcomes: SO6	Exceeds Expectations (20)Answers "what breaks if X changes" questions with correct, specific reasoning about the system's behavior and limits, including where they chose to verify the system's behavior themselves rather than rely on generated output. Meets Expectations (16)Answers are mostly correct but do not name the specific behavior or limit that breaks, or reasoning falters on follow-up questions. Does Not Meet Expectations (4)Answers are incorrect or evasive, or cannot say what the system does when X changes. Missing (0)Unexcused no-show, or no meaningful attempt to present or answer; excused absences are rescheduled per the absence policy and not scored here.
Role, team accountability, and work distribution20 pointsOutcomes: SO5	Exceeds Expectations (20)Articulates what their named role (PM, AI Coordinator, Quality Owner) or comparable ownership area required this term, with concrete examples; names a decision they chaired to a conclusion this term that matches the sprint-note record, or, where their turn to chair is still ahead, the decision the charter's rotation schedules them to chair and when; and explains how the team's decisions actually got made and how work was distributed. Meets Expectations (16)Describes the role and team process in general terms, with few concrete examples of what the role required in practice or of how work was distributed. Does Not Meet Expectations (4)Cannot articulate what their role or ownership area required, how the team makes decisions, or who did what. Missing (0)Unexcused no-show, or no meaningful attempt to present or answer; excused absences are rescheduled per the absence policy and not scored here.
Communication, both directions20 pointsOutcomes: SO3	Exceeds Expectations (20)Answers the question asked, at a level of detail the assessor does not have to correct; at the edge of their knowledge, says "I don't know, but here is how I would find out" (that scores; bluffing does not). Names a specific thing they told someone whose work they reviewed, and what changed in that work because of it; in fall and winter, where the reviewed RFC is not revised yet, the author's response to the comment (the reply, or the revision the author committed to) counts as what changed. Meets Expectations (16)Answers, but the assessor has to ask for a more concrete or a shorter answer, or hesitates at the edge of their knowledge without saying how they would find out. Names a real review comment but cannot say what changed, or describes their reviewing only in general terms. Does Not Meet Expectations (4)Does not answer the question asked, or bluffs instead of saying what they do not know. Cannot name anything they told a reviewee, or offers feedback that named no line and requested no change. Missing (0)Unexcused no-show, or no meaningful attempt to present or answer; excused absences are rescheduled per the absence policy and not scored here.

At the edge of your knowledge, “I don’t know, but here is how I would find out” scores; bluffing does not.

Communication runs both directions, and the reviewer-side half checks the other direction: being articulate about your own work doesn’t make you useful in review. In fall and winter it’s your RFC peer review, and since the RFC you reviewed may not be revised yet, the author’s reply to your comment, or the revision they committed to, counts as what changed. In spring it’s code review, and your sprint note contribution lines already name the change you asked for or what you checked before approving. Both are graded records, so this is checkable: “I left some comments” is not an answer, and neither is anything that named no line and requested no change. Google’s code review standard is the bar the criterion is written against.

NDA teams

The defense runs identically whether or not your project is under NDA: everything happens live and no artifact changes hands, so NDA constraints do not apply.

Activities That Prepare This

The defense runs once a term, so these rotate.

Term	Activity	Criterion it serves
Fall	Map Your Hard-to-Reverse Decisions	Judgment
Fall	Audit Your Safety Net	Ownership and delegation
Fall	Peer Technical Design Review	Technical depth
Winter	Run a Self-Audit and an Architectural Review Pass	Ownership and delegation
Spring	Run an Acceptance Pass	Ownership and delegation
Spring	Learn from Patrick Winston	Communication

Browse Testing, Release, and Handoff and Technical Design when these run out.