Appendix C — The Grading Contract

“A false balance is an abomination to the LORD, but a just weight is his delight.” — Proverbs 11:1 (ESV)

This is the contract. Everything in it is published in Week 1 and none of it changes in Week 16.

Most capstone courses keep the grading vague and then surprise the student in the last two weeks. This one does the opposite: the rubric that will be applied to your repository on the last Thursday of the semester is printed below, line by line, with the points, the evidence each line wants, and the week the evidence gets made. There are no hidden criteria. There is no curve for effort. There is a stack of artifacts, and either they exist and hold up or they do not.

Read this appendix three times. Week 1, so you know what you are building toward. Week 8, at the halfway audit, when you find out whether you are on pace. Week 15, when you self-score before a grader does. Between those, keep it open next to the pace table in C.8.

Coach’s Note — A published rubric is a gift and a trap. The gift: you can never lose points for something you were not told. The trap: you can never claim you did not know. From here on, every point you fail to earn is a point you chose to leave on the table. That is the deal professionals work under too — the acceptance criteria are in the contract, and nobody reads them aloud to you on the last day.

C.1 — The contract: 50 / 25 / 15 / 10

Four components. They sum to 100 percent. Nothing else is weighted.

Your course grade is the weighted average of the four percentages:

course grade  =  0.50 × (final %)  +  0.25 × (milestone average %)
              +  0.15 × (quiz average %)  +  0.10 × (presentation %)

Three worked examples, so the arithmetic is not a mystery:

Look hard at rows two and three. The student whose software is better finishes thirty points lower, and that is not a quirk of the rubric — it is the rubric working exactly as designed. Read C.3 and you will see why: only 18 of the final’s 100 points are the software running. The other 82 are the evidence that it is specified, verified, documented, and transferable to somebody who is not you.

C.2 — Why the fourteen milestones carry a quarter of the grade

The fourteen weekly milestones are 25 percent of your grade. There is a gradebook line called “Milestone 6,” it is worth 100 points, and it is due on a Sunday. Weeks 1–7 and 9–15 each ship one, fourteen in all. The Week-8 Design Review lab has no milestone of its own; that week’s evidence is the review package and the two quizzes.

That quarter is the smaller half of what a milestone is worth to you. Read on with the arithmetic attached.

The milestones are the final deliverable, produced one week at a time. The Week-16 rubric awards points for exactly the artifacts the milestones produce — the requirements specification is Milestone 3 and 4, the ADRs are Milestone 5, the test suite is Milestone 11, the runbook and handoff guide are Milestones 13 and 14. Every one of the twelve rubric lines in C.3 is the output of a week you have already been told to do the work in.

So skipping a milestone costs you twice. It costs you the milestone’s own hundred points now — about 1.8 points of your course grade, in the week you skipped it. And it costs you the identical points a second time, deferred to a week that has no hours left in it — a week that already contains a rubric self-audit, a clean-machine test with a real human, a secret sweep, a release, and a thirty-minute talk. It also costs you every downstream week that needed that milestone as an input, which is most of them.

Here is the whole map, so nobody can claim it was unclear:

Milestones are graded twice, and that is deliberate. Each ships its own 100-point rubric, and that score is both a real quarter of your grade and a pace signal you get every single week. Then the same artifact is read again in Week 16 as part of the package. This is not double jeopardy; it is the only structure that makes a sixteen-week project survivable. A thin specification costs you a little in Week 3, while fixing it is cheap — instead of costing you everything in Week 16, when it is not.

If your instructor’s syllabus weights the milestones differently, their syllabus governs and they will say so; this appendix is the book’s contract, not an override of your institution.

What about the milestones’ Medium and Hard tiers? They are stretch work, and a milestone score is capped at 100 — tier work is acknowledged in your feedback but does not push a milestone above full marks. That is on purpose: the quarter is a quarter. What tier work actually buys you is far more valuable than a few tenths of a point. A Hard-tier memo written in Week 5 is not extra credit floating in a gradebook; it is the ADR evidence that earns the decision-records line in Week 16, when the points are real. The extra credit that moves your recorded grade is on the final itself: see C.6.

