python -m mjcourse.capstone mjcourse.envs.push:PushEnv --kwargs '{"action_mode": "ee_delta"}' --object puck

## Requirements common to every capstone

1. A protocol committed before the first evaluation run (Lesson 21.1), including the result that would falsify the main claim.
2. Every environment passes `python -m mjcourse.capstone`.
3. Training, development and held-out initial states on separate seeds; nothing chosen on held-out data.
4. Learned components trained with at least 5 seeds; results reported with intervals over seeds, and per task when there are several tasks (Lesson 21.2).
5. A run record (`mjcourse.experiment.run_record`) for every number in the report, with MuJoCo and library versions and model fingerprints.
6. A failure analysis: at least ten failed episodes from the held-out set, grouped by cause, with images or videos.
7. One command that regenerates each table and figure from the records.

## Rubric

Each row is judged as below, meeting or exceeding expectations; a capstone passes when it meets expectations in every row.

| Criterion | Meets expectations | Exceeds expectations |
|---|---|---|
| Validity of the instrument | checker passes; success defined in code and tested on a policy that nearly succeeds; no privileged leakage at evaluation | an independent check of the success definition (for example, rendered evidence for each success) |
| Methodology | protocol before results; held-out splits; ≥5 seeds; intervals over seeds | power analysis before running (Lesson 21.2); paired designs where possible |
| Results and analysis | every claim backed by a table or figure with its interval; failure analysis | an ablation that isolates the claimed factor; a reported negative result |
| Reproducibility | versions pinned; run records; one command per table | a clean machine reproduces the main table from the repository alone |
| Clarity | each metric and axis defined where it is used; figures with units | a reader can re-implement the evaluation from the report |

## Reporting standard

A report of at most eight pages: question and hypothesis; environment, written along the seven axes of Lesson 21.3; protocol; methods and baselines; results with intervals; failure analysis; limitations; reproduction instructions. Tables carry the number of seeds and episodes in their captions.

## The capstones

### A. A 7-DOF manipulation environment

**Objective.** A Gymnasium environment for a manipulation task of your choice on `arm7` (for example, opening a drawer, inserting a peg, or stacking), with torque, joint-delta and end-effector action modes (Level 12). **Builds on** Lessons 5.2, 8.3, 10.3 and 12.2. **Accept when** the checker passes in all three action modes; a scripted policy succeeds on at least 90% of 200 held-out starts (Wilson interval reported); and the documentation describes the task along the seven axes. **Common failures:** a success function that rewards near misses; observations read after `mj_step` without `mj_forward` (one step stale, Lesson 20.1); a task solvable by a constant action. **Extensions:** a second task sharing the scene; a randomized-object variant.

### B. A vision-based pick-and-place system

