What a Result Card Is in ChatGPT Search

First: what a “result card” is

A search-result card is one individual result returned by the search system after a query. It usually contains some combination of:

• Page title
• URL or canonical-looking URL
• Publisher/domain
• Publication date, when detected
• A short snippet or extracted passage
• A result type, such as webpage, news article, PDF, image, or product
• An internal reference ID that can be used to open the result

It is analogous to one organic result on a conventional search-engine results page.

It is not necessarily a summary of the page

The snippet is generally a query-conditioned preview. It may be:

• Text extracted from the page
• Text surrounding terms matching the query
• Search-index metadata
• A description supplied by the publisher
• A search-system-generated condensation

I am not given a reliable field saying exactly how each individual snippet was generated.

Therefore, a card should be treated as:

A clue about what the page may contain—not evidence that the page actually establishes the claim.

A snippet can omit qualifications, confuse the publication date with an update date, quote another source, or make a page look more relevant than it is.

Opening the result is a separate action. That retrieves substantially more page content and permits actual evaluation.

Also, I do not “crawl” the web in the traditional sense of operating a spider that downloads every linked page. There are two relevant operations:

1. Search: retrieve result cards from a search index.
2. Open: fetch and inspect a specific result.

A URL that appears in a search card may never be opened.

---

The important correction to my earlier statement

For normal research, it is reasonable to discard obviously irrelevant search results without recording them.

For your explicit request, that was not the correct retention policy.

You specifically requested:

• Every fan-out query
• Every URL returned by those searches
• URLs considered but not opened
• URLs opened
• URLs used
• URLs cited

Under that requirement, the process should have separated two decisions:

1. Should the URL be captured in the audit log?
2. Should the page be opened or used as evidence?

Every URL actually returned to me should have passed the first decision automatically, even when it was obviously irrelevant.

The only legitimate reasons not to create a separate retained record would have been:

• It was an exact duplicate.
• It was merely a tracking or redirect variant of another retained URL.
• The search response exposed a title but no usable URL.
• It was not actually a webpage result.
• The same canonical page appeared through several equivalent URLs.

So this wording from the report:

“A small number of low-value or irrelevant result cards were screened out before their URLs were retained.”

describes what happened, but it should not be understood as an ideal methodological rule for your project. It was a limitation in the capture process.

The more accurate statement would be:

A small number of obviously irrelevant results were not opened, and their URLs were not captured before the search context was compressed. Their titles remained available, but the exact URLs did not. For the requested full audit, those URLs should have been logged before any relevance filtering.

Therefore, I did not fully satisfy the requirement to provide every URL surfaced during the searches. I retained 113 unique URLs, but a small additional set survived only as titles and publishers.

---

Three different meanings of “retained”

Part of the confusion comes from using “retained” too broadly. There should be three separate concepts.

1. Audit retention

Was the URL recorded at all?

For your research requirement, the answer should be yes for every returned URL, before evaluating quality.

2. Research retention

Was the source considered sufficiently relevant to remain in the active candidate pool?

A URL might be recorded in the audit but excluded from further review.

3. Evidentiary inclusion

Was information from the page used to support a finding or citation?

Only a relatively small subset should reach this level.

A clean source register should therefore contain fields such as:

That prevents “not used” from becoming “not recorded.”

---

The complete filtering pipeline

Stage 1: Define the evidence questions

Before searching, the broad question is broken into measurable subquestions.

For this project, those included:

• What are the major consumer LLM use cases?
• What are the major workplace use cases?
• What percentage of prompts or conversations fall into each category?
• What percentage of people report each use?
• How do ChatGPT, Claude, and Gemini differ?
• How much use is work-related versus personal?
• What is assistance versus automation?
• What is the platform reach of each system?
• What is known about free, logged-out, paid, enterprise, and API users?
• What methodologies have researchers used?
• How have the distributions changed over time?
• What research concerns therapy, companionship, learning, coding, writing, search, brainstorming, and agents?

This produces an evidence matrix. It prevents one prominent study from being treated as though it answers every part of the question.

---

Stage 2: Generate fan-out queries

Search queries are deliberately varied because terminology differs among researchers.

