Assumptions Log: Fields, Examples and a Design Template

An assumptions log is a living list of everything your project team is treating as true without proof, each with an owner, a way to test it and a date to check it by. Keep it and you find out that the client’s budget, the site survey or the consultant’s turnaround was wrong while changing the plan is still cheap. Skip it and you find out at the worst moment. This guide covers what belongs in the log, how it differs from risk, issue and constraint logs, a template you can copy, and how design and architecture teams can use it to preserve the reasoning behind their work.

TL;DR

• An assumption is a planning belief held without proof. The log records it, who owns it, how you will test it and what happens if it is wrong.
• Keep it separate from the risk register, issue log and constraints log, but link entries across them. An assumption that fails becomes an issue or a risk.
• Every entry needs eight things: the claim, source, importance, uncertainty, owner, test and deadline, fallback, and a dated status.
• Review it on a rhythm (monthly, at stage gates, after surprises), not once at kickoff.
• Design teams get the most value when each assumption points back to the conversation where it was made.

Table of Contents

• What an assumptions log is
• Assumptions log vs risk register, issue log and constraints log
• What to put in each entry
• A copyable assumptions log template
• Worked examples
• How design and architecture teams should adapt the log
• How to review and validate entries
• Common mistakes
• Perspective: why we think the source matters most
• Turning conversations into logged assumptions
• FAQ
• Sources

What an assumptions log is

The PMBOK Guide, 8th edition, defines an assumption as a factor in the planning process considered true, real or certain without proof. A constraint, by contrast, is a limiting factor that affects how the project can be executed. The same edition treats the Assumptions and Constraints Log as a project document used to record, manage and monitor both throughout the life cycle.

In plain terms: an assumption is something you are betting on. “The client will approve the schematic design within two weeks.” “The existing slab can carry the new partition.” “The planning authority will not require a traffic study.” None of these has been confirmed. All of them shape the schedule, the fee or the design.

The trouble is that assumptions are usually made out loud, in a meeting, and then dissolve. Someone says “let’s assume the façade contractor can start in March,” everyone nods, and three months later nobody remembers who said it or why the schedule depends on it. The log exists to stop that.

Assumptions log vs risk register, issue log and constraints log

This is the question most people searching for the topic actually have, and project managers argue about it constantly. The practical distinction is about what has happened and what you can do about it.

One account describes the progression this way: if an assumption proves false and creates an obstacle, it becomes an issue, and if it poses a threat that has not yet happened, it is typically managed as a risk. That same source stresses that an assumption is a planning belief that needs validation, not a fixed truth.

Some teams combine these in one document. A PMI article on logs notes that you can track risks, issues and changes in the same log, provided you differentiate them, because each needs a different response. That is the rule to follow whatever structure you pick: if one list holds everything, add a type column and filter on it.

Assumptions versus constraints

The PMBOK document combines them in a single log, yet distinguishes them by nature: assumptions are unproven planning beliefs, constraints are fixed limits. A quick test: can you check it and be wrong? Then it is an assumption. “The budget is $850,000 and cannot move” is a constraint. “The budget will not be cut after the design development phase” is an assumption, because it could prove false. If you want a deeper treatment of the fixed side, see our guide to a constraints log for small studios. Dependencies, the things you need from other people or tasks, have their own page too: dependencies log fields, example and review rhythm.

What to put in each entry

A log of vague sentences is just a worry list. One practitioner guide recommends that each entry carry a specific, measurable assumption; its source and evidence; importance and uncertainty; an owner; a validation test and deadline; signposts; the response if it proves wrong; and a dated status, as laid out in this guide to keeping an assumptions log. A leaner version from another source suggests five core fields: a precise falsifiable claim, what changes if it is false, evidence for and against, validation status, and the next action that will test it.

Combining the two gives a practical field set:

1. ID. A short code (A-012) so risks and decisions can reference it.
2. Assumption. One sentence that could be proven wrong. “The client will respond to each submission within five working days” works. “The client will be responsive” does not.
3. Source. Who said it, when, and in what conversation or document. This is the field most teams skip and the one that matters most later.
4. Impact if false. Which part of the schedule, scope, budget or design breaks.
5. Importance and uncertainty. Rate both, for example high, medium or low. The assumptions that are high on both get tested first.
6. Owner. One named person, not a team.
7. Validation test and deadline. The specific thing that will confirm or refute it, and by when.
8. Fallback. What you will do if it is false.
9. Status and date. Open, confirmed, invalidated or retired, with the date of the last review.
10. Links. Related risk, issue, constraint or decision IDs.

