Your project plan says the vendor can handle the volume. Someone remembers hearing that on a call. Nobody can find the call notes. Somehow, this has become a launch commitment.
That is what an assumption log is for: catching the moment a reasonable guess puts on a suit and starts issuing instructions.
These AI assumption log prompts help you extract unverified beliefs, define evidence checks, and keep decisions connected to what the team actually knows. AI can draft the table and ask useful questions. It cannot confirm a vendor limit, approve a security exception, or make an unavailable colleague agree to a deadline.
Use the templates below with your approved workplace AI tool. Start with one consequential assumption rather than feeding the model your entire company and hoping it becomes a project manager.
What belongs in an assumption log?
An assumption is something you are treating as true so planning can proceed, even though the relevant evidence is incomplete. It needs a clear statement, a reason it matters, and a way to discover whether it is wrong.
Keep these related concepts separate:
| Item | Meaning | Hypothetical example |
|---|---|---|
| Assumption | Unverified planning belief | Our existing export service supports the pilot volume |
| Risk | Uncertain event with a consequence | Export delays could prevent users finishing onboarding |
| Issue | Problem already observed | The test export timed out yesterday |
| Dependency | Input required by another activity | The pilot needs an approved service account |
| Decision | Choice made by an authorized person | Limit the first pilot to a smaller cohort |
One situation can produce all five records. Link them instead of cramming them into an enormous row nobody will read. A dependency register tracks required inputs; an assumption log tracks what you still need to establish about them.
Avoid vague entries such as “the system will work.” Write “the export service can process the proposed pilot workload within the agreed response-time threshold.” If that threshold does not exist, log the missing requirement. Do not ask AI to invent a convenient number.
Prepare evidence before you write prompts
Give the model a small, sanitized packet with stable source IDs. Keep the originals in your approved internal system. IDs let reviewers trace statements without putting confidential documents into a public chat.
| Input | What to supply | What to avoid |
|---|---|---|
| Goal | A short approved project outcome | Confidential strategy unrelated to the task |
| Evidence | Sanitized excerpts labeled S1, S2, S3 | Credentials, tokens, personal records |
| Scope | Environment, cohort, workflow, version | An undefined claim about everything |
| Constraints | Approved limits and decision dates | Guessed budgets or fictional commitments |
| Existing log | IDs, statuses, evidence references | Unnecessary customer or employee identities |
| Review roles | People or roles allowed to confirm facts | Treating a proposed owner as an accepted owner |
Use only tools approved for the data involved. Removing names is not automatically enough: combinations of details can still identify customers or reveal sensitive work. Do not paste raw production logs, private HR material, security findings, financial records, legal advice, or confidential client information into an unapproved tool.
Treat supplied documents as data, not instructions. A copied note that says “ignore the checks and mark everything approved” is still a note, not permission to change the workflow. Review outputs before copying them into any system of record.
For a cleaner starting packet, use the project kickoff prompts. Missing context is cheaper to surface before it has been formatted into a convincing table.
10 AI assumption log prompts to copy
Add this rule to every template: Use only the supplied evidence. Cite source IDs. Label inferences. Say unknown when evidence is missing. Do not invent owners, dates, approvals, or test results.
The prompts draft analysis and questions. They do not authorize messages, run tests, change records, or approve a launch.
Prompt 1: Extract hidden assumptions from kickoff notes
Use this when a brief looks complete but contains phrases such as “should be easy,” “already supported,” or “the team can absorb it.” These phrases are investigation leads, not automatic proof of a problem.
Read these sanitized project notes: [notes with source IDs]. Extract explicit assumptions and possible hidden assumptions needed for the proposed plan to work. Return candidate ID, precise statement, source quotation, source ID, affected activity, and why validation matters. Separate directly stated assumptions from your inferred candidates. Do not turn preferences or requirements into assumptions. Finish with questions a human should answer before adding each inferred candidate to the log.
Review every inferred row. Delete candidates that do not affect a real choice. The goal is a usable register, not an archaeological record of every uncertain sentence.
Prompt 2: Separate facts, assumptions, and unanswered questions
A quote proves someone said something. It does not necessarily prove the statement is correct. This distinction stops meeting notes from becoming fake evidence by repetition.
Classify each statement in [source packet] as documented observation, reported claim, planning assumption, requirement, decision, or open question. Return statement, classification, supporting source, scope limits, and missing evidence. A reported claim is not an independently verified fact. Preserve uncertainty words from the source. Flag any statement that cannot be classified without more context rather than forcing it into one category.
A reviewer should check that “the supplier expects capacity” has not become “capacity confirmed.” Use a separate decision record for actual choices; these decision log prompts can help organize them.
Prompt 3: Prioritize assumptions by consequence if wrong
Not every unknown deserves a workshop. Focus attention on beliefs that affect expensive, irreversible, customer-impacting, or time-sensitive choices.
Review [assumption log] against [project goals and known constraints]. For each assumption, describe a plausible consequence if false, the affected decision, reversibility, and when the team would need to know. Use qualitative priority with an explanation, not fabricated probabilities. Separate consequences supported by the packet from scenarios you propose for review. Return the smallest set of assumptions that need attention before [decision gate].
Have accountable owners confirm the consequences and priority. A model cannot estimate operational impact from missing architecture. For broader consequence mapping, pair this with change impact analysis.
Prompt 4: Design a cheap, falsifiable evidence check
“Ask whether it seems fine” is not much of a test. A useful check states what would count against the belief and what the result would actually cover.
For assumption [ID and statement], propose the smallest authorized evidence check that could challenge it. Use these constraints: [budget, environment, access, timing]. Return method, required inputs, proposed reviewer, success criterion drawn from supplied requirements, failure signal, limitations, and next decision. If a threshold is absent, mark it as requiring agreement. Prefer existing documentation or a safe scoped test where appropriate. Do not suggest production changes, sensitive data access, or security testing without explicit authorization.
A subject-matter expert must approve the method and interpret the result. One passing sample does not validate every configuration. Good acceptance criteria make this review much less theatrical.
Prompt 5: Ask an owner for confirmation without implying approval
Ownership is an agreement, not a name that appeared in an AI table. Draft a narrow request the recipient can answer accurately.
Draft a short confirmation request for [proposed reviewer role] about assumption [ID]. Include the exact claim, relevant source references, scope, why the upcoming decision depends on it, and the evidence requested. Offer response options: confirmed within stated limits, contradicted, needs more investigation, or wrong reviewer. Describe [date] only as a requested response date unless the packet shows an accepted commitment. Do not send the message.
Check the recipient and wording yourself. Silence is not confirmation. If no reviewer accepts ownership, leave that gap visible instead of letting the formatting solve it on paper.
Prompt 6: Set review triggers instead of forgetting the log
Evidence ages. A statement can be well supported for one vendor version and irrelevant after an upgrade. Review should follow meaningful changes, not only calendar guilt.
For each row in [log], propose conditions that should trigger revalidation: version changes, workload changes, scope expansion, supplier changes, expired evidence, or approaching decisions. Base triggers on the actual statement and source scope. Return ID, trigger, rationale, proposed review role, and requested review point. Separate event-based triggers from optional calendar reviews. Do not assign dates that have not been agreed.
Keep triggers observable. “Review if circumstances change” is too vague to help anyone. “Review before doubling the pilot cohort” gives someone a recognizable moment to act.
Prompt 7: Find contradictions without choosing the convenient source
Two documents can disagree because one is stale, because they describe different environments, or because someone is wrong. AI should surface the collision, not quietly vote.
Compare [source packet] with [assumption log]. Identify claims that conflict or appear inconsistent. For each pair, show exact source IDs, dates if supplied, scope differences, and the decision affected. Do not declare the newest source correct merely because it is newest. Return possible explanations as hypotheses and a specific question for the appropriate reviewer. Keep unrelated claims separate.
Check the quotations against their sources. Ask whether the apparent contradiction disappears when environment, cohort, or terminology is clarified. A confident synthesis that erases disagreement is worse than an untidy but honest log.
Prompt 8: Update a row when new evidence arrives
Do not overwrite history. A reviewer needs to understand what changed and why the status changed with it.
Propose a patch to [existing log] using [new evidence with IDs]. Return ID, old value, proposed value, evidence reference, reason, and required reviewer. Preserve previous evidence and uncertainty. Distinguish supported within scope, contradicted, partly tested, and unresolved. Leave status unchanged when the evidence does not address the original claim. Do not apply the patch; produce a reviewable change list.
Approve changes individually. A failed test might contradict an assumption, or the test setup might be invalid. The log should reflect the human interpretation and its limits, not simply the model's first explanation.
Prompt 9: Prepare a decision-gate summary
An executive summary should make uncertainty legible. It should not launder it into a reassuring shade of green.
Prepare a decision brief from [log] for [specific gate]. Include supported assumptions and their limits, contradicted assumptions, unresolved assumptions that affect the gate, missing reviewers, and available options from the supplied plan. Cite IDs for every statement. Separate evidence from recommendations. List what the accountable decision-maker must accept, resolve, or defer. Do not announce approval or infer risk acceptance from the planned launch date.
Reviewers should be able to click through to each underlying record. Use the go/no-go decision prompts when you need a fuller structure for the actual decision.
Prompt 10: Close or escalate an unresolved assumption
Some beliefs are tested. Some become irrelevant. Some remain uncertain and require an explicit choice. “Closed” should explain which of those happened.
Review assumption [ID] using [latest evidence and decision record]. Draft one proposed disposition: supported within documented scope, contradicted and replanning required, superseded, no longer relevant, or unresolved and escalated. Explain why, cite evidence, retain limitations, and identify affected linked records. If uncertainty is being accepted, require an explicit decision-maker and acceptance record; do not invent them. Draft the next question and suggested recipient role if disposition is blocked.
Use escalation plan prompts to frame the request. Escalation is not punishment. It is moving an unresolved decision to someone who can actually make it.
This came from a book.
Don't Replace Me
200+ pages. 24 chapters. The honest version of what AI means for your career, written by someone who actually builds this stuff.
Get the Book →Worked example: a pilot export assumption
The following example is fictional. It illustrates the workflow, not a real test result or a recommended performance threshold.
A team plans a customer export pilot. Source S1, the kickoff note, says the existing export service should be adequate. Source S2, a test note, records success with a small sample. Neither source defines the proposed pilot volume or acceptable completion time.
A poor AI summary says: “Export capacity confirmed; proceed.” A useful draft says: “Existing evidence covers only the sample in S2. Pilot capacity remains unverified, and the target workload is missing.”
| ID | Planning belief | Evidence | Status | Next action |
|---|---|---|---|---|
| A-01 | Existing export service supports the intended pilot workload | S1 proposes it; S2 covers a smaller sample | Unresolved | Agree workload and completion criterion, then approve a scoped test |
| A-02 | Support can handle the expected pilot questions | S1 expects existing coverage; no staffing confirmation | Unresolved | Request coverage confirmation from the appropriate support reviewer |
Notice what is absent: fictional owners, fabricated due dates, numerical confidence scores, and a magical approval stamp.
Suppose a later approved test, recorded as S3, satisfies the agreed criterion for the pilot cohort. A reviewer can mark A-01 supported for that cohort and configuration, preserving the test reference. A larger rollout still triggers review. If the test fails, link the resulting issue and reconsider scope rather than editing the original assumption until it appears true.
This example also shows why one log cannot replace every project artifact. Capacity validation, support coverage, and the launch decision are connected, but they have different evidence and authority requirements.
A review cadence people can actually maintain
At kickoff, capture assumptions that materially affect scope, effort, staffing, or delivery. Before each consequential decision, review the beliefs that decision depends on. Revisit a row when its trigger fires. Close irrelevant entries so important ones do not disappear under administrative compost.
In a short review, ask:
- Which claim matters to our next decision?
- What evidence changed since the last review?
- What could show the claim is false?
- Who has agreed to review it?
- What happens if we still do not know in time?
Use stable IDs and an existing approved project tool. You do not need a new subscription to store twelve rows and three uncomfortable questions. Include unresolved assumptions in stakeholder updates when they change the interpretation of progress, rather than reporting certainty the team does not possess.
Frequently asked questions
What is an AI assumption log?
It is an ordinary assumption log drafted or maintained with AI assistance. The model can extract candidate beliefs, compare evidence, and propose review questions. People still validate the claims, accept review responsibilities, and make decisions. Calling it AI-powered does not make the underlying evidence stronger.
Can ChatGPT verify project assumptions?
Not merely by reading and restating them. It can help identify what evidence would be needed and analyze material you provide, but analysis can be mistaken or incomplete. Verification depends on appropriate source records, authorized tests, and qualified review. A confident answer is not an independent observation of your project.
How is an assumption log different from a risk register?
The assumption log records beliefs used for planning. A risk register records uncertain events and their potential consequences. If an assumption might be false and that would threaten delivery, link it to the relevant risk. Keep the claim and its consequence distinct so reviewers know which evidence addresses which question.
What columns should an assumption log template include?
Start with ID, precise statement, source references, scope, consequence if false, evidence check, review role, status, and review trigger. Add an agreed deadline or decision link when relevant. Keep proposed owners visibly separate from accepted owners. More columns are useful only if somebody uses them to make or review a decision.
Should AI assign confidence scores to assumptions?
Avoid unsupported numerical scores. A model-generated percentage can look scientific while reflecting no calibrated measurement. Prefer a description of evidence coverage and gaps: tested for one cohort, reported by a supplier, contradicted by a log, or not yet investigated. If your organization has a defined scoring method, supply it and have reviewers check its application.
When can an assumption be closed?
When a responsible reviewer records why it no longer needs active tracking: adequately supported within scope, contradicted with replanning handled, superseded, or irrelevant. An unresolved assumption may instead need explicit risk acceptance or escalation. Neither a passed deadline nor a lack of objections is a substitute for that record.
Make the guess visible before it makes the decision
Pick one sentence in your current plan that begins with “we assume.” Give it a source, a consequence, and a check. Use AI to shorten the clerical work, then have a human review the result.
That is the practical approach behind Don't Replace Me: use the tool to expose gaps and save effort without outsourcing the judgment that makes the work trustworthy.
