Course resource
Capstone Submission Guide
What to submit, how it is assessed, and what "good" looks like.
What to submit
Five things. None should take more than an hour once the build is done.
1. The write-up (one page)
PROBLEM Who had it, how often, what it cost
BASELINE The measurement, before
WHAT I BUILT Plain English, two paragraphs, no jargon
RESULT The measurement, after — including what did not improve
WHAT BROKE The failures and what you learned
NEXT What you would do differently
2. The SOP — one page, from the documentation template.
3. Evidence it works — a short screen recording, or screenshots of real input and real output. Redact anything confidential.
4. The numbers — before and after, with a sentence on how you measured. "It feels faster" is not a measurement.
5. The prompts — the actual prompts, so an assessor can see the constraints you wrote.
How it is assessed
| Area | 1 point | 2 points | 3 points |
|---|---|---|---|
| Problem | Vague or hypothetical | Real and specific | Real, specific, and clearly costly |
| Design | A single prompt | A repeatable process | A system with filters, error handling and a human step |
| AI use | Basic prompting | Constrained prompts, right model per step | Strong prompt design, verification built in |
| Measurement | No baseline | Before and after stated | Measured properly, including what did not improve |
| Robustness | Works on the happy path | Handles common failures | Error paths, logging, documented fallback |
| Documentation | Minimal notes | Understandable SOP | Someone else could run it unaided |
| Honesty | Only successes described | Some limitations noted | Failures and their fixes clearly described |
Bands: 9–13 complete · 14–18 strong · 19–21 portfolio-ready.
What separates a strong capstone from a complete one
Three things, consistently:
A real number. "Reduced Monday invoice chasing from 40 minutes to 6" beats any description of sophistication.
A documented failure. Describing what broke, why, and how you fixed it is the clearest evidence you actually built it rather than followed a tutorial. Assessors read this section first.
Someone else could run it. The SOP that names how to stop it, what breaks if it does, and who can rotate the credentials.
What will not earn marks
- Scope. A large unfinished system scores below a small finished one.
- Tool choice. Nobody cares which platform. The problem going away is the point.
- A polished demo of something you do not use. If you built it for the submission and will not run it next month, it will show.
- Claiming no problems. Every real build breaks. A write-up with no failures reads as one that was not run enough.
Before you submit
- It has run on real data, not just test data
- I have used it at least five times
- The baseline was measured, not estimated
- Confidential data is redacted from every screenshot
- No customer personal data in the submission
- The SOP names how to stop it
- The write-up includes at least one thing that went wrong
- Someone who was not involved has read the SOP and understood it
Submitting
Send the five items to [email protected] with the subject:
Capstone — [YOUR NAME] — [COHORT START DATE]
Attach the write-up, the SOP and the evidence, or send links if they live in a shared workspace. Make sure any link is actually accessible from outside your organisation — the most common submission problem is a permissions error.
You will get written feedback against the table above, plus one specific suggestion for what to build next.
The certificate
Issued on a complete submission scoring 9 or above. It names the project and the measured result, not just attendance — which is what makes it worth showing anyone.
If you are not going to finish
Submit anyway. A partial build with an honest write-up of where you got stuck is assessable, and the feedback is more useful than for a finished one.
The failure mode we see most is people going quiet because it is not perfect. The half-built thing plus a clear account of the blocker is worth more than silence, and it is usually a smaller gap than it feels.