Start with structure, then replace every placeholder with information that is true, relevant, and natural for your context. These templates are intentionally skeletal so your final writing does not sound mass-produced.
A strong incident report lets a later reviewer reconstruct what was known at the time: it identifies when and where the event occurred, who was involved or witnessed it, what was directly observed, what immediate actions were taken, what evidence exists, and what remains uncertain without turning assumptions into facts.
Incident report Incident type: [x] Date/time/location: [known facts] Reported by: [name/role] People involved / witnesses: [x] Factual sequence: [chronology] Injury/damage/impact: [known facts] Immediate action: [x] Evidence preserved: [x] Notifications/escalation: [x] Open facts / follow-up owner: [x]
Near-miss report Hazard/event: [x] Where/when: [x] What could have happened: [bounded consequence] What actually happened: [x] Immediate control: [x] Evidence/witnesses: [x] Follow-up: [owner + action]
IT/service incident record Service: [x] Detected: [time/source] Impact: [users/functions] Timeline: [time → event/action] Containment/restoration: [x] Confirmed facts: [x] Hypotheses still unconfirmed: [x] Follow-up: [owner/date]
Incident quality check Direct observation separated from reports? [ ] Chronology clear? [ ] Unknowns labeled? [ ] No premature blame/cause? [ ] Required form/process checked? [ ] Sensitive information handled appropriately? [ ]
Persistent editorial registry audit: Topic slug → [ ]; claim UID/key → [ ]; source UID/key → [ ]; dependency UID + strength → [ ]; source status/version → [ ]; open review UID/reason/priority → [ ]; replacement source if any → [ ]; reviewer + resolution → [ ].