Skip to content
TaeyoungKim.dev

AI progress reports: Ask for missing facts before drafting

AIWritten 4 min readTaeyoungKim
LinkedInX

“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:

FieldSupplied?Next action
Completed: login screenYesPreserve as given
In progress: integration testingYesPreserve as given
Reporting periodNoAsk for dates
Next planNoAsk for the next task
Issue statusNoAsk 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:

python
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:

python
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:

python
confirmed = {
    **first,
    "period": "2026-09-21 to 2026-09-25",
    "next_plan": "Review error messages",
    "issues": "none",
}
print(progress_intake(confirmed)["state"])
# draft_ready

Now 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.

Author

TaeyoungKim

Connecting technical foundations with implementation, verification, and production decisions.

#AI reports#prompt design#input validation#workflow automation

Read next