Validation Rules

Validation rules enforce business logic and domain-specific constraints that simple type checking cannot. For example, a rule might ensure a discount_percentage field is between 0 and 100, or that an end_date is chronologically after a start_date. These rules guarantee that data is not just syntactically valid but also meaningfully correct for the application's context, preventing nonsensical API calls like scheduling a meeting for yesterday.

Rules can be dynamically applied based on the values of other fields. This is implemented through if/then/else clauses in JSON Schema or custom validators in Pydantic.

• Example: If payment_type is "credit_card", then the card_expiry field is required and must match a MM/YY pattern.
• Example: If country is "US", then state must be a valid two-letter abbreviation. This allows for complex, context-aware validation that mirrors real-world business processes.

For logic too complex for declarative schemas, custom validator functions are used. In Pydantic, these are methods decorated with @validator or @field_validator. They allow for:

• Checking data against an external API or database (e.g., validating a product SKU exists).
• Performing multi-field validation (e.g., ensuring city is within country).
• Applying complex business rules (e.g., calculating and verifying a checksum). These functions provide the ultimate flexibility for enforcing arbitrary correctness conditions.

This characteristic ensures relationships between multiple fields are correct. It is distinct from single-field validation.

• Example: In a flight booking, the sum of adult_count + child_count + infant_count must equal total_passengers.
• Example: The billing_address.zip_code must be within the billing_address.country's postal code format. This is typically implemented in Pydantic using root validators (@model_validator) or in JSON Schema with combined schemas and propertyNames keywords.

Effective validation rules produce actionable, human-readable error messages—not just "validation failed." This is critical for debugging AI agent outputs.

• Poor: "value is not valid"
• Good: "Field 'email': 'user@example' is not a valid email address. Must contain a '@' and a domain." Frameworks like Pydantic allow custom error messages per rule, and JSON Schema supports errorMessage keywords (draft 2019-09 and later) to guide the AI or developer toward the exact fix.

Validation rules work in tandem with static type hints (like Python's typing module) to provide layered guarantees.

1. Static Type Checking (e.g., MyPy): Catches string vs. int mismatches at development time.
2. Runtime Validation (e.g., Pydantic): Enforces the rules at execution time, handling data from unpredictable sources like LLMs. This combination ensures type-safe API calls where the structure is known at design time and the content is verified at runtime, creating a robust contract between the AI agent and external services.

Type enforcement is the runtime or compile-time verification that data values conform to declared type definitions (e.g., string, integer, boolean). In the context of AI tool calling, it ensures the parameters generated for an API call are of the correct type before the call is executed. This is a foundational layer of validation that prevents common errors like passing a string where a number is required. It is often implemented through type checking in the code or via schema validators like Pydantic, and is a prerequisite for achieving type-safe API calls.

A structured output guarantee is a system-level assurance that an AI model's response will conform to a predefined schema, such as JSON or a Pydantic model. This is more than a hope; it's often enforced by the model API (e.g., OpenAI's JSON mode) or a post-processing validation layer. This guarantee is critical for deterministic formatting in production, as it allows downstream code to reliably parse the output without try-catch blocks for malformed data, forming the core promise of reliable tool calling.

Output parsing is the process of converting the raw, unstructured text output from a language model into a structured, machine-readable format. After a model generates text meant to represent a function call, a parser extracts the relevant parts and constructs a structured object (like a dictionary or a Pydantic instance). This step often involves:

• Extracting JSON blocks from markdown or text.
• Applying type coercion (e.g., converting a numeric string to an int).
• Feeding the result into a validation layer to check against the schema. It is the bridge between the model's text generation and the executable type-safe outputs.

A data contract is a formal specification that defines the structure, semantics, quality requirements, and lifecycle of data exchanged between systems or components. In AI tool calling, the combination of the JSON Schema for the tool and the associated validation rules forms a data contract between the AI agent and the external API. This contract ensures that:

• The agent's requests are semantically correct.
• The API's expectations are met.
• Contract enforcement systems can monitor and validate all exchanges. It is the highest-level concept governing reliable integration.