Reshape a nested JSON payload into a flat schema without losing fields that only appear sometimes

Design a flattening spec to turn the nested JSON sample below into a flat, tabular schema — the spec itself, not just an example of the flattened output, since this needs to run against every future payload from this API, not just the sample shown.

SAMPLE JSON PAYLOAD
{"order_id": "A1", "customer": {"id": 9, "email": "x@y.com"}, "items": [{"sku": "S1", "qty": 2}, {"sku": "S2", "qty": "1"}], "discount": null}

TARGET USE
One row per order-line-item, for loading into a revenue-by-SKU BI table

KNOWN VARIABILITY ACROSS RECORDS
The "discount" field is sometimes a nested object with amount/reason instead of null, and "items" can occasionally be an empty array for cancelled orders

Work through the payload structure and propose a flat schema: one row per One row per order-line-item, for loading into a revenue-by-SKU BI table's natural unit (a single event, order, or user — state which one you're choosing and why if it's not obvious from the payload). For each nested object or array, decide and state explicitly how it should be handled: flattened into prefixed columns (address.city, address.zip), exploded into multiple rows (one row per item in an array, with a clear rule for how the parent fields repeat across the exploded rows), or kept as a raw JSON string column if it's too variable to usefully flatten — and give the reasoning for which choice fits which field, not just the mechanical result. Explicitly handle fields that appear in some records and not others: state the exact behavior for a missing field (null vs. a specific default) rather than leaving it to whatever the flattening code happens to do by accident. Where a field's type is inconsistent across records in a way the sample hints at (a quantity field that's sometimes a string and sometimes a number, an array that's sometimes absent and sometimes empty), flag it as a normalization rule to build in, not something to discover later when the flattening script throws an error on a record shaped differently than the sample.

WHAT NOT TO DO
Do not just show one example of the sample payload flattened — the deliverable is the general rule, applicable to a payload you haven't seen, not a one-off transformation of the one example given. Do not silently choose "explode into rows" for every array without checking whether that specific array's cardinality actually calls for it versus a flattened summary column (e.g., a count or a comma-joined list).

OUTPUT FORMAT
1. Chosen row grain and why.
2. Field-by-field flattening rule: source path | target column(s) | flatten/explode/raw-JSON | missing-value behavior.
3. Type-inconsistency flags with the normalization rule for each.
4. One worked example showing the sample payload run through the spec.