Key facts.
- SWE-bench Verified (arXiv:2310.06770): frontier coding agents pass syntax and format checks at much higher rates than they pass functional test suites. Structural validity and semantic correctness are different things. They need separate validation (SWE-bench Verified, arXiv:2310.06770).
- Every agent system needs at least two validation components. Schema: is the output structurally correct and complete? Business rules: does it satisfy the domain-specific constraints that actually define correctness for this task?
- Schema tools, JSON Schema, Pydantic, Zod, are mature, fast, and cheap to wire up. Business rule validation is harder: the domain knowledge it needs lives in your application, not in any library you can install.
- The most common production failure: schema passes, business rule fails. Valid JSON, all fields present, values that break domain constraints, a negative price, a date range where end comes before start, a quantity past available inventory.
- Validation completeness metrics - the fraction of possible output states that the current validation layer can correctly classify as valid or invalid - is a useful engineering measure for assessing output validation coverage. Most production agent validation layers have completeness below 80% on business rule constraints.
- SWE-bench Verified shows agents pass compilation oftener than the requirement; a better model clears schema, business rules fail. (arXiv:2310.06770)
Why schema validation is insufficient
Schema validation confirms that the output is well-formed: required fields are present, data types are correct, optional fields if present have the right types. What it can't confirm is that the values in those fields are correct for the task. A valid JSON object with a quantity field containing -500 passes schema validation. A valid date range object where checkout is before checkin passes schema validation. A valid address object with a ZIP code that doesn't exist passes schema validation. These are all business rule failures that schema validation wasn't designed to catch.
In production agent deployments, the business rule failures are the expensive ones. A malformed JSON triggers an immediate error and retry. A JSON with wrong values gets stored in the database, consumed by downstream processes, and discovers its incorrectness when a human tries to fulfill the order, process the refund, or ship to the nonexistent ZIP code. The cost of schema failure is negligible. The cost of business rule failure scales with how far the incorrect value propagates before discovery.
Implementing the business rule validation layer
Business rule validation can be implemented at three levels of comprehensiveness. The minimum level covers hard constraints: values that are definitionally impossible (negative prices, dates before the business's founding, quantities exceeding physical limits). Standard level: operational constraints, values that are technically possible but wrong for this context (an employee ID that isn't in the HR system, a discontinued product code, a region without the requested service). Complete level: cross-field semantics, relationships between values that must hold for internal consistency (end date after start, billing country matching card issuer, required fields for a specific transaction type). Each level requires different implementation approaches, with the complete level often requiring integration with authoritative data sources that the agent didn't use during generation.
Output validation coverage by layer
| Validation layer | What it catches | Implementation approach | Typical coverage |
|---|---|---|---|
| Schema validation | Missing fields, wrong types, malformed structure | JSON Schema, Pydantic, Zod | High for structural failures |
| Hard constraint check | Impossible values (negatives, invalid dates) | Custom validators in wrapper layer | Medium (depends on constraints defined) |
| Operational constraint check | Values valid in principle but not in context | Lookup against authoritative sources | Low without integration |
| Cross-field semantic check | Relationships between fields that must hold | Business rule engine or declarative rules | Low in most deployments |
VibeModel's Pattern Intelligence Layer learns which business rule violations in your specific domain most often appear in agent outputs, and which of them your current validation layer misses. By correlating output validation results with downstream error signals - returns, disputes, fulfillment failures - it identifies which business rule constraints have the highest uncovered failure rate. That gives the validation engineering team a specific priority list: implement these three business rule checks first, because they've the highest miss rate and the highest downstream cost.
Frequently asked questions
How do we define business rules for validation without a formal business rule system?
Start with the errors. Review the last six months of agent-generated outputs that caused downstream problems, extract the common violation patterns, and codify them as explicit validation checks. This bottom-up approach produces a practical business rule set faster than top-down analysis, because the failure cases are already enumerated in your incident history.
When should business rule validation reject vs flag for review?
Hard constraints (impossible values, definitive violations) should reject immediately with a specific error. Operational and semantic constraints should flag for human review when rejection would block a valid workflow and the violation type can be resolved by a human looking at context. Reserve rejection for violations that are definitionally unresolvable without agent re-generation.
Can LLM-based output validation replace a rule engine for business rules?
Not reliably for hard constraints - rule engines are faster, cheaper, and more consistent for deterministic checks. For semantic constraint checking, LLM validation can cover cases that are difficult to express as rules, but with lower reliability than explicit rules for cases that can be expressed. The recommended architecture combines both: explicit rules for everything that can be explicitly stated, LLM validation for the residual semantic space.