Keep Strict Output Boundaries Strict
Jun 07, 2026
Strict structured-output boundaries should reject invalid output instead of trying to repair it silently. When a producer adds extra prose, status text, or wrapper content around expected data, the first response should be to clarify the producer contract and add missing tests, not to make the parser more permissive.
Definition
A strict output boundary is a validation point where a system expects data in a precise format, such as JSON, and rejects anything that does not match that contract.
A fail-closed output boundary rejects malformed, ambiguous, or wrapped output instead of trying to infer what the producer meant.
Why it matters
Structured-output workflows depend on clear handoffs. If a downstream parser starts accepting "almost valid" output, contract violations can become harder to see. That can move ambiguity into later steps, where failures are more expensive and harder to diagnose.
Strict boundaries are especially important when output drives automation, persistence, approval flows, or user-visible artifacts.
Common failure mode
A producer returns structured data with extra surrounding text:
- A status line before the data
- An acknowledgement preamble
- Explanatory prose after the data
- Markdown fences around data
- A partially valid object mixed with commentary
The failure appears at the parser, so it is tempting to "fix" the parser by extracting the valid-looking portion. That may solve the immediate symptom, but it can weaken the contract.
Better pattern
Keep the consumer boundary strict unless there is clear evidence that the contract itself should change.
A better sequence is:
- Confirm whether invalid output is already being rejected.
- Classify the source of failure: producer instructions, schema, parser, routing, or tests.
- Clarify the producer contract.
- Add tests for known invalid-output classes.
- Verify invalid output still fails closed.
- Only change the parser if the intended contract explicitly requires it.
Example
A workflow expects a producer to emit a single JSON object. Sometimes the producer returns a sentence before or after the object.
The parser correctly rejects the output. In that case, the parser is not the defect. The defect is the producer contract or the missing test coverage around that contract.
The right fix is to tell the producer explicitly that no surrounding text is allowed and to add rejection tests proving that wrapped output still fails. The output boundary remains strict, and the upstream behavior becomes clearer.
Related concepts
- Output Contracts
- Interface Contracts
- Fail-Closed Behaviour
- Structured Output Validation
- Regression Testing
- Producer Contract Hardening
