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

# Guarantees & Guardrails

> What the framework enforces itself, and what it leaves to the LLM.

A guardrail in Mantle is **not advice to the model**. It is a rule the framework
enforces itself, in the [runtime loop](/mantle/runtime-loop), before and after
the LLM ever gets a say. This is what lets you trust an agent with an expensive
action: the guarantee doesn't depend on the model choosing to follow it.

## The division of labor

By default the LLM has full freedom. You write plain-language instructions and
it runs the conversation. Every guardrail you add moves one specific decision out
of the model's hands and into the framework's. Nothing else about the skill
changes.

| What you author | The framework enforces | The LLM still decides |
| - | - | - |
| **Nothing (pure prose)** | Nothing | Everything: what to say, which tool, what order |
| **`hidden: true`** | Omits the skill from routing (still startable via `call` / `link` / `resolve_with`) | Which remaining skill fits the user's intent |
| **`precondition`** | Parks the skill as pending and runs the bound resolver before it becomes active | Which skill to request; the resolver conversation |
| **`if:` markers** | Strips non-matching paragraphs from the prompt | Everything within the visible paragraphs |
| **`tool_constraints`** | Hides a tool from the LLM until `requires:` is met | When to attempt the tool call |
| **Ordered blocks** | Step order, no skipping ahead; runs deterministic steps without the LLM | The conversation within each conversational step |

## How each guardrail is enforced

Because enforcement happens in the loop, a guardrail isn't something the model can
argue its way past:

* **Gating (`requires:`).** A tool whose condition isn't met is removed from the
  LLM's tool list. It can't call a tool it can't see. See
  [Tool constraints](/build-guide/tool-constraints).
* **Scoped instructions (`if:`).** Non-matching paragraphs are stripped
  from the prompt, so the LLM never sees the wrong path. See
  [Scoped instructions](/build-guide/scoped-instructions).
* **Ordered blocks.** The framework holds a step pointer and won't advance out of
  order. Deterministic steps run with no model call at all. See
  [Ordered blocks](/build-guide/ordered-blocks).

<Info>
  `tool_constraints` are enforced regardless of who triggers the tool. A tool
  whose `requires:` is unmet is removed from the LLM's tool list, and an
  ordered-block `execute_tool:` step runs the same gate before calling the
  function, holding the step until the condition holds.
</Info>

## Progressive control

The point of all this is that you don't choose between "autonomous" and
"scripted" up front. You start loose and tighten only where the business needs a
guarantee. The more you add, the more is guaranteed and the less is left to the
model's judgment.

| You need... | Add... |
| - | - |
| The LLM can't call a tool until a value exists | [Tool constraints](/build-guide/tool-constraints) |
| Only one branch of instructions visible at a time | [Scoped instructions](/build-guide/scoped-instructions) |
| Steps must run in a strict order | [Ordered blocks](/build-guide/ordered-blocks) |
| One skill to reuse another | [Sub-skills](/build-guide/sub-skills) |

## Reference

For the exact framework-versus-LLM boundary at each control level, plus the rules
that govern how they interact, see the
[Constraint Table reference](/reference/constraint-table).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.