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

# When to Use Boundary

> Where Boundary fits — and where it doesn't

Boundary is a correctness layer for structured LLM outputs. It's not for every use case.

## Use Boundary when

<CardGroup cols={1}>
  <Card title="LLM output feeds into application logic">
    Database writes, API calls, routing decisions, workflow triggers — anywhere the output drives behavior, not just display.
  </Card>

  <Card title="Incorrect values would break workflows">
    Not just incorrect types (Zod handles that), but incorrect *values*. A lead scored as "hot" with a score of 25. An invoice where subtotal + tax ≠ total.
  </Card>

  <Card title="Cross-field consistency is required">
    When fields must be consistent with each other — tier matches score, currency matches account, action matches status.
  </Card>

  <Card title="You need correctness, not just structure">
    Structured outputs help with valid JSON. Boundary enforces the value rules your workflow depends on.
  </Card>
</CardGroup>

## Don't use Boundary when

<CardGroup cols={1}>
  <Card title="Chat / conversational UX">
    Free-form text responses shown directly to users. No structured output to validate.
  </Card>

  <Card title="Creative generation">
    Poetry, stories, marketing copy — there's no "correct" output to enforce.
  </Card>

  <Card title="Free-form text without structure">
    If the LLM output isn't JSON, there's no schema to validate against.
  </Card>

  <Card title="Human makes the final decision">
    If a person reviews every output before it enters your system, the human is the boundary.
  </Card>
</CardGroup>

## Performance and cost

Boundary adds **zero overhead** on the happy path beyond validation (which is synchronous and in-memory).

Extra LLM calls happen **only on failure**:

| Scenario                       | LLM calls                  |
| ------------------------------ | -------------------------- |
| Output is correct on first try | 1 call (no extra cost)     |
| Output needs one repair        | 2 calls                    |
| Output needs two repairs       | 3 calls (default max)      |
| All attempts fail              | 3 calls + structured error |

Most runs complete in **1-2 attempts**. The `result.durationMS` field tells you the exact time for each call.

<Tip>
  Cost increases only when outputs are incorrect. If the model returns correct outputs consistently, Boundary costs nothing extra.
</Tip>

## The right mental model

Boundary is not:

* A testing framework
* A prompt engineering tool
* A model evaluation suite

Boundary is a **correctness layer**. It sits between the model and your application and enforces a deterministic acceptance decision. The model is probabilistic; the side effects in your application should not be.

## Observability

If you are still deciding whether Boundary fits, start with [local development](/guides/local-development). You can see rejected attempts, repair messages, and rule failures without an account. Add [production observability](/guides/production-observability) when those runs need to be visible to the team.