A language model is fundamentally probabilistic: the same input yields different outputs, and errors are inevitable. The most common mistake when building reliable systems is trying to force the model to be flawless. A better approach accepts this probability and wraps the model in a deterministic layer to catch whatever slips through.
The division of labour: cognition versus rules
The foundational principle is separating two kinds of work. The model handles the cognitive work: understanding context, reasoning, generating language, and making decisions that are not rule-bound. The rule layer β the harness β handles the deterministic work: validation, error recovery, policy enforcement, and anything expressible as a strict rule. The model is free to generate; the harness ensures that the generation conforms to the rules.
A trigger, not just a prompt: where the rule belongs
The key architectural question is where each rule should live. These fall into three categories:
- Hard policy belongs in the harness, not the prompt. For example, βany output that contradicts the given context must be rejectedβ β a deterministic check downstream does this, not a hope that the model will respect it itself.
- Soft guidance belongs in the prompt, where the model decides. Instructions like βprefer fidelity over fluencyβ require balance. The model weighs the trade-off but is not mechanically constrained.
- Format constraints are validated by the harness. The model generates structured output as a best effort; the harness validator verifies it and routes errors to a fallback path.
Walk the data path
To design this layer effectively, run a decisive exercise: walk the data path of each call. Before invoking the model, what does the harness assemble? What exact input does the model receive? What is it permitted to invent, and what must be strictly extracted from context? After the model returns, what does the harness verify or mitigate? Tracing this path clarifies which responsibility belongs to the model and which to the rule layer β and that removes the most common design error.
The verifier as a guardrail
A powerful extension of the rule layer is the verifier model. When a single model cannot guarantee a critical constraint, a second model acts as a guardrail. The primary model generates; the secondary model evaluates both the input and the output, rejecting the result if a rule is violated. This is the same primary-and-verifier pattern, but here the verifierβs role is a policy guardrail: a gatekeeper that wonβt let an undesirable output through the gate.
The key invariant
The core principle remains: the goal is not to force the model into flawless compliance. That is impossible. The goal is to allow the model to generate freely, while the harness assumes full responsibility for enforcing constraints. The rule layer catches exactly what slips through the modelβs training. This is the structural difference between a system built on the hope of a perfect model, and one designed around the certainty that a model will err. The latter is always more stable.