Project Assumptions vs Decisions: How to Stop Guesses Becoming Facts

A project assumption is something the team is treating as true without enough evidence yet. A decision is a choice an authorized person has made. They can look similar in meeting notes, but they need different next steps: test the assumption; follow the decision until the person changes it. An AI assistant continuing work tomorrow needs to tell them apart as clearly as a new human teammate does.

The difference in one example

Suppose a team is building a customer import. Someone writes, "The API accepts files up to 20 MB." No one checked the deployed API or its configuration. That is an assumption, even if several people repeat it. The team lead separately says, "For this release, imports must go through the existing review step." That is a decision: it names the behavior the team must implement and the person who chose it.

The decision does not prove the 20 MB claim. If a developer or assistant combines the two into "the approved 20 MB import process," a guess has been promoted into a requirement. The safe next action is to check the live limit or a current contract, then record what was found and its date.

Give each kind of statement a different home

• For an assumption, write the claim, why it matters, the evidence you currently have, who will verify it, and when. Mark it unverified until a check resolves it.
• For a decision, write the choice, the named human decider, date, reason, scope and any earlier choice it replaces. A decision can remain binding while the evidence behind it is revisited.
• For a verified fact, record the source, environment and date. "The staging API accepted this sample today" is narrower and more useful than "the API supports imports."

This does not require a new project-management module. A short note on the relevant task can hold the open assumption and the check to perform. Use a decision log for an actual choice. When handing work to another person or assistant, link the task and the decision rather than paraphrasing them from memory.

Validate before the costly step

1. Find the claim that would make the next step fail if it were wrong: an API limit, an owner, a deadline or a data source.
2. Choose a direct check, such as current documentation, a safe read-only query or a small controlled test in the right environment.
3. Write the observed result with its date and limits. A test in development is not proof about production.
4. If the result conflicts with a decision, pause that dependent work and put the conflict to the decider. Do not silently rewrite the decision.

When new evidence arrives

Replace the unsupported assumption with the narrower verified fact, and update the task that depended on it. If the choice itself must change, ask the human decider to make a new decision and link it to the old one. Keep the original record so a later teammate can see why the plan changed. A checked fact can also become stale after a deployment, policy change or data migration; mark the date and recheck it when the environment changes.

The task-writing guide covers scope and acceptance for an AI assistant. The distinction here is earlier: which inputs are facts, which are guesses, and which choices are already settled by a person. Fenbs can keep the task and its context together; the team remains responsible for checking claims and making decisions.