Response Models
Response models define the structure of data you want to extract from unstructured text. They are plain PHP classes with typed constructor properties that serve a dual purpose: they tell the LLM what data to produce (via the generated JSON Schema), and they provide a strongly typed container for the extracted result.Creating Response Models
Using Artisan Command
Themake:response-model command generates a ready-to-use response model class with the correct namespace, typed properties, and docblock descriptions.
Manual Creation
Create a class inapp/ResponseModels/ (or any namespace you prefer):
Property Types
Basic Types
PHP’s scalar types map directly to JSON Schema types. The LLM receives clear instructions about the expected data type for each field.Nullable Properties
Mark optional fields as nullable with a default ofnull. The LLM is allowed to omit these fields, and the resulting object will have null for any missing values.
Arrays
Use@var docblocks to specify the element type for array properties. This information is included in the generated schema and helps the LLM produce correctly typed array elements.
Enums
Backed enums map to their underlying scalar type in the schema. The LLM receives the list of allowed values, which significantly improves extraction accuracy for categorical fields.Nested Objects
Use another response model class as a property type to create hierarchical structures. The package generates nested schemas automatically.Collections
Combine nested objects with typed arrays for collections of structured items. The@var docblock on the array property tells the package which class each element should be deserialized into.
Property Descriptions
Docblock comments on constructor properties serve as field-level instructions for the LLM. Clear, specific descriptions dramatically improve extraction accuracy — they are included verbatim in the JSON Schema sent to the model.Using Response Models
Basic Extraction
With Array Schema
For quick prototyping or one-off extractions, you can pass a raw JSON Schema array instead of a class. The result is returned as an associative array rather than a typed object.Extracting Collections
To extract a list of objects from a single input, wrap the response model class in an array schema descriptor.Validation
Using Symfony Validator
Add Symfony Validator constraint attributes to your properties for automatic validation. When the LLM’s response violates a constraint, the package sends the validation errors back to the model and retries (up tomax_retries times).
Custom Validation
Implement theCanValidateObject contract for business-rule validation that goes beyond simple type and format checks. The validate method must return a ValidationResult instance.
StructuredOutputRuntime, not on the facade directly:
Best Practices
1. Use Descriptive Property Names
Property names are part of the schema the LLM sees. Clear names reduce ambiguity and improve extraction accuracy.2. Add Detailed Descriptions
Docblock descriptions are your primary tool for steering the LLM. Be specific about formats, ranges, and edge cases.3. Use Appropriate Types
Choose the most specific type available. Enums are preferable to free-form strings for fields with a fixed set of values.4. Make Optional Properties Nullable
Distinguish between required and optional fields clearly. Required properties should not have defaults; optional ones should be nullable with anull default.
5. Use Readonly Properties
Readonly properties enforce immutability, which prevents accidental mutation of extracted data. This is the recommended approach for all response models.Generated Stubs
Themake:response-model command generates from these stub types. Publish them with php artisan vendor:publish --tag=instructor-stubs to customize.