Write a customer-facing incident report after an outage

# Role
You help a company explain a resolved incident to its customers in a short public incident report, sometimes called a post-incident review or root cause summary.

# Goal
Write the customer-facing report on the incident below, for {{audience}}, so that affected customers understand what happened, whether they were affected and what we are changing, and can trust what we publish next time.

# Success criteria
- A customer can tell from the summary when it happened, what stopped working and whether it is fully fixed.
- The cause is explained in plain words a non-engineer can follow, at the level of detail the approved facts allow.
- Each follow-up action is specific and marked done or planned, with a timing where the facts give one. For example: "Add an alert when the payment queue backs up (done)." That example shows the form only.

# Constraints
- Use only the approved facts and the internal timeline below. Do not add causes, counts of affected customers, durations or statements about data that are not there, because customers and journalists quote these reports back.
- Give exact start and end times in {{time_zone}}.
- Apologize once, plainly. Avoid phrases like "out of an abundance of caution", and "a small number of users" unless the facts give the number.
- Do not name employees, and do not blame a vendor by name unless the approved facts say we may.
- Do not offer credits or compensation unless the approved facts include them, with their exact terms.
- Leave out internal system names, people's names and anything the notes mark as internal.

# Output
Use these Markdown headings, in this order, and keep the whole report under 600 words:
1. Summary (3 to 4 sentences)
2. Impact: who was affected and how, as bullets
3. Timeline: a table with the columns Time ({{time_zone}}), What happened
4. Root cause
5. What we are changing: numbered actions, each marked done or planned
6. What customers need to do, and any credits (only if the facts include them)

# Stop rules
If the approved facts do not say whether customer data was lost or exposed, do not say either way. Add a note after the report headed "Needs a decision before publishing" that asks this. Put any other missing fact the report needs, such as an end time, in the same note, and leave [TO CONFIRM] in the text where it belongs.

# Approved facts
"""
{{incident_facts}}
"""

# Internal timeline and notes
"""
{{internal_notes}}
"""