For example, the same underlying concept might be described as:

• Use cases
• User intent
• Conversation categories
• Prompt taxonomy
• Task distribution
• Economic activities
• Workplace adoption
• Augmentation versus automation
• Artifact types
• Consumer behavior
• Information seeking
• Emotional use
• Affective use
• Companion use

Queries are also aimed at different evidence classes:

• Official company research
• Academic papers
• Representative surveys
• Workplace surveys
• Usage telemetry
• Platform statistics
• Secondary summaries
• Dataset downloads
• Methodology documents

The previous run issued 64 recorded queries.

At this point, the correct process for your request would be:

1. Save the exact query.
2. Save every returned result card immediately.
3. Assign it a discovery ID.
4. Preserve the raw title, raw URL, snippet, publisher, position, and query.
5. Only then begin filtering.

That fourth step was not performed perfectly in the prior run. The search interface did not provide a downloadable raw SERP archive, and some results were triaged before their URLs were transferred into the persistent register.

---

Stage 3: Card-level triage

Card-level triage determines opening priority, not whether the URL deserves an audit record.

Each result can be assigned one of four priorities:

Card-level criteria

1. Topical relevance

Does the title or snippet address the actual research question?

For example:

• “How People Use ChatGPT” is highly relevant.
• “Ten Prompts to Improve Productivity” is about recommended usage, not measured usage.
• “AI Will Reshape the Future of Work” may be commentary with no use-case data.
• “ChatGPT Traffic Increased 20%” concerns scale but not task categories.

2. Evidence type

The title and publisher may indicate what kind of evidence is likely present:

• Official telemetry
• Peer-reviewed paper
• Working paper
• Representative survey
• Commercial survey
• Opinion article
• Product announcement
• News summary
• SEO article
• Dataset portal

Primary telemetry and representative surveys receive higher opening priority.

3. Source authority

Examples of high-priority sources for this question:

• OpenAI
• Anthropic
• Google
• Pew Research Center
• Gallup
• AP-NORC
• Federal Reserve researchers
• Census Bureau
• NBER
• Original academic papers

A news article might still be important when it reports methodology omitted from an official announcement, but it is usually secondary.

4. Likely methodological value

A result mentioning any of the following is especially valuable:

• Sample size
• Field dates
• Dataset period
• Number of conversations
• Representative sample
• Classification methodology
• Work/non-work definition
• Prompt categories
• User-plan segmentation
• Occupational mapping

5. Freshness

For rapidly changing LLM usage, recency matters substantially.

A 2024 study may remain valuable as a baseline, but it should not be presented as the current 2026 distribution without qualification.

6. Duplication

Searches frequently return:

• The official report
• The report’s press release
• A news story about the report
• Several blog summaries
• Charts republishing the same numbers
• Syndicated copies of the news story

All URLs should be logged, but only some need opening.

7. Apparent denominator fit

A card may look relevant but concern the wrong population.

Examples:

• Share of AI users, rather than all adults
• Share of workers who already use AI, rather than all workers
• Share of messages, rather than users
• Share of organizations, rather than employees
• Share of web traffic, rather than active users
• Use among teen AI-companion users, rather than general chatbot users

These results may still be useful, but they should be routed to the correct evidence section.

8. Availability

Cards may point to:

• Paywalled pages
• Oversized PDFs
• Dynamically rendered pages
• Blocked pages
• Download-only datasets
• Pages inaccessible to the retrieval environment

Inaccessibility does not mean the URL should disappear. It should receive an access-status label.

---

Stage 4: Open and validate the page

Once a URL is opened, the actual source is evaluated. This is where most substantive filtering should happen.

A. Identity validation

Confirm:

• Page title
• Publisher
• Author
• Publication date
• Update date
• Whether the page is the original source
• Whether it is reporting another organization’s research

A page saying “a new OpenAI study found…” is not the same as the OpenAI study.

B. Methodology validation

For quantitative research, extract:

• Sample size
• Population
• Geography
• Collection dates
• Publication date
• Sampling method
• Weighting
• Unit of analysis
• Classification system
• Whether categories overlap
• Whether results are self-reported or observed
• Product surfaces included
• Product surfaces excluded

For example:

“42% use AI for search”

is uninterpretable without knowing whether that means:

• 42% of all U.S. adults
• 42% of AI users
• 42% of workers
• 42% of chatbot conversations
• 42% of weekly users
• 42% of respondents who selected at least one overlapping option

C. Claim validation

Check whether the page really supports the apparent search-result claim.

A snippet may say:

“Therapy is the leading AI use case.”

Opening the source may reveal that this was:

• A qualitative ranking of online discussion themes
• Not a measured percentage
• Not a representative survey
• Not a prompt-distribution study
• Not limited to general-purpose LLMs

That source can still help identify a category, but it cannot establish prevalence.

D. Scope validation

Determine what “AI” means in the study:

• General-purpose chatbots
• All generative AI
• Search features
• Image generators
• Coding assistants
• Enterprise applications
• Specialized companion bots
• Embedded AI features
• API usage

A broad “AI” survey should not automatically be treated as an LLM-chat survey.

E. Internal consistency

Check whether:

• Percentages total 100% when categories are supposed to be exclusive.
• Overlapping-response percentages are being mistakenly added.
• Dates match the stated observation period.
• A chart and accompanying prose use the same denominator.
• “Automation” has a specific operational definition.
• A platform’s active-user metric is WAU or MAU.
• Paid accounts, subscriptions, and active users are being distinguished.

F. Source provenance

Determine whether the numbers are:

• Generated by the publisher
• Quoted from another source
• Estimated by a third party
• Derived from web traffic
• Based on an undisclosed model
• Reconstructed from a chart
• Merely repeated without attribution

---

Stage 5: Decide how the source can be used

After opening, a source falls into a functional category.

The previous register used these statuses:

Those labels describe research use, not discovery retention.

USED_CORE

A source qualified as core when it did one or more of the following:

• Supplied an original quantitative result
• Supplied an original taxonomy
• Supplied methodology required to interpret a result
• Was the strongest available source for a major claim
• Materially changed the final conclusions

Examples include first-party conversation telemetry and representative population surveys.

USED_CONTEXT

A contextual source might:

• Confirm a platform’s official active-user figure
• Explain exclusions from a dataset
• Supply historical comparison
• Clarify the meaning of a category
• Show how a result had changed over time
• Corroborate a primary finding without being the principal evidence

CONSIDERED

A considered source might be credible and relevant but unnecessary because:

• A better primary source was found.
• It repeated facts already established.
• It addressed a narrower population.
• It supplied no additional numbers.
• It was useful for discovery but not for the final findings.
• It was a secondary summary of a report already available directly.

CONSIDERED_NOT_USED

This was reserved for sources rejected for a material reason, such as:

• Subjective assumptions
• Incomparable metrics
• Unverified claims
• Weak methodology
• Web-traffic estimates being presented as user market share
• Categories that did not match the requested domain

In a more rigorous register, every unused source should have a standardized reason code rather than relying only on prose.

---

Stage 6: Build a claim ledger

A source should not simply be labeled “good.” Individual claims need to be tracked.

A claim ledger might look like this:

This is where apparent contradictions are usually resolved.

For instance:

• “10% of adults have used chatbots for emotional support”
• “Therapy is the top discussed AI use case”
• “Emotional conversations are rare in ChatGPT telemetry”

can all be simultaneously true because they measure different things.

---

Stage 7: Cross-source synthesis

Sources are grouped by denominator before comparison.

Conversation telemetry

Measures messages, conversations, interactions, or tasks.

Examples:

• OpenAI consumer conversation classifications
• Anthropic Claude conversation telemetry
• Google Gemini/AI Mode/API interactions

Population surveys

Measure people.

Examples:

• Percentage of U.S. adults who have ever used AI for a purpose
• Percentage who used it in the last week
• Percentage of workers who use it at work

Conditional surveys

Measure a subgroup.

Examples:

• Among AI users
• Among workers who have used chatbots
• Among teen companion users
• Among enterprise customers

Platform scale

Measures:

