How to Write an Incident Report Using AI — The 6-Section Method

Why Most Incident Reports Fail

An incident report fails for one of two reasons: it says something that cannot be supported, or it hides the fact that something is missing. Both are writing problems, not investigation problems, and both get worse under time pressure.

The first failure is language. Most people write incident notes the way they talk, and everyday speech is full of intent and blame. “Carelessly dropped” is a legal opinion wearing the clothes of a description. So is “seemed distracted”, “was clearly rushing”, and “should have known better”. Every one of those sentences invites a question you cannot answer under oath.

The second failure is silence about gaps. Nobody has the full picture an hour after an event, and a report that reads as though somebody did is the one that gets picked apart. OSHA’s incident investigation guidance treats an incident report as the opening move in finding a root cause, not the closing argument — which is why saying “the cause is not yet established” is a strength in the document, not an admission.

Where AI makes it worse

Hand thin notes to a general AI assistant with a vague instruction and you get both failures at once, dressed in confident prose. It will smooth over the gaps because it is built to produce complete-sounding text, and it will reach for dramatic verbs because that is what most of its training material sounds like. This is the same mechanism behind the way AI hallucinates details in any other document — it just costs a great deal more here.

The Observed-Reported-Unknown Rule

Every sentence in a defensible incident report belongs in exactly one of three buckets: something you directly observed, something another person reported, or something that is still unknown. That is the Observed-Reported-Unknown Rule — ORU for short — and it is the approach we teach at PromptPeakAI for any document that might be read by someone looking for a weak point.

The rule matters because AI blurs those buckets by default. Tell an assistant that a witness said the guard was already off, and it will happily write “the guard was off” three paragraphs later. That is a promotion from hearsay to established fact, made silently, by a tool with no idea what it just cost you.

Why the Unknown bucket earns its place

Most people resist writing down what they do not know. It feels like an admission of sloppy work. In practice it does the opposite: a named gap tells the reader you looked and came up short, and it protects you when the answer arrives later and contradicts a guess you never should have written.

The Six Sections That Hold Up

A defensible incident report needs six sections, in this order. The order is not decoration — it front-loads what a busy reader needs and pushes the interpretive material to the end, where it belongs.

1. Summary — what happened, where, and how serious, in three sentences.
2. Details — date, time, location, roles involved, and any equipment.
3. Timeline — a timestamped sequence of what was observed.
4. Statements — what each person reported, attributed to them by role.
5. Actions taken — what was done immediately, by whom, and when.
6. Open questions — every unknown, listed plainly.

Section six is the one people delete before sending. Leave it in. A report with three open questions listed reads as controlled; the same report with those questions quietly absent reads as complete until somebody notices it isn’t. If you write executive summaries regularly, the same discipline applies to summarising a long document down to its decisions.

How to Write an Incident Report Using AI

Most advice on how to write an incident report using AI stops at the prompt itself. The two steps on either side of it — de-identifying the notes first, auditing the output afterwards — are what turn a fast draft into something you would be willing to sign.

Three steps, in order. The middle one is the one people search for; the first and third are the ones that make it safe.

Open your notes in a plain text file and replace every real identifier before anything touches a chat window. Names become Employee A, Witness B, Supervisor C. Badge numbers, phone numbers, and email addresses come out entirely. Specific room or bay numbers become a general description. Medical detail comes out unless it is the injury itself.

Do this manually. It is tempting to ask an AI tool to redact the notes for you, but that requires pasting the unredacted version first, which is the exact thing you were trying to avoid. Keep a single mapping note on your own machine so you can put the real names back at the end.

This prompt does four things: it sets a role, it fixes the six sections, it forbids interpretation, and it forces every gap to appear as a visible marker rather than an invented detail. That last instruction is the whole game.

You are an experienced workplace incident documenter. Turn the notes below into a formal incident report.

STRUCTURE — use exactly these six headings, in this order:
1. Summary
2. Details
3. Timeline
4. Statements
5. Actions Taken
6. Open Questions

RULES — follow all of them:
- Write in neutral third person. No emotional or judgemental adjectives.
- Do NOT infer intent, motive, fault, or cause. Describe only what the notes support.
- If a time, name, quantity, or detail is not in my notes, write [NOT SPECIFIED] in its place. Do NOT estimate, interpolate, or assume.
- Anything a person told me goes in Statements, attributed to their role, never stated as established fact elsewhere.
- Under Open Questions, list every [NOT SPECIFIED] item and every question the notes raise but do not answer.
- Do not add a conclusion, a recommendation, or a root cause.

CONTEXT:
Incident type: [safety / conduct / equipment / security / IT outage]
My role: [your job title]
Reader: [supervisor / HR / insurer / regulator]

NOTES:
[paste your de-identified notes here]

The bracketed lines near the bottom are yours to fill. Telling the model who will read the report changes the register more than you would expect — an insurer wants quantities and timings, HR wants attribution and process. This is the Context layer of the Logic System doing its job, and it is worth giving AI proper context even when the prompt is already long.

Read the Open Questions section first, not the summary. It tells you where your investigation actually stands. Then run a second pass to catch anything the model slipped in on its own — this is the same verification habit that makes fact-checking AI research output worth the extra two minutes.

