Most language-model applications need to turn unstructured input into structured data that existing software can consume.
2
Pydantic models let engineers define data, validation, documentation, and behavior in code, then generate the JSON schema used for OpenAI function calling.
3
Structured outputs can model search queries, execution plans, graphs, and citations so language-model results can move through ordinary software systems.
Summary
Jason Liu argues that production language-model systems need typed objects more often than chat interfaces. Applications commonly send model output into APIs and existing software, so parsing strings or loosely typed dictionaries creates missing keys, invalid values, and inconsistent names. Pydantic provides typed models, validation, autocomplete, documentation, and JSON Schema generation. OpenAI function calling can use that schema, while Liu's Instructor library turns the response into a Pydantic object and can retry after validation errors. He also discusses Marvin for broader model support. The same approach can add escape hatches for uncertainty, reusable components, validators, query planning, graph extraction, and citation checks. His examples treat prompts, data, and behavior as one model that ordinary code can inspect and execute. The talk's practical argument is that language-model work should borrow the development habits already used for typed application code.
Production language-model systems need structured data more often than chat
Liu says roughly 90% of the applications people build ask a language model for JSON or another structured output that gets parsed. These systems must process input data and connect to APIs or schemas that the team may not control. String prompts and string outputs make this fragile. A model may return extra prose, malformed JSON, or inconsistent field names such as "user" in one response and "username" in another. Function calling helps place output according to a JSON Schema, but Liu says the resulting dictionary still leaves engineers with missing keys, missing values, misspellings, and hallucinated fields to handle.
Pydantic turns output definitions into typed code and JSON Schema
Pydantic uses Python type hints to define models and validate their fields. Liu's delivery example gives a timestamp a datetime type and dimensions a tuple type, then lets Pydantic parse compatible input into the expected representation. The model also gives an IDE information for autocomplete and spellchecking. Pydantic can generate JSON Schema, which is the format OpenAI function calling uses to describe the expected output. This replaces loosely managed dictionaries with an object whose fields have types and whose invalid values produce a validation error.
Instructor makes an OpenAI response become a Pydantic object
Liu introduces Instructor as a library for making OpenAI function calling easier to use with Pydantic. The example patches the completion API, defines a Pydantic object, and passes it as the response model. The returned value is then an instance of the declared entity rather than a raw dictionary. That gives the calling code type safety and autocomplete. Liu says this particular approach works with OpenAI function calling, while Marvin offers a broader framework with access to more language models and capabilities.
A model can contain data, prompt descriptions, behavior, and validation
Pydantic classes can contain nested references, methods, docstrings, and field descriptions. Liu shows user-related classes with an address, a best friend, and a list of friends. Their structure would be difficult to maintain as hand-written JSON Schema. Docstrings and field descriptors become part of the schema sent to OpenAI, so names and documentation affect both code quality and prompt quality. Pydantic validators can also enforce ordinary rules, such as lowercasing a value or checking that a string has a required form, and they return errors that application code can catch.
Validation errors can become feedback for another model call
Liu shows an LLM validator that checks a value against a natural-language rule such as not saying mean things. The validator makes a model call through Instructor and can return a validation error with an explanation. Instructor can retry by appending the previous error message to the request, or by collecting validation failures and sending them back together. Liu distinguishes this from a prompt chain or constitutional AI. In his framing, it is ordinary validation and error handling implemented as separate pieces of code. The same pattern can check character counts or make a database request.
Explicit result and error fields give the model an escape hatch
Liu says systems should let a language model express that it does not know something or cannot find an answer. Instead of asking the model to emit a special string such as "I DON'T KNOW" and then searching for that exact text, a Pydantic result can contain an optional role, a result object, an error, and an error message. Code can then inspect those fields directly. This makes uncertainty part of the data structure and lets the application handle it as a normal programmed case.
Reusable structures can control reasoning and extract relationships
Liu defines reusable time-range components for work and leisure time, then suggests placing a chain-of-thought field inside the component when parsing needs help. That field could be enabled in testing and disabled in production to compare latency or performance. He also models arbitrary properties as key-value objects and can add prompts or validators for consistent keys and a fixed number of properties. A user model with an ID and an array of friend IDs can extract a network from source data, turning the model output into a graph that ordinary algorithms can traverse.
Typed plans let ordinary software execute model-generated workflows
Liu applies the same models to retrieval and planning. A search object can contain a search type, title, query, date limit, and execution method, allowing different backends such as email and video search to be selected in code. The model can return several searches, including rewritten or decomposed queries. A graph-shaped query plan can hold an ID, a question, and dependencies. In Liu's population example, independent queries can run in parallel, then later nodes wait for their dependencies. This turns a model-generated plan into something a conventional query planner or workflow system can execute.
Validators can require citations to exist in the source text
For question answering, Liu models an answer as a list of facts, where each fact contains a statement and substring quotes from the original text. A validator checks every quote against the source chunk and rejects facts without a matching quote. The question-answer validator then keeps only facts with at least one valid source quote. This approach addresses unsupported answers through application logic rather than relying only on an instruction not to hallucinate. The resulting answer can identify the actual supporting sentences instead of merely naming a page number.
"This isn't prompt chain, this isn't constitutional AI here, we just have validation error handling and then reasoning."08:14
Who should watch
You are sending model output into APIs or existing systems and are tired of repairing malformed JSON and inconsistent field names.
You want typed Python objects, validation, and IDE support around language-model calls instead of loosely typed dictionaries.
Your application needs structured retrieval, query plans, graphs, or source-backed answers that ordinary code can execute and check.
