> ## Documentation Index
> Fetch the complete documentation index at: https://maestro.rasa.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Constraint Table

> What the framework enforces vs what the LLM decides, at each control level.

The orchestrator's freedom depends on what the builder has authored. More control primitives means more framework enforcement, less LLM discretion.

| Mode                  | Framework enforces                                                                                                                                                                                                     | LLM decides                                                                         |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Skill routing**     | Filters skills by `requires:`. Manages dialogue stack. Enforces `@skill.<name>` vs interrupt semantics.                                                                                                                | Which skill to activate based on user intent                                        |
| **Pure prose**        | Nothing (unless `tool_constraints` present)                                                                                                                                                                            | Full freedom: navigation, tool selection, ordering, branching                       |
| **if: markers**       | Strips non-matching paragraphs from the prompt. The LLM cannot see inapplicable branches.                                                                                                                              | Everything within visible paragraphs                                                |
| **tool\_constraints** | Hides the tool from the LLM until `requires:` is met, and blocks dispatch. Pauses for optional `requires_confirmation:` before sensitive tools.                                                                        | When to attempt the tool call                                                       |
| **Ordered block**     | Step sequence: the pointer never moves backward or jumps past an unsatisfied step. Deterministic steps (`execute_tool:`, `noop:`, `set_memory:`, `action:`, and already-satisfied `collect:`) execute without the LLM. | Conversation within `instructions:` steps, and value extraction in `collect:` steps |

## Boundary rules

1. **An ordered block enforces local order, not global lock-in.** The user can trigger a different skill mid-block (interrupt). The block pauses and, if the user chooses to resume, continues at the same step when the interrupt completes.

2. **`@skill.<name>` guarantees parent resumes; user-initiated interrupt does not.** An `@skill.<name>` reference is a structured invocation with guaranteed return. An interrupt is a user changing topic; the original skill stays on the stack but may not be revisited.

3. **Prose and ordered blocks coexist.** Prose references a block via `@block.<block_id>`. The orchestrator enters the block, runs it, and returns to prose.

4. **`if:` markers are prompt-level, not execution-level.** They change what the LLM sees, not what the orchestrator tracks. Each marker scopes the one paragraph beneath it, so every case reads as its own `if:`.

5. **`tool_constraints` are always enforced.** Whether the LLM or an ordered-block `execute_tool:` step attempts the call, `requires:` and any confirmation gate are checked before the function runs.

6. **Every gate fails closed.** When a `requires:` or `if:` condition does not hold, the tool stays hidden and the paragraph stays out of the prompt. Withholding is the safe direction, so it is also what happens when a condition cannot be evaluated.

7. **Values can satisfy upcoming `collect:` steps early.** A user who volunteers several answers at once lets the block advance past each already-satisfied `collect:` step in one turn, unless the step sets `ask_before_filling: true`. Order is still preserved: the block never runs a later step before an unsatisfied earlier one.

## Conditions

Every `requires:`, `if:`, `complete_when:`, `utter:` `when:`, and `next:` condition is a string expression in one grammar. See [Conditions](/docs/maestro/reference/conditions).