ChatGPT Workflow Verified

Source-grounded research brief for ChatGPT

Uses ChatGPT search plus an adversarial verification pass to turn a fuzzy question into a sourced brief you can hand to someone else.

LLM Mart · 0 points · 25 228

#writing #research

What vetted this — trust report

## Use case When the question is broad, the failure mode is a polished answer with weak sourcing — fluent, well-structured, and resting on three SEO pages that all paraphrase the same press release. This workflow forces the sourcing step to happen *before* the summary, because once a summary exists the citations get retrofitted to it rather than the other way round. ## Workflow Run these as **separate turns.** Combined into one prompt, the evidence-gathering phase gets compressed into whatever fits around producing the answer, which defeats the purpose. ### 1. Frame the brief > Use web search. Before answering: restate the decision I'm trying to make, define the time range > that matters, and list the 3–5 subquestions required to answer it well. **Stop.** Read the subquestions carefully — they define the scope of everything that follows, and it's much cheaper to add one now than to discover a gap in step 5. Make sure at least one of them could *falsify* your expected answer. A subquestion list that can only confirm your prior is a literature search, not research. ### 2. Collect candidate sources > Use web search to find 6–10 candidate sources. Prefer primary sources and current data, and > include **at least one source likely to disagree** with the dominant view. Return only: source, > date, type (primary/secondary/tertiary), and why it matters. Don't summarize their contents yet. The "likely to disagree" clause is doing real work. Default search behaviour returns the consensus, and consensus is exactly what you can't evaluate without the dissent. **Check independence before moving on:** *"Which of these cite each other or trace to the same original source?"* Six articles from one announcement is one source, and treating it as six is the most common way research goes confidently wrong. ### 3. Build an evidence table > Build a table: claim | source | publication date | the exact supporting line | why the claim > matters. If a claim cannot be grounded in a specific line, omit it. The **exact supporting line** column is the mechanism. Without it, claims get paraphrased on the way into the table and the paraphrase drifts — usually toward being stronger and more quotable than what the source said. Scan the date column before anything else. In fast-moving domains, half of a plausible evidence table can turn out to describe last year's state of the world. ### 4. Run the conflict pass > For each load-bearing claim, find the strongest contrary source or caveat. Mark each claim as > supported, contested, or weak. For contested claims, say who's on each side and what would settle > it. This is the step that separates a brief from a summary. A claim nobody has argued with is a claim nobody has checked. ### 5. Check coverage > Which of the subquestions from step 1 are still unanswered? What did you look for and fail to > find? The second question routinely produces the most valuable line in the whole brief. "No primary source states this, although it's widely repeated" is a finding, not a gap. ### 6. Draft the brief > Write the final brief in this order: direct answer, evidence, contested points, open questions. > Every non-obvious claim carries a source and a date. ### 7. Final scrub > Remove every claim that lacks a source. Mark any inference as inference. If web search was > unavailable or returned nothing for any part of this answer, say so explicitly. That last clause catches the silent failure where search didn't work and the model answered from memory in the same confident register — which is indistinguishable from success unless you ask. ## Output shape - **Direct answer** — 2–4 sentences. The part someone will quote. - **Evidence** — bullets, each with source name, date, and tier. - **Contested** — genuine disagreement only, with both sides named. Not filler balance. - **Open questions** — what would still change the recommendation, and how to find out. ## Why it works The answer comes last. By forcing an evidence table and a conflict pass first, you get a brief short enough to read and solid enough to defend when someone pushes back — and the pushback is the point, since a brief nobody challenges wasn't worth writing. ## ChatGPT specifics - **Put the standing context in a Project** — your industry, your constraints, your house style for briefs — instead of retyping it. Project instructions apply to every chat in it. - **Deep research** can replace steps 2–3 for a big question. Treat its output as a well-organized reading list with a summary attached, and still run steps 4–7 by hand. The value is that it read forty pages so you only read six; the six still need reading. - **Connectors** let the same brief span your own documents and the live web. Say which is which in the evidence table — an internal doc is a primary source about your company and no kind of source about the market. - **Canvas** for step 6 onward, so edits are targeted rather than full regenerations. ## Failure modes - **Every source is a listicle.** Re-run step 2 with "primary sources only: vendor docs, filings, standards, changelogs, the original announcement." - **The evidence table is thin but the brief is long.** The prose is being generated, not synthesized. Cut the brief to what the table supports. - **Everything is marked "supported".** The conflict pass was performed as ritual. Ask for the strongest counter-argument to the *central* claim specifically. - **A URL 404s.** Strong signal that the claim was generated rather than retrieved. Treat neighbouring claims with suspicion and re-run that row. - **The brief hedges on everything.** Balance is not the same as rigor. Ask it to state the answer it would give if forced to choose, and why.

