Chapter 35 — Capstone proposal
Lesson map
Lesson 35 published. Map, example, EX069.
flowchart TD
N0["Learning outcomes"]
N1["35.1 Choosing a problem"]
N2["35.2 Proposal structure"]
N3["35.3 Authorization and ethics"]
N4["35.5 Practical activity"]
N5["35.7 Supervisor agreement"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX069"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["35.1 Choosing a problem"]
N2["35.2 Proposal structure"]
N3["35.3 Authorization and ethics"]
N4["35.5 Practical activity"]
N5["35.7 Supervisor agreement"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX069"]
[Learning outcomes]
|
v
[35.1 Choosing a problem]
|
v
[35.2 Proposal structure]
|
v
[35.3 Authorization and ethics]
|
v
[35.5 Practical activity]
|
v
[35.7 Supervisor agreement]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX069]
Learning outcomes
You will (1) choose a capstone problem in quantum and post-quantum security; (2) write aims, scope, methods and deliverables; (3) plan authorization, ethics and data handling; and (4) define success criteria and risks.
35.1 Choosing a problem
A good capstone addresses a real decision, can be completed in one academic year, and uses evidence the student can lawfully obtain. Suitable topics: an inventory and prioritisation method for a synthetic organization; a lab comparison of hybrid configurations; an archive-protection design; a crypto-agility refactoring of a small open-source tool; or a study of vendor PQC roadmaps from public documents.
The best topics come with a named person who would use the result. A study that answers a question nobody is asking is harder to motivate and to evaluate, however good its method.
35.2 Proposal structure
State the problem and why it matters; the aims and research questions; scope (in and out); method; data and authorization; deliverables (report, code, lab records); timeline with milestones; risks and mitigations; and success criteria. Success criteria should be observable, for example "a reproducible lab showing negotiated groups for five client types".
A proposal of three or four pages is enough. The most important part is often the part on risks: what happens if a library, dataset or interview access does not arrive in time, and what the fallback plan will be. Reviewers look for criteria that can clearly be met or missed.
35.3 Authorization and ethics
Any work on real systems needs written authorization from the owner. Prefer synthetic or lab environments. Plan data minimisation and retention. If interviews are included, plan consent and anonymisation. If you might find vulnerabilities in products, plan coordinated disclosure.
Write these plans down before starting, and have them checked by the supervisor and, where interviews are involved, by the ethics process of your institution. Record any data you will not collect and why. For projects based on HCU, all data is synthetic, which removes most risks but not the need to describe how the model was built.
35.4 Worked example
Proposal (synthetic): "Prioritising HCU's quantum migration with a lifetime-weighted CBOM." Aims: build a CBOM for a synthetic 60-asset HCU model; rank flows using Mosca's inequality swept over z; validate ranking with three practitioner interviews. Scope: key establishment and signatures; excludes QKD. Data: synthetic model, public standards, consented interviews. Deliverables: Python tool, report, lab record. Success: ranking stable across z from 10 to 25 years for the top five flows, or a documented explanation where it is not.
The interview plan was reviewed for consent before approval.
35.5 Practical activity
Draft your proposal using the structure above, then exchange with a peer for review against the success-criteria test.
The reviewer should check whether each success criterion could clearly be judged met or not met at the end of the year, and whether the scope fits the time available. Revise the proposal using their comments, and keep both versions so that the changes are visible to your supervisor. If the reviewer could not judge a criterion, rewrite it until they can.
35.6 Common errors and limits
- Scope too large for one year.
- Unobservable success criteria.
- Assuming access to real systems without authorization.
- Choosing a method before the question is clear.
- Leaving the timeline without milestones, so delays are noticed too late.
- Planning interviews without allowing time for ethics approval.
- Writing aims that describe activity, such as studying a topic, rather than an answer that can be judged.
Each makes the final evaluation harder to do fairly. A peer review of the proposal usually catches them early.
35.7 Supervisor agreement
Before starting, agree the proposal with your supervisor in writing, including what counts as success and what happens if a key dependency fails — for example, if a library needed for the lab is not released. A one-paragraph fallback plan prevents a late scramble and makes it clear that a well-documented negative result is an acceptable outcome.
The agreement is revisited if the scope changes. Note any change in a dated addendum signed by both of you, so that the final evaluation is measured against the agreed version rather than the first draft.
Exercises
- EX069 — Success criteria. Rewrite "the tool should work well" as two observable success criteria. Rubric: 3 = measurable, relevant criteria.
- EX070 — Risk table. List three project risks for the worked proposal with mitigations. Rubric: 3 = plausible risks and mitigations.
Synthesis
A capstone proposal states a decision-relevant problem, bounded scope, lawful evidence, observable success criteria and managed risks.
Continue studying — chapter 35 of 40
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →