Friday’s report, assembled from daily notes
A weekly report is easier to review when it is built from small, dated records rather than reconstructed from memory on Friday. A model can help organize those records, find recurring themes, and draft a readable summary. The person responsible for the work still checks the facts and decides what belongs in the final report.
§ 1. Choose the report’s shape
Before collecting notes, decide who will read the report and what they need to know. Keep the structure stable from week to week. For a team update, that might mean completed work, current priorities, risks, and decisions needed. A consistent shape makes changes easier to spot and keeps the model from inventing a new format each time.
Write down the period covered and the intended level of detail. For example: “Monday through Friday; concise update for the product team; include blockers that need attention.” Avoid asking for a general summary without specifying its audience or purpose.
§ 2. Keep dated source notes
During the week, record useful details close to when they happen. Each note can include a date, the work or project, the outcome, and any open question. Include numbers only when you know their source. A brief entry such as “Wednesday: staging release delayed; payment test failed on retry; owner investigating” gives the model more to work with than “release issue.”
Keep observations separate from interpretation. “Three customer interviews mentioned setup time” is an observation. “Setup is the main reason customers leave” is a conclusion that may require more evidence. This distinction helps prevent a draft from presenting a guess as a finding.
§ 3. Gather only relevant material
At the end of the week, collect the notes that support the report. Remove unrelated details and mark items that are incomplete, sensitive, or not ready to share. If your notes contain confidential information, follow your organization’s data-handling rules before sending them to any model.
Preserve the source material so you can check a sentence against its origin. A report should be traceable: a date, result, or blocker should connect to a note, ticket, or other record rather than to the model’s confidence.
§ 4. Ask for a draft with boundaries
Give the model the audience, date range, report structure, and source notes in one request. State what it must not do: add unsupported facts, infer causes, or turn unresolved work into a completed result. Ask it to flag gaps instead of filling them in.
For example, request a draft with four headings, a short paragraph under each, and a final section listing facts that need confirmation. A capable model such as Claude Sonnet 5.5 can help organize a longer set of notes, but the quality of the result still depends on clear inputs and review.
§ 5. Check claims against the record
Review every date, metric, named owner, and statement of completion. Check that risks have not been softened and that planned work has not been described as finished. Compare the draft with the notes, then correct unsupported claims or remove them.
Read the report once for accuracy and once for usefulness. The first pass catches factual errors. The second asks whether a reader can understand what changed, what remains open, and where a decision is needed. Shortening is often part of this review.
§ 6. Save the report and improve next week’s notes
Keep the approved report with its date range and source notes. If a section was difficult to assemble, improve the note-taking habit rather than adding more elaborate instructions to the prompt. A missing owner, unclear status, or absent metric is usually a source-data problem.
If you run this workflow through an API, Vana API provides an OpenAI-compatible endpoint and also supports Anthropic Messages and Gemini native protocols. Usage is billed per real token with no monthly fee. Create an account to connect a client or script you already use, then keep the same review steps around the generated draft.