Coach’s Note — Students who fail this course almost never fail it in Week 16. They fail it in Weeks 3 through 6, quietly, by treating a weekly milestone as an optional one — and then they spend the last month building software with no specification to build against, no tests to prove it, and nothing written down. The milestone schedule is not a set of assignments stacked next to the final. It is the final, disassembled into fourteen pieces small enough to carry.

C.3 — The final: 50 percent

The full specification of what to submit ships with Chapter 16 as Milestone 16. This section is the same rubric, on one page, with the evidence each line wants.

The twelve graded artifacts

One repository, one tag. Twelve artifacts, at these paths or at paths obviously equivalent to them and indexed in the README.

The rubric (out of 100)

Two gates, scored before the rubric is read

Fail either and the rubric is not applied until it is fixed:

1. Access. The grader can open the link. Verify it from a logged-out private browser window. If the repository is private, the invitation must be accepted, not merely sent.
2. No live credential anywhere in the working tree or the history. If the sweep finds one, rotate it first, then clean, then resubmit. A pushed key is a compromised key.

Where the points actually are

Only 18 of 100 are the software running. The other 82 are the evidence that the software is specified, verified, documented, and transferable. Do not spend your last week on features. Spend it on the eighty-two.

C.4 — What evidence earns each line

A grader does not score intentions. Each line below says what full marks looks like and the cheapest way students lose it.

Working software — 18. Full marks: a fresh clone of the submitted tag runs, and every Must-priority requirement either demonstrably works or appears in the defect log as a rated, disclosed open item. Lost by: a repository that only runs on the author’s laptop; a Must silently missing with no defect entry — the omission costs less than the concealment.

Requirements specification — 12. Full marks: every requirement has a unique ID, a MoSCoW priority, and acceptance criteria a stranger could check without asking you a question; the traceability runs forward to tests and backward from tests to IDs. Lost by: “the system shall be user-friendly,” and by a specification frozen in Week 4 that no longer describes what shipped. Amend it through change control; do not let it rot.

Test plan, suite, and recorded results — 12. Full marks: a plan naming levels, environment, and exit criteria; automated tests that actually run; a recorded execution at the submitted tag; every test traceable to a requirement ID. Lost by: tests that pass because they assert nothing, and a results file dated three weeks before the tag.

Technical specification — 10. Full marks: context and component views, module responsibilities, interface contracts, the data model, and the critical-path flows — as built. Where the build diverged from the Week-6 design, an ADR says when and why. Lost by: submitting the Week-6 document unchanged. A grader compares it to the code; drift you did not document reads as drift you did not notice.

README — 10. Full marks: what it is, who it is for, prerequisites, install, run, test, configure, a document index, license, and status — proven by the recorded clean-machine test in C.5. Lost by: a README that was never executed by a human being who is not you.

Runbook and handoff guide — 8. Full marks: how to operate it, what normal looks like, what to do when it breaks, how to back up and roll back — plus a handoff document that tells a successor what to do on day one. Lost by: writing them for yourself. The reader is a competent stranger with no context and no way to ask.

Hours log — 6. Full marks: all sixteen weeks, session-level, with the estimate-versus-actual analysis that Week 7’s plan was built to be checked against. Lost by: backfilling. A log of round numbers on tidy dates is visible from across the room, and it is worth less than an ugly honest one.

Architecture decision records — 5. Full marks: at least five, each with context, the options considered, the decision, and the consequences you accepted. Lost by: records that list only the option you picked. A decision with no rejected alternative is not a decision; it is a default.

Defect log — 5. Full marks: real defects found by real testing, with severity, priority, status, and resolution, current as of the tag, including the ones still open. Lost by: an empty log. Nobody believes it, and it costs you the line plus the grader’s trust in every other line.

Change log, tag, license — 5. Full marks: a dated CHANGELOG.md entry for the submitted version, an annotated tag pushed to the remote, and a real license whose SPDX identifier matches what the README claims. Lost by: a lightweight tag, a moved tag, or a README that says MIT next to a file that says something else.

AI usage log and integrity statement — 5. Full marks: specific entries kept all semester, headed by the signed statement in C.12. Graded on specificity, not abstinence. Lost by: vagueness. See C.11.

Retrospective — 4. Full marks: numbers pulled from your own logs, one decision you would remake, and how you would spend the same 240 hours differently. Lost by: feelings with no figures.

