How do I distinguish a proposal's assumptions from facts and commitments?
Quick answer
Label decision-relevant statements by status: Observed for information you have seen or recorded, Assumed for an unconfirmed premise, Proposed for an option or recommendation, and Agreed only for something explicitly accepted. Keep a brief register of assumptions that could change the recommendation, including how to check each one and what you would revisit if it is wrong. Update labels when the status changes.
The question, the details, the next step.
I’m writing a proposal and worry readers will treat guesses as facts—or suggestions as promises. How can I make the difference obvious?
Use a small set of labels consistently, placing each label beside the statement it describes:
- Observed: information you have seen or recorded.
- Assumed: an unconfirmed premise you are using for planning.
- Proposed: an option or recommendation you want readers to consider.
- Agreed: something the relevant people have explicitly accepted.
Label claims when their status could affect a reader’s decision. A polished sentence is not evidence that something has been confirmed or accepted.
Could you show me the difference using a simple example? I’m proposing a small staff workshop, but I don’t know everyone’s availability.
Here’s an illustrative example with placeholders, not details about your project:
Observed: The request asks for a staff workshop about [topic].
Assumed — confirm: A 60-minute session will be enough. If it is not, the scope or session length may need to change.
Proposed: Hold the workshop during [date range], using [format].
Agreed: No date or format recorded as agreed yet.
That last line helps prevent a suggested time from sounding like a booking. If someone accepts a date, update the status and record the specific item accepted in the project’s normal documentation.
How do I track assumptions that could change the recommendation without listing every minor unknown?
Include an assumption if it could materially change the recommendation, scope, timing, or resources. Make each entry specific enough to check, and note what you would revisit if it proves wrong. For example:
A1 — Assumed: Most invitees can attend one of the proposed time slots. Why it matters: The schedule depends on sufficient availability. Check: Ask [group or role] by [date]. If wrong: Revisit the date or consider another format.
A2 — Assumed: The planned materials will be available. Why it matters: The activity plan uses those materials. Check: Confirm with [role] by [date]. If wrong: Adjust the activity or resource request.
Use placeholders until details are confirmed. If a table suits your document, these same fields can be its columns.
What about figures or statements from someone else? Should I mark those as observed, and how do I handle agreement?
Use Observed for information you have actually seen or recorded, and make its basis clear: “Observed: The request document specifies [duration].” If you only heard an estimate, identify it as reported rather than confirmed: “Reported by [role]: [estimate]; not independently confirmed.”
Reserve Agreed for explicit acceptance—not silence, a draft suggestion, or a hoped-for response. Be precise about its scope: “Agreed: [person or group] accepted [specific item]. Still proposed: [remaining item].” Acceptance of one part does not make related options agreed.
Can you give me a quick review routine before I share the proposal?
Read it from the reader’s point of view. Check that every decision-relevant claim has a clear status, and look for wording such as “will,” “has approved,” or “is available.” Those phrases may be accurate, but make sure the statement supports them. Confirm that each Agreed item says exactly what was accepted, and keep the assumptions register close to the recommendation it may affect.
A closing note might say: “This proposal relies on the assumptions listed above. If any remain unconfirmed by [decision point], we will revisit [affected recommendation].” Use that only if it reflects the process the people involved intend to follow.
A practical checklist
Define a consistent set of labels: Observed, Assumed, Proposed, and Agreed.
Put labels beside claims whose status could affect a decision.
Identify the basis of reported information and distinguish it from confirmed information.
Track consequential assumptions, how to check them, and what may change if they are wrong.
Use Agreed only for explicit acceptance, and state its precise scope.
Check that commitment wording matches what has actually been accepted.
A few more useful answers
Do I need to label every sentence in a proposal?
No. Label claims whose status could affect how readers interpret the recommendation, schedule, scope, or commitment. Connective prose usually does not need a label.
What if I cannot check an assumption before the proposal is reviewed?
Keep it labeled as an assumption and state which part of the recommendation depends on it. You can identify a decision point for revisiting that recommendation without implying the assumption is confirmed.
Can a proposal contain both agreed and proposed items?
Yes. Mark each item separately and make the boundary clear. Agreement to one item does not make related options or next steps agreed.