Demonstrate the work
Use the capstone brief and the artifacts from earlier labs. This review checks what you can build, diagnose, and explain. Reading completion alone does not establish readiness, and the rubric is a self-assessment rather than a hiring guarantee.
Review session
- Give a five-minute explanation of the user problem, baseline, and chosen architecture.
- Run a successful case from a clean setup using the documented instructions.
- Demonstrate one failure without editing the result after the fact. Trace its cause and recover safely.
- Defend one tradeoff using your recorded evaluation or pilot evidence.
- Ask the reviewer to change a constraint and explain what you would reconsider.
Evidence rubric
| Dimension | Evidence to inspect |
|---|---|
| Application engineering | Input contracts, deadlines, cancellation, and reproducible setup |
| Data and retrieval | Versioned ingestion, deletion, provenance, and evidence recall |
| Evaluation | Held-out cases, failure analysis, and release gates |
| Security and operations | Access isolation, safe logs, deployment, and rollback |
Score each dimension from 0 to 3: 0 means no artifact; 1 means you can follow a guided happy path; 2 means you can reproduce, test, and explain the work independently; 3 means you can adapt it to a changed constraint and diagnose a new failure. Aim for at least 2 in every dimension. Any unauthorized action, data leak, or irreproducible core workflow is a blocker to resolve before calling the project ready.
Have a peer review the evidence if possible. If you work alone, record the demo and return later with an unfamiliar test case. Keep the reviewer’s questions and unresolved gaps. Do not replace evidence with a polished slide deck.
Questions to answer without a script
- A reviewer can run your project from a clean setup and reproduce a successful and a failed request.
- You can explain retrieval failures separately from generation failures using case-level evidence.
- Your tests cover cross-tenant access, unsupported questions, timeouts, and invalid outputs.
- You can compare a baseline with your chosen design and justify quality, latency, and cost tradeoffs.
Finish with a development plan
List the weakest dimension, the next experiment or implementation change, and the evidence that would show improvement. Add the repository, architecture record, evaluation results, and recovery instructions to your portfolio. Describe synthetic engagements and simulated outcomes explicitly. A credible portfolio explains limitations as well as successful results.