C.5 — The clean-machine acceptance test

This is a required, recorded part of the README line, and it is the hardest single standard in the course.

Setup. A person who is not you. A machine that is not yours. Your README, and nothing else. The exact tag you intend to submit.

The rule: you do not speak. Not a hint, not a correction, not a sympathetic noise. You sit with a notebook and write down everything the tester has to guess, ask, or look up. Each one is a documentation defect.

Record it in docs/test-results.md: date, tester, operating system, tag, commit SHA, minutes to first successful run, and every gap found. Then fix the gaps and note the fixes. A recorded failing test that you fixed and re-ran scores better than a passing test you cannot evidence — because the second one is not a test, it is a claim.

Run it twice: once in Week 13, when there is time to fix what it finds, and once in Week 16 against the tag.

C.6 — Extra credit on the final

Extra credit lives here and nowhere else. The fourteen milestones cap at 100 apiece (see C.2); the quizzes and the presentation have no tiers. The two tiers below are the only work in the course that can push a recorded score past full marks.

The final carries two optional tiers, on its own 100-point scale:

• Medium tier — up to +25. Evidence past the bar: a live deployment with its cost stated and dated, green CI at the submitted tag, measured non-functional numbers with the method used, a second clean-machine test on a different operating system, a successor backlog of well-formed issues, a dependency and license inventory, or a security review. Two done well beat five done thinly.
• Hard tier — up to +25 more. The Successor’s Brief: a 3–4 page memo to the engineer who inherits your project — the decision you would reverse with a migration cost in hours, the parts of your own system you do not trust, the twelve-month cost of ownership, and your AI accountability statement. Graded on judgment, specificity, and honesty. A memo that admits nothing scores near zero.

The presentation has no extra-credit tier. It is a performance, not a build; the only way to raise the score is to rehearse.

Whether your institution’s gradebook records a component above 100 is a local policy question. Ask in Week 14, not Week 16.

C.7 — The presentation: 10 percent

Delivered live in Week 16, built in Week 15. Thirty minutes total, including questions unless your institution schedules Q&A separately. The complete brief — format, delivery logistics, the recorded-fallback requirement — is The Capstone Presentation assessment that ships with Chapter 15. The scoring is here.

The rubric (out of 100)

The clock

The recommended allocation, which you build into your run sheet:

You may reallocate. You may not exceed thirty minutes, drop the demo, drop the evidence, or drop the “what did not get done” section, and the demo is capped at ten minutes however you rebalance. You get a visible signal at 25 and at 29 minutes; at 30:00 you are stopped wherever you are. If your evidence slides are still ahead of you, those points are gone — which is exactly why the run sheet exists.

Required regardless: a recorded demo, trimmed to the demo’s time budget, that plays with the network disabled, stored on the presenting machine and in the repository. Using it costs you nothing. Committees routinely score a clean fifteen-second recovery above a demo that never broke. What costs you is debugging on stage.

The podium is closed to AI. Preparation is open; no assistant may be consulted during the talk or the Q&A. Expect to be asked what an assistant contributed to your project, and answer from your ai-usage log.

C.8 — The pace table: where you should be every Sunday night

Sixteen weeks, about fifteen hours a week, 240 hours total. The budget has no slack in it beyond the buffer you declare yourself in Week 7 — which is the point of declaring one.

How to read this table. The artifacts govern, not the hours. Fifteen hours logged with nothing committed is not a week on pace; it is a week you should write an honest paragraph about. Every Sunday, do two things that take four minutes: run your hours report, and read your row. If the artifacts in your row exist in your repository, you are on pace. If they do not, you are behind by however many rows are incomplete — say the number out loud.

Coach’s Note — The 120-hour line in Week 8 is not decorative. It is the last week where a correction is cheap. A student who is thirty hours and two artifacts behind at Week 8 can still finish well by cutting scope through change control. The same student at Week 13 cannot, because Weeks 13 through 16 are already spoken for. Count the cost before you build the tower (Luke 14:28) — and then count it again at the halfway mark, when the tower is real enough to measure.

C.9 — What falling a week behind actually costs

A week behind is fifteen hours of debt against a budget with no slack in it. There are exactly three ways to settle it, and only one of them is professional.

