Plans often look more certain than the conversation that produced them. A team may write “launch the pilot next month” even though the meeting also contained several untested beliefs: people will be available, the material will fit the session, and the approval will arrive on time.
An assumption log records the beliefs a team is temporarily using for planning, together with the evidence, risk, owner, and next check. It does not treat an assumption as a fact. It makes the uncertainty visible so the plan can change before a hidden belief becomes an expensive surprise.
The example below is entirely fictional. It demonstrates the method without using customer material, internal company data, or Recolx product output.
Separate assumptions from questions, decisions, and actions
Four kinds of statements can sit next to each other in the same meeting notes:
- Decision: a choice the group has confirmed.
- Open question: information the group knows it is missing.
- Action: work assigned to a person or role.
- Assumption: a belief the group is using before it has enough evidence to call it confirmed.
Suppose the notes say, “We will run a 45-minute pilot in October. Most participants should be able to attend after lunch. The facilitator will check the room calendar.” The pilot decision is clear. Checking the calendar is an action. Attendance after lunch is an assumption until evidence supports it.
If the team has already agreed on a choice, place it in a decision log. If the missing information can be phrased as something the team needs answered, use an open-question log. The assumption log is for beliefs that are already shaping the plan.
Find assumption language in the notes
Read the notes once for phrases that make a future outcome sound likely without showing how it was verified. Common signals include:
- “We expect…”
- “It should be…”
- “They probably…”
- “We can assume…”
- “That is unlikely to change…”
- “This will be enough…”
Do not automatically label every forecast as a bad assumption. The purpose is not to criticise the speaker. The purpose is to show which beliefs deserve evidence before the team makes a hard-to-reverse commitment.
Use six fields that lead to a check
A useful assumption entry needs enough context to be testable but not so much detail that nobody maintains it:
- Assumption: the belief written as a specific statement.
- Source: the note, timestamp, agenda item, or speaker context where it appeared.
- Current evidence: what supports the belief today, including “none recorded.”
- Impact if wrong: what part of the plan would need to change.
- Evidence owner and check: who will look for what information.
- Status and checkpoint: untested, in review, confirmed, disproved, or retired, plus the next review date or milestone.
The owner is responsible for finding or reviewing evidence, not for guaranteeing the outcome. That distinction prevents the log from turning uncertainty into blame.
Worked example: a fictional training pilot
Imagine a project team discussing an internal training pilot. The meeting notes contain these fragments:
“A 45-minute session should be enough for the first module.”
“Most participants will probably be free after lunch.”
“The existing worksheet can be reused with only small edits.”
“The facilitator will confirm the room and send the invitation.”
The last sentence contains actions. The first three contain assumptions. A compact log could look like this:
| Assumption | Evidence now | If wrong | Owner and check | Checkpoint |
|---|---|---|---|---|
| Forty-five minutes is enough for the first module. | No timed rehearsal recorded. | Reduce scope or extend the session. | Facilitator runs a timed rehearsal. | Before invitations are final. |
| Most participants are available after lunch. | No availability check recorded. | Move the session or offer another slot. | Coordinator checks the invite list. | Before booking the room. |
| The existing worksheet needs only small edits. | Prior version exists; new module not compared. | Allocate editing time or simplify the exercise. | Content owner compares both versions. | At the content review. |
Each entry preserves what the group believed, what it actually knew, and what would change if the belief failed. It also creates a practical path to better evidence.
Prioritize by impact and uncertainty
Not every assumption deserves the same attention. Use two questions:
- How much would the plan change if this were wrong?
- How weak is the current evidence?
Check high-impact assumptions with weak evidence first. In the fictional example, participant availability may determine whether the session can happen at all, so it deserves an early check. A minor worksheet-format assumption may wait until the scheduled content review.
Avoid inventing numerical scores when the team does not need them. Plain labels such as high, medium, and low can be enough if the reason is recorded.
Update the status without erasing the original belief
When new evidence arrives, add it to the entry and change the status:
- Confirmed: available evidence supports using the belief for the current plan.
- Disproved: evidence shows the belief should no longer guide the plan.
- Retired: the plan changed, so the assumption is no longer relevant.
- In review: evidence is being gathered or remains mixed.
Keep the original wording and source. Replacing the old statement with the new conclusion makes it harder to understand why the plan changed. A short history is more useful than a perfectly tidy record.
Copy-ready assumption log template
- Assumption:
- Source note or timestamp:
- Current evidence:
- Impact if wrong:
- Evidence owner:
- Check method:
- Status: Untested / In review / Confirmed / Disproved / Retired
- Next checkpoint:
- Evidence history:
Start with one permitted meeting note. Identify three assumptions that are already shaping the plan, link each one to its source, and give each an evidence owner and a checkpoint. The goal is not to remove uncertainty. It is to stop uncertainty from hiding inside confident-sounding plans.
