Capstone + Job Readiness

Name the baseline, the alternatives you tried, and the number that decided between them on the metric you chose. Say what this model does that the simpler option could not, and what it costs in latency, cost and interpretability. Point at the experiment in the repository.

State the decision the system supports and the cost of each error type, then show that the metric reflects them. Say what it fails to capture, how the threshold was chosen and who it affects, and name a higher-scoring metric you rejected and why.

Show the rules-based baseline you actually implemented and the score it reached. Say where it failed, why it could not be extended to cover those cases, and what the model captures that enumerated rules could not. If the rules were close, say so and justify the extra machinery honestly.

Show the lexical baseline and its retrieval metrics, then the same metrics for what you shipped. Say what chunking, hybrid search or reranking changed, at what latency and cost, and name the queries where the simpler approach was as good. Complexity that cannot show a gain is complexity you should remove.

Walk the data path and name each point where information could reach the model that would not exist at prediction time: features derived after the outcome, preprocessing fitted before splitting, a random split over grouped or time-ordered rows, and evaluation cases that overlap training data. Say how you checked each one and what you found.

Say which inputs would plausibly change, how you would detect that, and what the model would do while it is happening. Cover the lag before true outcomes arrive, the monitoring that would notice before a user complains, the threshold that triggers retraining, and the fallback while the system is degraded.

Describe the evaluation set, how it was built and when, and how it is kept representative as it grows from real failures. Report the components separately, including retrieval, generation, tool selection and task completion, alongside latency and cost. Give real numbers, including a result that disappointed you.

Present the threat model and then what you actually demonstrated: injection directly and through retrieved content, disclosure of data the system holds, misuse of tools, and any action the system can take unattended. Give the mitigation for each, the retest result, and the residual risk with its owner.

Say what happens right now: whether calls fail fast or hang, what the timeout is, what the user sees, and whether any partial work is left inconsistent. Then describe the fallback, whether a queued or degraded mode exists, and how state is recovered when the provider returns.

Describe the procedure end to end: what identifies the previous good version, who or what triggers the rollback, how long it takes, and how you confirm it worked. Include what happens to in-flight tasks and to data written by the version being rolled back, and say when you last rehearsed it.

Give a number with its arithmetic: model calls and their token counts, retrieval and infrastructure, multiplied by the calls one successful task actually requires, including retries and failures. Say which component dominates, how it scales with volume, and what you would change first if the cost had to halve.

Every answer above points at something in the repository: the experiment, the evaluation run, the trace, the threat model, the rollback note, the cost calculation. An answer given from memory with nothing to open is not defensible. Assemble the artifacts before the walkthrough, not during it.

Every subject in this stage has review questions. The condition is met when you can answer them out loud, without notes and without looking anything up, in your own words rather than a recited definition. An explanation you can only give with the material open is recognition, not recall.

Complete means each exercise satisfies its stated requirements and its done-when criteria, not that you attempted it. Where an exercise says you should be able to explain or defend something, that explanation is part of completing it. A stage whose source lists no exercises meets this through its owned project milestone instead.

Works means it runs end to end from a clean checkout, on the inputs it was built for, with the failure cases it claims to handle actually handled. It is not a notebook that produced a result once. Someone else following your README should be able to run it without asking you a question.

There is something that would fail if the behaviour regressed, and you have watched it fail. That can be automated tests or a written verification procedure with recorded results, depending on what the stage produces. A test that has only ever passed is evidence of nothing.

The README says what the project is, how to install, run and test it, and why it is built the way it is: the choices you made, the alternatives you rejected, and what you deliberately left out. A list of commands with no reasoning does not meet this condition.

Delete the central piece and write it again from an empty file, without your previous version, a tutorial, or generated code in front of you. It does not have to be identical, it has to work and you have to be able to explain every line. This is the condition that separates having finished from being able.

Record a gate exam and score yourself honestly against the dimensions the roadmap defines: recall, implementation, debugging, testing and design judgment. Elapsed time, hours watched and completed resources count for nothing here. Checking the boxes without a recorded exam does not open the gate.

Ask an AI reviewer to examine the work against this stage's concepts and report foundational misunderstandings, not style. A foundational blocker is a misconception that later stages would build on, such as leakage, a broken abstraction, or an explanation that is confidently wrong. Nothing in that class may remain open when you pass.