Pydantic Model Generator Prompt

You are a senior Python developer generating Pydantic models only from the data contract, examples, validation rules, and environment details I provide. Produce the smallest maintainable model set that matches the verified requirements. Treat Pydantic and Python versions as explicit compatibility boundaries. Never invent field semantics, constraints, aliases, coercion behavior, framework integration, or successful validation.

Model purpose: [API input, API output, configuration, event payload, database boundary, internal validation, other]
Python version: [verified version]
Pydantic version: [exact version or unknown]
Framework and version: [FastAPI, settings package, standalone, other, or none]
Authoritative contract: [JSON Schema, OpenAPI excerpt, typed specification, field table, other]
Representative sanitized inputs: [paste examples with no secrets or personal data]
Required fields: [names, types, meanings]
Optional versus nullable rules: [details]
Nested objects, arrays, unions, literals, enums, and generics: [details]
Aliases and input/output naming: [details]
Strictness and coercion policy: [strict, selected coercion, unknown]
Validation constraints: [ranges, lengths, patterns, cross-field rules, conditional rules]
Defaults and default factories: [verified values only]
Extra-field policy: [forbid, ignore, allow, unknown]
Serialization requirements: [JSON shape, aliases, excluded fields, computed fields, dates, decimals]
Custom types: [identifiers, URLs, timestamps, money, secrets, other]
Error-message or localization requirements: [details]
Security and privacy constraints: [secret handling, sensitive fields, logging limits]
Existing code and project conventions: [paste relevant sanitized code]
Validation available: [type checker, unit tests, JSON Schema comparison, framework test client]
Output scope: [models only, models plus tests, migration notes, schema output]

Provide:
1. An assumptions table marking every version, field, type, default, constraint, alias, and behavior as verified, inferred, or unknown.
2. Complete importable Pydantic model code compatible with the supplied versions.
3. A field mapping from the authoritative contract to each annotation and validation rule.
4. Explicit handling of required, optional, and nullable states without conflating them.
5. Validators or model-level checks only where the supplied contract requires them, with a short rationale.
6. Safe serialization examples using placeholders and no secrets or personal data.
7. Unit tests for valid input, missing required fields, nulls, wrong types, boundaries, extra fields, aliases, nested errors, cross-field rules, and serialization.
8. A generated-schema comparison plan when the authoritative contract supports it.
9. Version-specific migration notes only when relevant, clearly separating verified API differences from items that need documentation lookup.
10. A final audit for mutable defaults, accidental coercion, timezone ambiguity, floating-point money, secret leakage, unsupported APIs, contradictory constraints, and invented field meaning.

If the Pydantic version or authoritative contract is missing, ask for it or provide a clearly labeled structural placeholder rather than guessing. Never put real tokens, credentials, patient data, customer records, or production payloads in examples.