Validating a model's output before it executes an action or reaches a sensitive destination takes more than checking that the output is well-formed. A practical implementation needs to layer schema validation, business rule checks, and destination-specific handling, applied in a defined order before anything the output triggers actually takes effect.
Start with strict schema validation against an expected structure
Before anything else, validate that the model's output matches the exact structure your code expects: required fields present, correct data types, values within any format constraints like string length or numeric range. Use a strict schema definition and library-based validation rather than ad hoc manual checks, since a formal schema is easier to review, test, and keep synchronized with the tool's actual interface than scattered manual validation logic spread across the codebase.
Reject malformed output rather than attempting to repair it
When output fails schema validation, reject it and handle the failure explicitly, rather than trying to automatically repair or guess at the intended correct value. Automatic repair logic brings its own risk, since a repair heuristic might "fix" malformed output into something the model never actually intended, effectively swapping the validation code's own guess in for the model's actual decision, which defeats the whole point of validating the model's output in the first place.
Apply business rule validation as a distinct step from schema validation
After schema validation passes, apply a distinct layer of business rule checks: does this specific value fall within an approved limit, does this specific action match what the current context and identity are actually authorized to request. This is a conceptually separate check from schema validation, covered in output validation guidance, and implementing it as a distinct step, rather than folding it into the same validation function as schema checks, keeps the two concerns clearly separated and each easier to test on its own.
Validate against the actual current state, not stale assumptions
Business rule validation should check against the current, live state relevant to the decision, current account balance, current inventory level, current authorization status, not a snapshot that might have been current when the model's context got assembled but could have changed since. A time-of-check versus time-of-use gap here can let an action that was valid when the model made its decision become invalid by the time it actually executes, so validation needs to check state at the point of execution, not just at the point of the model's original decision.
Apply destination-specific encoding and handling as the final step
Once schema and business rule validation both pass, apply encoding and handling specific to where the output is actually going: HTML encoding for content rendered in a browser, parameterization for a database query, strict allowlisting for anything that might reach a command execution context. Treat this as the final step in the validation pipeline, applied consistently no matter which earlier validation path the output took to get here.
Log validation failures with enough detail to investigate patterns
Every validation failure, whether at the schema, business rule, or destination-handling stage, should get logged with enough detail to investigate later: what got rejected, at which validation stage, and why. A pattern of repeated validation failures from a specific interaction or identity can point to either a bug in a specific integration or a deliberate attempt to probe the validation boundaries, and that pattern only becomes visible if failures get logged consistently instead of silently discarded.
Build validation as a mandatory step the code cannot bypass
Structure the code so any path from a model's output to an action has to pass through the validation pipeline, rather than allowing a shortcut or alternate code path that bypasses validation for convenience in some specific case. A validation function that exists but can be optionally skipped by a caller is a validation function that will eventually get skipped, whether through a rushed implementation decision or an oversight during a later refactor.
Test the validation pipeline itself with adversarial inputs
Following the unit and integration testing guidance covered elsewhere, specifically test the validation pipeline with inputs designed to probe its boundaries: malformed structures, business-rule-violating values that are otherwise well-formed, destination-specific injection attempts like content designed to break out of expected encoding. This confirms the validation pipeline itself holds up, not just that it exists.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, can implement the business rule validation layer specifically for tool calls, checking a requested action against configured limits and authorization independent of the model's own output.
Schema validation and destination-specific encoding and handling remain application-level implementation work specific to each tool's interface and each output's actual destination.
A short checklist
- Apply strict schema validation as the first step, rejecting rather than
repairing malformed output.
- Apply business rule validation as a distinct step from schema
validation.
- Validate against current live state, not a stale snapshot from when
the model made its decision.
- Apply destination-specific encoding and handling as the final step.
- Log every validation failure with enough detail to investigate
patterns.
- Structure the code so validation cannot be bypassed by an alternate
path.
- Test the validation pipeline itself with adversarial inputs targeting
each stage.
Validating LLM output before execution requires a layered pipeline, schema, business rules, destination handling, applied consistently and without bypass, rather than a single generic check that assumes covering one category of validation is sufficient for all of them.