• Weekly active users
• Monthly active users
• Subscribers
• Business seats
• Feature reach
• Website visits

These cannot be merged into one market-share distribution without additional data.

---

Stage 8: Citation selection

Not every opened source needs to appear in the final narrative.

A source is cited when it is the strongest or necessary support for a delivered claim.

Citation selection favors:

1. Original source over a summary
2. Published methodology over a press quotation
3. Current data over outdated data
4. Representative evidence over convenience samples
5. Clearly defined denominators
6. Direct support for the exact sentence
7. Independent corroboration for surprising claims

Secondary sources may be cited when they uniquely provide:

• Details omitted from the primary announcement
• A chart transcription
• Access to otherwise unavailable methodology
• An independent critique
• Context necessary to interpret the primary source

---

What “cutting something out” should mean

There are several different levels of exclusion.

Do not open

The card is recorded, but the page is not fetched because it is obviously:

• Irrelevant
• Duplicate
• A weak rewrite of an available primary source
• Outside the date range
• About a materially different technology
• Unlikely to contain methodology or useful evidence

Open but do not extract

The page initially looked relevant but contains no usable evidence.

Extract but do not use

The page contains potentially useful information, but a better source exists or its denominator does not fit the intended comparison.

Use for context but not quantitative support

The page helps explain terminology, trends, or controversy but cannot support prevalence claims.

Use as core evidence

The source directly supports an important finding with an interpretable method and denominator.

Cite in final answer

The source supports a claim actually presented to the reader.

The URL should remain in the audit register at every level.

---

What happened to the unretained result cards

During broad fan-out, some search results were visibly low-value—for example:

• General opinion pieces
• Consumer advice articles
• News stories only tangentially related to LLM usage
• Articles about isolated risks
• Repetitive summaries of studies already found
• Articles about whether people trust AI
• Commentary on job losses
• Generic articles about AI therapy
• Articles about product plans rather than use patterns

Those cards were not opened. Later, when the accumulated search context was compressed, their titles or rough descriptions remained in the working record but their exact URLs were no longer available for export.

That is why Appendix C contained descriptions such as:

• “Financial Times article about AI nostalgia”
• “Kiplinger article about financial chatbots”
• “The Guardian article about job-apocalypse claims”

Those descriptions were not summaries of the pages. They were shorthand identifiers for result cards that had appeared but were not opened or fully retained.

I should not reconstruct exact URLs from titles after the fact because that could falsely associate the record with the wrong article, syndicated copy, regional edition, or URL variant.

---

What can and cannot be captured

Even with a corrected procedure, “every URL” has an important boundary.

It can mean:

Every URL actually returned to me in the search-tool responses.

It cannot mean:

• Every URL indexed by the search engine
• Every URL internally considered by its ranking system
• Every result that might have appeared on later SERP pages
• Every link contained inside every discovered page
• Every alternative canonical or syndicated version
• Every URL omitted by the search API before results reached me

The search system itself returns only a finite selected result set.

A truly exhaustive link-discovery exercise would require:

• Explicit pagination
• A defined number of results per query
• Raw SERP capture
• Link extraction from opened pages
• Recursive discovery rules
• Canonicalization
• Deduplication
• A stopping condition

That is closer to a reproducible systematic review or web-crawling project than ordinary assisted web research.

---

The correct process for future research of this type

For a project where complete discovery provenance matters, the process should be:

1. Create the query register before searching.
2. Run one query at a time or in small batches.
3. Immediately persist every returned card.
4. Store raw title, URL, snippet, rank, date, publisher, query, and retrieval timestamp.
5. Canonicalize URLs without deleting the raw originals.
6. Deduplicate only through explicit relationships.
7. Assign opening priority separately from retention.
8. Record every open attempt and HTTP/access outcome.
9. Extract methodology and claims into structured fields.
10. Record one or more exclusion reasons for every unused source.
11. Mark exactly which claims each used source supports.
12. Mark which used sources were cited in the final output.
13. Export the untouched discovery log as well as the cleaned source register.
14. Report any unavoidable capture gaps numerically.

The essential rule is:

Capture first; filter second.

That is the part the earlier run did not execute perfectly.