Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Choosing the project"]
N2["44.2 Project plan"]
N3["44.3 Baseline approval"]
N4["44.4 Teamwork"]
N5["44.4b Ethics and authorization for the capstone"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX130"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["44.1 Choosing the project"]
N2["44.2 Project plan"]
N3["44.3 Baseline approval"]
N4["44.4 Teamwork"]
N5["44.4b Ethics and authorization for the capstone"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Choosing the project]
|
v
[44.2 Project plan]
|
v
[44.3 Baseline approval]
|
v
[44.4 Teamwork]
|
v
[44.4b Ethics and authorization for the capstone]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define a capstone AI-security engineering project with a client, requirements and constraints; (2) plan it with milestones, risks and verification; (3) produce the system requirements and architecture baseline; and (4) obtain approval to build.
44.1 Choosing the project
A good capstone has a real (or realistic synthetic) client, an AI component with meaningful security risk, a deliverable that can be built and verified in two semesters, and a clear evaluation. Examples: a secured RAG assistant with enforcement and evaluation harness; a poisoning-resistant data pipeline; a monitoring service for extraction and abuse.
Two semesters pass quickly, so a project that needs months of data collection before anything can be built is usually too large. The examples share a pattern: a clear threat, a component the team can build and control, and a measurement that will show whether it works. A client gives the project real requirements and a reviewer outside the university.
44.2 Project plan
Include: problem statement; stakeholders; scope and exclusions; requirements (functional, security, statistical, operational) with verification methods; architecture with trust boundaries; threat model; verification plan; risk register for the project itself (data access, compute, team availability); milestones and deliverables; ethics and authorization.
The plan's risk register covers the project, not the system: a delayed data agreement, a cloud budget that runs out or a team member falling ill. Each risk has a mitigation, such as synthetic data prepared in advance. Milestones are spaced so that each produces something the panel can inspect, which keeps progress visible and problems early.
44.3 Baseline approval
A review panel approves the baseline: requirements, architecture and plan. After approval, changes go through change control, so scope creep is visible and justified.
Change control does not forbid change. It asks that each change state what it adds, what it costs and which requirements or tests it affects, and that the panel or client agree. A team that adds image attachments to Bulletin Gate halfway through must show the schedule still works and the new threats are covered, or defer the feature as originally planned.
44.4 Teamwork
Assign roles (lead, security architect, ML engineer, test lead) but rotate review duties so everyone understands the whole. Keep decisions in ADRs and meetings brief with recorded actions.
Fixed roles make responsibility clear, but rotating reviews spreads understanding, so the project survives if one member is absent. A security architect reviewing the ML engineer's data pipeline, and the reverse, catches problems neither would see alone. Short meetings with written actions avoid decisions that exist only in someone's memory, and decision records explain choices to the panel later.
44.4b Ethics and authorization for the capstone
Even synthetic projects need an authorization note: which environments, data and accounts the team may use, and what is forbidden (production systems, real personal data, public AI services beyond their terms). If a client provides real data, agree data-protection terms in writing before receiving it.
For Bulletin Gate, the note named the staging copies of Wrench and the bulletin store, synthetic or supplier-cleared bulletins only, and no connection to the production work-order system. It also covered the panel's condition: the other team writing adaptive attacks was authorised to attack only Bulletin Gate's staging instance, and its attack strings were stored with the evidence rather than shared outside the course.
44.5 Worked example (synthetic NRS case)
Sam's team chose "Bulletin Gate": a service that ingests supplier bulletins, extracts structured maintenance facts with a quarantined model, flags instruction-like content, and passes only structured records to Wrench. Requirements included: extraction accuracy ≥ 95% on 500 held-out bulletins; zero instruction text in output records (schema-enforced); ≤ 2 s median latency; full provenance. Exclusions: image attachments (deferred). The panel approved with one condition: add an adaptive-attack test set written by another team.
The schema-enforced requirement is notable because it is absolute rather than statistical: the output format has no field that can hold free instruction text.
44.6 Errors and limits
- Capstones too large to verify.
- Requirements without verification methods.
- No change control after approval.
An oversized capstone ends with a system that is partly built and barely tested, which makes a weak dossier. Requirements without verification methods cannot be shown to pass and invite arguments at the final review. Without change control, scope drifts quietly, deadlines slip and the panel cannot tell what was approved. Sam's team reviewed scope against verification effort at every milestone. Cutting scope early cost less than cutting tests late.
Exercises
- EX130 — Scope. Write scope and exclusions for a capstone that secures a RAG assistant. Rubric: 3 = clear in-scope items and justified exclusions; 2 = one side weak; 1 = vague; 0 = none.
- EX131 — Risk register. List three project risks and mitigations. Rubric: 3 = three relevant with mitigations; 2 = two; 1 = one; 0 = none.
- EX132 — Panel condition. Why did the panel require another team to write adaptive attacks? Rubric: 3 = independence; builders are blind to their own assumptions; 2 = partial; 1 = vague; 0 = wrong.
Synthesis
Capstone I sets a verifiable baseline: a realistic problem, measurable requirements, a defensible architecture, a project plan with risks, and independent adversarial testing built in.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →