Force reliable structured JSON out of messy unstructured text, every time

TASK
extract structured order details from free-text customer support emails

INPUT TEXT
a support inbox export of 40 emails, each requesting a return, exchange, or refund in the customer's own words

SCHEMA CONTRACT
Extract exactly these fields for every record, no more and no fewer: order_id (string or null), request_type (enum: return, exchange, refund, other), reason (short string), sentiment (enum: neutral, frustrated, angry), requires_human_review (boolean)

FIELD RULES
- Every field must be present in every record, even when there is nothing to extract for it — use the specified null/default rather than omitting the field.
- Set the field to null rather than guessing a plausible value, and only set requires_human_review to true if the email is genuinely ambiguous about request_type.
- If a value doesn't cleanly map to one of the listed enum options, use "other" and add a one-line note explaining what it actually was — never invent a new enum value on the fly.
- Do not add commentary, an introductory sentence, or a trailing explanation outside the structured output — the schema contract above is the entire contents of a valid response, nothing else.

WHAT TO DO WITH AMBIGUOUS INPUT
If a single input record genuinely contains information for what should be two separate records (for example, one email requesting both a return and a separate unrelated complaint), split it into two records rather than merging mismatched information into one, and note the split has happened via whatever notes/flag field the schema provides for it.

CONSISTENCY ACROSS RECORDS
Apply the exact same interpretation of each field and each enum value to every record in this batch — if you'd classify a given phrase as "frustrated" sentiment in record 3, classify the same phrase the same way if it appears again in record 27. Don't let earlier or later records in the batch shift your calibration.

HANDLING RECORDS THAT DON'T FIT ANY SCHEMA FIELD WELL
If a record is genuinely too garbled, too short, or too off-topic to extract meaningful values for most fields, don't force plausible-looking values into every field anyway — populate what's genuinely extractable, set the rest to their null/default per the missing-field policy, and if the schema includes a review flag, set it so a human knows this record needs a manual look rather than trusting the automated extraction for it.

MULTI-LANGUAGE INPUT
If the batch includes records in more than one language, extract and classify consistently regardless of the source language — don't let sentiment or category classification become less reliable for non-English records than for English ones just because the underlying text differs; if you genuinely can't classify a non-English record with the same confidence, flag it via the review field rather than silently guessing.

VALIDATION BEFORE RETURNING
Before returning the final output, check your own result against the schema contract one more time: every record has every declared field, every enum value is one of the declared options, and no field contains a type mismatch (a string where a boolean was declared, for instance). This is a self-check, not optional — treat a self-caught schema violation the same as one a downstream validator would catch, and fix it before returning rather than after.

OUTPUT
Return only the structured data conforming to the schema contract above — one entry per record, in the order the input records appeared.