Schema validation: Zod and Pydantic
Words made simple
A few useful meanings before you read the explanation.
- Schema
- A description of the fields and value types that data should contain. It helps check that an answer has the expected shape.
- Pydantic
- A Python library for describing data fields and checking or converting incoming values against those descriptions.
- API
- A way for one piece of software to ask another for data or an action. A claims API might return the current status of a claim.
More words from this lesson
- Structured output
- An answer organized into specified fields, such as claimId and status, instead of only free-form text.
- JSON
- A common text format for exchanging data using named fields, lists, numbers and values. Example: {"status": "pending"}.
- Persistence
- Saving information so it remains available after a request ends or a process restarts.
- Authorization
- Checking what that identity is allowed to read or do. Being logged in does not grant access to every record.
Overview
- Schema validation verifies data shape, types, required fields, and declared constraints at runtime.
- Zod is commonly used in TypeScript; Pydantic serves a similar role in Python.
- These validators check structure, not whether facts are true or actions are permitted.
Why this matters
Type declarations disappear or are not enforced at runtime, while model/provider data arrives from an external trust boundary.
An everyday example
A form checker verifies that the amount field contains a number; an assessor separately checks whether that amount is justified.
A technical example
An enum restricts intent to known routes, and a bounded string prevents a megabyte-long claim ID.
How it works
- Parse untrusted value
- Reject unknown fields/invalid values
- Normalize deliberately
- Run domain checks
- Persist or execute only valid data.
Architecture and flow
Unknown JSON → Zod/Pydantic → domain validation → permitted operation.
The insurance assistant example
An extracted accident date must be valid, within relevant business constraints, and confirmed when ambiguous.
When to use it
API boundaries, structured outputs, tool arguments, provider results, and event payloads.
When to avoid it
Do not approve coverage merely because covered: true is a valid boolean.
Interview answer
“Runtime schemas make data usable by code; business services still verify truth, authorization, and domain rules.”
Benefits, trade-offs, and production considerations
- Keep schemas and types aligned, reject excess properties when appropriate, and avoid silent coercion at sensitive boundaries.
- Repeated invalid output needs bounded retries and a failure path.
import { z } from "zod";
const ClaimDraft = z.object({
policyId: z.string().min(1).max(80),
incidentDate: z.string().regex(/^\d{4}-\d{2}-\d{2}$/),
description: z.string().min(10).max(5000),
}).strict();
// Teaching boundary: raw is externally produced unknown data.
function parseDraft(raw: unknown) {
return ClaimDraft.parse(raw);
}
// A date-shaped string may still be impossible, e.g. 2026-99-99.
// The business service verifies calendar validity, ownership, applicability,
// and approval of the exact draft before submitting it.Can you explain it without the notes?
Schema validation: Zod and Pydantic
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
Schema validation verifies data shape, types, required fields, and declared constraints at runtime. Zod is commonly used in TypeScript; Pydantic serves a similar role in Python. These validators check structure, not whether facts are true or actions are…
Turn this concept into a clear answer.
Practice this conceptAdapted from 13_AI.MD · “Schema validation: Zod and Pydantic”. Examples are study fragments; framework behavior can depend on your version.