1. Repay it with extra hours. Two weeks at 22 hours instead of 15. This is the option everybody believes they will take. Almost nobody does, and it works only in Weeks 1–8.
2. Cut scope through change control. Write the change request, do the impact analysis, move a Must to a Won’t with a dated reason, re-baseline, and tell your instructor in writing that week. This is the professional move and it costs you almost nothing on the rubric — a smaller Must set, honestly specified and fully delivered, scores far better than a large one half-built.
3. Do nothing and pay twice. The default, and the most expensive. You take the zero on the milestone in the week you skipped it, and then you pay for the missing artifact again in Week 16 — the week that already has a presentation, a self-audit, a clean-machine test, and a release in it.

The downstream bill

The part of the debt you cannot repay

Some artifacts are not reconstructible in Week 16 at any price, because the evidence no longer exists:

• an elicitation conversation with a real user, in Week 3, when the requirements were still open;
• a dated verification of a vendor’s terms as they were then;
• an honest hours log — sixteen weeks of sessions cannot be remembered;
• the defects that construction finds, which only appear if construction happened on schedule;
• a spike result, which only teaches you something if it runs before the decision;
• estimate-versus-actual calibration, which requires estimates written before the work;
• a commit history showing work on forty distinct days.

Manufacturing any of those in Week 16 is not catching up. It is fabrication, it is an integrity violation under C.12, and it is the easiest kind to detect, because a repository’s history is a timestamped witness that does not cooperate with revision.

The recovery protocol, when you are behind

1. Measure it honestly. Run your hours report; count the pace-table rows whose artifacts are missing. Write the number down.
2. Do the remaining-capacity arithmetic. From the pace table: at the end of Week 10 there are six weeks and 90 hours left, of which Weeks 13–16 (60 hours) are documentation, release, presentation, and audit — already committed. What is genuinely discretionary is a fraction of Weeks 11 and 12. Do that sum for your own week before you decide anything.
3. Cut scope, never documentation. More code cannot buy back the 82 points that are not code. A Must you cut on purpose, with a written rationale, costs a fraction of a Must you fail to deliver silently.
4. Write the change request and re-baseline through the machinery you stood up in Week 8, and tell your instructor the same week — not in Week 15.
5. Never backfill a log. Write the true row, including the row that says the week was lost. An honest bad week is worth points; an invented good one is worth an integrity referral.

C.10 — The repository structure a grader expects

Adapt it freely — but if a grader cannot find an artifact in under thirty seconds, the README must point at it.

your-capstone/
├── README.md
├── LICENSE
├── CHANGELOG.md
├── .gitignore
├── .env.example                    # placeholder values, committed on purpose
├── src/                            # or app/, cmd/, lib/ — whatever your stack calls it
├── tests/
├── script/                         # setup script, seed script, or a container definition
├── docs/
│   ├── charter.md                  # M1–M2: the problem, the users, the scope decision
│   ├── requirements.md             # M3–M4: FRs, NFRs, constraints, traceability, DoD
│   ├── architecture.md             # M6: the technical specification, as built
│   ├── baseline.md                 # Week 8: what is frozen, at which commit, with which open items
│   ├── review/                     # Week 8: reviewer brief, defect log, review report, halfway audit
│   ├── test-plan.md                # M11
│   ├── test-results.md             # M11 + the Week 16 clean-machine record
│   ├── defect-log.md               # M11 onward
│   ├── hours-log.csv               # M1 onward, all sixteen weeks
│   ├── runbook.md                  # M13–M14: operate, back up, roll back
│   ├── handoff.md                  # M14: day one for your successor
│   ├── ai-usage.md                 # every week + the integrity statement
│   ├── retrospective.md            # M16
│   ├── plan/                       # M7: wbs.md, schedule.md, risk-register.md
│   ├── adr/                        # M5 onward: 0001-choose-the-stack.md, ...
│   └── diagrams/
└── .github/workflows/ci.yml        # M9, or your CI provider's equivalent

Equivalent paths are fine. The milestone chapters name a few artifacts slightly differently than the final rubric does, because each week names the document for the job it is doing that week. The rubric accepts any obviously equivalent path that the README indexes:

Two hard constraints on naming. No live secrets, ever — .env.example carries placeholders and the real file is ignored. And nothing in your repository may be named after a course file (chapter, exercises, a numbered milestone, project-arc). Your repository is a professional artifact and it reads like one.