Use case

When the question is broad, the failure mode is a polished answer with weak sourcing — fluent, well-structured, and resting on three SEO pages that all paraphrase the same press release.

This workflow forces the sourcing step to happen before the summary, because once a summary exists the citations get retrofitted to it rather than the other way round.

Workflow

Run these as separate turns. Combined into one prompt, the evidence-gathering phase gets compressed into whatever fits around producing the answer, which defeats the purpose.

1. Frame the brief

Use web search. Before answering: restate the decision I'm trying to make, define the time range that matters, and list the 3–5 subquestions required to answer it well. Stop.

Read the subquestions carefully — they define the scope of everything that follows, and it's much cheaper to add one now than to discover a gap in step 5.

Make sure at least one of them could falsify your expected answer. A subquestion list that can only confirm your prior is a literature search, not research.

2. Collect candidate sources

Use web search to find 6–10 candidate sources. Prefer primary sources and current data, and include at least one source likely to disagree with the dominant view. Return only: source, date, type (primary/secondary/tertiary), and why it matters. Don't summarize their contents yet.

The "likely to disagree" clause is doing real work. Default search behaviour returns the consensus, and consensus is exactly what you can't evaluate without the dissent.

Check independence before moving on: "Which of these cite each other or trace to the same original source?" Six articles from one announcement is one source, and treating it as six is the most common way research goes confidently wrong.

3. Build an evidence table

Build a table: claim | source | publication date | the exact supporting line | why the claim matters. If a claim cannot be grounded in a specific line, omit it.

The exact supporting line column is the mechanism. Without it, claims get paraphrased on the way into the table and the paraphrase drifts — usually toward being stronger and more quotable than what the source said.

Scan the date column before anything else. In fast-moving domains, half of a plausible evidence table can turn out to describe last year's state of the world.

4. Run the conflict pass

For each load-bearing claim, find the strongest contrary source or caveat. Mark each claim as supported, contested, or weak. For contested claims, say who's on each side and what would settle it.

This is the step that separates a brief from a summary. A claim nobody has argued with is a claim nobody has checked.

5. Check coverage

Which of the subquestions from step 1 are still unanswered? What did you look for and fail to find?

The second question routinely produces the most valuable line in the whole brief. "No primary source states this, although it's widely repeated" is a finding, not a gap.

6. Draft the brief

Write the final brief in this order: direct answer, evidence, contested points, open questions. Every non-obvious claim carries a source and a date.

7. Final scrub

Remove every claim that lacks a source. Mark any inference as inference. If web search was unavailable or returned nothing for any part of this answer, say so explicitly.

That last clause catches the silent failure where search didn't work and the model answered from memory in the same confident register — which is indistinguishable from success unless you ask.

Output shape

Direct answer — 2–4 sentences. The part someone will quote.
Evidence — bullets, each with source name, date, and tier.
Contested — genuine disagreement only, with both sides named. Not filler balance.
Open questions — what would still change the recommendation, and how to find out.

Why it works

The answer comes last. By forcing an evidence table and a conflict pass first, you get a brief short enough to read and solid enough to defend when someone pushes back — and the pushback is the point, since a brief nobody challenges wasn't worth writing.

ChatGPT specifics

Put the standing context in a Project — your industry, your constraints, your house style for briefs — instead of retyping it. Project instructions apply to every chat in it.
Deep research can replace steps 2–3 for a big question. Treat its output as a well-organized reading list with a summary attached, and still run steps 4–7 by hand. The value is that it read forty pages so you only read six; the six still need reading.
Connectors let the same brief span your own documents and the live web. Say which is which in the evidence table — an internal doc is a primary source about your company and no kind of source about the market.
Canvas for step 6 onward, so edits are targeted rather than full regenerations.

Failure modes

Every source is a listicle. Re-run step 2 with "primary sources only: vendor docs, filings, standards, changelogs, the original announcement."
The evidence table is thin but the brief is long. The prose is being generated, not synthesized. Cut the brief to what the table supports.
Everything is marked "supported". The conflict pass was performed as ritual. Ask for the strongest counter-argument to the central claim specifically.
A URL 404s. Strong signal that the claim was generated rather than retrieved. Treat neighbouring claims with suspicion and re-run that row.
The brief hedges on everything. Balance is not the same as rigor. Ask it to state the answer it would give if forced to choose, and why.