A project assumptions log records what you are relying on before you have enough evidence to treat it as established. Give each assumption a reference, someone to check it, a method and a deadline. When an answer arrives, record what it supports and what you will do with the affected work.
A checked assumption is not automatically an approved change, a finished task or permission to publish. The useful result is knowing which part of the plan you can rely on, for what purpose, and which part still needs an answer.
Consider this small programme-design job. Every organisation, person, document, message, date and result below is fictional. Merrin Arts Club has asked Wattle Room Studio for the first layout of an English two-page workshop programme as a PDF. Nina maintains the log and checks the evidence. Ben is the client contact; the fictional brief lets him identify wording for that first layout, without making that final publication sign-off.
At 16:00 on 11 November 2026, the log looks like this:
| ID and assumption | What the check established | What Nina does next |
|---|---|---|
| AS-01: Programme-text-v1 is the wording to use for the first layout. | Supported for that purpose on 10 November. A possible room change reported on 11 November means the next use needs a recheck. | Hold text-dependent adjustments and ask which wording remains usable by 12 November, 12:00. |
| AS-02: The receiving coordinator can use the agreed PDF without an editable version. | Contradicted for the intended later updates: Ben says the coordinator needs an editable version. | Discuss the additional handover request by 12 November, 10:00; do not treat it as approved extra work. |
| AS-03: The workshop list in the brief is complete. | Unverified: no reply to the completeness question is recorded. | Keep completeness unconfirmed and obtain the comparison by 12 November, 15:00. |
All example times use the fictional project’s agreed UTC+11:00 offset. These are planned follow-ups at the snapshot, not completed actions or promised delivery dates.
Copy the blank log and compare the worked example
Use the blank assumptions log (CSV), the fictional worked log (CSV) and the instructions and full example history (TXT). The two CSVs have the same 17 columns. The worked file contains the three current rows above, including the earlier checks in their history, at the stated snapshot.
These are plain UTF-8 value files. They contain no formulas, alerts, automatic approvals or automatic history. Office/Excel/Sheets opening has not been tested. Import into a copy and check IDs, text, column boundaries and timestamp offsets before live use; keep an unchanged original.
For a quick start, copy this smaller working note and fill it in before the next commitment:
Assumption ID and statement:
Output, version and purpose it applies to:
Why we are relying on it:
Who will check it, how, and by when:
Evidence reference, check time and result:
Work affected, next action, owner and next check:
Earlier checks to retain:
The completed CSV keeps those details in separate fields so that a future check does not erase why you first relied on the assumption.
Set a check that can change the work decision
Write a statement that another person can confirm or contradict for a particular purpose. “Client inputs” is a topic. “Programme-text-v1 is the wording to use for the first layout” identifies something Nina can ask Ben to check.
Then record why it was taken as given. A file being named in a brief explains where an assumption came from; it does not prove that the file is current. If a statement is already explicitly agreed, record that agreement where the project keeps it rather than making it look unconfirmed merely to fill the log.
Andy Jordan’s public assumptions-log description on ProjectManagement.com covers capturing assumptions and the work to validate them, with description/reason, owner, status and update fields. The CSV here is our suggested workflow, not a reproduction of the members-only file or a mandatory standard.
The check needs a clear answer, not just a reminder to “follow up”:
| Assumption | Check Nina arranges | Answer needed |
|---|---|---|
| AS-01: v1 is the wording for the first layout. | Ask Ben to identify the wording file and version, including any exclusions. | An answer that identifies which wording can be used for that draft. |
| AS-02: the coordinator can use the PDF without an editable version. | Ask whether the recipient can use the PDF for their intended later updates. | The actual handover need, without assuming that an extra deliverable has been agreed. |
| AS-03: the brief lists every workshop. | Ask Ben to compare the list with the current programme and identify missing or removed workshops. | A completeness comparison; confirming wording alone does not answer this question. |
The verification owner is the person responsible for obtaining and assessing the answer. Nina owns these checks even though Ben supplies the client information. A check deadline is when she needs the answer; it is not a promise that the client will reply then.
Choose that deadline before the work needs the information. If you are still at proposal stage, the design proposal template helps state what you are assuming and what questions change the job. This log carries those questions forward into checks and evidence during the work.
Follow the same assumptions from entry to evidence
Before checking: all three are unverified
On 9 November at 09:00, Nina records AS-01, AS-02 and AS-03. She keeps the original statements and entry time. AS-01 and AS-02 need an answer by 10 November at 12:00; AS-03 is due on 12 November at 15:00.
She asks Ben to compare the workshop list with the current programme. That request is Q-03 in this invented case. Sending a question is an action, but it is not a validation result. AS-03 stays unverified until there is an adequate answer.
AS-01: an exact version is supported for a limited purpose
At 10:15 on 10 November, Ben identifies Programme-text-v1 for the first layout. Nina checks the response at 10:30 and records E-01 as the evidence reference. AS-01 becomes Supported for the first layout only.
The source time and the time Nina evaluates it are different. So are the things it establishes: it identifies the wording for that draft, but does not establish publication sign-off or whether the workshop list is complete. AS-03 still needs its own comparison.
This lets Nina use the identified wording for the stated draft purpose. It does not show that a layout has been completed, reviewed or accepted.
AS-02: a contradiction creates a question about the plan
At 11:00 on 10 November, Ben says the receiving coordinator needs an editable version for later updates. Nina checks that response at 11:15 and records E-02. The PDF-alone assumption is Contradicted for the intended handover.
Nina keeps the original proposition so someone else can see what proved unsuitable. She records the request for an editable version and sets a discussion for 12 November by 10:00. The agreed PDF deliverable remains distinguishable from that additional request.
Finding that a premise is wrong does not authorise its replacement. The log does not approve an editable deliverable, its price, a new date or a work start. Nina needs the project’s actual agreement before promising the extra output. If that affects the agreed work, use the project’s change process; the scope of work template explains the separate job of defining deliverables and agreeing changes.
AS-03: no reply leaves the answer unknown
By 16:00 on 11 November, Q-03 has no recorded response. Nina leaves AS-03 Unverified, with no completed check time. Its 12 November, 15:00 deadline is still ahead.
She does not mark the list complete because nobody objected. She also does not invent a missing workshop. The next action is to obtain the comparison and keep the completeness of the list visibly unconfirmed until then. An unanswered question does not itself approve extra sessions or a revised layout.
Recheck when the basis for using an answer changes
AS-01 does not stay supported forever just because E-01 exists. At 15:00 on 11 November, Ben reports that a room change is being considered. He cannot yet confirm whether the wording in v1 will need changing. Nina records the message as E-03 and reopens the check at 15:10.
This is Recheck, not a claim that the old answer was wrong when it was given. E-01 still explains why v1 was usable for the earlier first-layout purpose. E-03 makes the next use uncertain; it does not identify or approve replacement wording.
Nina appends the new event to AS-01’s history, retains E-01, adds E-03 to the references and sets a new check for 12 November at 12:00. She asks Ben which wording remains usable and what, if anything, has changed.
Her work response is specific: hold text-dependent adjustments until that answer is clear. She does not use the log to freeze unrelated agreed work. The answer may support continued use within a stated limit, contradict the premise or leave a narrower question open; the evidence determines which result she records.
Update the current row without erasing earlier evidence
Use one current row per assumption ID. The worked CSV is a snapshot, not three separate worksheets for before, during and after. Earlier checks sit in the check_history cell, with their sources, dates, recorder and changes to deadlines.
The fields have different jobs:
| Keep together | Fields and purpose |
|---|---|
| The original premise | assumption_id, assumption, applies_to, reason_for_assumption, recorded_at, recorded_by: what was taken as given, for which work, why and when. |
| The planned check | verification_owner, check_method, check_due_at: who obtains the answer, what they compare or ask, and when it is needed. |
| The actual result | status, checked_at, evidence_ref, finding: the current state, when evidence was assessed, where it is and what it establishes. |
| The next work decision | work_response, action_owner, next_check_at: the specific next step, who handles it and when to look again. |
| The retained reasoning | check_history: append the previous and new state, dates, sources, person recording the check and reason for the update. |
Before changing the current fields, append the history entry. AS-01’s history therefore retains its original 10 November check deadline, the E-01 result and the 11 November reason for setting a new deadline. Moving the current date alone would hide that sequence.
Keep source references precise enough to find the right message, document version or comparison. The example uses short invented references; your live log needs the agreed source location behind each one. Keep sensitive client material there rather than copying entire messages into every shared log.
Recheck the same proposition under the same ID. If the proposition itself changes, create a new ID and cross-reference the old one. Do not rewrite AS-02 as “we will deliver an editable file”: that would replace a statement being tested with a promise the check did not authorise.
What if a check is missed or the answers conflict?
If the deadline passes without an adequate answer, retain the missed deadline in the history and record the current situation. Set a separate next follow-up rather than moving the date to make the check appear on time. The premise remains unverified; the dependent work needs an explicit discussion before anyone relies on it.
If two answers differ, keep both references and check whether they concern the same version, output and purpose. An answer about first-layout wording cannot settle publication approval. Ask the appropriate project contact to resolve the specific conflict before marking that proposition supported. If the evidence is still incomplete, record the remaining uncertainty and the next check.
The person maintaining a log does not acquire authority to change the scope, promise a new date or approve publication. Recording the next action makes that decision visible; it does not make the decision for the project.
Assumptions log questions
How is an assumption different from a risk?
An assumption is a premise you are relying on and need to check. A risk describes something that might happen and affect the work. “The brief lists every workshop” needs a completeness check. “An additional workshop may require a layout change” is a possible event and consequence. Neither proves the other. Use the project risk register when you need to consider likelihood, warning signs and a response to that possible event.
Can we proceed while an assumption is still unverified?
Sometimes a project can agree to proceed on a stated basis, but record who agreed, the permitted work and its limits through the actual project process. Keep the assumption unverified until the evidence supports it. Agreement to proceed despite uncertainty is a work decision, not confirmation that the premise is true. If no such agreement exists, do not invent it in the log.
Can I reuse the worked assumptions on another project?
Reuse the questions, not the results. The evidence for one client, file version or handover purpose does not validate another. Start new project records and set the checks that fit the actual job. The CSV labels are prompts for that work, not a checklist whose completed cells make the project ready.
Start with the assumption that the next commitment depends on. Name the person who will obtain the answer, the evidence they need and the point when the team must decide what to do if it is still unknown.
