fal content_policy_violation 422 vs Sume generation_rejected

fal returns content_policy_violation with status 422 and marks it not retryable. In Sume's job errors the nearest category is generation_rejected, whose documented next action is "Inspect events and fix unsupported input." Treat both as a signal to change the input, not to retry unchanged.

fal facts are from its Model Errors page; Sume facts from Errors and credits, read 2026-10-01. The mapping is a reading aid, not an official equivalence.

What does fal say content_policy_violation means?

The input, such as a prompt or uploaded image, was flagged by automated safety systems. The flag may come from fal's filter or a partner's, and sensitivity can vary between partner APIs. The same page lists no_media_generated (also 422, not retryable) for a run that completed without producing media. The error body is a detail array whose objects carry loc, msg, type and url; fal says to branch on type, not msg.

Which Sume category matches?

Failed Sume jobs expose public error metadata: category, stage, retryability, retry-after seconds, public reason and next action. Three categories are easy to confuse with a policy block.

Does the HTTP status match?

Not necessarily. The Sume docs key the next action on the job's error category and its retryability fields, so branch on those rather than on a 422. Because the docs do not say that every moderation block maps to generation_rejected, read public reason and the job events before deciding.

What should my retry logic do?

Retry generation_unavailable later; do not retry generation_rejected or validation unchanged. For a worked moderation case, see GPT Image moderation blocked and Sume content policy rejected.