# `Monty.Frameworks.Models.MotorPolicies.MotorPolicy`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/frameworks/models/motor_policies/motor_policy.ex#L1)

The scaffold every motor policy is built on.

Mirrors `tbp/monty/frameworks/models/motor_policies.py::MotorPolicy`, which is
abstract and says only what a policy has to be able to do: act on a step,
start an episode over, and say what it knows.

Monty's `load_state_dict` is absent: loading a memento is how a *checkpoint*
restores a run, and this port's checkpoints are the studio's own records.
`fixme_provide_motor_system` is absent for the reason given in
`...MotorPolicySelectors.MotorPolicySelector` — the flag travels in the result.

# `t`

```elixir
@type t() :: struct()
```

# `call`

```elixir
@callback call(
  t(),
  ctx :: Monty.Context.t(),
  observations :: map() | nil,
  state :: Monty.Frameworks.Models.MotorSystemState.t(),
  percept :: Monty.Cmp.Message.t() | nil,
  goal :: Monty.Cmp.Goal.t() | nil
) :: {Monty.Frameworks.Models.MotorPolicies.MotorPolicyResult.t(), t()}
```

The actions to take, whether learning modules should sit this step out, and
the policy as it now stands.

# `handle_successful_jump`
*optional* 

```elixir
@callback handle_successful_jump(t()) :: t()
```

What to do once a jump has landed with the object in view.

Monty's `_handle_successful_jump`, which `SurfacePolicy` overrides; a policy
that does not care answers itself unchanged. The policy's own module is asked
for it (`docs/monty-differences.md` §2.9).

# `reset`

```elixir
@callback reset(t()) :: t()
```

Starts the next episode: whatever the policy learned about this one goes.

# `state_dict`

```elixir
@callback state_dict(t()) :: map()
```

What the policy recorded, for a run that wants to be read afterwards.

---

*Consult [api-reference.md](api-reference.md) for complete listing*