You do not need to start with all ten. Claim, owner, test and status gives you a working log on day one. Add the others as the project grows.

A copyable assumptions log template

A template that works is usually smaller than people expect. One published template pack describes a guide sheet, a basic-entry sheet, an advanced-tracking sheet and a sheet for specifying ranges. For a design studio, a single table in a spreadsheet or shared document is enough to begin:

Set up three habits with it:

• Add a row the moment someone says “let’s assume” or “we’re going to treat that as.”
• Never delete a row. Change its status and keep the history.
• Give the log a standing agenda slot in the project meeting, even if it takes three minutes.

Worked examples

Examples help because the quality of the wording is where most logs fail. Here is a general project one, then two from design work.

A resourcing assumption

A commonly cited example is assuming that subject matter experts will provide 10 hours a week, validated by the resource manager’s confirmation. If that proves false, requirements workshops and the schedule may slip, as one PMP-focused guide explains. Notice what makes it work: a number, a person who can confirm it, and a stated consequence.

A design example: the structural assumption

A design example: the client-feedback assumption

This second entry shows something generic templates miss. In design work, many assumptions are interpretations of what someone meant. Logging them as assumptions, not as facts, gives you a cheap way to check before you build on them. For a fuller approach to this kind of material, see our guide to client comment tracking for design teams.

How design and architecture teams should adapt the log

Most published templates come from IT and construction management. Design teams can borrow them but need to change a few things.

Link assumptions to design recommendations

DCA Design’s account of assumption-based design recommends linking each assumption to the information that prompted it, assigning a confidence level, linking assumptions to the design recommendations that depend on them, identifying the critical ones, and defining how they will be confirmed and monitored. Put simply, a design decision should always be able to answer the question “what are we assuming for this to be right?”

Use categories that match the work

Architecture description guidance suggests capturing assumptions across technical, organizational, third-party, data and timeline categories. For a building project you might translate these into site and existing conditions, client and stakeholder, authorities and consultants, information and survey data, and program and schedule. A category column makes it easy to see where your uncertainty is concentrated.

Separate what was shown from what was inferred

A drawing, render or model communicates intent. It does not prove dimensions, performance or compliance. When a team reviews a concept image, anything it implies but does not establish (a ceiling height, a material finish, a clearance) should go into the log as an assumption instead of being treated as agreed. This single habit prevents a lot of “but the render showed it” arguments.

Record where the assumption came from

In design practice, the origin is usually a conversation: a critique, a client call, a site walk. If the log records only the claim, a junior designer picking up the file in six months sees a statement with no reasoning. If it records the source conversation, they can go back and read what was actually said. That is also the difference between an assumption log and a decision log: the decision log records what you chose, the assumption log records what the choice depends on. The two should reference each other. If you are building the decision side too, our piece on the record of decision and its eight fields covers it.

How to review and validate entries

The log earns its keep in review. The same practitioner guidance suggests reviewing it monthly, at stage gates or major commitments, and after unexpected events, and testing critical assumptions early. Here is a workable routine:

1. Sort by importance and uncertainty. Look at the high-high entries first. Low-importance, low-uncertainty items can wait.
2. Check the due dates. Any test past its deadline with no result is itself a flag. Chase the owner.
3. Update status. Mark entries confirmed, invalidated or still open, and add the date and the evidence.
4. Handle invalidated assumptions. Decide whether to revise the plan, adjust the scope or business case, or, in extreme cases, reconsider the project. Move any resulting risk or issue to the proper register and cross-reference its ID.
5. Retire confirmed ones. Move them out of the active list so the log stays short enough to read. Keep them archived for the project record.
6. Add new ones. Ask the team what they are currently taking for granted that is not in the log.

Watch for signposts

Some assumptions drift rather than fail. A signpost is an early indicator that an assumption is weakening: the client’s replies slowing from two days to a week, a consultant missing a second deadline, a supplier quote arriving with new exclusions. Writing the signpost in the entry means anyone on the team can spot it, not only the owner.