Now audit the report you just wrote against my original notes.

List, in a table:
- Every statement in the report that is NOT directly supported by a line in my notes
- Every place you chose a specific word where my notes were vaguer
- Every [NOT SPECIFIED] marker, grouped by which section it appears in

Do not rewrite the report. Do not defend your choices. Just list them.

Then fill the gaps yourself, put the real names back from your mapping note, and read the whole thing once out loud. Anything that sounds like an accusation gets rewritten as a description.

The HR and conduct variant

Conduct investigations need a stricter separation between what was seen and what was claimed, because the two carry completely different weight in a grievance process. Swap the master prompt’s rules block for this one.

Additional rules for this conduct report:

- Split Section 4 into two labelled subsections: "Directly observed" and "Reported by others".
- Every reported item must name the role of the person who said it, in this form: "The [role] stated that ..."
- Never merge two people's accounts into one sentence. Where accounts differ, present both and label them as differing.
- Do not characterise anyone's tone, mood, or intent. Describe volume, words used, and physical actions only.
- Do not use the words: aggressive, hostile, unprofessional, deliberate, refused, negligent.

Fixing the Four Most Common Errors

Four failure modes come up again and again once people start working out how to write an incident report using AI. Every one of them is a prompt problem rather than a tool problem, which means every one of them is fixable in a single line.

The pattern behind all four fixes is the same: an explicit prohibition beats a polite request every time. Telling a model to “stay factual” does almost nothing; telling it “do not use the words aggressive, hostile, or deliberate” works immediately. It is worth understanding why negative constraints outperform positive instructions before you write your own variants.

If a draft has already come back with loaded language in it, you do not need to start over. Send it back with a repair instruction that names the problem sentences and the substitution rule.

Rewrite the report you just produced using these corrections.

For every sentence that describes a person's state, intent, or judgement, replace it with the physical observation underneath it:
- Mood or tone words become the actual volume, words used, or movement.
- Judgement words such as careless, rushed, or distracted are removed entirely.
- Any sentence implying fault becomes a plain description of what occurred.

Where the notes do not contain a physical observation to substitute, delete the sentence and add the point to Open Questions instead. Change nothing else.

When the draft comes back too thin

Sometimes the report is almost entirely gap markers, and that is a useful signal rather than a failure. It means your notes were thinner than you thought — better to find that out at your desk than in a review meeting. Go back to the people involved while the details are still fresh, then re-run the same prompt with the fuller set.

What AI Cannot Do Here

This is the part most guides skip, and it is the part that matters most in a document with your name at the bottom. AI is a formatting and structuring tool for this task. It is not an investigator, and treating it as one is how people get into trouble.

There is also a quieter limit worth naming. A well-structured report can look more authoritative than the evidence behind it, and AI is very good at producing well-structured text. If the draft reads more confidently than your notes justify, that is a signal to soften the report — not a signal that your notes were fine all along.

None of this is legal advice, and this article is not a substitute for your organisation’s own reporting procedure. Where an incident involves injury, potential liability, or a regulator, the report should go past someone qualified before it goes anywhere else. The same caution applies when you turn the incident into a risk assessment or a lessons learned write-up afterwards.

Which Tool and Plan to Use

The short answer: for de-identified notes, any of the major assistants will do this well on a free tier. For anything identifiable, the question stops being about capability and becomes entirely about which account you are typing into.

• De-identified notes: any of the major assistants, any tier, no approval needed.
• Identifiable detail: only an account your employer provides and your IT team has approved.

The distinction people get wrong is free versus paid. That is not the line. Paying for a personal subscription changes your usage limits and your model access; it does not change how your conversations are handled. The training default and the opt-out are identical whether you pay nothing or the top personal rate.

The line that actually matters is consumer account versus business or enterprise account, where organisational data is excluded from model training by default. OpenAI’s own documentation on how your data is used states this distinction plainly, and the other major providers draw it the same way.

If you live in Microsoft 365

Copilot inside Word is the most frictionless version of this workflow for anyone whose reports already start as a .docx on a company template — the draft appears in the document rather than in a browser tab you then have to copy out of. The trade-off is that it is an organisational licence, so the decision is your IT department’s rather than yours. The Copilot in Word workflow covers the mechanics.

Save it before you need it

The reports that go wrong are almost always the ones written at the end of a long shift, from memory, in a hurry. A saved prompt is what turns that into a five-minute job. Ask the tool to build you a version tuned to your own reporting template, then keep it somewhere you can reach from your phone.

Take the incident report prompt we just used and adapt it into a saved version for my own use.

Adjust it so that:
- The section headings exactly match my organisation's template, which uses: [paste your headings]
- The incident type defaults to [safety / conduct / equipment / security / IT outage]
- The banned-word list includes any terms my industry treats as loaded: [list them]
- The gap marker is written as [my preferred marker text]

Return the finished prompt as one block of plain text I can copy and save. Do not explain the changes.

The same principle applies to turning any raw transcript into structured notes: the value is in having the system ready before you need it, not in inventing one under pressure.

If you want a fuller picture of what is and isn’t safe to hand a chat window at work, the workplace privacy guide goes deeper than this article has room for.