Problem framing
Define the business problem. Show the evidence behind the request, the stakeholders involved, and the decision the system needs to support.
A completed lesson shows participation. Assessed work shows whether you can apply what you’ve learned.
Projects use the same published rubric. Passing requires a score of at least 3 out of 4 in every category and no critical failure.
Define the business problem. Show the evidence behind the request, the stakeholders involved, and the decision the system needs to support.
Meet the required test thresholds. Meet the project’s test thresholds. Recognize critical cases and explain the errors that remain.
Document and test the implementation. Make the system reproducible, tested, and understandable. Put calculations and business rules in code.
Handle access and data responsibly. Keep secrets out of the repository. Respect the project’s data rules and treat untrusted material as data.
Demonstrate usability. Show that the intended user can do the job. Surface difficult cases instead of hiding them.
Explain costs and business value. Use the case’s numbers, state your assumptions, and show the cost of operating the system.
Prepare the project handoff. Make the deck, demo, case study, and runbook accurate, readable, and consistent with the tested system.
Strong presentation does not cancel out broken software or unsafe data handling. Each category must meet the standard independently. Distinction begins at a weighted score of 90, with the same passing requirements.
The assessment process looks at both the delivered system and your understanding of it.
Provide the running application, repository, test report, demo, client deck, case study, and runbook.
Project assessment includes a time-limited hidden test using cases you have not seen. The purpose is to check whether your approach generalizes.
Review identifies the category and evidence that need improvement. You address those gaps in your next submission.
Answer three reviewer questions in one unedited recording within 72 hours. Explain your code, decisions, tradeoffs, and limitations.
The assessment asks what your work demonstrates, not just what you have watched.
Examples include exposed secrets, real personal data in a submission, a non-working application, prohibited data sharing, or an inability to explain your own work.
These rules keep the assessment focused on responsible delivery.
Torchlane assessment evaluates the program’s applied work. The optional AWS and Google Cloud exams assess their own vendor-defined knowledge.
Neither should be presented as accreditation, a professional license, or a guarantee of employment.
Review the training stages, project requirements, and assessment criteria before applying.