Write the assumption as a testable statement
Avoid entries such as data should be fine. State what the project needs to be true, including the relevant system, records and access. A fictional pilot might assume that staff can retrieve a representative set of completed enquiries with their outcomes. That can be checked. Record why the assumption matters and what changes if it is false. A vague concern is difficult to resolve; a concrete dependency gives the team a specific question to investigate before it shapes the delivery plan.
Separate facts, estimates and decisions
A measured processing time is different from a staff estimate, and both are different from a target the business wants to achieve. Label them accordingly. Include the source and date for a fact, the basis for an estimate and the owner of a decision. Do not let a number become more certain as it is copied into slides or a proposal. If an assumption has already influenced cost or scope, make that connection visible so the team knows which parts of the plan need revision when evidence changes.
Prioritise assumptions that can change the project
Focus first on dependencies that could prevent the pilot, change its boundaries or invalidate the expected benefit. Access to a required system may matter more than a minor interface preference. Consider how difficult the assumption will be to test and how late discovery would affect the work. Avoid a long register of trivial points that hides the few important ones. The purpose is to guide investigation, not create an administrative inventory that nobody uses when making project decisions.
Assign evidence collection to a person
Name who will check the assumption, how they will do it and when the result is needed. A practical check might involve inspecting source records, testing a permitted operation or observing staff complete the current process. Define what would count as sufficient evidence before the test. A product brochure or a remembered demonstration may not establish that your own account can perform the required action. If the evidence is inaccessible, leave the assumption unresolved rather than converting the absence of a failure into a pass.
Record what changed after verification
Mark the assumption confirmed, disproved or still uncertain and retain the supporting evidence. Explain the consequence for scope, timing or the next decision. If a check only covers a subset, state that limit. For example, access to one team folder does not establish access to every source planned for the project. Keep superseded assumptions in a short history rather than silently rewriting them as if they had always been known. This helps reviewers understand why the project plan changed.
Use the register at decision points
Review unresolved assumptions before approving a pilot, expanding access or agreeing implementation scope. Decide which can remain bounded uncertainties and which must be resolved first. Do not present a provisional estimate as a fixed outcome while its major dependencies remain open. Update the register when a stakeholder, source system or process changes. The register is useful when it prompts a concrete check or changes a decision. If entries remain untouched through every review, simplify the format and reconnect each item to the action it should influence.