Keep a small closing record: the result, its final files, the decisions that explain it, and the conditions that would make an open question worth revisiting.
A finished project can still leave you guessing later: which file was the result, why did you leave something out, and was that unanswered question important? Closing the work means recording enough context to answer those questions without rereading the entire project.
Project close-out readme
PROJECT: [Project name]
CLOSED ON: [Date]
RESULT
Completed: [What this project produced]
Scope boundary: [What this completed effort does not include]
FINAL FILES
File: [Exact filename]
Location within project: [Folder or relative path]
Role: [Finished output, editable source, or supporting material]
Potentially confusing draft: [Filename and why it is not the final result, or None]
DECISIONS WORTH KEEPING
Choice: [Decision reflected in the finished work]
Reason: [Why this choice was made]
OPEN QUESTIONS
Question: [Unresolved question, or None]
Disposition: [Outside scope, intentionally unanswered, or conditional revisit]
Revisit condition: [Specific event that would make this relevant, or None]
CLOSING CHECK
[Confirm that the files listed above match the completed result and that no unresolved question prevents the stated scope from being complete.]What does closed mean if some questions remain?
Closed means the intended work has reached a stated stopping point. It does not require every idea to be explored. Begin with one sentence describing what you completed, followed by the boundary of that work: “The family recipe booklet is finished with the recipes received by June 1; later contributions are outside this edition.”
Use a four-answer close-out method: What is the result? Which files represent it? Why did it take this form? What remains unresolved? Put the answers in a readme note kept alongside the project. This is a record of a finished effort, so the note does not need an ongoing task schedule.
Which files should I identify as final?
List the files someone would need to use the result or deliberately revise it. For each one, record its exact name, its location within the project, and its role. Distinguish the finished output from the editable source when both exist.
Do not infer final status from a filename alone. Check the candidate against your completion sentence. If two files serve different purposes, explain both purposes. If an earlier draft could easily be mistaken for the result, add a short exclusion: “The eight-page draft was not used.” You can establish that distinction without reorganizing or deleting anything.
Which decisions deserve a place in the note?
Keep decisions whose absence would make the finished result confusing. Ask: “Would I be tempted to undo this choice because I forgot its reason?” If yes, record the choice and the reason together.
A useful decision entry is brief: “Used one recipe per page so longer instructions would not need a separate continuation page.” A full discussion history is usually unnecessary. Include a rejected option only when it explains an otherwise puzzling omission or surviving draft.
How do I keep open questions from becoming permanent chores?
Give each unresolved question a disposition: outside the completed scope, intentionally unanswered, or worth revisiting under a specific condition. This separates uncertainty from unfinished required work.
Write the condition in observable terms. “Revisit someday” offers little guidance. “Revisit if another edition is planned” explains when the question matters. If the missing answer prevents you from meeting the completion sentence, narrow that sentence honestly or record the project as paused instead of closed.
What would this look like in practice?
Hypothetical worked example: Maya finishes a family recipe booklet. Her project contains a finished PDF, an editable document, a shorter abandoned draft, and a question about adding an index. She records the result as “A twelve-recipe booklet covering contributions received by June 1.”
Her file entries identify Recipe Booklet.pdf in the Finished folder as the reading copy and Recipe Booklet Source.docx in the Source folder as the editable source. She notes that the eight-page draft does not represent the completed booklet. Her decision entry explains that one recipe per page keeps each recipe together.
The index question gets a clear disposition: “Not included in this edition; reconsider if a later edition adds more recipes.” Maya can now stop without treating the index as an overdue task. The readme explains both the finished result and its limits.
How much readme is enough?
Use the template below, repeating file, decision, or question entries only as needed. Write “None” where there is nothing to preserve. The note should point to the work and explain it, rather than duplicate its contents.
Finish with a cold-read check: using only the readme, locate the finished output, distinguish it from the source, and explain one important choice. Correct any vague references such as “the latest version” or “that earlier discussion.” Stop when the note answers the four questions clearly.
Your checklist
- State the completed result and what falls outside its scope.
- Record each final file’s exact name, project-relative location, and role.
- Pair each context-critical decision with its reason.
- Give each open question a disposition and, if relevant, a specific revisit condition.
- Use only the readme to locate the result and check that its status is unambiguous.
The stopping point is a finished result with an understandable record. Questions can remain open when the note explains why they do not prevent closure.