**Objective.** A pick-and-place policy that acts from rendered RGB or RGB-D images and proprioception only. **Builds on** Lessons 10.2, 11.2, 15.1 and 21.5. **Accept when** the policy receives no simulator state at evaluation (the checker's leak test passes on its observation); success with intervals over 5 seeds on held-out object positions; and the gap to the same policy with privileged object poses is reported, with a camera-pose-shift evaluation. **Common failures:** the object pose reaching the policy through an auxiliary input; evaluation on training positions; a single camera pose. **Extensions:** depth against RGB at equal data; distractor objects.

### C. A language-conditioned manipulation benchmark

**Objective.** A benchmark of instructions over a manipulation scene, with training and held-out instructions (paraphrases and new compositions) and held-out object placements. **Builds on** Lessons 16.1 and 21.3. **Accept when** at least ten instruction templates exist with a documented held-out split; a language-blind baseline (the same policy given an empty instruction) and chance level are reported; and results are separated by generalization axis (object, spatial, instruction). **Common failures:** instructions that a scene alone determines; paraphrases seen in training; per-episode aggregation over unequal tasks. **Extensions:** a VLA baseline evaluated on it with Capstone E's evaluator.

### D. A bimanual manipulation environment

**Objective.** An environment that needs both arms, such as a handover or a two-handed lift, on the course's bimanual scene. **Builds on** Lessons 5.4, 8.3 and 10.1. **Accept when** the checker passes; a scripted two-arm policy succeeds on at least 80% of held-out starts; and a one-arm ablation shows that the task needs both arms. **Common failures:** a task one arm can do; self-collision between the arms ignored in the success definition. **Extensions:** asymmetric roles; a learned policy.

### E. A VLA evaluation environment

**Objective.** An evaluator that takes any policy mapping (images, instruction, proprioception) to actions and reports success along generalization axes. **Builds on** Lessons 16.1, 21.2, 21.3 and 21.5. **Accept when** the evaluator passes only declared sensors to the policy (verified with the checker); a scripted oracle and a random policy bracket the reported range; results come per axis with intervals; and the evaluator writes a run record per evaluation. **Common failures:** the policy reading simulator state through the environment object; axes that change several factors at once. **Extensions:** an open-weight VLA evaluated on it, with its training distribution documented.

### F. A world-model-based manipulation agent

**Objective.** A planner that uses a learned dynamics model for a manipulation task, such as pushing. **Builds on** Lesson 21.4. **Accept when** the model's fidelity, action-conditioned accuracy and the planner's success are reported separately; the same planner with MuJoCo as its model is the reference; and the training data's coverage of the states the planner visits is measured. **Common failures:** one-step error reported as model quality; exploration data that never visits the task's states. **Extensions:** a latent model learned from images.

### G. A sim-to-real-ready environment with domain randomization

**Objective.** An environment whose parameters are identified from data and whose randomization ranges come from that identification, with latency and actuator models. **Builds on** Lessons 17.1, 18.1, 18.2 and 19.1. **Accept when** identified parameters carry intervals; randomization ranges are justified by them; a held-out "real" variant with hidden parameters is evaluated by a transfer experiment designed to fail informatively, as in Lesson 19.1; and performance is plotted against the size of the mismatch. **Common failures:** randomizing parameters the controller is insensitive to; delays shorter than the actuator's history (`nsample`) can hold. **Extensions:** hardware, if available.

### The final capstone

**Objective.** A research question of your own, studied with MuJoCo to the standard of Level 21. **Accept when** Checkpoint 21's protocol was committed before the runs, the study meets every common requirement, an ablation isolates the factor the claim depends on, and the report includes the result that would have falsified the hypothesis and whether it occurred. The final examination is on the [Final expert exam](#/page/final-exam) page.

## Exercise

Run the checker on the course's `ReachEnv` and on a copy of `PushEnv` in which you return `self.data.qpos` itself, not a copy, as part of the observation. Which check fails, and why does Gymnasium's own checker not catch it?

## Challenge

Choose the capstone closest to your research, write its protocol now, before building anything, and state the result that would make you abandon the approach.

## Research connection

> [!research] From capstone to paper
> Each capstone corresponds to a kind of contribution reviewers see often: an environment, a perception system, a benchmark, a multi-arm task, an evaluation tool, a model-based agent, a transfer study. What separates a publishable one from a demonstration is the methodology of Level 21 (inference): a protocol before results, seeds as the unit of replication, axes that change one factor at a time, and a failure analysis that tells the next researcher where to look.

```quiz
{"id": "24.1-check", "title": "Knowledge check", "questions": [
  {"kind": "mcq", "q": "What does mjcourse.capstone judge?",
   "options": ["Whether the research question is interesting", "Whether the environment is a valid instrument: API, copies, truncation, reproducibility, sensor declarations, leaks", "The policy's success rate", "Code style"],
   "answer": 1,
   "explain": "<p>It checks the instrument; the rubric and the report judge the research.</p>"},
  {"kind": "mcq", "q": "Capstone C requires a language-blind baseline. Why?",
   "options": ["To have more rows in the table", "To show how much success comes from the instruction at all; a scene may determine the task alone", "Because VLAs need it", "For speed"],
   "answer": 1,
   "explain": "<p>If the blind policy succeeds as often, the benchmark does not test language.</p>"},
  {"kind": "mcq", "q": "Which is a common requirement for every capstone?",
   "options": ["A GPU", "A protocol committed before the first evaluation run, with its falsifying result", "A real robot", "A reference solution"],
   "answer": 1,
   "explain": "<p>Lesson 21.1: decisions made after seeing results are not a test.</p>"}
]}