Guarantees

Boundary enforces a deterministic acceptance boundary around your LLM calls. Your application only receives outputs that have passed the schema and rules you defined.

When `result.ok === true`

The output is guaranteed to be:

Valid JSON — successfully parsed
Schema-compliant — matches your Zod schema exactly
Rule-correct — all domain rules returned true
Accepted for this workflow — safe for the side effects covered by your schema and rules

if (result.ok) {
  // result.data passed the contract
  await saveToDatabase(result.data);
}

You can treat result.data as accepted input for the workflow the contract protects.

When `result.ok === false`

No output is returned to your application. Instead, you receive a structured error:

No invalid data leaks through
All attempts are preserved for debugging
Failures are fully explained with categories and violations

if (!result.ok) {
  // nothing entered your system
  // full history available for debugging
  console.log(result.error.message);
  console.log(result.error.attempts);
}

What Boundary guarantees

Boundary guarantees system-level correctness, not model behavior:

Guarantee	Description
Deterministic gate	Every run is accepted or rejected. Rejected data does not enter the success path.
Schema compliance	Accepted output matches your Zod schema exactly.
Rule enforcement	Every rule returned `true` on the accepted output.
Targeted repair	On failure, specific violations are sent back to the model — not blind retry.
Full history	Every attempt is recorded with raw output, cleaned output, issues, and failure category.

The model may generate incorrect outputs. Boundary keeps those outputs out of the accepted path and gives you structured rejection details.

What Boundary does NOT guarantee

Not guaranteed	Why
The model will succeed	It may exhaust all retries and return `ok: false`
Zero retries	Most calls take 1-2 attempts. Some need 3.
Correctness beyond your rules	If you don’t write a rule for it, Boundary can’t catch it
Latency bounds	Total time depends on retry count and model speed

Correctness is defined by your schema and rules:

defineContract({
  schema, // ← defines structure
  rules,  // ← defines what "correct" means
});

If a value violates your domain logic but you have not written a rule for it, Boundary will not catch it. The guarantee is scoped: everything you define is enforced.

Mental model

The model proposes outputs. Boundary decides what your system accepts.This separation makes your application deterministic, even when the model is probabilistic.

The acceptance boundary

LLM output
    ↓
  clean     → extract JSON from raw response
    ↓
  verify    → schema check + rule check
    ↓
 accept?  ──yes──→  result.ok = true  →  your application
    │
    no
    ↓
  repair    → explain violations to model
    ↓
  retry     → model tries again with repair context
    ↓
  (loop until accepted or maxAttempts exhausted)
    ↓
  result.ok = false  →  structured error, no data leaks

Next steps

When to Use

Where Boundary fits — and where it doesn’t

API Reference

Full API surface

Observability

The guarantee is enforced locally by @withboundary/contract. Use local development logging to inspect individual runs, then add production observability when you want aggregate dashboard views.

Start Here

Learn The Model

When `result.ok === true`

When `result.ok === false`

What Boundary guarantees

What Boundary does NOT guarantee

Mental model

The acceptance boundary

Next steps

When to Use

API Reference

Observability

​When result.ok === true

​When result.ok === false

​What Boundary guarantees

​What Boundary does NOT guarantee

​Mental model

​The acceptance boundary

​Next steps

When to Use

API Reference

​Observability

When `result.ok === true`

When `result.ok === false`

What Boundary guarantees

What Boundary does NOT guarantee

Mental model

The acceptance boundary

Next steps

Observability