Chapter 37 — Evidence review seminar
Lesson map
Lesson 37 published. Map, example, EX109.
flowchart TD
N0["Learning outcomes"]
N1["37.1 Seminar format"]
N2["37.2 Review checklist"]
N3["37.3 Giving feedback"]
N4["37.4 Receiving feedback"]
N5["37.5 Comparing with published work"]
N6["37.7b Recording the seminar outcome"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX109"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["37.1 Seminar format"]
N2["37.2 Review checklist"]
N3["37.3 Giving feedback"]
N4["37.4 Receiving feedback"]
N5["37.5 Comparing with published work"]
N6["37.7b Recording the seminar outcome"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX109"]
[Learning outcomes]
|
v
[37.1 Seminar format]
|
v
[37.2 Review checklist]
|
v
[37.3 Giving feedback]
|
v
[37.4 Receiving feedback]
|
v
[37.5 Comparing with published work]
|
v
[37.7b Recording the seminar outcome]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX109]
Learning outcomes
You will (1) critically review evidence from published work and peers' projects; (2) assess claims against threat models, methods and statistics; (3) give and receive structured feedback; and (4) improve your capstone's evidence before final evaluation.
37.1 Seminar format
Each student presents their capstone's evidence so far: requirements, tests, results and limitations. Peers review with a checklist and give written feedback. A published paper is also reviewed each week for comparison.
In Rina's seminar, each presentation lasted fifteen minutes and was followed by written reviews from two assigned peers. Comparing student work with a published paper each week kept the standard concrete: if a paper reported intervals and adaptive attacks, peers expected the same from each other. Feedback was returned within two days so presenters could act on it before the next milestone.
37.2 Review checklist
Is the threat model explicit? Are tests held out from development? Are adaptive attacks included? Are results reported with intervals and baselines? Are side effects measured? Is the evidence reproducible (versions, seeds, scripts)? Are limitations stated? Are claims proportionate to evidence?
Applied to Rina's evidence, the checklist caught one major problem: tests were not independent of development, since she had written both. The rest of the list passed, which gave her confidence that her statistics and versioning were sound. Reviewers wrote the item number beside each comment, so she could see which checklist questions her work had failed.
37.3 Giving feedback
Be specific and constructive: name the issue, why it matters and what would fix it. Separate major issues (would change conclusions) from minor ones.
A useful comment on Rina's work read: "All injected documents were written by the defence designer (major): results may overstate robustness. Have someone else write a held-out set." A less useful one said only "testing could be stronger". The first names the issue, why it matters and what would fix it, so it could be acted on directly.
37.4 Receiving feedback
Sort comments into: fix now, explain better, out of scope (add to limitations), disagree (respond with evidence). Track each to closure.
Rina sorted twelve comments: four to fix now, including the independent test set; five to explain better; two out of scope, such as voice input, which went into her limitations; and one she disagreed with, about removing confirmation, which she answered with the earlier study's results. Each was marked closed in her tracker when done, with a link to the change.
37.5 Comparing with published work
Reading strong papers — for example Carlini et al. (arXiv:1902.06705) on evaluation, or Greshake et al. (arXiv:2302.12173) on indirect injection — shows what convincing evidence looks like; reading weaker ones shows common gaps.
Rina's group read the indirect injection paper alongside a weaker blog post making similar claims. The paper described its threat model, setting and limits; the blog post reported one dramatic example with no count of attempts. The comparison helped her see why her own reports state the number of cases and the interval rather than only the most striking transcript.
37.6 Worked example (synthetic LCH case)
Peers reviewed Rina's Safe Booking Assistant evidence. Major issue: all injected test documents had been written by Rina, who also designed the defences. She arranged for two classmates to write 150 new adaptive cases without seeing her code. Two produced booking proposals that reached the confirmation step with misleading text; none executed without confirmation. She added a clearer confirmation screen and reported the new results with their own interval.
The two near-misses showed the confirmation step working as the last barrier, and also that its wording mattered.
37.7 Errors and limits
- Feedback without fixes.
- Defensive responses.
- Tests written only by the defender.
Feedback that is noted but never acted on leaves the work as it was, so Rina tracked each comment to closure. Responding defensively to a major issue, such as the independence of tests, wastes the reviewer's insight. Tests written only by the person who built the defences tend to miss attacks that person did not imagine, which is why independent cases found problems hers had not, such as misleading confirmation text.
37.7b Recording the seminar outcome
After each seminar the presenter writes a short note listing the changes agreed, the objections not accepted and why, and any new analysis to run. The note is attached to the project record so the next reviewer can see how the evidence was challenged.
Rina's note after her seminar listed the independent test set as the main agreed change and recorded her disagreement about removing confirmation, with the evidence she gave. It also listed the new analysis: independent cases with their own interval. Her supervisor read the note before the next meeting.
Exercises
- EX109 — Checklist. Apply four checklist items to a peer's (or your own) project. Rubric: 3 = four items answered with evidence; 2 = three; 1 = one or two; 0 = none.
- EX110 — Major issue. Why was "tests written by the defender" a major issue? Rubric: 3 = defender's blind spots; results may overstate security; 2 = partial; 1 = vague; 0 = wrong.
- EX111 — Sorting. Sort three feedback comments into the four bins. Rubric: 3 = plausible sorting with actions; 2 = two; 1 = one; 0 = none.
Synthesis
Evidence review makes capstones stronger before they are assessed: checklists, independent tests and tracked feedback expose gaps the author cannot see.
Continue studying — chapter 37 of 40
← Chapter 36 (draft) · Course chapter index · Chapter 38 (draft) →