“Write a progress report. The login screen is finished and integration testing is underway.” That request is understandable, but it does not identify the reporting period, next steps, or whether there are issues. If an AI silently invents “80% complete” and “no issues,” the prose may read well while the facts are unsupported.
The useful boundary is choose the report type, collect its required facts, then open the drafting step. This example follows one work-progress report from missing input to a draft-ready state. It does not assume facts the requester has not supplied.
Why is drafting immediately risky?
The diagram keeps the two stated facts. It asks for the missing reporting period, next plan, and issue status. An explicit answer of “none” is different from an empty issue field.
A progress report needs to distinguish completed work, current work, the reporting period, next actions, and issues. In this example, only the first two are known:
| Field | Supplied? | Next action |
|---|---|---|
| Completed: login screen | Yes | Preserve as given |
| In progress: integration testing | Yes | Preserve as given |
| Reporting period | No | Ask for dates |
| Next plan | No | Ask for the next task |
| Issue status | No | Ask whether there are issues, including “none” |
No statement about issues is not a confirmed “no issues.” Likewise, the existence of a percentage field in a template does not authorize the AI to calculate or invent a progress number.
Define an input contract for this report type
First determine whether the user wants a task assignment, a progress report, or a final-results report. Their purposes and required fields differ. Once “progress report” is selected, this small example requires period, completed, in_progress, next_plan, and issues for the body draft. A real submitted document may separately need a title, author, recipient, and document identifier.
If issues truly do not exist, let the user say none. An empty string means “not answered.” Ask only for missing fields instead of repeating the whole intake questionnaire.
Check the facts in code before requesting a draft
A prompt saying “do not guess” does not enforce application input requirements. The following Python function blocks drafting until the required fields are nonempty strings:
REQUIRED = {
"period": "reporting period",
"completed": "completed work",
"in_progress": "work in progress",
"next_plan": "next plan",
"issues": "issue status",
}
def progress_intake(facts):
missing = [label for key, label in REQUIRED.items()
if not isinstance(facts.get(key), str) or not facts[key].strip()]
if missing:
return {"state": "ask", "missing": missing}
return {"state": "draft_ready",
"facts": {key: facts[key].strip() for key in REQUIRED}}The initial request supplies two fields:
first = {
"completed": "Login screen implemented",
"in_progress": "Integration testing",
}
print(progress_intake(first))
# {'state': 'ask', 'missing': ['reporting period', 'next plan', 'issue status']}The interface should ask for those three facts rather than generate a report. After the user answers, validate the same input again:
confirmed = {
**first,
"period": "2026-09-21 to 2026-09-25",
"next_plan": "Review error messages",
"issues": "none",
}
print(progress_intake(confirmed)["state"])
# draft_readyNow a short body draft can use only confirmed values:
Work progress
- Period: 2026-09-21 to 2026-09-25
- Completed: Login screen implemented
- In progress: Integration testing
- Next plan: Review error messages
- Issues: None reported
This function neither calls an AI model nor approves a report. It decides whether to ask or draft. Check that missing fields, whitespace, and None cause questions, while confirmed values reach draft_ready.
What belongs in code, and what belongs in the prompt?
Code checks whether required values are present. The prompt tells the model how to express only those values: do not invent dates, progress percentages, owners, or issue statements. Review the generated draft anyway. Input validation does not prove that every sentence the model writes is true.
In a real workflow, define requirements per report type, remove private names and internal addresses before sending data to an AI service, and have a person approve final text before submission. This example addresses only the entrance to a progress-report body draft.
Key takeaways
Start an AI report by confirming the report type and missing facts. Ask when a field is absent; treat an explicit “none” differently from silence. Even complete input permits a draft, not automatic fact verification or final approval. Make the boundary between user-provided facts and generated wording visible.

