422 Unprocessable Entity in FastAPI request validation layer

The goal is to clarify where request validation cost sits in FastAPI and how validation error responses can be controlled without changing the default 422 Unprocessable Entity behavior.

Validation is performed by the request parsing layer before the path operation function is invoked. Errors are raised by the framework rather than user code and are not visible in endpoint profiling unless the whole ASGI call is wrapped. FastAPI does not expose a first-party setting to change the validation error aggregation strategy or to map specific validation failures to different HTTP status codes. The behavior is inherited from Pydantic and can be altered only via custom exception handlers or model configuration.

There is uncertainty about measuring per-segment timing for validation versus dependency resolution and business logic, and about the supported limits for fine-grained error control.

Is there a documented way to distinguish validation time from dependency resolution time in the ASGI call? Can specific Pydantic validation failures be mapped to different HTTP status codes without a custom exception handler? What is the supported approach for fine-grained error control?