Home: README
This protocol defines the final standard for claiming mastery from this plan.
You must pass all five:
- Baseline doc chain completion (
01through35). - Elite extension completion (
36through45). - Universal learner layer completion (
46through49). - Project evidence completion (level-0 through level-10 plus elite track).
- Assessment completion (written, practical, oral defense).
- Portfolio links and summaries.
- Capstone outputs and runbooks.
- Test and quality gate records.
- Architecture decision records.
- Incident and remediation logs.
| Criterion | Pass | Fail |
|---|---|---|
| All 15 exercises produce correct output | Yes | No |
| Student can explain what their code does | Demonstrates understanding | Cannot explain |
| No syntax errors in submitted code | Clean execution | Runtime errors |
| Category | Points | Criteria |
|---|---|---|
| Correctness | 30 | All tests pass. Output matches specification. |
| Code quality | 25 | Meaningful names, no dead code, functions under 30 lines. |
| Testing | 20 | Tests cover happy path + at least 2 edge cases. |
| Documentation | 15 | notes.md filled in with genuine observations. README present. |
| Iteration evidence | 10 | Git history shows multiple commits, not a single bulk upload. |
Pass threshold: 70/100. Projects scoring 60–69 may resubmit once.
| Category | Points | Criteria |
|---|---|---|
| Correctness | 25 | All tests pass. Handles malformed input gracefully. |
| Architecture | 20 | Clear separation of concerns. Functions have single responsibility. |
| Testing | 20 | Unit tests + integration tests. Parametrized where appropriate. |
| Code quality | 15 | Type hints on function signatures. Logging instead of print statements. |
| Documentation | 10 | notes.md explains design decisions, not just observations. |
| Tooling | 10 | ruff check passes. Code formatted with black. |
Pass threshold: 70/100.
| Category | Points | Criteria |
|---|---|---|
| Correctness | 20 | All tests pass. Idempotent operations. Recovery from failure. |
| Architecture | 25 | Appropriate design patterns. Clear module boundaries. |
| Testing | 15 | Integration tests with realistic data. Failure mode tests. |
| Operations | 15 | Monitoring hooks. Structured logging. Error classification. |
| Code quality | 10 | Consistent style. Type hints throughout. No code smells. |
| Documentation | 15 | Architecture decision records. Runbook for deployment/operation. |
Pass threshold: 75/100.
| Category | Points | Criteria |
|---|---|---|
| System design | 25 | Justified architecture. Tradeoffs documented. Scalability considered. |
| Reliability | 20 | SLOs defined. Failure modes tested. Graceful degradation. |
| Security | 15 | Input validation. Auth implemented correctly. No OWASP top-10 violations. |
| Observability | 15 | Metrics, logs, traces. Dashboards or monitoring configuration. |
| Code quality | 10 | Production-grade. CI passes. No shortcuts. |
| Documentation | 15 | Complete ADRs. Operational runbooks. Capacity estimates. |
Pass threshold: 80/100.
| Category | Points | Criteria |
|---|---|---|
| Novelty | 20 | Solves a genuinely complex problem. Not a tutorial replication. |
| System design | 25 | Distributed systems thinking. Event-driven where appropriate. |
| Engineering rigor | 25 | Comprehensive testing. Performance profiled. Security hardened. |
| Communication | 15 | Can defend every design decision in oral examination. |
| Documentation | 15 | Architecture diagrams. Postmortem or incident analysis included. |
Pass threshold: 80/100.
For each project you submit as evidence of completion:
# [Project Name] — Level [X], Project [Y]
## Summary
One paragraph: what this project does and why it exists.
## How to Run
Step-by-step instructions. Include dependencies.
## Design Decisions
- Decision 1: [What you chose] because [why]
- Decision 2: [What you chose] because [why]
- What you would change with more time: [specific improvement]
## Test Results
- Total tests: [N]
- Passing: [N]
- Coverage: [X%] (if measured)
## Quality Checks
- [ ] ruff check passes
- [ ] black formatting applied
- [ ] Type hints on all function signatures
- [ ] No hardcoded paths or secrets
## What I Learned
3–5 bullet points of genuine insight. Not "I learned Python."For level capstones and the elite track:
# [Capstone Title] — Level [X] Capstone
## Problem Statement
What real-world problem does this solve?
## Architecture
Describe the system design. Include a diagram if applicable.
### Components
- Component A: [purpose]
- Component B: [purpose]
- How they interact: [description]
### Design Tradeoffs
| Decision | Alternatives Considered | Why This Choice |
|----------|------------------------|-----------------|
| [Decision 1] | [Alt A, Alt B] | [Reasoning] |
| [Decision 2] | [Alt A, Alt B] | [Reasoning] |
## Operational Characteristics
- How does it handle failure?
- How would it scale to 10x load?
- What monitoring is in place?
## Test Strategy
- Unit tests: [count and what they cover]
- Integration tests: [count and what they cover]
- What is NOT tested and why
## Deployment
How to deploy this in a production-like environment.
## Retrospective
- What went well
- What was harder than expected
- What you would do differently- Levels 0–5: Self-review using the rubric above, or a study partner
- Levels 6–8: Review by a peer who has completed the same level
- Levels 9–10 and Elite: Review by a peer who has completed the curriculum, or a professional developer
- Reviewer receives: the project repository (or fork link) and the submission template
- Reviewer checks (30–60 minutes):
- Clone the repo and run
python -m pytest tests/ - Run
ruff check . - Read the code (focus on readability, not style preferences)
- Read the submission template (are the design decisions genuine?)
- Run the project and test 2–3 scenarios manually
- Clone the repo and run
- Reviewer writes feedback using this template:
## Peer Review — [Project Name]
**Reviewer:** [Name/Handle]
**Date:** [Date]
### Rubric Scores
| Category | Score | Notes |
|----------|-------|-------|
| [Category] | [X/Y] | [Brief note] |
### Strengths
- [What the project does well]
### Areas for Improvement
- [Specific, actionable feedback]
### Questions for the Author
- [Things the reviewer wants the author to explain]
### Verdict
- [ ] Pass
- [ ] Pass with minor revisions (list them)
- [ ] Resubmit (explain what needs to change)- Review the code, not the person
- Be specific: "This function is 80 lines — consider splitting the validation into a helper" is better than "Code is too long"
- Acknowledge what works before noting what does not
- If you are unsure whether something is wrong, ask a question instead of making a statement
Oral defense is required for:
- Level 9–10 capstones
- Elite track projects
- Final certification claim
Defense is optional but recommended for:
- Level 6–8 capstones
- Expansion module completion
| Phase | Duration | Content |
|---|---|---|
| Presentation | 10 min | Walk through the project: problem, design, implementation, results |
| Live demo | 5 min | Show the project running. Demonstrate a normal flow and an error flow |
| Q&A | 10 min | Examiner asks questions about design decisions, tradeoffs, alternatives |
| Code walkthrough | 5 min | Examiner selects a section of code. Explain it line by line |
- "Why did you choose this data structure / algorithm / pattern?"
- "What happens if [input X] is provided?" (edge case probing)
- "How would you scale this to handle 100x the current load?"
- "What is the most fragile part of this system?"
- "If you had two more weeks, what would you add or change?"
- "Walk me through how you debugged [specific issue]."
- "What does this test verify, and what does it NOT verify?"
| Criterion | Weight | Excellent | Adequate | Insufficient |
|---|---|---|---|---|
| Clarity | 25% | Explains concepts clearly without jargon | Understandable with some prompting | Cannot articulate design |
| Depth | 25% | Understands internals, tradeoffs, alternatives | Surface-level understanding | Cannot go beyond "it works" |
| Honesty | 25% | Acknowledges limitations and unknowns | Mostly honest, occasionally deflects | Claims perfection or avoids questions |
| Adaptability | 25% | Thinks through new scenarios on the spot | Handles some curveballs | Cannot reason about changes |
Pass threshold: "Adequate" or better in all four criteria.
Pass when all are true:
- All required outputs are reproducible.
- Quality gates pass without manual exception.
- Tradeoff reasoning is clear and defensible.
- Failure handling is tested and documented.
- Remediation loops are closed with evidence.
Fail when any are true:
- Hidden assumptions block reproducibility.
- Test coverage is cosmetic.
- Critical security or reliability controls are missing.
- Oral defense cannot justify design decisions.
Below is an example of what a completed certification summary looks like. This is the document you produce when you have finished the entire curriculum and are claiming mastery.
# Python Mastery Certification — [Your Name]
# Date: 2025-06-15
## Completion Summary
| Requirement | Status | Evidence |
|-------------|--------|----------|
| Docs 01-35 (baseline chain) | Complete | All exercises done, notes filled |
| Docs 36-45 (elite extension) | Complete | Elite track projects submitted |
| Docs 46-49 (learner layer) | Complete | Self-assessments and gap analysis done |
| Project evidence (levels 0-10 + elite) | Complete | 175 projects, all tests passing |
| Assessments (written + practical + oral) | Complete | Scores below |
## Level Scores
| Level | Score | Threshold | Result |
|-------|-------|-----------|--------|
| Level 00 | Pass | Pass/Fail | PASS |
| Levels 0-2 | 84/100 | 70 | PASS |
| Levels 3-5 | 78/100 | 70 | PASS |
| Levels 6-8 | 82/100 | 75 | PASS |
| Levels 9-10 | 85/100 | 80 | PASS |
| Elite Track | 81/100 | 80 | PASS |
## Portfolio Highlights
1. **Level 5 Capstone — Data Pipeline Engine**
Batch CSV processor with schema validation, error quarantine, and checkpoint recovery.
Tests: 42 passing. Coverage: 87%.
2. **Level 8 Capstone — Monitoring Dashboard**
Real-time metrics aggregator with structured logging, alerting thresholds, and a Flask dashboard.
Tests: 61 passing. Coverage: 79%.
3. **Elite Track — Distributed Task Queue**
Multi-worker task queue with Redis backend, dead-letter handling, and graceful shutdown.
Tests: 38 passing. Defended in oral exam.
## Oral Defense
| Criterion | Score |
|-----------|-------|
| Clarity | Excellent |
| Depth | Excellent |
| Honesty | Excellent |
| Adaptability | Adequate |
## Expansion Modules Completed
Modules 01-08, 10-11 (10 of 12 modules, 47 of 56 projects)
## Quality Gate Summary
- ruff check: 0 violations across all projects
- black formatting: applied to all files
- Type hints: present on all function signatures (levels 3+)
- No hardcoded secrets found
## Self-Assessment
Strongest areas: data processing, testing, API design
Areas for continued growth: async programming, deployment automation
Next goals: complete modules 09 (Docker) and 12 (Cloud Deploy)- Weekly: run one project improvement cycle.
- Monthly: publish one new technical artifact.
- Quarterly: run full reassessment and remediation loop.