Yes — that is exactly the direction I’m taking.

The emotion/state layer is not meant to be a fixed hardcoded enum, but it also should not be completely free-form.

The user can dynamically add the emotions or vessel states they want, and then the runtime treats that loaded preset set as the current contract. The LLM can choose from that allowed state space, but it should not invent new executable states outside of it.

So the flow is roughly:

1. User defines or adds emotion presets
2. Runtime loads the available preset set
3. The model selects from those existing states
4. Missing, malformed, or unknown tags fail closed or fall back to neutral

That way the vessel stays customizable, but the model’s output is still schema-bound instead of arbitrary free text.