RFC (Request for Comments)

Individual·Fall and winter·14% fall, 15% winter

• RFC Draft + Peer ReviewSunday of week 4, peer reviews Sunday of week 5·4% fall, 5% winter·Rubric
• RFC Final DraftSunday of week 8·10%·Rubric

Up to 48 hours late loses one rubric band on each criterion. After that it scores zero, unless you contacted the instructors before the deadline with a documented reason.

You write a different RFC each term, in fall and winter, about a real decision your team faces that is hard to reverse. An RFC (Request for Comments) frames the problem, lays out the options, recommends one, and invites critique before the team commits; the name comes from the IETF’s RFC series, and the same shape is used internally at Google as a design doc and at Oxide as an RFD. In fall the decision is still open when you submit the draft. Where you can, pick one your team can leave open until the peer reviews come back in week 5; either way, the team decides when the work requires it, by the final in week 8 at the latest. In winter it may be one the team has already started acting on, as long as the RFC still changes something: how the team verifies it, what reversing it would take, or what comes next. The RFC is not a hypothetical, and not a justification written after the fact for a decision it no longer changes.

Picking a decision that is actually yours

Hard-to-reverse decisions are typically architecture, database schema, authentication and authorization, deployment topology, data migrations, licensing, and third-party commitments: undoing them costs far more than getting them right now. Most feature code is easy to reverse. The distinction comes from Jeff Bezos’s 2015 letter to Amazon shareholders, which calls them Type 1 and Type 2 decisions and warns that applying the heavyweight Type 1 process to reversible decisions makes an organization slow. Telling one from the other is itself part of the exercise, and it’s the judgment that matters most when much of the building is delegated.

Two situations make the choice harder, and both are ordinary:

Your partner already decided. Your team may inherit the stack, the hosting, the database, and the review process, and find out in week 3 how little is yours to choose. Write on a decision inside that constrained space, or on how to work within a constraint you were handed: how to verify against a system you cannot change, how to migrate data on a schedule someone else owns, what you would have to prove before asking your partner to reconsider. Naming a constraint accurately and reasoning inside it is a legitimate RFC topic.

Nothing hard to reverse is live in your four-week window. Write on the most consequential reversible decision you face, and say in the problem framing why it is reversible and what would make it not.

Do not invent a hard-to-reverse decision you are not actually facing.

What you can direct an agent or a teammate to build is bounded by how precisely you can specify it. Write the RFC to that standard.

What You Produce

1. Problem and context: what decision is needed, why now, what happens if the team does nothing.
2. Options: at least three options including “do nothing”, each with its real costs and the condition under which it would be the right choice.
3. Analysis: the technical tradeoffs that matter (performance, complexity, maintainability, security, cost), argued from cited sources and your own project evidence.
4. Recommendation and verification plan: what you propose based on the analysis and, concretely, how the team will know it worked (tests, metrics, acceptance criteria).
5. Constraints: licensing, data use, IP, and the partner confidentiality boundary as they bear on this decision.
6. Delegation and validation: what you handed to AI tools on this decision, what checks made that reasonable (tests, CI, review gates, staging, a rollback path), and the specific points where you stopped and validated the result yourself. The AI policy says what is assessed.

Write it in the sections of the RFC template: the six above, then Decision. Commit the draft to your repository under docs/rfcs/ or docs/adr/ when you submit it, with Status and Decision set to Proposed. When your team decides, before or after the reviews, record the outcome in both; the ADR guide covers keeping it as a record from then on. You submit the RFC twice, each time as one PDF (Submitting Your Work): the draft in week 4 and the revised final in week 8. The draft is 1,500 to 2,500 words and the final 2,000 to 2,500, in fall and in winter, not counting the revision log (see RFC Final Draft).

AI use: AI may research options, draft sections, and sharpen the argument; the Delegation and validation criterion is where you say what you handed off and how you checked it. Presenting a generated analysis you did not verify as your own judgment, or inventing evidence (benchmarks, quotes, references that do not exist), fails the assignment. The defense will ask you to explain the decision without the tool.

What You Submit

RFC Draft + Peer Review

Submit a complete draft by Sunday of week 4: every section above, 1,500 to 2,500 words. You don’t need the draft’s grade before revising: start as soon as your peer reviews arrive.

The Peer Review

In week 5 you review two drafts by other students, and two students review yours. Your reviews carry most of this entry’s points, and the larger share goes to how specific each one is to its draft.

1. Get your pairings. At the start of week 5, you are assigned two drafts through the peer review on this entry.
2. Answer four questions for each draft, in writing:
   1. Is the problem framed so a newcomer understands the stakes?
   2. Is any credible option missing?
   3. Would the verification plan actually detect failure?
   4. What is the single strongest improvement?
