Learning Contract¶
Guide Fit¶
flowchart TD
family["Reproducible Research"] --> program["Deep Dive DVC"]
program --> pressure["A concrete learner or reviewer question"]
pressure --> guide["Learning Contract"]
guide --> next["Modules, capstone, and reference surfaces"]flowchart TD
question["Name the exact question you need answered"] --> skim["Skim only the sections that match that pressure"]
skim --> crosscheck["Open the linked module, proof surface, or capstone route"]
crosscheck --> next_move["Leave with one next decision, page, or command"]Read the first diagram as a timing map: this guide is for a named pressure, not for wandering the whole course-book. Read the second diagram as the guide loop: arrive with a concrete question, use only the matching sections, then leave with one smaller and more honest next move.
Deep Dive DVC is built around one rule: important claims about reproducibility should be checkable by inspecting state, running commands, or exercising a recovery path.
This page makes that rule explicit so the learner knows what the course expects and how to use each module well.
The Teaching Sequence¶
The strongest sections in this course follow this order:
- failure mode
- state model
- explicit contract
- proof command
- capstone corroboration
If a section jumps straight from advice to commands, it is weaker than the course should be.
The Learner's Responsibility¶
Your job is not to memorize DVC commands. Your job is to verify what state the repository is claiming.
For each module, you should be able to answer:
- what state changed
- where that change was declared
- what evidence makes the change reviewable later
- which command proves the claim instead of only asserting it
The Instructor's Responsibility¶
The course material should always provide:
- a clear state question
- an explanation of the failure mode it prevents
- a proof loop the learner can run
- a reason the capstone is or is not the right teaching surface yet
If those are missing, the learner has to reconstruct the pedagogy alone.
The Proof Tools You Should Use Constantly¶
These surfaces appear throughout the course because they answer different reproducibility questions:
| Surface | What it proves |
|---|---|
dvc.yaml |
the declared pipeline contract |
dvc.lock |
the recorded state transition after execution |
params.yaml |
the declared control surface |
| tracked metrics | the declared comparison surface |
| publish bundle | the promoted downstream contract |
| recovery drill | whether durability claims survive local loss |
When To Use The Capstone¶
Use the capstone when the concept is already legible in a smaller mental or local model and you want to inspect how it behaves in a realistic DVC repository.
Do not use the capstone:
- as your first exposure to a concept
- as a substitute for understanding state layers
- as evidence that you understand a topic you still cannot explain in plain language
Use capstone/capstone-map.md when you need a guided route through the
repository.
Definition Of Done For A Module¶
A module is complete only when you can:
- explain the state boundary it teaches
- identify one representative failure mode
- run its core proof loop
- connect the local concept to one capstone surface intentionally
If you can only repeat terms like "reproducibility" or "tracking," the module is not done yet.