Common mistakes

• Writing vague assumptions. If it cannot be proven wrong, it is not testable. Add a number, a date or a named party.
• No owner. An entry owned by “the team” is owned by nobody.
• Filling it in once. A log written at kickoff and never opened again records the first week, not the project.
• Mixing everything without a type. If you combine assumptions, risks and issues, add a type field. Otherwise responses blur.
• Losing the source. Without the origin, nobody can tell whether an assumption was a client instruction, a guess or an inherited habit.
• Logging too much. Fifty low-impact entries bury the five that matter. Record what would change a decision if it were false.

Perspective: why we think the source matters most

We build project memory software for design teams, and the pattern we see in studios is consistent: the assumption itself is rarely the problem. The problem is that nobody can find where it came from. A sentence in a spreadsheet saying “client accepts the phased handover” is not much use when the project manager has changed and the client says they never agreed.

Our view is that an assumption log is a piece of project memory, and project memory is only as good as its traceability. Each entry should be able to answer three questions: what are we treating as true, why did we start treating it as true, and what would tell us we were wrong. The second question is where design teams lose the most, because the reasoning lives in meetings, critique sessions and client comments that nobody wrote down in structured form.

That is the reason we built The Intent Ledger around the why behind decisions, not only the what. Whatever tool you use, even a plain spreadsheet, we would encourage you to link every assumption to its conversation and to cross-reference it with the decisions that depend on it. For more on this approach, see how we think about capturing design intent with decision-record discipline.

, Rajas

Turning conversations into logged assumptions

The hardest part of keeping this log is not the template. It is noticing assumptions as they are made, in the middle of a call, and getting them into the log with their source. Our software turns meeting notes, transcripts, critique feedback and client comments into structured, source-backed records of decisions, design intent, risks, actions, commitments and unresolved questions, each traceable to the conversation it came from. That gives your assumption log a starting point instead of a blank page.

If you want to try it on a live project, the one-off packs start with Working Set at $12, and monthly plans start with Working Memory at $29 per month. You can compare all options on our pricing page, or see the product on the Intent Ledger home page.

A pack suits a single project or a student critique cycle. A subscription suits a studio that creates records every week.

FAQ

What is the difference between an assumption log and a risk register?

An assumption log holds beliefs you are treating as true without proof. A risk register holds uncertain events that could affect the project. They overlap because an assumption that might be false is a risk, which is why entries should reference each other. Keep both so you can test the assumption before it turns into a live risk.

What are the fields of an assumption log?

At minimum: the assumption, its source, an owner, the test and its deadline, and a status. A fuller log adds impact if false, importance, uncertainty, fallback, signposts and links to related risks or decisions. Start small and add fields only when the team will actually use them.

How often should we review the assumptions log?

Monthly is a sensible baseline, with extra reviews at stage gates, before major commitments and after unexpected events. Test the assumptions that are both important and uncertain first. If the log is only opened at kickoff, it is not doing its job.

Do I need a separate log for constraints?

Not necessarily. The PMBOK document combines assumptions and constraints in one log, as long as each entry is marked by type. A constraint is a fixed limit, an assumption is an unproven belief, and they need different handling, so keep a type column. Teams with many constraints often prefer a dedicated list.

Can a design student use an assumption log?

Yes, and it works well for critique cycles. Log each interpretation of reviewer feedback as an assumption, with the reviewer and date as the source, then test it at the next crit. It also gives you a clear record of why the design changed between reviews.

Sources

• PMBOK Assumptions and Constraints Log, 8th edition
• Risk Register vs Issue Log vs Assumption Log
• Risks, issues, and changes: help, I’m drowning in logs (PMI)
• Keeping an assumptions log that tests the plan (KEVOS)
• Track assumptions in a five-field register
• Assumption and Constraints Log template (IPM)
• Designing for uncertainty: assumption-based design (DCA Design)
• Decision Making and Governance (Architecture Description standard)

Recommended

• Dependencies Log: Fields, Example and Review Rhythm
• Constraints Log for Small Studios: Assign Owners, Review Weekly
• Record of Decision: 8 Fields Design Teams Must Capture
• Design Documentation Template: Capture Decisions, Not Just Tasks