Chapter 35 — Capstone proposal
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 Choosing a capstone"]
N2["35.2 Proposal contents"]
N3["35.3 Ethics and authorization"]
N4["35.4 Inventory as a starting point"]
N5["35.4b Supervisor agreement"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX103"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["35.1 Choosing a capstone"]
N2["35.2 Proposal contents"]
N3["35.3 Ethics and authorization"]
N4["35.4 Inventory as a starting point"]
N5["35.4b Supervisor agreement"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 Choosing a capstone]
|
v
[35.2 Proposal contents]
|
v
[35.3 Ethics and authorization]
|
v
[35.4 Inventory as a starting point]
|
v
[35.4b Supervisor agreement]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) propose a capstone project in AI security with a clear problem, objectives and deliverables; (2) define requirements, methods and evaluation; (3) plan ethics, authorization and data handling; and (4) build a realistic timeline with risks.
35.1 Choosing a capstone
Good capstones solve a concrete problem with an AI-security component, produce a working artefact and evidence, and can be finished in two semesters. Options: a secured retrieval chatbot with policy enforcement and an evaluation harness; a poisoning-detection pipeline; an AI inventory and risk-assessment tool for a small organisation; a monitoring service for abuse of model APIs.
Rina chose the first option because LCH had a real booking flow to model and she had already studied its weaknesses, so the threat model was ready.
35.2 Proposal contents
Problem and stakeholders; objectives; scope and exclusions; requirements with verification methods; method and architecture; evaluation plan with metrics, test sets and acceptance criteria; ethics and authorization; data management; timeline with milestones; risks and mitigations; expected deliverables.
Each part answers a question the supervisor will ask. Scope and exclusions say what will not be done, so nobody expects a voice channel. Requirements with verification methods show how success will be judged. The ethics part states that all patient data is synthetic. The timeline leaves room for a second round of testing, since the first round usually finds problems that need fixing.
35.3 Ethics and authorization
State which systems and data you will use and under whose authority. Prefer synthetic data and isolated environments. If working with a real organisation, obtain written authorization and agree data handling.
Rina's proposal named LCH's security lead as the person authorising access to staging, attached the signed scope, and stated that no real patient data would leave LCH. Her university's ethics office reviewed the plan because the independent testers were classmates, and confirmed it needed no further approval since no human participants' data was collected beyond their test cases.
35.4 Inventory as a starting point
Many capstones begin by understanding the AI landscape of an organisation. The inventory lab scores systems by exposure, autonomy, data sensitivity and untrusted input, suggesting where to focus.
"""Lab V: an AI system inventory scored for review priority (synthetic).
Each system lists exposure, autonomy, data sensitivity and whether it reads
untrusted content; mapping to OWASP LLM Top 10 (2025) IDs is illustrative."""
import json
inv = json.loads("""[
{"name":"support-chatbot","exposure":"public","autonomy":"tools","data":"customer","untrusted_input":true},
{"name":"invoice-ocr-model","exposure":"internal","autonomy":"none","data":"financial","untrusted_input":true},
{"name":"code-assistant","exposure":"internal","autonomy":"suggest","data":"source","untrusted_input":true},
{"name":"churn-predictor","exposure":"internal","autonomy":"none","data":"customer","untrusted_input":false},
{"name":"hr-cv-screener","exposure":"internal","autonomy":"decide","data":"personal","untrusted_input":true}
]""")
E = {"public": 3, "internal": 1}; A = {"none": 0, "suggest": 1, "tools": 3, "decide": 3}
D = {"customer": 2, "financial": 2, "source": 2, "personal": 3}
for s in inv:
s["score"] = E[s["exposure"]] + A[s["autonomy"]] + D[s["data"]] + (2 if s["untrusted_input"] else 0)
risks = []
if s["untrusted_input"]: risks.append("LLM01")
if s["autonomy"] in ("tools", "decide"): risks.append("LLM06")
if s["data"] in ("customer", "personal"): risks.append("LLM02")
s["owasp"] = ",".join(risks) or "-"
for s in sorted(inv, key=lambda s: -s["score"]):
print(f"{s['name']:18s} score={s['score']:2d} owasp={s['owasp']}")
Expected output:
support-chatbot score=10 owasp=LLM01,LLM06,LLM02
hr-cv-screener score= 9 owasp=LLM01,LLM06,LLM02
code-assistant score= 6 owasp=LLM01
invoice-ocr-model score= 5 owasp=LLM01
churn-predictor score= 3 owasp=LLM02
In the lab's synthetic inventory, the public support chatbot with tools scores 10 and the CV screener that decides scores 9, so both rise to the top. The churn predictor, with no untrusted input, scores 3. Rina used the same scoring for LCH: Ask Lumen came first, followed by DocSort and NoShow, which confirmed her choice of capstone.
35.4b Supervisor agreement
Agree the proposal with your supervisor and, where relevant, the client. Record decisions and changes after approval in a change log, so that the final assessment compares what you delivered with what was agreed.
Rina's change log recorded one approved change: removing the voice channel from scope, since the staging copy had no voice interface. The entry gave the date, the reason and the supervisor's approval, so the examiner later saw that the narrower scope was agreed, not a quiet omission of something hard.
35.5 Worked example (synthetic LCH case)
Rina proposed "Safe Booking Assistant": a re-implementation of Ask Lumen's booking flow with delegated tokens, a policy service, confirmation, grounding checks and a red-team harness, evaluated on 1,000 synthetic conversations. Exclusions: voice channel, non-English languages. Acceptance criteria included zero cross-patient bookings (upper bound < 0.5%) and completed bookings ≥ 93%.
The bookings threshold was set just below the 94% achieved in the earlier confirmation study, so the capstone had to keep usability close to what LCH had already accepted. A thousand conversations was chosen because, with zero failures, it gives an upper bound under the half-percent target.
35.6 Errors and limits
- Capstones without measurable acceptance criteria.
- Missing authorization.
- Timelines with no slack.
Without measurable acceptance criteria, a capstone can only describe what was built, not whether it works. Missing authorization can end a project when the organisation discovers testing it did not approve. Timelines without slack fail when the first evaluation finds problems, as it usually does; Rina's plan left three weeks between the first full test run and the final evaluation for exactly that reason, and she used all of them.
Exercises
- EX103 — Proposal parts. List ten proposal sections. Rubric: 3 = ten; 2 = eight; 1 = five; 0 = fewer.
- EX104 — Lab reading. Which system tops the inventory and what drives its score? Rubric: 3 = support-chatbot, 10: public, tools, customer data, untrusted input; 2 = name; 1 = vague; 0 = wrong.
- EX105 — Acceptance. Write two acceptance criteria for an AI-monitoring capstone. Rubric: 3 = measurable with thresholds and sample sizes; 2 = one; 1 = vague; 0 = none.
Synthesis
A capstone proposal turns an AI-security idea into an authorised, measurable plan with clear scope and acceptance criteria.
Continue studying — chapter 35 of 40
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →