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

Goal-state generators: what a learning module wants to look at next.

Mirrors `tbp/monty/frameworks/models/goal_generation.py`, which holds one
error and two generators:

  * `...GoalGeneration.ParentLMNotProvided` — **ported**: the error a generator
    raises when asked about its learning module before it has one;
  * `...GoalGeneration.GraphGoalGenerator` — **ported**: the base generator,
    which checks whether the goal it last emitted was reached and emits the
    next one; on its own it emits nothing, meaning "just be more certain";
  * `...GoalGeneration.EvidenceGoalGenerator` — **ported**: the generator an
    evidence-based module uses to pick where to look, from the mismatch
    between the graph of the object it believes in and the graph of the one
    it cannot rule out.

The behaviour these implement is
`Monty.Frameworks.Models.AbstractMontyClasses.GoalGenerator`.

# `from_config`

```elixir
@spec from_config(map()) :: {:ok, struct()} | {:error, term()}
```

The generator a config entry names, built from its own keys.

Monty instantiates the entry through Hydra and hands the learning module the
object; a module built from a config has to instantiate the entry itself, which
is what this does. A class this port has not written is an error rather than a
silent `nil`, so building a module cannot quietly drop the goals the experiment
asked for.

---

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