To stop ChatGPT or Claude from making up details in a project status report, give it only the task evidence you exported, make it fill a fixed set of fields before it writes any prose, and tell it to write MISSING wherever the evidence is silent. Then test the prompt with a status block that has known gaps, and check every name, date and number against its source ticket before the report reaches your sponsor or client.
Why does ChatGPT make up details in a status report?
ChatGPT makes up status report details because it is built to produce fluent text, and a status report has slots (dates, owners, percentages) that the model will fill whether or not your evidence covers them. Missing input becomes a plausible guess unless the prompt and your process leave no room for one.
CopyCharm describes the cause plainly: the model produces the most statistically likely continuation of a prompt, so when it lacks context it may invent details. Canny puts it as filling gaps with confident-sounding guesses. MyWritingTwin notes the other common failure: without your specific numbers, the model writes generalizations such as "the project is progressing well."
In a status report, those guesses usually show up as:
- a completion date nobody committed to
- an owner assigned to a task that has none
- a percentage that is a little too round
- a risk described more gently than the ticket describes it
What should you give the AI before it writes?
Give the AI a single, dated block of evidence for the reporting period and nothing else. Each line should carry a ticket or task ID, its status, its owner as recorded, and any due date as recorded. If a field is empty in your tool, leave it empty in the block.
Build the block like this, whether you paste an export or pull it through a connector:
REPORTING PERIOD: [start date] to [end date]
SOURCE: [task tool] export taken [date and time]
[ticket ID] | [title] | status: [status] | owner: [owner or blank] | due: [date or blank] | note: [latest comment, quoted]
[ticket ID] | [title] | status: [status] | owner: [owner or blank] | due: [date or blank] | note: [latest comment, quoted]
DECISIONS PENDING (from [meeting or thread]): [decision], requested of [sponsor role], asked on [date]
KNOWN RISKS (from risk log): [risk ID] | [description as written] | rating: [rating as written]
The Doitify guide makes the same point: gather the data before you prompt. The source line and timestamp matter later, when you need to know which version of the truth the draft was built from.
What prompt stops ChatGPT from guessing?
A prompt that leaves the model no room to guess asks for structured fields first and prose second, names the exact placeholder for missing facts, and forbids softening. Separating the two stages makes guesses visible, because an invented date has to appear in a field you can check before it can hide in a sentence.
Copy this and adjust the bracketed parts:
You are drafting a project status report for [sponsor or client role].
Use ONLY the evidence block below. Do not use earlier messages, memory, or general knowledge about projects like this one.
Stage A. Fill this table first. One row per item.
| Section (Done / In progress / At risk / Decision needed) | Claim | Source ticket ID | Owner as recorded | Date as recorded |
If the evidence does not state an owner, date, number, or reason, write MISSING: [what is missing]. Never estimate, round, or infer.
If an item does not fit a section, put it under "Unclassified" rather than choosing for me.
Stage B. Write the report using only rows from the table.
- Keep each risk at the severity the evidence states. Use the ticket's own wording for problems.
- Every sentence ends with its ticket ID in brackets.
- Do not assign a red, amber or green rating. Leave [RAG: lead to set].
- List every MISSING item at the end under "Gaps to confirm".
EVIDENCE:
[paste evidence block]
Other guides recommend the same basics: Coursiv has the model use only the supplied notes and write MISSING rather than guess, MyWritingTwin flags gaps as [DATA NEEDED], and Doitify uses MISSING placeholders, ties numbers to a source line, and has a person set and check the status color.
How do you make every claim traceable to a ticket?
You make every claim traceable by requiring a ticket ID at the end of each sentence and treating any sentence without one as unsupported. A citation the model writes is only a pointer, not proof, so the check is whether the ticket it points to actually says what the sentence says.
Start with a second-pass check. Open a fresh chat, paste the draft and the same evidence block, and run this:
Below are a DRAFT status report and the EVIDENCE block it was written from.
List every name, date, number and percentage in this draft.
For each, quote the evidence line it came from or write NOT IN EVIDENCE.
Do not correct the draft. Do not explain. Output a table:
| Item from draft | Sentence it appears in | Evidence line quoted, or NOT IN EVIDENCE |
DRAFT:
[paste draft]
EVIDENCE:
[paste evidence block]
Check the NOT IN EVIDENCE items first and fix or delete each one. Then spot-check the rest, because the checker is also a model and can quote a line that does not quite match.
When you review, work through the draft and ask of each sentence:
- Does it carry a ticket ID that exists in the evidence block?
- Does that ticket support the claim, including its date, owner and status?
- Is a number in the sentence the same number the ticket shows, unrounded?
Delete or rewrite any sentence that fails. Do not ask the model to "add a source" to it, because it may attach one that only looks relevant.
How do you test whether the prompt actually works?
Test the prompt by running it on a status block that has gaps you planted on purpose, then checking whether the draft fills them. If a planted blank comes back with an owner, date or figure, the prompt is not holding, and you have learned that before a sponsor did.
Run this test when you first adopt the prompt, and again whenever you change the prompt, the model, or the connector:
- Copy a real evidence block and remove a few facts: blank an owner, delete a due date, strip the reason from a blocked ticket.
- Add one item with no status at all.
- Run the prompt in a fresh chat.
- Check that each removed fact appears as MISSING, the no-status item lands in Unclassified, and nothing in the report is absent from the block.
- Save the test block. Rerun the same block later and compare the drafts.
This is a check you can repeat in the tools you already use, and it gives you a known input with a known correct answer.
How do you stop details carrying over from last week?
Stop carryover by starting each report in a fresh chat with a fresh evidence block, and by telling the model to ignore earlier messages and memory. Long chats and saved workspaces are convenient, but last week's dates and owners can reappear in this week's draft as if they were current.
If you keep a saved project or workspace for the report format, keep only the template and instructions there, never past evidence. Put the reporting period at the top of the block, and during review look for any date outside that period.
How do you keep bad news from getting softer over time?
Keep bad news from softening by instructing the model to reuse the ticket's own wording for problems and by setting the red, amber or green rating yourself. Then compare this week's risk sentences with last week's for the same risk: if the evidence has not changed but the wording has eased, put the original wording back.
Doitify warns against softening at-risk items, and Coursiv offers a useful tell: "a smoothed-over percentage is usually the tell." Watch for phrases such as "on track pending," "minor delay," or "being worked through" sitting next to a ticket that says blocked.
What should you check before the report goes to the sponsor?
Before a status report goes to a sponsor or client, confirm that every claim has a real source, every gap is either filled by you or stated openly, and every risk reads as seriously as its evidence. The checklist below covers that in a single pass.
[ ] Second-pass check run; every NOT IN EVIDENCE item fixed or removed
[ ] Every sentence ends with a ticket ID that exists in the evidence block
[ ] Every name, date and number matches its ticket exactly
[ ] No date falls outside [reporting period]
[ ] Every MISSING item is either confirmed by me or listed under "Gaps to confirm"
[ ] Risk wording matches the ticket or risk log
[ ] RAG rating set by me, with a one-line reason
[ ] Each decision needed names the decision, who it is for, and the date it is needed by
[ ] Nothing confidential the client should not see
Decide whether ticket IDs stay in the sent report (useful for internal sponsors who work in the same tool) or come out after review (common for clients), and keep the reviewed version with IDs for your own records.
A report that openly says "owner not yet confirmed" earns more trust than one that names the wrong person.
When are prompts and checks not enough?
Prompts and checks reduce invented details but cannot rule them out, and the Doitify guide says as much about its own rules. The model can still misread a ticket, and your evidence can itself be stale or wrong. You remain accountable for what is sent.
The practical response is to keep the AI's job narrow: arranging evidence you supplied into a format you chose. Judgments such as the overall rating, whether to escalate, and how to frame a request to the sponsor stay with you. If your task tool's records are thin, the report will be thin, and the fix belongs in the tool, not in the prompt.
Sources
- CopyCharm: How to Stop ChatGPT From Making Things Up: why the model invents details
- Canny: How to get ChatGPT to stop lying: gaps filled with confident guesses
- Doitify: How to Use ChatGPT for Project Status Reports: MISSING placeholders, source lines, no softening, limits
- Coursiv: ChatGPT for Project Management: MISSING instruction, review against the export, smoothed percentages, confidentiality
- MyWritingTwin: ChatGPT for Report Writing: generic output without data, [DATA NEEDED] flags
- Asana: Asana for ChatGPT: connecting Asana to ChatGPT
- Vantagepoint: Claude project management connectors: connecting Claude to project tools
- Truto: Connect Jira to Claude: connecting Jira to Claude