Pydantic 1.10

Apply the Python 3 baseline first. These rules cover Pydantic 1.10, the maintenance-only V1 line that receives bug and security fixes on the 1.10.X-fixes branch until Pydantic V3 ships. V1 has no pydantic-core, no V2-style model_config (its exported ConfigDict uses V1 options), and no global strict mode, so its defaults and bypasses differ from V2 and the two APIs must not be mixed in one model.

Version scope and maintenance posture

• Declare pydantic with a <2 upper bound, lock one tested 1.10 release, and move to each new 1.10 patch release as it ships: Pydantic fixes V1 only for critical bugs and security issues, and only as patch releases from the 1.10.X-fixes branch, until V3 ships.
• Treat V1 as maintenance-only: assume no new hardening lands here, and plan a V2 migration for any service whose validation layer is a primary trust boundary.
• Run Pydantic 1.10 on a CPython minor that still receives security fixes and that upstream's V1 CI covers (3.8 through 3.14), and do not read the >=3.7 floor in the package metadata as a recommendation to deploy on an end-of-life interpreter.
• Keep V1 and V2 models in separate modules when a codebase runs both, because Config classes, validator decorators, and export methods silently mean different things across the two lines.
• Import email-validator and python-dotenv deliberately through the email and dotenv extras rather than relying on whichever version another dependency happens to pull in.

Model boundaries and Config defaults

• Define separate models for untrusted request payloads,