When would you use ProblemDetails instead of a custom error response shape?

In production I publish each reusable problem type with its normal status, extension schema, and remediation meaning. Clients branch on type or a documented code, never on localized title or detail text. I keep the HTTP status and body status aligned, use application/problem+json where negotiated, and preserve important headers such as Retry-After, WWW-Authenticate, or ETag-related preconditions. Correlation data helps support locate the occurrence but does not expose stack traces, SQL, tokens, tenant details, or the existence of protected resources. Gateways and downstream adapters preserve the useful upstream identity when safe instead of collapsing every failure into 500. Contract tests cover representative binding, validation, authorization, not-found, conflict, precondition, rate-limit, and dependency cases, including content type and extensions. Schema evolution remains additive, and observability groups failures by stable problem identity so product errors, abuse, and infrastructure incidents do not become one noisy bucket.