policy_flagged — chunk rejected by policy

This is not an HTTP error. The code arrives in two ways: as the value of OrderItem.status, and as the reason in the skipped[] array of the 202 response to POST /orders/{order}/items/retry-failed. The order itself moves to partially_completed — a NON-terminal status: completed chunks stay in place, failed ones wait for action.

The content of the chunk was rejected by the policy of the generation provider. Bulk retry deliberately skips such chunks: the same text would be rejected again, and an attempt is not free in terms of time. Technical failed chunks, on the other hand, it picks up all at once.

Fetch the current text of the chunk, rephrase the offending fragment, and retry the chunk individually with the corrected text. The rejection reason is not exposed in any field — edit at your own discretion. Retry constraints: the new text must be ≤ original_text_length, no more than 5 attempts, and single-chunk retry is not available at all for sfx and music. The order-level POST /orders/{order}/retry will not help here — it does not accept partially_completed.

GET /orders/{order}/items/{item}/text → then POST /orders/{order}/items/{item}/retry with the body {"text": "<corrected text>"} → 201 with the updated OrderItem. The retry is free: it reuses the remainder already locked for the order and does not consume the key token quota.

• max_attempts_reached — neighboring code in skipped[]
• content_blocked — the same thing at order creation
• Guide: retries and idempotency
• GET /orders/{order}/items/{item}/text
• POST /orders/{order}/items/{item}/retry
• POST /orders/{order}/items/retry-failed