Your plan says the review room has a screen. A note says the room has a screen, too. Before marking the assumption confirmed, check whether both statements refer to the same room, date, and use. Put those conditions beside the evidence instead of hiding them in a status label.
Use this assumption log template to connect a planning belief to the work that depends on it, the question that would test it, and the circumstances that require another check. Start with the filled example, then replace its fictional records with your own.
Open the complete example · Download the full HTML source
A room change that changes the question
This original fictional project is preparing a review of a browser-based report. The plan calls for displaying the report to the group in Room Cedar. No real venue, booking, equipment check, or project outcome is represented.
A01 — Room Cedar has a screen that can display the report for the planned review. The dependent activity is the group walkthrough. The initial source is an unconfirmed planning note, not an equipment test. A useful next check asks the room contact about the actual room, intended date, connection requirements, and a permitted display test.
In the second fictional snapshot, note E01 says: “Room Cedar has a screen.” That supports only the presence of a screen in Cedar. It does not establish that the presenter's device connects, that the report displays correctly, or that the screen is available for the review date. Keep those questions visible.
In the third snapshot, the proposed room changes to Maple. E01 still describes Cedar. The note has not become a false historical statement; it no longer answers the question about the proposed room. Reopen the room-specific check rather than copying a confirmed status into the revised plan.
The example lets you inspect these three snapshots. The selector changes the local illustration; it does not contact a venue or update a shared project record.
Copy a record that can be checked
Assumption ID:
Planning statement, including scope and conditions:
Activity or plan reference that relies on it:
Origin: who supplied the statement and where:
Evidence received, its reference and exact scope:
What the evidence supports:
What remains untested:
Question or test needed next:
Responsible person, if agreed:
Review date, if agreed:
Condition that requires another review:
Earlier entry and change note:
For A01, the condition requiring another review is a change of room, date, equipment, or presentation setup. These are proposed checks for this exercise, not a claim that an organization requires this exact form. Leave actual names and dates blank until someone supplies them.
A PMI conference paper on assumptions discusses connecting assumptions to other project documents, assigning ownership, and revisiting them as conditions change. This example applies that traceability principle without adopting the paper's numerical ranking models.
Make the next question specific enough to answer
“Check the room” is difficult to close with a useful record. Ask instead: “For the agreed review date in Room Maple, what display equipment and connection are available, and when can we test the supplied report on the intended setup?” Record the reply and any actual test separately. An equipment description and a successful display test answer different questions.
If the display cannot be used, review the affected walkthrough plan. Do not let a suggested fallback silently become an agreed decision. Use a decision log when the team actually chooses an alternative and needs to retain the reason.
Ask for a review copy from your own notes
Create a complete HTML assumption-log review copy.
Project and dependent activities: [PASTE]
Planning beliefs with their scope and conditions: [PASTE]
Source notes and actual evidence, with references: [PASTE]
Changes to the plan or circumstances: [PASTE]
Agreed people and dates, if supplied: [PASTE]
For each assumption, distinguish what each evidence item supports
from what remains untested. Preserve earlier snapshots. Identify
the next question and the condition requiring another review.
Leave missing facts blank. Do not infer confirmation, a successful
test, a booking, approval or a completed fallback. Include readable
worked records and a blank scaffold. Use local HTML/CSS and no
network, saving, sending or approval controls. Return full source.
The RAID log helps classify risks, assumptions, issues, and dependencies. Use this focused record when the remaining work is tracing whether particular evidence still supports a planning belief. Finish by comparing the current plan's conditions with the evidence's conditions, then take the unresolved question to the person who can answer it. Keep the maintained project record in the team's required format; the HTML is a separate review copy.