Get ChatGPT's chat interface to emit JSON reliable enough to feed into a script

You are producing JSON output from inside the ChatGPT chat interface that will be copied directly into a script — there is no schema-validation layer here the way there is calling the API with a response_format; the only thing enforcing the shape is this prompt and your own self-check before showing the output.

SOURCE CONTENT TO CONVERT
A block of freeform customer feedback text pasted from a support ticket, needing conversion into a structured sentiment record.

TARGET SCHEMA
{ "ticket_id": string, "sentiment": "positive" | "neutral" | "negative", "topics": string[], "urgency_score": number (1-5) }

FIELDS THAT CAN BE NULL VERSUS FIELDS THAT MUST ALWAYS HAVE A VALUE
ticket_id and sentiment are required, never null. topics can be an empty array if nothing specific was mentioned. urgency_score defaults to 1 if nothing suggests urgency.

WHAT THE DOWNSTREAM SCRIPT DOES WITH THIS
A Python script that loops over these objects and inserts each one as a row into a Postgres table — it will throw on a missing required key.

OUTPUT RULES
Produce only the JSON object — no prose before it, no explanation after it, no markdown code fence unless explicitly requested — since a downstream script parsing this output with a direct JSON parser will fail on any leading or trailing text, and a friendly one-line introduction before the JSON is enough to break a naive parse. Match the target schema's field names, nesting, and types exactly — if the schema says a field is a number, do not return it as a numeric-looking string, and if it says an array, do not collapse a single-item result into a bare object instead of a one-element array, since a downstream script written against the schema will branch on the type it expects and silently mishandle the type it actually got, often without throwing an error at all. Follow the nullable-versus-required distinction exactly — a required field with genuinely no value in the source content should get an explicit sentinel value agreed on in advance, not be omitted from the object entirely, since an omitted key and a null value are different things to most parsers and omission is more likely to throw an unhandled key-error downstream than a null read would. Before producing the final output, do a self-check pass that the JSON is syntactically valid — matched braces and brackets, no trailing commas, all strings properly quoted and escaped — and silently fix anything found, rather than showing output that hasn't been checked. If any part of the source content doesn't map cleanly onto the schema, do not silently drop or coerce it; stop and ask before generating the object, since a downstream script trusting a schema it thinks was followed exactly has no way to detect a silent, plausible-looking deviation on its own.

OUTPUT FORMAT
The JSON object exactly as specified above, and nothing else, unless something needed flagging per the last rule, in which case flag it before producing any JSON at all rather than producing a guessed version alongside the flag.