# `Monty.Experiment.RecognitionStrategy.ObjectRecognition`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/experiment/recognition_strategy/object_recognition.ex#L1)

Monty's own object-recognition policy: three ways to finish an episode.

Mirrors `tbp/monty/experiment/recognition_strategy.py::ObjectRecognition`, and is
what `termination/any1_objectrecognition_t1000_e500_tot6000` configures. In
Monty's order:

  1. the mode's matching limit is reached and the model is not exploring —
     done, and time the modules out beside it;
  2. the total step ceiling is reached — done, and time the modules out;
  3. the model says it is done — done, and nothing to time out.

The order matters because the first two also *time out* the modules: an
episode stopped by a limit still owes an answer, while an episode that
recognised its object already has one.

# `call`

```elixir
@spec call(map(), Monty.Experiment.RecognitionStrategy.RecognitionCounter.t(), map()) ::
  Monty.Experiment.RecognitionStrategy.RecognitionResult.t()
```

The first of the three conditions that holds, in Monty's order.

# `new`

```elixir
@spec new(keyword()) :: {:ok, {module(), map()}} | {:error, String.t()}
```

A policy with a matching limit per mode and a total ceiling.

Monty raises `ValueError` for any limit that is not positive; here that is
`{:error, message}` with Monty's own words, checked in the same order.

---

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