3. Point at the draft. Each answer names the passage it is about, so the author can find it.
4. Submit both reviews by Sunday of week 5, as a comment on each draft in its peer review.

If an assigned reviewer does not submit, flag it to your Teaching Assistant (TA): you won’t be penalized for feedback you never received, and the instruction team will supply a review. Not submitting your reviews of other students’ drafts forfeits the review criteria below and is visible to the authors you were paired with.

If your project is under NDA

Submit a sanitized draft: your reviewers read it, so replace partner-confidential specifics with neutral placeholders. If that isn’t possible, contact the instruction team.

Instructor Comments

By Sunday of week 6, an instructor returns comments on your draft submission. Each comment becomes a row in your revision log, the same as a point from a peer review.

RFC Final Draft

Submit the RFC by Sunday of week 8, revised after both peer reviews and the instructor comments, followed by its revision log, in one PDF. Record your team’s decision in its Status and Decision first (accepted, rejected, or superseded), and commit the revised RFC in place of the draft. The instruction team grades the final against the rubric below and returns rubric feedback.

Revision Log

After the RFC, add a table with one row for every point raised in the feedback you received: both peer reviews (one may be a review the instruction team supplied in place of a reviewer who did not submit) and the instructor comments on your draft. Each row records what you did with that point:

Source	Feedback	Decision	Where or why
Reviewer 1	No check in the verification plan would catch a migration that drops rows	Changed	Recommendation and Verification Plan: a row-count and checksum comparison now runs before cutover
Reviewer 2	A managed queue is a missing option	Declined	The partner’s hosting agreement rules out a third-party processor for this data, so a managed queue is not a credible option

Feedback is the point in your words, not a quote. For a change, Where or why names the section that moved and what moved in it, so the grader can find it in the final. For a decline, it gives the reason the point does not hold for this decision; a reasoned decline counts as much as a change.

The log goes in the submission only: the RFC in your repository is the team’s record of the decision, and who asked for which change is not part of it, so don’t commit the log there. It does not count toward the length band.

Length floor

The revised RFC, not counting the revision log, must total at least 2,000 words.

Rubric

RFC Draft + Peer Review

Rubric: 100 points across 3 criteria

Criterion	Ratings
Draft complete30 points	Exceeds Expectations (30)All six sections before Decision are present and in order, none a placeholder, and the draft is 1,500 to 2,500 words. Meets Expectations (24)One section is missing, out of order, or a placeholder, or the draft is under 1,500 or over 2,500 words. Does Not Meet Expectations (6)Two or more sections are missing or placeholders; the submission is an outline rather than a draft.
Reviews submittedboth assigned reviews, each answering the four questions30 points	Exceeds Expectations (30)Both assigned reviews are submitted by the peer review deadline, and each answers all four questions. Meets Expectations (24)Both reviews are submitted, but one leaves a question unanswered. Does Not Meet Expectations (6)One review is missing, or both leave several questions unanswered.
Reviews: specific to the draft40 pointsOutcomes: SO3	Exceeds Expectations (40)Each review is specific to its draft: it points at the passage it critiques, names a missing option, a verification gap, or an understated stake, and ends with the single strongest improvement the author can make. Meets Expectations (32)Each review has at least one point specific to its draft; the rest would apply to any RFC. Does Not Meet Expectations (8)Generic praise or a restatement of the draft; nothing the author could act on.

The draft is graded for completeness, not for the quality of its reasoning, and the instructor comments carry no points.

RFC Final Draft

Rubric: 100 points across 8 criteria

