Correctness / Deterministic Boundary Stack
Deterministic Boundaries for Probabilistic Systems
Language models and other AI systems are probabilistic generators. Production software systems, however, operate under deterministic guarantees.
When probabilistic components are embedded inside deterministic software, these two properties interact in ways that are often poorly understood.
Deterministic boundaries provide a structured mechanism for managing that interaction. They introduce an explicit layer where deterministic constraints are applied to probabilistic model outputs before those outputs enter the rest of the system.
The Core Mismatch
A probabilistic generator can be represented as:
x → M(x) → y
x domain input
M probabilistic model
y candidate output
In many demonstrations and simple integrations, y is treated as immediately usable by the application. In real software systems this assumption breaks down.
Outputs may be malformed, structurally invalid, logically inconsistent, incomplete or truncated, or incompatible with downstream systems. These are not exceptional conditions. They are normal behavior for probabilistic generators.
The deeper issue is that software systems also impose deterministic constraints on what outputs they can accept.
Deterministic Constraints
Every real application has requirements that must always hold:
- schema requirements
- validation rules
- domain consistency checks
- workflow requirements
- integration constraints
- safety and policy rules
These requirements are deterministic guarantees of the surrounding software system. When a probabilistic model is embedded inside such a system, its outputs are shaped by two independent forces.
The model is not generating freely. It is generating inside the constraints imposed by the system. In other words:
y = M(x, C)
Where C represents deterministic constraints required by the application.
Constraint Accumulation
As systems evolve, additional guarantees are added: structured output schemas, domain invariants, integration requirements, safety policies, workflow constraints.
Each new guarantee introduces additional constraints on acceptable outputs. The system gradually shifts from:
y = M(x) → y = M(x, C₁, C₂, C₃, ...)
As constraint pressure increases, the admissible output space becomes smaller. This is why systems built on probabilistic components often become brittle as they grow in capability.
The underlying issue is not necessarily model quality, but the interaction between probabilistic generation and accumulated deterministic constraints.
Deterministic Boundaries
Deterministic boundaries provide an explicit mechanism for managing deterministic constraints. Instead of allowing constraints to appear implicitly across prompts, parsing logic, and application code, they are centralized at a system boundary.
x → M(x) → y → B(y, C) → z
x domain input
M probabilistic generator
y candidate output
B deterministic boundary
C deterministic constraints
z accepted system output
The model proposes candidate outputs. The boundary determines whether the system accepts them. This separation introduces two distinct responsibilities:
| Responsibility | Mechanism |
|---|---|
| generation | probabilistic models |
| acceptance | deterministic boundaries |
The model generates possibilities. The boundary applies deterministic constraints.
Boundary Responsibilities
A deterministic boundary performs several core functions.
Parsing
Model outputs often contain formatting artifacts or partial structures: invalid JSON, mixed text and structure, truncated responses. Parsing normalizes raw output into a representation that can be validated.
Verification
Verification ensures that outputs satisfy system guarantees. Two levels of checks are typically required.
Structural validation
{
sentiment: "positive" | "negative" | "neutral",
confidence: number
}Domain constraints
confidence > 0.5 subtotal + tax ≈ total
Failure Classification
When verification fails, the boundary classifies the failure mode. Classification enables targeted recovery strategies.
EMPTY_RESPONSE REFUSAL NO_JSON TRUNCATED PARSE_ERROR VALIDATION_ERROR RUN_ERROR
Repair and Retry
Instead of failing immediately, the boundary can attempt controlled recovery.
generate → clean → verify → classify → repair → retry
This continues until a valid output is produced or the retry policy is exhausted.
Determinism vs Stability
Deterministic boundaries do not make the model deterministic. Instead they make the system stable. A stable system guarantees that application logic only receives outputs that satisfy explicit constraints.
domain input ↓ probabilistic generation ↓ deterministic boundary ↓ deterministic software system
The uncertainty of the model remains, but its effects are contained.
Observability of Boundary Behavior
Probabilistic systems rarely fail in a single step. Instead, execution evolves across multiple attempts:
attempt 1 → verification failed attempt 2 → repair generated attempt 3 → verification passed
Traditional logs make this behavior difficult to understand. Deterministic boundaries can represent execution as structured event streams.
Boundary Event Streams
Each transition in boundary execution produces a structured event.
{
system: "llm-contract",
runId: "run_42",
ts: "2026-03-10T12:00:00Z",
type: "verification.failed",
attempt: 1,
data: {...}
}Common events include:
run.started attempt.started output.raw_observed output.cleaned verification.failed repair.generated retry.scheduled verification.passed run.succeeded run.failed
These events form the canonical trace of boundary execution.
Inspecting Boundary Execution
Once boundary behavior is represented as structured events, execution can be inspected and visualized. Inspection tools can expose attempt timelines, failure causes, repair strategies, and terminal outcomes.
This makes probabilistic systems understandable when embedded in deterministic software.
Reference Implementations
The deterministic boundary pattern can be implemented through reusable system components.
llm-contract
Runtime for enforcing deterministic boundaries around structured LLM outputs. Handles output cleaning, schema verification, domain constraint checks, failure classification, and repair/retry loops.
boundary-trace
Structured event system for recording deterministic boundary execution. Captures transitions such as verification failures, repair generation, retry scheduling, and terminal outcomes. These events form the canonical execution trace.
boundary-inspector
Interactive UI for exploring boundary execution traces. Provides run timelines, attempt inspection, failure analysis, and event replay. This makes probabilistic execution observable and debuggable.
Summary
Probabilistic models generate candidate outputs. Software systems require deterministic guarantees. Deterministic boundaries provide a structured mechanism for applying deterministic constraints to probabilistic outputs before they enter the system.
input ↓ probabilistic model ↓ deterministic boundary ↓ deterministic software
By separating generation from acceptance, reliable software systems can be built on top of probabilistic components.