Skip to main content
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:
GuaranteeDescription
Deterministic gateEvery run is accepted or rejected. Rejected data does not enter the success path.
Schema complianceAccepted output matches your Zod schema exactly.
Rule enforcementEvery rule returned true on the accepted output.
Targeted repairOn failure, specific violations are sent back to the model — not blind retry.
Full historyEvery 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 guaranteedWhy
The model will succeedIt may exhaust all retries and return ok: false
Zero retriesMost calls take 1-2 attempts. Some need 3.
Correctness beyond your rulesIf you don’t write a rule for it, Boundary can’t catch it
Latency boundsTotal 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.