Criterion	Ratings
Problem framing and context15 pointsOutcomes: SO1	Exceeds Expectations (15)States what decision is needed, why now, and what happens if the team does nothing; the decision is real and current for the team (in fall, open when the draft was submitted, whether or not the team has decided since; in winter, open or already being acted on, with the RFC still changing how it is verified, reversed, or continued); a newcomer to the project would understand the decision and its stakes without extra context. Meets Expectations (12)Problem and context are present but the stakes, the urgency ("why now"), or the cost of doing nothing are underspecified; a newcomer would need additional context to follow. Does Not Meet Expectations (3)Problem framing is missing or generic, the RFC is a hypothetical, the decision was already made when the draft was submitted in fall, the RFC justifies a decision it no longer changes in winter, or the stakes are unclear.
Options: three or more, including "do nothing"10 pointsOutcomes: SO1	Exceeds Expectations (10)At least three options including "do nothing", each with its costs and consequences and the condition under which it would be the right choice. Meets Expectations (8)At least two options state their costs and the condition under which each would be the right choice, but fewer than three options are listed, another option states no such condition, "do nothing" is missing or dismissed without its costs, or costs are stated for some options and not others. Does Not Meet Expectations (2)Fewer than two options state their costs and the condition under which they would be the right choice.
Technical tradeoff analysis15 pointsOutcomes: SO6, L07	Exceeds Expectations (15)The tradeoffs that matter (performance, complexity, maintainability, security, cost) are argued from cited sources and evidence specific to this project, and uncertainty is acknowledged where it exists. Meets Expectations (12)Analysis is present, but a tradeoff is argued without a cited source, or without project-specific evidence; a relevant tradeoff is unexamined; or uncertainty is not acknowledged. Does Not Meet Expectations (3)Analysis is missing, not project-specific, or asserted without evidence.
Recommendation and verification plan15 pointsOutcomes: SO2	Exceeds Expectations (15)One option recommended, plus a verification plan (tests, metrics, acceptance criteria) that would actually detect failure; the team could act on it as written. Meets Expectations (12)One option is recommended, but the verification plan is partial, vague, or would not clearly detect failure. Does Not Meet Expectations (3)No single option recommended, or no verification plan.
Constraints: licensing, data use, IP, confidentialitylicensing, data use, IP, confidentiality boundary addressed10 pointsOutcomes: SO4	Exceeds Expectations (10)Licensing, data use, IP, and the partner confidentiality boundary are each addressed as they bear on this decision (or explicitly noted as not applicable, with reasoning). Meets Expectations (8)Constraints are mentioned but one or more relevant areas are missing or named without saying how they bear on this decision. Does Not Meet Expectations (2)Constraints are not addressed.
Delegation and validationwhat you handed to AI tools, the checks that made that reasonable, and the points where you validated yourself10 pointsOutcomes: SO4	Exceeds Expectations (10)States what was handed to AI tools on this decision, the checks that made that reasonable (tests, CI, review gates, staging, a rollback path), and the specific points where the author validated the result themselves, each with a reason tied to what was hard to reverse (schema, authentication, deployment, data migration). Meets Expectations (8)Delegation and validation are described, but the checks are named only in general terms ("we had tests"), or a validation point has no reason tied to what was hard to reverse. Does Not Meet Expectations (2)Not addressed, or describes delegating a hard-to-reverse decision with no checks and no validation.
Writing: length, sections, sourced claims10 pointsOutcomes: SO3, L08	Exceeds Expectations (10)2,000 to 2,500 words, not counting the revision log; the six sections before Decision present and in order; every claim about the system names a file, a pull request, or a measurement. Meets Expectations (8)One of the three missing: outside 2,000 to 2,500 words, a section missing or out of order, or claims without a named source. Does Not Meet Expectations (2)Two or more of the three missing.
Revision: feedback integrated, with a revision log15 pointsOutcomes: SO3, L09	Exceeds Expectations (15)The revision log has a row for every point raised in the feedback received, each marked changed or declined; every change is visible in the section the row names; every decline gives the reason the point does not hold for this decision; the team's decision (accepted, rejected, superseded) is recorded in the RFC. Meets Expectations (12)The revision log omits one or two points raised, a decline has no reason, a listed change is not visible in the final, or the team's decision is not recorded. Does Not Meet Expectations (3)No revision log, the log omits most points raised, or no row has either a change visible in the final or a reason. Non-submission of the draft forfeits these points (there is nothing to revise).

Not submitting the draft forfeits the revision points, because there is nothing to revise.

Activities That Prepare This

Different activities suit the fall and winter RFCs, so you’re not redoing the same exercise twice.

Term	Activity	Criterion it serves
Fall	Map Your Hard-to-Reverse Decisions	Choosing the topic, and problem framing
Fall	Choose a Storage or Technology	Options, and technical tradeoff analysis
Fall	Six Thinking Hats	Options, including “do nothing”
Fall	Peer Technical Design Review	Reviews specific to the draft, and revision
Winter	Write a Literature Review	Tradeoff analysis, and sourced claims
Winter	Proof-of-Concept	Recommendation with a verification plan
Both	Apply the Privacy by Design Guidelines	Constraints
Both	Run a Self-Audit and an Architectural Review Pass	Delegation and validation

Examples, for finding a decision worth writing about. A project may match several rows or none. If none fits, ask your partner or mentor which activities do.

If	Activities
you work inside an existing codebase’s conventions	Analyze an Existing Codebase. Those conventions constrain your options hard, and an RFC that reasons accurately inside them is stronger than one that ignores them
your results are compared against a baseline or a metric	Reproduce Your Baseline and Identify Success Metrics. Which baseline and which metric are both hard-to-reverse decisions: change either late and every earlier result stops being comparable
several people at the partner have a say, or the system handles personal data	Stakeholder Mapping and Apply the Privacy by Design Guidelines for the constraints criterion
you’re choosing the stack from scratch	Choose a Storage or Technology and The Mom Test, which is a fast check on whether the decision matters to anyone outside the team

Browse Technical Design and Research Methods when these run out.