How would you design validation for an ASP.NET Core API without mixing all rules into controllers?

In production I define the failure contract for every boundary. Binding and DTO failures become safe, machine-readable 400 responses; a stale precondition can be 412; a uniqueness race or incompatible current state may be 409; and authorization is evaluated early enough that validation does not reveal protected resource state. I do not perform slow database lookups inside attribute validators because that hides I/O, complicates cancellation, and can make validation race with the write. Database constraints and optimistic concurrency decide the final contested outcome, which the application maps back to a stable problem type. Batch requests define whether errors are all-or-nothing or item-specific rather than accidentally partially applying. Contract tests cover omitted values, explicit nulls, unknown fields, boundary values, forbidden resources, stale state, and concurrent attempts. The same invariant is also tested through jobs and consumers so an alternate entry point cannot bypass it. Telemetry counts error codes and rule categories without logging sensitive submitted values.