What this application runs in place of a Monty class it has not written.

Two things do, and nothing else:

• the runtime does the job of Monty's shell — Monty, whose concrete stepping is MontyBase, and MontyForGraphMatching, which owns the matching step and the vote round. Here those are processes (Monty.Runtime.Model) stepped by Monty.Runtime.Step, and the episode belongs to Monty.Studio.Run. That is a replacement on purpose, not a hole: the job is done — the step order, the goals through the attention system, the vote round, the counters and the terminal decision.
• the MuJoCo world — Monty's MuJoCoSimulator, its agents and its scene objects are written here, in priv/monty_py/world.py, against mujoco rather than in Elixir: a renderer is a C library with a Python binding, so the scene cannot live in the BEAM. The behaviour is Monty's (the spec, the cameras, the semantic ids, metres and wxyz rotations); the code is this application's, and Monty.Simulators.Mujoco.Simulator.MuJoCoSimulator is the class a run steps. A Python file is therefore not evidence of an unported class — it is where this port had to stay Python.

A class in neither list has no stand-in, and a config naming it is refused: an unwritten class is an error rather than a fake run wearing the experiment's name (Monty.Studio.Setup's findings say so on the page).

This module is the one place the answer is written down. mix monty.module_map.gen copies it into the map as stand_in on each class, and everything else — the studio's findings, /modules — reads it from there, so a page and a refusal cannot disagree about what runs.