A defense narrative without chaos
A capstone defense should lead the reviewer from the problem to the observable outcome, not replay the entire work transcript. A strong narrative names the audience, bounded scope, one core flow, key decisions, evidence anchors, and honest limitations.
The presentation order controls cognitive load. First explain what is being checked and why it matters, then show the short flow, open the evidence, and finish with a decision request. If the demonstration deviates from the scenario, stop and record Unknown instead of improvising a claim.
Four pillars of a defense narrative
- Context: name the problem, primary user, bounded outcome, and non-goals.
- Walkthrough: show three to five core-flow steps with expected signals.
- Evidence: open the relevant diff, check, or record and explain its boundary.
- Decision: ask for GO, HOLD, feedback, or the next bounded slice; do not call it approval without an actual decision.
Defense narrative
# DEFENSE_NARRATIVE.md
Audience: <reviewer or evaluator>
Problem: <bounded problem and user>
Claim: <what this capstone slice demonstrates>
Path:
1. <action> -> <expected signal>
2. <action> -> <expected signal>
3. <action> -> <expected signal>
Evidence anchors: <files, commands or notes>
Known limits: <Unknowns and unsupported cases>
Decision requested: <GO / HOLD / feedback>
Status: documented example; defense outcome: Unknown.Canonical lesson source · JavaRush
Open JavaRush material