# `Monty.Experiment.MatchCriteria.MatchCriterion`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/experiment/match_criteria/match_criterion.ex#L1)

What a match criterion is.

Mirrors `tbp/monty/experiment/match_criteria.py::MatchCriterion`, a protocol
for a callable that takes the terminal states of every learning module and
answers whether the system has recognised the object.

Monty's terminal states are strings; here they are atoms
(`:match`, `:no_match`, `:time_out`, `:pose_time_out`), and a module that has
not concluded yet is `nil`.

# `terminal_state`

```elixir
@type terminal_state() :: :match | :no_match | :time_out | :pose_time_out | nil
```

# `terminal_states`

```elixir
@type terminal_states() :: %{optional(String.t()) => terminal_state()}
```

# `matched?`

```elixir
@callback matched?(terminal_states(), term()) :: boolean()
```

Whether the terminal states amount to a recognition.

Called with the criterion's own configuration as the second argument, so a
criterion that needs a count or a set of module ids carries it as data rather
than in its module.

---

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