VII · Verification & ReflectionEmerging★

Stochastic-Deterministic Boundary (SDB)

also known as SDB, Proposer-Verifier-Commit-Reject Contract

Formalize the seam between an LLM proposal and a system action as a four-part contract — proposer, verifier, commit step, reject signal — so the contract itself, not the agent's good intent, gates side-effects.

Context

A production agent runtime takes LLM outputs and turns them into real-world actions. The team has ad-hoc validation scattered across the codebase: some calls are wrapped, some are not; verifiers exist but are not contractual; rejection has no standard signal that downstream systems can react to.

Problem

Without a named contract at the boundary, validation is implicit and inconsistent. An LLM proposes something; somewhere downstream it commits; somewhere there may be a check. Audit cannot say 'every action passed verification' because verification is not architecturally enforced. The team has no shared vocabulary for the seam where stochastic generation becomes deterministic effect.

Forces

  • Inline validation per call site drifts and decays.
  • Formalizing the contract demands a small amount of upfront discipline.
  • Without a named primitive the team cannot reason about boundary failures uniformly.

Example

A trading agent proposes 'sell 50 NVDA at market'. SDB: Proposer = the LLM call producing the order JSON; Verifier = deterministic check (cash sufficient, within risk limits, market hours); Commit = order-submit API call; Reject = typed error {reason: limit-exceeded, retry_with: smaller_order}. Every order goes through this seam; auditor counts commits-with-matching-accept as 100%.

Diagram

Solution

Therefore:

Treat the SDB as the load-bearing primitive of the runtime. Define the four parts explicitly per action class: Proposer is the LLM call that emits a candidate action; Verifier is a deterministic function that returns accept/reject with reason; Commit is the side-effect that fires only on accept; Reject is a structured signal (typed error, retry hint, escalation token) that downstream systems can react to. Audit reports group by SDB instance. Pair with supervisor-plus-gate, policy-as-code-gate, eval-as-contract.

What this pattern forbids. No LLM output reaches a side-effect without instantiating all four SDB parts; rejection produces a structured signal, not a silent fallback.

And the patterns that stand alongside it, or against it —

  • complementsSupervisor-Plus-Gate★— Supervisor controller that validates and gates LLM outputs against deterministic checks before they commit to side-effects.
  • complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
  • complementsEval as Contract★★— Treat the eval suite as the contract the agent must satisfy; releases ship only if evals pass.
  • complementsTyped Refusal Codes★— Define a single source of truth for machine-readable refusal codes across all guard surfaces, so refusals can be triaged mechanically rather than by string-grepping ad-hoc human-readable messages.
  • complementsCompensating Action★★— Pair every irreversible-looking agent action with a compensating action that can undo or counteract it.
  • complementsPlanner-Executor-Verifier (PEV)★— Triadic specialization where a planner produces the plan, an executor runs it, and a separate verifier checks each step's effects against the original goal.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance