Your focused syllabus and ways of thinking
TL;DR
Learn the common evaluation loop first, then specialize by the role you want. Progress when you can produce, explain, test, and bound each artifact without outsourcing your judgment.
This syllabus is a curriculum recommendation derived from the selected roles in chapter 26 and the supplied G2i posting. It is not an employer-certified qualification. Follow the shortest route that builds valid evidence for your intended role.
The core you should learn first
| Priority | What to learn | Plain-language question | Proof |
|---|---|---|---|
| 1 | System boundaries | What exactly am I testing? | One configuration manifest |
| 2 | Python and Git reading | What changed, and why can it fail? | A reviewed repair |
| 3 | Task definition | What would count as success? | A task contract |
| 4 | References and datasets | How do I know the answer? | Adjudicated cases and a split policy |
| 5 | Grader validity | Could my measurement be wrong? | Valid/invalid control tests |
| 6 | Execution | Did the entire cohort actually run? | Complete trace and status |
| 7 | Statistics | What does the denominator permit me to claim? | Bounded analysis |
| 8 | Failure diagnosis | What intervention follows from the evidence? | Reproduced failure and retest |
| 9 | Communication | What decision should change? | One-page report |
Choose a specialization
For clinical or scientific evaluation, deepen references, unknown handling, workflow validation, and domain-specific failure severity. For coding-agent review, deepen debugging, compatibility, architecture, and codebase practice. For ML research engineering, add training experiments and post-training methods. For infrastructure, add distributed systems, scheduling, performance, and operational recovery.
Do not make the first syllabus a union of every job requirement. That would delay the most valuable practice. Broaden when a target role or observed project bottleneck justifies it.
Ways of thinking to retain
Task before tool: define the behavior and reference before choosing a framework. Mechanism before prompt: diagnose where an error enters the system before lengthening instructions. Evidence before confidence: inspect artifacts rather than trusting assertive language. Denominator before percentage: verify which cases and attempts are counted. Boundary before autonomy: enforce what tools can do before evaluating how politely the model describes its actions.
Counterfactual before explanation: change one relevant detail and see whether behavior changes appropriately. Holdout before headline: preserve a fresh acceptance cohort before announcing improvement. Decision before dashboard: collect a metric because it affects an action, not because it is easy to graph.
What to skip today
Skip memorizing model release names, collecting framework certificates, building elaborate dashboards before a scorer works, and learning all languages simultaneously. Do not skip source verification, security rules, executable checks, or understanding the code you are judging.
A practical stopping rule
You finish a learning stage when you can produce the artifact, explain it without delegating the explanation, handle its failure paths, and state its limits. You finish a project when the intended decision has enough evidence, the implementation is verified, and remaining uncertainty is explicit. Do not manufacture more work merely to feel productive.
Start with the first-day route, then return to this table and select the next missing proof. The route is accelerated by focused practice, not by pretending the missing experience is already present.