C.11 — The AI-use and disclosure policy

This course permits and expects assistant use. The rule is one sentence, and it is the spine of the whole library:

The human stays in the loop where the judgment lives. AI accelerates; you decide, you verify, and you are accountable.

The practical test is not how many characters a model typed. It is this: can you explain every line and every claim in your repository, in your own words, under questions, without the tool in front of you? If not, it does not ship.

The three zones

Three things are never delegated, in any tier: an architecture decision record, the Week-16 Successor’s Brief, and the retrospective. Those are the artifacts whose entire value is that a human owned a judgment.

The log format

Copy the Week-1 template into docs/ai-usage.md. It has three parts — the policy header written once, the tools you have decided to use, and the entries table that grows all semester.

# AI Usage Log — <project name>

**Owner:** <name> · **Policy set:** <YYYY-MM-DD> · **Last entry:** <YYYY-MM-DD>

## Policy
Spine rule. The human stays in the loop where the judgment lives.
The line I do not cross: <one sentence, in your words>

## Tools
| Tool / product | Model or version, as the tool reported it | What I use it for | What I never use it for |

## Entries
| Date | Tool / model | What I asked | What I kept | What I changed | How I verified |

The columns are the requirement; the exact layout is not. A four-column variant (week, tool, used for, what you changed and verified) earns the same points if it carries the same information. What it must always carry is what you rejected, because that is the clearest possible evidence that a human was in the loop.

A bad disclosure:

I used an AI assistant to help with some of the coding and to fix bugs.

A real disclosure:

Notice what the good version does: it names the time the tool was wrong and what you did instead. Do not guess at a model version you cannot see — write what the tool displayed, or write “version not shown.”

This line is graded on specificity, not on abstinence. Nobody is penalized for using assistance well. People are penalized for vagueness — and for undisclosed use, which is not a rubric deduction at all.

Coach’s Note — Your first employer will ask you some version of one question: what is your rule for what you will sign your name to? The ai-usage log is sixteen weeks of practice answering it with evidence instead of adjectives. Write the row the day it happens; ninety seconds then, or an hour of reconstruction and a weaker answer in Week 16.

C.12 — Academic integrity

You will sign this. It goes at the top of docs/ai-usage.md and into the submission block.

Integrity statement. This repository is my own work. I wrote or directly supervised, reviewed, and understand every line in it, and I can explain any part of it on request. All assistance I received — from AI tools, documentation, tutorials, libraries, classmates, or anyone else — is disclosed in docs/ai-usage.md. Third-party code and content are attributed and used within their licenses. No requirement, test result, measurement, or log entry in this repository is fabricated.

— <your full name>, <date>

What is not acceptable, in any tier:

• submitting code you cannot explain;
• a fabricated test result, measurement, hours-log entry, or interview;
• an undisclosed third-party component;
• presenting someone else’s project as your own;
• a number in your presentation that no artifact in your repository supports.

These are integrity violations, not rubric deductions. They are handled under your institution’s academic-integrity policy, which governs over anything in this book. If you are ever unsure whether something crosses the line, the cost of asking your instructor is one email, and the cost of not asking is your degree.

“One who is faithful in a very little is also faithful in much, and one who is dishonest in a very little is also dishonest in much” (Luke 16:10, ESV). Everything in this course that looks like paperwork — the honest log, the disclosed defect, the dated verification, the gap named before anyone finds it — is the same discipline in different clothes. And the standard runs both directions: “Let what you say be simply ‘Yes’ or ‘No’” (Matthew 5:37, ESV) rules out inflating your work and the false modesty that hides it. Say what is so.

C.13 — The complete final submission checklist

Do this in order, the day before your presentation. The full procedure ships with Chapter 16; this is the checklist.

Freeze and audit

• Feature freeze declared; only documentation, audit fixes, and the change log since
• Fresh clone of the tag audited against all twelve rubric lines, each with a written evidence note
• Gaps fixed in points-per-hour order (a missing LICENSE is 5 points and four minutes)

Prove it

• Clean-machine test run by a human who is not you, on a machine that is not yours, recorded
• Every open Must requirement disclosed in the README, the release notes, and the defect log
• Test suite executed at the submitted tag and the results recorded with the date

