A fact is a claim supported by evidence you can check; an assumption is something you provisionally treat as true without sufficient verification. At work, separate both from your interpretation of what the evidence means. Then identify the smallest useful check before making a consequential decision.
“The message has no reply” and “my colleague is deliberately ignoring me” are different claims. The first may be observable in a particular channel and time period. The second assigns a motive. It could be true, but the unread message alone does not establish it.
The purpose is not to distrust everyone. It is to make uncertainty visible so people can resolve the right problem.
Facts, reports, assumptions, and interpretations
| Category | Example | What to do with it |
|---|---|---|
| Direct observation | The current output uses a particular log format | Record the source, environment, and time |
| Someone else’s report | The developer says the fix is ready | Attribute the report and clarify what “ready” means |
| Assumption | The client must be running that fixed build | Mark it as unverified and identify a check |
| Interpretation | The deployment process may have used the wrong package | Compare it against the evidence and alternatives |
| Unknown | The exact installed build has not been verified | Assign an appropriate owner to find out |
A report is not worthless because you did not observe it yourself. It simply needs the right attribution and scope. “The developer reported the fix was prepared” is more precise than silently converting that statement into “the client environment is fixed.”
A first-hand example: the logs did not match the expected build
During client-site technical work around 2014–2016, I noticed that the log format and encoding of a version sent to the site matched our internal testing version rather than the expected release. I pointed out the discrepancy. The site and development team then recognized that the wrong version had been sent.
The observation mattered because it gave the discussion something concrete to check. It was not necessary to begin by deciding who was careless, who was protecting themselves, or who deserved blame.
I am describing this retrospectively. I do not have the original logs attached here, and the table below reconstructs the reasoning rather than reproducing an incident record. Log format alone is not a universal method of identifying every software build; use your organization’s approved release-verification method.
| Step | Reconstructed reasoning |
|---|---|
| Expected state | The site should have the designated release |
| Observation | Its output matched the internal testing format |
| Assumption exposed | Sending a package meant the correct release was deployed |
| Question | Which package and configuration were actually installed? |
| Verification | The relevant teams checked and recognized the version mismatch |
This is the practical value of separating evidence from explanation: you can challenge an assumption without making an unsupported accusation.
Use a five-column verification worksheet
Copy this structure into an approved team document or ticket:
| Claim | Evidence and source | What remains uncertain | Next check and owner | Result or review date |
|---|---|---|---|---|
| The fix is live at the site | Development reports a completed change | Deployment and site validation | Release owner verifies installed build | Pending |
| The deadline was approved | A date was discussed in a meeting | Whether it was proposed or authorized | Ask the decision owner to confirm | Pending |
| A colleague withheld a requirement | One participant received the file earlier | Routing error, role difference, or deliberate withholding | Check distribution and role requirements | Pending |
These are illustrative entries, not verified events. Keep the source link in the appropriate access-controlled location. Do not copy credentials, personal information, or confidential client records into a broadly shared worksheet.
This worksheet is a practical writing aid, not a validated scoring system. A small task may need only one sentence, not a new spreadsheet.
Four checks before acting on a claim
1. What exactly is being claimed?
Replace vague words with a defined state. “Done” might mean coded, reviewed, deployed, or accepted. Ask which one the speaker means before treating it as proof of the next stage.
You can acknowledge the work already completed while clarifying the remaining stage: “Thanks for preparing the change. Has the site verified the result, or is that still pending?”
2. What is the evidence, and what does it actually establish?
Check whether the evidence belongs to the right version, environment, period, or task. A screenshot from a test environment may show that the behavior works there; it does not automatically establish the production state.
Use the single source of truth guide when different teams keep referring to different versions of the same information.
3. What alternative explanation is still plausible?
If an update did not reach you, the reason could involve distribution, access, timing, or behavior. You do not need to prove every possible alternative. Identify the ones that would materially change your response and check those first.
Avoid replacing one unsupported story with another. “They must be busy” is also an assumption if you do not know. It can be a possibility without becoming a conclusion.
4. What decision depends on the answer?
Prioritize uncertainty by consequence. If a mistaken assumption could affect safety, security, authorization, or an important commitment, use the appropriate verification and reporting route promptly. If the detail does not change the decision, further investigation may not be useful.
You can report an urgent concern before completing a root-cause analysis. Distinguish the observed risk from the suspected cause; do not wait for certainty when the designated incident procedure calls for immediate reporting.
How to communicate uncertainty without sounding evasive
Use a clear separation:
Observed: [what the evidence shows]. Reported: [what someone has stated]. Not yet verified: [the remaining gap]. Next check: [action, owner, and timing].
For example: “Development reports that the change is ready. The installed site build is not yet verified. The release owner will check it before the next acceptance test.”
This is not weaker than saying “everything is fixed.” It is more useful when that is the actual state. The project status update template provides a place for the result, risk, and next action.
If uncertainty comes from a verbal arrangement, use how to confirm verbal instructions by email to separate your understanding from a decision that still needs approval.
What if the assumption turns out to be wrong?
Update the shared record and tell the people whose decisions depend on it. Explain what changed, what remains valid, and what action is now needed. Do not leave the original confident statement circulating without correction.
For a consequential change in direction, preserve the reason in the decision log. A record should support learning, not become a tool for humiliating someone who made a reasonable provisional judgment.
Frequently asked questions
Are assumptions always bad?
No. Work often begins before every detail is known. State the assumption, identify what would invalidate it, and decide when it needs checking.
Is an opinion the same as an assumption?
No. A preference or judgment is not necessarily a claim of fact. “I prefer option A” differs from “option A has already been approved.” Label each according to what it actually means.
How can I challenge a statement without calling someone a liar?
Ask what evidence or definition supports it: “When you say deployed, which environment are we referring to?” An inaccurate statement is not automatically a deliberate lie.
Does documenting facts protect me from every dispute?
No. Records can clarify events, but they cannot guarantee fair treatment or resolve every conflict. Serious conduct concerns require the appropriate workplace or professional support route.
Sources and limits
PMI’s article on using assumptions in planning provides project-planning context. The workplace examples and worksheet here are this site’s own synthesis.
This article is about practical verification and communication. It is not a method for diagnosing character, proving deception, or substituting for technical incident procedures.