1. Decide whether this task needs Deep Research
Use it when answering well requires several sources, comparisons, or a documented synthesis. Examples include comparing vendors against the same requirements, tracing a policy change across versions, or explaining a historical question with primary documents. A single fact, a quick current update, or a short back-and-forth usually takes less time with standard ChatGPT or ChatGPT Search. Deep Research uses a limited number of tasks on some plans; your ChatGPT usage counter shows what is available to you.
Before opening the tool, write one sentence that says what you will do with the answer. Then list the questions the report must settle. If you cannot name the decision or the deliverable, the resulting report may be long without being useful. For a vendor choice, the deliverable might be a comparison table plus unresolved questions for a trial. For a research brief, it might be a dated timeline, the sources behind each event, and a short explanation of where the sources disagree.
2. Open Deep Research and set the sources
In ChatGPT, select Deep research from the + tools menu, choose it in the sidebar, or type /Deepresearch in the prompt. These are the entry points in OpenAI's current help guide. If you do not see the tool, check the plan, country or territory, and, for a managed workspace, your role and admin settings. Availability and task allowances vary; use the controls and counter shown in your account instead of an old screenshot or a quoted quota.
Decide which material the report may use before you submit. Deep Research can search the public web and work with uploaded files. It can use a connected app only if that app supports Deep Research and is available under your account, workspace, role, and provider permissions. Its app research actions are read-only. A connected app being visible elsewhere in ChatGPT does not guarantee that it is a Deep Research source.
| Source choice | Use it when | Set it up and check it |
|---|---|---|
| Open web | You need to discover and compare material across publishers. | Leave broad web access available. Name preferred primary sources and the types of outside evidence you will accept in the prompt. Review the final source list for relevance and dates. |
| Specified sites | You need evidence from named domains, such as official documentation. | In Sites > Manage sites, enter domains. Choose the option that restricts research to entered sites, or the option that prioritizes them while allowing full-web search, according to the task. Recheck the report's actual links. |
| Uploaded files | The answer depends on a contract, policy, paper, or other document you supply. | Attach the correct versions. Name their titles and dates in the prompt. Check that the report cites the passages used for its conclusions. |
| Eligible connected apps | Relevant documents or data live in a supported service your account can read. | Confirm the app is offered as a research source and that your account can access the specific material. Verify the required records appear in the report. |
The two site settings answer different questions. The restricting option limits web research to the domains you entered. The prioritizing option lets Deep Research search beyond them. A sentence in your prompt saying “use only NASA” is an instruction to the model; it is not proof that you selected the site restriction. If a source is missing or a connected app is unavailable, record that limit and adjust the request. Attach workplace material only when you have permission to use it.
Use restrict when the report must stay inside a defined evidence set, such as a regulator's site or your organization's approved documentation. Use prioritize when official pages should lead the research but independent reporting may reveal limitations they do not mention. After either choice, inspect Sources used in the finished report: the setting controls where research is directed, while the final links show what the answer actually relies on. If you mix uploaded requirements with public product pages, tell the tool which claims belong to each source type. A public feature page can establish what a vendor advertises; your internal document establishes what your team needs.
For an app source, first check whether the app appears in Deep Research. If it requires your own connection, connect the provider account that can read the required documents and review its requested permissions. A connected personal account cannot read files held only in a work account. If the app finds a document title but cannot use its contents, treat the document as unavailable; OpenAI's app troubleshooting guide distinguishes finding a file from reading it. You may need a supported file format or a permitted upload.
3. Write a request that defines the finished report
Give Deep Research five things: the question, why you need the answer, the scope, the evidence rules, and the format. The scope may include a country, date range, document version, product tier, or population. The evidence rules tell it which sources are required and how to handle gaps. The format makes omissions visible. “Research the topic thoroughly” provides none of those checks.
I need to decide [decision] for [audience] by [date].
Research [specific question] for [region, period, or versions].
Use [required sources]; use [other sources] only for [purpose].
Deliver [table, timeline, brief, or recommendation] with:
- the same comparison criteria for every option;
- links or document citations beside important factual claims;
- dates and definitions where they affect the answer;
- disagreements, missing evidence, and assumptions in a separate section.
If a required source is unavailable, say what is missing.
Do not fill the gap with an unsupported estimate.Replace every bracket with task-specific content. For a three-vendor comparison, name the three vendors and the exact criteria: supported regions, integration requirements, published support terms, and trial questions. For a literature review, state the study period, population, and what counts as evidence. Asking for “pros and cons” alone invites an uneven summary; a row for each option under the same columns makes the answer easier to use.
OpenAI says ChatGPT may ask clarifying questions before research starts. Answer the question that changes the report: which region, which versions, which audience, or whether outside sources are allowed. If you do not know, tell it to show both plausible interpretations and label them. Avoid pretending a vague prompt is fixed by asking for more pages.
For example, “compare three password managers” still leaves the answer to guess the deployment size, region, required identity provider, and whether a published price or a sales quote counts. A usable request would specify “50 US employees, SSO with our identity provider, published Business-tier features as of the research date, and a table of unanswered sales questions.” Those details give you a way to reject an attractive but irrelevant report.
4. Edit the proposed research plan
Deep Research proposes a plan before it begins. Read the steps against your requested output. For a comparison, check that it will examine each option under the same criteria. For a date-sensitive task, check that it will look for current versions and effective dates. For an internal-document task, check that it plans to use both documents rather than infer changes from one. Revise a missing step or source before starting the run.
Useful plan corrections are concrete: “Add the 2025 policy as a source and compare it clause by clause with the 2026 version,” or “Separate published support commitments from customer reviews.” “Be more thorough” does not tell the tool what to change. The OpenAI Academy guide also recommends shaping the plan and checking live progress as the research proceeds.
Use the five checks in the diagram below to decide whether the proposed plan can answer your question. It is an editorial checklist rather than a capture of the ChatGPT interface; the exact button names and placement may differ by account.
| If the proposed plan says... | Change it to... | Why it matters |
|---|---|---|
| “Summarize each vendor.” | “Compare all three against the same five requirements; give a source for each filled cell.” | Separate summaries hide missing criteria. |
| “Review the current policy.” | “Compare the approved 2025 and 2026 versions by section number and effective date.” | One version cannot prove what changed. |
| “Find the latest figures.” | “Use the named agency's release for each year and identify whether figures are preliminary or revised.” | Two differently defined figures can look comparable when they are not. |
Before starting, confirm the plan includes the sources you supplied, the comparison or extraction method you need, and an explicit place for missing evidence. If the task counter matters, check it before submitting. OpenAI says allowances vary by plan; on plans with a fixed monthly allowance, the counter resets 30 days after the first use, rather than necessarily on the first day of a calendar month.
5. Watch the run and change direction when needed
Once the research begins, follow the visible progress. OpenAI says you can interrupt to refine the focus or change accessible sources. Do that when the plan or progress reveals a specific problem: it is comparing different years, overlooking a required document, or spending effort on background you do not need. State the correction and the desired output, such as “Keep the comparison to the US editions effective in 2026; add each provider's official support policy; remove general company histories.”
If a source cannot be reached, ask for the exact gap in the report. An inaccessible file does not establish that a clause was removed, and a failed search does not establish that a policy does not exist. If the task changes substantially, revise the plan rather than patching the final answer with a casual follow-up. Progress indicators describe what the tool is doing; they do not prove that the sources support its claims.
Make one correction at a time and say what should change in the deliverable. “Stop using 2024 pricing pages. Keep the same three vendors and criteria, but use current US Business-tier pages and mark unpublished prices as ‘request a quote’” is actionable. “Those sources look wrong” leaves the tool to guess. If a required file or site remains inaccessible after you correct the source, stop treating the draft as complete; request a gap list and decide whether to provide the material, narrow the question, or finish that part manually.
6. Read the completed report as a research output
The finished report opens with a table of contents, a Sources used section, and an activity history, according to OpenAI's help guide. Start with the executive answer and the section that directly addresses your question. Then inspect the source list and open the citations behind the two or three claims that would change your decision. Check the source's date, relevant passage, and whether the report has carried a claim across the wrong region, product tier, or document version.
A useful review has three passes. First, check completeness: are all requested options, criteria, and exceptions present? Second, check support: do the linked passages actually say what the report claims? Third, check synthesis: if sources conflict, does the report explain the difference or merely choose one? Citations are a way to inspect an answer, not a guarantee that every sentence is correct. For important decisions or external publishing, continue with a claim-by-claim fact check.
Ask a follow-up that acts on a discovered gap. For example: “The report compares Vendor A's US support terms with Vendor B's global terms. Rebuild that table using US terms for both, and mark any term you cannot verify.” You can also request a shorter brief for a different audience or a deeper section on one uncertainty. Keep the original report and sources available so you can see what the revision changed.
Use the report's activity history to see whether the run changed course or encountered source gaps. Then examine Sources used against the domains, documents, and dates you asked for. Open the citations from the answer itself: a source list can be relevant overall while a particular sentence still cites the wrong passage. When you ask for a revised table or shorter version, recheck its new claims; compression can remove a qualifier that made the original answer accurate.
A documented report example: the Voyager question
We ran one documented Deep Research task in an authenticated English-language ChatGPT Pro session on August 19, 2026. The prompt below asked for a bounded brief rather than a generic history. It is the only product run we claim in this article; the later scenarios are instructions you can adapt, not reports we generated.
Create a source-bounded brief explaining why Voyager 2
launched before Voyager 1 despite its name.
Use only pages on nasa.gov, including NASA Science and JPL
subdomains. Do not use another domain.
Deliverables:
- a concise explanation;
- a two-row timeline with launch date and planetary flybys;
- exact links for each factual row;
- explicit separation of sourced facts and your inference;
- an insufficiency note when the allowed evidence cannot support a claim.
Research cutoff: August 19, 2026.The completed report supplied the timeline, explanation, inference section, and insufficiency note. The interface displayed two minutes, seven citations, 92 searches, and seven sources. The report body exposed six unique direct NASA URLs. We could inspect those six links, but the visible record did not explain why the source counter said seven. We did not find Sites > Manage sites before submission in that session, so “NASA only” was a prompt instruction, not a demonstrated site restriction. These counters describe one run; they are not a speed or accuracy benchmark.
The decisive links were the Voyager 2 mission page, the Voyager 1 mission page, and NASA's launch-order explanation. The mission pages give the launch dates, August 20 and September 5, 1977. NASA explains that the later-launched Voyager 1 followed a faster path to Jupiter and Saturn. Those pages do not establish a universal rule that spacecraft numbers always follow arrival order. That distinction belongs in the final brief.
We also found a date-label trap on NASA's Voyager 2 page: its Key Dates lists August 25, 1981 for the Saturn flyby, while the detailed text gives 01:21 UT on August 26 for closest encounter. A report using “flyby key date” and one using “closest encounter” can show different dates without either source being fabricated. Decide which event your timeline records and label it. The source-audit CSV includes two filled Voyager claim rows to show how to record a checked passage and an unresolved distinction.
Here is what a useful claim check looks like in this example. These are editorial checks against the linked NASA pages, not additional product actions observed in the August run.
| Report claim to check | Where to check | Decision for the brief |
|---|---|---|
| Voyager 2 launched before Voyager 1. | The two NASA mission pages give August 20 and September 5, 1977. | Keep the claim and show both dates. |
| Voyager 1 reached the first planetary targets sooner. | NASA's launch-order article explains its faster path to Jupiter and Saturn. | Use this narrower explanation; do not invent a general naming rule. |
| Voyager 2's Saturn encounter happened on one unqualified date. | The Voyager 2 page uses different dates for its key-date label and closest encounter time. | Define the event and time convention, or preserve both labels. |
Adapt the workflow to other research tasks
The following are task designs based on the documented controls. We have not run them in ChatGPT. Each requires its own source check before you use the result.
Compare products using both official and independent evidence
Suppose you must shortlist three tools for a team. Set the official product documentation and pricing pages as preferred sites, and allow broader web search if independent incident reports or user experience matter. Ask for one row per tool covering the same version, region, integration requirement, support term, and price basis. Put independent observations in a separate column. On review, reject a price from a different region, a feature promised in a beta announcement but absent from current documentation, or a review presented as an official commitment. If the decision is expensive, use the report to write trial tests and vendor questions rather than treating a score as the final decision.
Compare [A], [B], and [C] for our [team/use case] in [region].
Use current official docs and pricing for stated capabilities and terms.
Use independent sources only for reported experience and incidents.
Give one table with the same criteria for all three, exact links,
publication or effective dates, missing terms, and five trial tests.Compare two versions of a document
Upload both approved versions, or use an eligible connected app if the files are available there. Ask for changed sections with old and new identifiers, a short description, and citations to both versions. State the effective dates and whether outside web context is permitted. Check a sample of “added,” “removed,” and “changed” rows against both originals. If one version is inaccessible, the tool should report that limitation; it cannot establish a deletion from a missing file.
Compare the attached [2025 policy] and [2026 policy].
List every changed section with the old and new identifiers,
effective dates, a short change summary, and a citation to each file.
Separate confirmed changes from clauses missing in one version.
Do not infer a deletion if a file or section could not be read.Research a narrow question from named public sites
For an evidence brief like Voyager, enter the allowed domains under Sites > Manage sites and choose the restricting option if your account offers it. Name the same domains in the prompt, ask for links beside factual rows, and require an explicit gap when the sites do not answer a question. After the report, open each decision-relevant link and check the final hostname after redirects. If the control is absent, label the source boundary as a prompt instruction in your handoff; do not call the run technically restricted.
Combine internal requirements with public evidence
Suppose your team has an approved requirements sheet and wants to assess two vendors. Upload that sheet or select an eligible app that can read it, then use the vendors' current documentation as web sources. Ask the report to map each requirement to each vendor's documented capability, with one citation to the internal requirement and one to the public claim. Keep “vendor says it supports this” separate from “our team has tested it.” A blank cell means the evidence was missing, not that the feature is absent. If internal requirements should not appear in a shared copy, prepare a redacted handoff after review.
Use the attached approved requirements sheet as our criteria.
Compare [Vendor A] and [Vendor B] using their current official docs.
For each requirement, cite its row in the sheet and the vendor page.
Mark each result documented, unclear, or not found; do not infer
that "not found" means unsupported. Add questions for a live trial.
Keep internal requirements separate from public vendor claims.Map research studies without flattening disagreements
For a literature overview, specify the question, population, outcome, study period, and types of studies you want included. Ask for a study table with design, sample, measured outcome, date, and a direct link. Have the report separate a paper's findings from the authors' interpretation and from its own synthesis. If two studies seem to conflict, inspect whether they measured the same outcome in comparable populations before asking for a single conclusion. This workflow can organize an initial reading list; it does not establish that every relevant paper was found or replace a formal systematic review.
Map peer-reviewed studies about [specific outcome] in [population]
published from [start] to [end]. Include [eligible study types].
For each study, give its design, sample, outcome definition, result,
limitations, and direct link. Separate measured findings from
interpretations. List studies that disagree and possible reasons.
State what your search may have missed; do not claim completeness.Export, share, and fix common problems
OpenAI says you can download a completed report as Markdown, Word, or PDF. Choose Markdown when you will edit or reuse the text, Word for an editable document, and PDF for a fixed-layout copy. Before sharing, keep the research date, source links, and unresolved questions with the report. A downloaded file preserves the answer you received; it does not automatically update when a source changes.
In the completed report view, use the download option and choose the format that matches the next step. Open the exported file before sending it: confirm that the tables survived, source links still work, and the date and limitations remain visible. If you are sharing a report built from a connected app or an uploaded internal file, remove material the recipient may not be authorized to see. Exporting a report does not change the provider's permissions or grant the recipient access to its source documents.
- Deep Research is missing: check availability in your plan and region, and ask a workspace admin about role access if applicable. Check the in-product task counter before planning repeated runs.
- An app or file is missing: confirm the app supports Deep Research, your account can read the material, and the right file version was supplied. Ask the report to list what it could not access.
- The plan is too broad: narrow the period, region, options, and output columns before the run. Remove background sections that do not serve the decision.
- Research drifts while running: interrupt and name the incorrect scope or missing source, then state the revised deliverable.
- A citation is weak or wrong: open the passage, narrow the claim to what it supports, locate a better source, or mark the point unresolved.
- The report is long but unusable: ask for a decision table with evidence, assumptions, and next checks. Verify that the shorter version retains the important caveats.
- The task allowance is exhausted: check the in-product counter and its reset timing. Use Search or a narrower manual workflow for urgent work; do not promise that another plan or account will have the same quota.
- You need to retain or delete the work: Deep Research results follow the conversation's retention policy; deleting the chat also deletes its associated research output. Separately saved Library files may remain, so review those as well. Check your account or workspace data controls before uploading sensitive material.
A good handoff contains the request, selected sources, any plan changes, the dated report, checked links for consequential claims, and the open questions. That record makes the research reusable and shows a colleague what still needs human judgment.
