Extract Hidden Assumptions from a Business Proposal with ChatGPT

A proposal can be persuasive while depending on conditions it never states clearly. It may assume that a team has capacity, that a source is accessible, or that users will adopt a new process without additional support. Those conditions affect the proposal even when they are absent from its headline recommendation.

An assumption register identifies these dependencies and connects them to evidence, validation questions, and review decisions. This guide offers an original method using ChatGPT, with fictional examples and current documentation checked on October 6, 2026. It does not establish whether a business proposal is commercially sound or replace the owner's evaluation of its facts.

Set the boundary of the review

Identify the proposal version, requested decision, intended outcome, and review scope. An assumption review asks what must be true for the proposal's claims or plan to hold. It does not begin by deciding that the proposal is wrong or by rewriting it into a different initiative.

Give relevant passages stable IDs. Include approved supporting sources separately and describe their relationship to the proposal. A background document may support one constraint without validating the proposal's entire recommendation.

Preserve stated assumptions and qualifications. If the writer already says that staffing is subject to confirmation, the review should retain that acknowledgment. An explicit unresolved assumption is different from an unmentioned dependency, though both may need validation.

Distinguish facts, assumptions, and uncertainties

A fact in the register is a statement supported by reviewed evidence within the stated scope. An assumption is a condition the proposal relies on without sufficient confirmation. An uncertainty is a question whose answer remains open; not every uncertainty is essential to the proposal's success.

For example, a documented team allocation may support a capacity statement. A sentence saying “the existing team can absorb the work” without that evidence is a candidate assumption. The review should explain why capacity affects the plan, rather than merely label the sentence uncertain.

The current OpenAI prompting reference discusses specifying context and boundaries. In this original workflow, the key boundary is that an inferred dependency remains a candidate for review, not a confirmed fact about the organization.

Inspect claims and transitions

Ask which conditions connect each proposed action to its expected outcome. A plan to publish new documentation may assume the target audience can find it, understands it, and has permission to perform the described steps. These are different conditions that could require different evidence.

Pay attention to transitions such as “therefore,” “with existing resources,” and “once launched.” They can compress several dependencies into a short phrase. Inspect the supporting passages rather than assuming that a confident transition establishes the relationship.

Also examine omitted prerequisites. A workflow using an external data source may depend on access that the proposal never discusses. Record the source passage describing the workflow and label the access dependency as inferred, with a question for the owner.

Build the assumption register

Use fields that make the candidate assumption reviewable and actionable. Avoid a long list of vague risks with no connection to the proposal. Each row should explain the dependent claim and what evidence would address the uncertainty.

Record impact in concrete terms. “Could delay the pilot until access is available” is more useful than an unsupported “high risk” label. If the owner uses a rating scale, document its definitions before applying it.

Ask ChatGPT for candidates and a coverage check

Supply the proposal, source packet, register schema, and review boundary. Request candidates with evidence references first. The model should not claim to have established hidden intentions or organizational facts merely by reading the proposal.

Extract candidate assumptions from the supplied proposal.
Separate explicit assumptions from inferred dependencies.
For each candidate cite the passage, dependent outcome, and current evidence.
Explain what would change if the condition were false.
Propose a neutral validation question and leave unknown owners unassigned.
Do not invent supporting data, motives, probability estimates, or completed checks.
Return the assumption register and claims that could not be assessed from the packet.

Check whether every candidate is material to the proposal. “The organization will still exist next week” is theoretically an assumption but usually adds little to this review. Focus on conditions that meaningfully affect the stated decision and can be clarified or monitored.

Review a fictional dependency

Suppose a fictional proposal recommends a customer tutorial series and states that existing support notes can supply the examples. The register might identify a dependency on those notes being suitable for publication. The proposal establishes the intended source, but not that the notes have been reviewed for accuracy and permitted use.

The validation question can ask which notes are approved and who checks them. The dependent outcome is the ability to draft the tutorials from that material. If the notes are unavailable or unsuitable, the team may need another approved source before writing begins.

Keep the inference bounded. Do not state that the notes contain sensitive information unless the packet establishes it. “Publication suitability has not been confirmed” accurately describes the gap without inventing a problem.

Plan validation without pretending it happened

For each material assumption, identify the evidence needed and the responsible review role. This could be an approved allocation, a source owner confirmation, or a documented pilot result. Record the proposed check separately from its result.

Define what would count as support or disconfirmation. A general assurance that “it should be fine” may not resolve a specific capacity dependency. Ask for the scope and conditions of the confirmation rather than accepting confidence as evidence.

Do not let ChatGPT assign probabilities without a supported basis. If the team wants estimates, record who supplied them and how they will be used. A numerical confidence score generated from prose can create an appearance of measurement that the packet does not justify.

Update the proposal and decision record

After review, mark each assumption supported, contradicted, still unresolved, or no longer relevant. Preserve the evidence and decision reason. A condition may become irrelevant because the owner changes the proposal, but that change should be visible.

For assumptions that remain open, decide whether the proposal should be qualified, deferred, reduced in scope, or monitored under an approved condition. The decision belongs to the owner. ChatGPT can organize these alternatives without selecting an organizational commitment on its own.

The decision memo workflow can use the reviewed register as supporting material. Keep assumptions separate from verified facts in the memo, and retain the register for later outcome review. This turns hidden dependencies into explicit decisions rather than polished but unsupported claims.

Frequently asked questions