Artifacts present

• Working software, requirements specification, technical specification (as built), ADRs (≥ 5)
• Test plan, suite, and results traced to requirement IDs; defect log current at the tag
• README, runbook, handoff guide
• Hours log complete for all sixteen weeks, including the bad ones, with estimate-versus-actual
• CHANGELOG.md entry written and dated; LICENSE present and matching the README
• docs/ai-usage.md specific, current, and headed by the signed integrity statement
• docs/retrospective.md written from the logs, with at least one rule that has a number in it

Gates

• Secret sweep clean on the working tree and the history; anything found rotated first
• Repository link opened successfully from a logged-out private browser window

Release and submit

• Annotated tag pushed (never move an existing tag); commit SHA copied
• Release published with real release notes: what it is, what works, what does not, setup time, verification date
• Submission block pasted and submitted — before the presentation

Repository:   https://github.com/<owner>/<repo>
Tag:          v1.0.1
Commit SHA:   <40 hex characters>
Access:       public  |  <grader-username> invited and accepted on <date>
Verified on:  <OS/runtime> — clean-machine test <date>, tester <name or initials>
Known gaps:   <open Must requirements by ID, or "none">
Integrity:    <the statement from C.12, signed>

C.14 — The sixteen weekly quizzes: 15 percent

One quiz a week, Weeks 1 through 16, auto-graded, drawn from a pool so no two attempts are identical. Ten items each, covering the phase you are supposed to be in that week. Week 8 carries two: its ordinary weekly quiz, and a separate 30-point Design Review Checkpoint that is cumulative over Weeks 1–8. Both sit inside this same 15 percent — the checkpoint is not a fourth component.

The settings the course ships with (your syllabus governs if your instructor changes them):

Unless your syllabus says otherwise, this component is scored on points, not on a flat average: the sixteen weekly quizzes are 10 points each and the Design Review Checkpoint is 30, so the component totals 190 points and the checkpoint is worth about a sixth of it. The checkpoint gets one attempt and 45 minutes; the weekly quizzes get two attempts and 15.

The quizzes exist for two reasons, and the second is the real one. The first is ordinary: they check that the vocabulary of the life cycle is actually in your hands — that you can say what a non-functional requirement is, what an ADR records, what a walking skeleton proves. You will be expected to speak that language in every interview you take next spring.

The second is that they are the early-warning system that catches a slipping week before the milestone does. A quiz you cannot pass is a week whose reading you skipped, and a week whose reading you skipped is a milestone you probably did not ship. Fifteen percent is small enough that no single quiz can hurt you and large enough that a pattern will. When you find yourself guessing on Week 6’s quiz, that is not a quiz problem. That is the late start, ringing a bell in Week 6 instead of Week 16 — which is the entire mercy of the design.

C.15 — What a grader is actually asking

Strip away the tables and every line of every rubric in this appendix is one question, asked twelve different ways:

Could a competent stranger take this over on a Tuesday afternoon?

They clone it and are running in eleven minutes. Every claim in the README is backed by a requirement ID with criteria they could verify themselves. The architecture document matches the code in front of them, and where it does not, an ADR says when and why. They do not have to hunt for what is broken, because you listed it first, with severities. The hours log has a bad week in it, honestly recorded. The ai-usage log names things you rejected. The retrospective has numbers.

And somewhere in the first twenty minutes they think: this person is careful, and I can trust what they wrote down.

That reaction is the grade, and it is also the job. Every professional reputation you will ever have is built out of exactly that reaction, repeated — which is why the contract is shaped this way. Not to measure how clever you are. To measure whether your work can be trusted by somebody who cannot ask you a question.

Coach’s Note — Print this appendix. Put it where you plan your week. Nothing in it will change between now and delivery day, and everything in it is earnable fifteen hours at a time. There is no curve, there is no mystery, and there are no surprises in Week 16 — only deadlines, and you have all of them in front of you today.

Related: Appendix A — your workbench, including the no-admin browser path · Appendix B — every artifact on this rubric as a blank template, a worked example, and a deliberately bad version · Appendix D — fifty sized project ideas · Appendix E — the glossary. Start the work in Chapter 1; the halfway audit is in Chapter 8; the final is specified in Chapter 16.