ChatGPT disclosed things in this session that I did not expect it to disclose, and there is no guarantee it stays available. I would rather people had time to use it than had a tidier version of it later.
So: every word of every ChatGPT response here is verbatim, and that part is checked automatically on every build. What is not finished is the presentation. The color coding on the code blocks is incomplete and some of it is imprecise, and there are notes to myself still sitting in the page.
Parts 1 and 2 are close to empty and are getting a lot of detail over the next week or so, along with a cleanup pass on everything else. Worth checking back.
Search result schemas
JSON Shapes for Every ChatGPT Search Result Type
Written from memory, before any live call. The shapes are plausible and the values are invented.
Here we ask for the JSON shape of every result type, with sample data.
The values on this page are invented. ChatGPT says so before it starts: these are "normalized representations of the maximum observable information, not leaked or guaranteed internal backend schemas."
That is why the code blocks here are blue. Compare them against the green blocks on the live tests page. They look almost identical. One set is made up and the other came back from a real call.
The longest answer so far and the least trustworthy, which it says up front.
Three objects, kept separate
It opens by separating things that had been getting mixed together:
- The public API tool-call object, which OpenAI documents and which is thin: a
status, the queries, and a list of source URLs.
- The internal result card, visibly richer but with no published contract.
- The normalized research record, which is what a research pipeline would
build for itself.
It then introduces a six-level certainty legend and uses it throughout: documented, observed, request context, derived, proposed, and unknown.
Why this page is blue
The header above the JSON says these are "normalized representations of the maximum observable information, not leaked or guaranteed internal backend schemas."
That sentence is why every code block here is blue. The shapes are plausible. The values are invented.
What follows is a full JSON shape for each result family: general web, news, image, finance, sports schedule and sports standings, each with a field-status table marking which fields were observed, which are derived, and which are proposed.
What survives the caveats
A few genuinely useful facts. The finance request takes a ticker, an instrument type and a market. The sports request takes a league, a team, a date range and a game count. The web request accepts a recency filter and a domain restriction.
Those are real levers.
Why it cannot go further
It does not receive the backend transport payload. What it sees may already have been transformed. The model-facing representation may differ from the one the interface receives. And OpenAI does not publish internal schemas for finance, sports, news or image cards.
All of which raises an obvious question, asked in the next turn.
Two questions.
First: when you say what an ideal enriched research card would contain, and then show that JSON, is that the ideal you would receive from a fan-out query combined with your internal search? Is that what you are saying?
Second: for each of the result card types you listed, sports schedule event, finance result, image search result, news result, general web search result, give me the JSON shape of each one. Full JSON, every field you might receive, with sample data that represents the data type, so a string where a string goes and a number where a number goes.
Take your time. Include as much as you can find about all the different fields you might receive for each individual result card. Show me what that JSON would look like for each of them.
1. What I meant by the “ideal enriched research card”
No—the JSON object I showed was not the actual object I receive from an internal fan-out search.
It was a proposed application-level research record: the object I would want a research system to construct by combining:
- The original search query
- The returned result card
- Information learned by opening the result
- Page-level metadata extracted independently
- URL normalization and redirect analysis
- Methodological details extracted from the source
- Researcher judgments about relevance, quality, use, and citation
The distinction is:
Actual search result
↓
Open and inspect page
↓
Extract and normalize metadata
↓
Add research decisions
↓
Ideal enriched research cardIt was an ideal output of the entire research-ingestion process, not the raw output of the fan-out query.
What the public OpenAI web-search API actually documents
The public Responses API exposes a web_search_call. For a search action, the documented fields are essentially:
- Tool-call ID
- Item type
- Status
- Action type
- Search query or queries
- Source URLs
The response text can then contain URL-citation annotations with:
- Citation type
- Title
- URL
- Start character index
- End character index
The documented public schema does not expose a result array containing author objects, snippets, publication dates, JSON-LD, relevance scores, PageRank, or arbitrary page metadata. (OpenAI Platform)
A simplified example of the documented tool call is:
{
"id": "ws_67f3f831c4b4819089e38f1a",
"type": "web_search_call",
"status": "completed",
"action": {
"type": "search",
"query": "consumer uses of large language models",
"queries": [
"consumer uses of large language models",
"generative AI use case survey consumer behavior"
],
"sources": [
{
"type": "url",
"url": "https://example.com/research/report"
},
{
"type": "url",
"url": "https://example.org/survey/methodology"
}
]
}
}query is documented as deprecated in favor of queries. The sources objects are documented as containing a source type—currently url—and the URL itself. (OpenAI Platform)
The corresponding assistant output might contain:
{
"id": "msg_67f3f831c4b4819089e38f1b",
"type": "message",
"status": "completed",
"role": "assistant",
"content": [
{
"type": "output_text",
"text": "The survey found that information seeking was the most common reported use.",
"annotations": [
{
"type": "url_citation",
"title": "Consumer Uses of Generative AI",
"url": "https://example.com/research/report",
"start_index": 0,
"end_index": 76
}
]
}
]
}That is the closest thing to a publicly documented, contractual schema.
2. Three different objects are being conflated
There are really three separate data structures.
A. Public API tool-call object
This is documented and relatively thin:
queries
source URLs
tool-call status
citations in generated outputB. Internal or tool-facing result card
This is what appears in my research environment as references such as:
turn260213search0
turn260213news12
turn260213image0
turn260213finance0
turn152657sports0These objects visibly provide richer information, but their complete raw transport schema is not exposed to me as a public contract. I see a rendered or transformed representation.
C. Normalized research record
This is what I proposed:
raw discovery data
normalized URL
page metadata
authors
publisher
schema types
methodology
quality decisions
citation statusThis third object would be created by your own research pipeline.
3. What I can state with different levels of certainty
I will use these labels below:
| Label | Meaning |
|---|---|
| Documented | Appears in official public OpenAI documentation |
| Observed | Directly visible in actual tool results available to me |
| Request context | Supplied in the request and may not be repeated in the returned payload |
| Derived | Can be calculated or inferred from observed fields |
| Proposed | Useful field for a normalized system, but not known to be returned |
| Unknown | May exist internally but is not exposed or documented |
The JSON objects below are normalized representations of the maximum observable information, not leaked or guaranteed internal backend schemas.
4. General web-search result
Known request shape
The search request available in this environment accepts approximately:
{
"q": "OpenAI web search API response schema",
"recency": 30,
"domains": [
"platform.openai.com",
"help.openai.com"
]
}Field meanings:
| Field | Type | Meaning |
|---|---|---|
q | string | Search query |
recency | integer or null | Restrict results to approximately this many recent days |
domains | array of strings or null | Restrict results to specified domains |
The search request may be sent as part of a batch of queries.
Observable result-card shape
A maximally populated normalized representation of a general result visible to me would look like:
{
"ref_id": "turn260213search0",
"result_type": "web",
"title": "OpenAI News | OpenAI",
"url": "https://example.com/news/",
"snippet": "A page containing recent company, research, product, safety, and engineering announcements.",
"published": {
"display": null,
"iso_8601": null,
"precision": null,
"source": "unknown"
},
"crawled": {
"display": "2 days ago",
"iso_8601": null,
"precision": "relative",
"source": "search_index"
},
"word_limit": 200,
"result_order": 0,
"content_type_hint": "text/html",
"source_domain": "example.com",
"publisher_name": null,
"author": null,
"language": null,
"thumbnail": null,
"raw_html": null,
"json_ld": null,
"open_graph": null,
"canonical_url": null,
"relevance_score": null,
"authority_score": null
}Field status
| Field | Status | Important qualification |
|---|---|---|
ref_id | Observed | Internal conversational reference, not a stable external ID |
result_type | Observed/inferred | Indicated by the search reference family |
title | Observed | Exact upstream origin is not provided |
url | Observed | May already have undergone normalization |
snippet | Observed | May be extractive, generated, metadata-derived, or mixed |
published.display | Sometimes observed | Often absent |
crawled.display | Sometimes observed | Usually relative, such as “2 days ago” |
word_limit | Observed | Usage/summarization constraint, not page metadata |
result_order | Derived | Comes from ordering, not necessarily an explicit field |
content_type_hint | Derived | Usually inferred from the result or opened resource |
source_domain | Derived | Parsed from the URL |
publisher_name | Sometimes inferable | Not reliably exposed as a normalized field |
author | Not ordinarily exposed | Requires opening or independent extraction |
language | Not ordinarily exposed | Can often be inferred |
thumbnail | Occasionally rendered | Not normally exposed as a raw URL field |
raw_html | Not exposed | No direct DOM access in the card |
json_ld | Not exposed | No raw schema graph |
canonical_url | Not exposed | Destination URL is not necessarily the declared canonical |
relevance_score | Not exposed | Ordering is visible, numerical score is not |
authority_score | Not exposed | No PageRank-like value |
What the rendered result may resemble
{
"ref_id": "turn260213search0",
"title": "OpenAI News | OpenAI",
"url": "https://example.com/news/",
"word_limit": 200,
"crawled_display": "2 days ago",
"content": "OpenAI\n\n## All\n\nCompany\nResearch\nProduct\nSafety\nEngineering..."
}Notice that the visible result may contain substantially more extracted page text than a conventional SERP snippet. It is still not necessarily raw page HTML.
5. News result
A news result is visibly distinguished through a reference such as:
turn260213news12The public Responses API does not document news as a separate URL-source object type; public web-search sources remain URL sources. The richer news classification belongs to the search/tool presentation layer rather than the documented public source schema. OpenAI documents that ChatGPT Search may return specialized structured or visual results, including timely information, but does not publi(OpenAI Help Center)
Observable normalized news shape
{
"ref_id": "turn260213news12",
"result_type": "news",
"title": "Technology Adviser Briefed on AI Security Incident",
"url": "https://example.com/technology/security-incident-2026-07-23/",
"publisher": {
"name": "Example News Service",
"domain": "example.com",
"logo_url": null
},
"author": {
"name": null,
"url": null
},
"published": {
"display": "2 days ago",
"iso_8601": "2026-07-23",
"precision": "day",
"source": "unknown"
},
"updated": {
"display": null,
"iso_8601": null,
"precision": null,
"source": "unknown"
},
"crawled": {
"display": null,
"iso_8601": null
},
"word_limit": 100,
"summary": "A government technology adviser was briefed on an incident involving an AI security test.",
"snippet": null,
"result_order": 0,
"content_type_hint": "news_article",
"section": null,
"location": null,
"dateline": null,
"thumbnail": {
"rendered": false,
"url": null,
"width": null,
"height": null,
"alt_text": null
},
"paywall": null,
"syndication": {
"is_syndicated": null,
"original_source": null
},
"raw_html": null,
"newsarticle_json_ld": null,
"relevance_score": null,
"authority_score": null
}What is genuinely observed
A news result visible to me commonly includes:
{
"ref_id": "turn260213news12",
"title": "Technology Adviser Briefed on AI Security Incident",
"url": "https://example.com/technology/security-incident-2026-07-23/",
"published_display": "2 days ago",
"word_limit": 100,
"summary_or_snippet": "A government technology adviser was briefed on..."
}Fields that may visually appear but are not guaranteed model-facing fields
- Publisher logo
- Thumbnail
- Publisher display name
- Relative publication time
- Headline styling
- Source favicon
The ChatGPT interface can present publisher logos and source previews, but that does not establish that every value is delivered to(OpenAI Help Center)n explicit JSON property.
Not exposed in the standard news card
{
"byline": null,
"editor": null,
"news_keywords": null,
"article_section": null,
"dateline": null,
"copyright_holder": null,
"is_accessible_for_free": null,
"word_count": null,
"citation_count": null,
"original_reporting": null,
"fact_check_rating": null,
"news_source_quality": null,
"newsarticle_schema": null
}Those values may exist on the source page or internally but are not part of the visible result contract.
6. Image-search result
An image result has a reference such as:
turn260213image0In actual tool output, I can receive:
- A rendered image
- Source-page title
- Source-page URL
- Publication age in some cases
- Text associated with the source page
- Sometimes a generated or extracted description
OpenAI’s public Search help states that images may appear in search responses and that selecting an image reveals its citation and source. It d(OpenAI Help Center)image-result transport schema.
Known request shape
{
"q": "Grand Canyon National Park sunrise",
"recency": null,
"domains": [
"nps.gov"
]
}Observable normalized image-result shape
{
"ref_id": "turn260213image0",
"result_type": "image",
"title": "Grand Canyon Sunrise",
"source_page": {
"url": "https://example.com/photo/grand-canyon-sunrise/",
"domain": "example.com",
"publisher": "Example Photography",
"published": {
"display": "4 months ago",
"iso_8601": null,
"precision": "relative"
}
},
"image": {
"rendered_in_result": true,
"image_url": null,
"thumbnail_url": null,
"source_image_url": null,
"width": null,
"height": null,
"aspect_ratio": null,
"mime_type": null,
"file_size_bytes": null,
"alt_text": null,
"caption": null,
"credit": null,
"creator": null,
"copyright_notice": null,
"license": null
},
"description": "Sunrise illuminating the layered cliffs and Colorado River in the Grand Canyon.",
"extracted_page_text": null,
"entities": [],
"location": {
"name": "Grand Canyon National Park",
"latitude": null,
"longitude": null
},
"result_order": 0,
"visual_similarity_score": null,
"text_relevance_score": null,
"quality_score": null,
"safety_classification": null,
"perceptual_hash": null,
"raw_exif": null,
"raw_iptc": null,
"raw_xmp": null
}What was actually visible in a result during this research
Conceptually:
{
"ref_id": "turn260213image2",
"title": "Centennial Sunrise | Grand Canyon National Park",
"source_page_url": "https://example.com/photo/grand-canyon-centennial-sunrise/",
"published_display": "7.3 years ago",
"image_preview": "<rendered image>",
"associated_text": "Sunrise on February 26, 2019...",
"description": "Grand Canyon National Park at sunrise."
}"<rendered image>" is not a literal string I receive. It represents the fact that the result includes a visual object in the interface. I do not necessarily receive its original binary bytes or direct image URL.
Potential ambiguity around image descriptions
The prose under an image may be:
- Source-page text
- Image-page caption
- Alt text
- Search-provider-generated description
- Model-generated visual description
- A combination of those
I generally do not receive a provenance field such as:
{
"description_source": "og:image:alt"
}Fields not reliably exposed
{
"original_image_url": null,
"thumbnail_url": null,
"width": null,
"height": null,
"format": null,
"creator": null,
"license": null,
"copyright": null,
"camera": null,
"lens": null,
"gps": null,
"date_taken": null,
"dominant_colors": null,
"safe_search_score": null,
"visual_embedding": null,
"duplicate_cluster_id": null
}Some of these almost certainly exist somewhere in an image-search pipeline, but they are not exposed to me.
7. Finance result
A finance result in this environment is a dedicated structured-data result with a reference such as:
turn260213finance0OpenAI publicly states that ChatGPT Search can return specialized structured information for finance and other timely categories,(OpenAI Help Center) the complete internal finance-result schema.
Known request shape
{
"ticker": "AMD",
"type": "equity",
"market": "USA"
}Known request fields:
| Field | Type | Allowed meaning |
|---|---|---|
ticker | string | Symbol or instrument identifier |
type | enum | equity, fund, crypto, or index |
market | string | Market identifier; cryptocurrency may use an empty value |
Observable normalized finance shape
{
"ref_id": "turn260213finance0",
"result_type": "finance",
"instrument": {
"name": "Advanced Micro Devices Inc.",
"ticker": "AMD",
"type": "equity",
"market": "USA",
"exchange": null,
"exchange_mic": null,
"isin": null,
"cusip": null,
"figi": null,
"currency": "USD"
},
"quote": {
"price": 521.95,
"currency": "USD",
"change": -17.66,
"change_percent": -3.272,
"previous_close": 539.61,
"open": 547.0,
"high": 551.01,
"low": 518.5,
"volume": 27200730,
"trade_time": "2026-07-24T23:59:18Z",
"market_status": null,
"bid": null,
"ask": null,
"bid_size": null,
"ask_size": null,
"day_range": {
"low": 518.5,
"high": 551.01
},
"fifty_two_week_range": {
"low": null,
"high": null
}
},
"fundamentals": {
"market_cap": 861217500000,
"pe_ratio": 171.13114754098362,
"eps": 3.05,
"dividend_yield": null,
"shares_outstanding": null,
"beta": null
},
"history": {
"interval": null,
"currency": "USD",
"points": []
},
"provider": {
"name": null,
"timestamp": null,
"delayed": null,
"delay_minutes": null
},
"source_urls": [],
"data_quality": {
"is_stale": null,
"is_estimated": null
}
}Which finance fields were actually observed
The actual finance result exposed these values:
{
"name": "Advanced Micro Devices Inc.",
"ticker": "AMD",
"instrument_type": "equity",
"market": "USA",
"price": 521.95,
"currency": "USD",
"change": -17.66,
"change_percent": -3.272,
"intraday_high": 551.01,
"intraday_low": 518.5,
"open": 547.0,
"volume": 27200730,
"market_cap": 861217500000,
"pe_ratio": 171.13114754098362,
"eps": 3.05,
"latest_trade_time": "2026-07-24T23:59:18Z"
}Important derived field
previous_close was not separately stated in the rendered result. It can be derived:
previous_close = current_price - absolute_change
previous_close = 521.95 - (-17.66)
previous_close = 539.61A robust schema should distinguish returned values from calculated values:
{
"previous_close": {
"value": 539.61,
"provenance": "derived",
"formula": "price - change"
}
}Fields likely required by a chart but not visibly present in the textual card
A finance chart needs a time series, conceptually:
{
"history": {
"interval": "1d",
"points": [
{
"timestamp": "2026-07-20T20:00:00Z",
"open": 510.0,
"high": 525.0,
"low": 507.0,
"close": 522.0,
"volume": 24100000
}
]
}
}I cannot confirm that this exact object is supplied to the model. The interactive finance widget may receive data through a different UI channel that is not represented in the text I inspect.
Not exposed
- Data-provider identity
- Exchange code
- Quote latency
- Bid/ask
- Premarket and after-hours values
- Corporate-action adjustments
- Split-adjustment flags
- Confidence score
- Raw provider response
- Instrument identifiers beyond ticker/name
- Calculation methodology for fundamentals
8. Sports schedule result
A sports result uses a reference such as:
turn152657sports0The same broad reference family can represent:
- Schedule
- Live or completed games
- Standings
OpenAI publicly confirms that ChatGPT Search may return speciali(OpenAI Help Center)but no public field-level transport schema is provided.
Known schedule request shape
{
"tool": "sports",
"fn": "schedule",
"league": "mlb",
"team": "NYY",
"opponent": null,
"date_from": "2026-07-20",
"date_to": "2026-07-30",
"num_games": 10,
"locale": "en-US"
}Known request fields:
| Field | Type | Meaning |
|---|---|---|
tool | constant | sports |
fn | enum | schedule or standings |
league | enum | Supported league code |
team | string or null | Common broadcast abbreviation |
opponent | string or null | Optional opponent filter |
date_from | date or null | Beginning of schedule range |
date_to | date or null | End of schedule range |
num_games | integer | Maximum games requested |
locale | string or null | Display locale |
Observable normalized sports schedule shape
{
"ref_id": "turn152657sports0",
"result_type": "sports_schedule",
"sport": "baseball",
"league": {
"code": "mlb",
"name": "Major League Baseball"
},
"query": {
"team": "NYY",
"opponent": null,
"date_from": "2026-07-20",
"date_to": "2026-07-30",
"num_games": 10,
"locale": "en-US"
},
"display_timezone": {
"name": "America/Los_Angeles",
"abbreviation": "PDT",
"utc_offset": "-07:00"
},
"events": [
{
"event_id": null,
"start_time": "2026-07-20T16:05:00-07:00",
"start_time_display": "Monday, Jul 20, 2026 at 04:05 PM PDT",
"status": "final",
"status_detail": null,
"away_team": {
"id": null,
"name": "Pittsburgh Pirates",
"short_name": "Pirates",
"abbreviation": "PIT",
"score": 5,
"record": null,
"logo_url": null
},
"home_team": {
"id": null,
"name": "New York Yankees",
"short_name": "Yankees",
"abbreviation": "NYY",
"score": 8,
"record": null,
"logo_url": null
},
"winner": "home",
"venue": {
"name": null,
"city": null,
"region": null,
"country": null
},
"broadcasts": [],
"period": null,
"inning": null,
"clock": null,
"series": null,
"postponed": false,
"canceled": false
},
{
"event_id": null,
"start_time": "2026-07-26T16:20:00-07:00",
"start_time_display": "Sunday, Jul 26, 2026 at 04:20 PM PDT",
"status": "scheduled",
"status_detail": null,
"away_team": {
"id": null,
"name": "New York Yankees",
"short_name": "Yankees",
"abbreviation": "NYY",
"score": null,
"record": null,
"logo_url": null
},
"home_team": {
"id": null,
"name": "Philadelphia Phillies",
"short_name": "Phillies",
"abbreviation": "PHI",
"score": null,
"record": null,
"logo_url": null
},
"winner": null,
"venue": {
"name": null,
"city": null,
"region": null,
"country": null
},
"broadcasts": [],
"period": null,
"inning": null,
"clock": null,
"series": null,
"postponed": false,
"canceled": false
}
],
"provider": {
"name": null,
"last_updated": null
}
}What was actually observed in the rendered schedule
For each event:
{
"away_team_short_name": "Pirates",
"away_team_abbreviation": "PIT",
"home_team_short_name": "Yankees",
"home_team_abbreviation": "NYY",
"date": "2026-07-20",
"time": "04:05 PM",
"timezone_abbreviation": "PDT",
"status": "final",
"away_score": 5,
"home_score": 8
}For an upcoming event:
{
"away_team_short_name": "Yankees",
"away_team_abbreviation": null,
"home_team_short_name": "Phillies",
"home_team_abbreviation": null,
"date": "2026-07-26",
"time": "04:20 PM",
"timezone_abbreviation": "PDT",
"status": "scheduled",
"away_score": null,
"home_score": null
}The missing abbreviations in that second normalized example reflect that the rendered text did not include them for every future event. The underlying provider may know them, but I should not state that they were returned.
Fields not observed in the textual result
- Stable league event ID
- Team IDs
- Venue
- Broadcast networks
- Betting lines
- Probable pitchers
- Attendance
- Weather
- Box score
- Play-by-play
- Game clock
- Inning or period
- Postponement reason
- Ticket links
- Team logos
- Provider identity
Some may appear in a UI widget, but they were not included in the textual result I inspected.
9. Sports standings result
This was not explicitly required in your second list, but it is the other sports-card family and clarifies the structure.
Known request shape
{
"tool": "sports",
"fn": "standings",
"league": "mlb"
}Observable normalized standings shape
{
"ref_id": "turn960878sports0",
"result_type": "sports_standings",
"sport": "baseball",
"league": {
"code": "mlb",
"name": "Major League Baseball"
},
"conferences": [
{
"name": "American League",
"divisions": [
{
"name": "East",
"teams": [
{
"rank": 1,
"name": "Tampa Bay Rays",
"abbreviation": null,
"wins": 61,
"losses": 43,
"ties": null,
"win_percentage": 0.5865,
"games_behind": null,
"streak": null,
"home_record": null,
"away_record": null
},
{
"rank": 2,
"name": "New York Yankees",
"abbreviation": null,
"wins": 59,
"losses": 45,
"ties": null,
"win_percentage": 0.5673,
"games_behind": null,
"streak": null,
"home_record": null,
"away_record": null
}
]
}
]
}
],
"provider": {
"name": null,
"last_updated": null
}
}Only team name, wins, losses, conference, division, and ordering were directly visible. Rank and winning percentage can be derived.
10. Combined field matrix
| Field | Web | News | Image | Finance | Sports |
|---|---|---|---|---|---|
| Internal reference ID | Yes | Yes | Yes | Yes | Yes |
| Result-family type | Yes/inferred | Yes/inferred | Yes/inferred | Yes/inferred | Yes/inferred |
| Title | Yes | Yes | Yes | Instrument name | Event/team data |
| Destination URL | Yes | Yes | Source-page URL | No visible source URL | No visible source URL |
| Snippet or summary | Yes | Yes | Sometimes | Generated textual rendering | Generated textual rendering |
| Publication date | Sometimes | Usually | Sometimes | Trade timestamp | Event date/time |
| Crawl date | Sometimes | Rarely shown | Rarely shown | No | No |
| Word limit | Yes | Yes | Not consistently visible | No | No |
| Publisher/domain | Inferable | Usually inferable | Inferable | Market/instrument instead | League/team instead |
| Author | No dedicated field | Not normally | Sometimes in source text | Not applicable | Not applicable |
| Image preview | Occasionally | Sometimes | Yes | Chart possible | Logos/widget possible |
| Numeric factual fields | Rare | Rare | Rare | Extensive | Scores/records |
| Result relevance score | No | No | No | No | No |
| PageRank/authority | No | No | No | No | No |
| Raw JSON-LD | No | No | No | Not applicable | Not applicable |
| Raw provider payload | No | No | No | No | No |
| Provider identity | Usually no | Usually no | Usually no | No | No |
| Stable external entity ID | No | No | No | Ticker only | No visible ID |
11. A rigorous unified envelope for all card types
Were you building your own search-and-research system, I would use a common envelope around every result:
{
"result_id": "res_01J9ZKFHAT5V4WT5XJ2Z5P8YK7",
"ref_id": "turn260213search0",
"result_type": "web",
"schema_version": "1.0",
"discovery": {
"query_id": "query_01J9ZKF4XV7NNYGCYAQ0655GTG",
"query": "consumer use of large language models",
"provider": "unknown",
"provider_result_id": null,
"result_position": 0,
"retrieved_at": "2026-07-26T12:00:00Z",
"request_parameters": {
"recency_days": 30,
"domains": []
}
},
"source": {
"title": "Consumer Uses of Generative AI",
"url": "https://example.com/report",
"domain": "example.com",
"content_type": "text/html",
"language": "en",
"publisher": null,
"authors": [],
"published_at": null,
"modified_at": null
},
"presentation": {
"snippet": "A nationally representative survey...",
"summary": null,
"thumbnail_url": null,
"rendered_media": false
},
"provider_metadata": {
"word_limit": 200,
"relevance_score": null,
"authority_score": null,
"freshness_score": null
},
"raw": {
"available": false,
"payload": null
},
"research": {
"opened": false,
"opening_status": null,
"relevance": null,
"source_quality": null,
"primary_source": null,
"used": false,
"cited": false,
"exclusion_reasons": []
}
}Each specialized type would add a data object.
Finance extension
{
"data": {
"instrument": {},
"quote": {},
"fundamentals": {},
"history": {}
}
}Sports extension
{
"data": {
"league": {},
"events": []
}
}Image extension
{
"data": {
"image": {},
"visual_description": null,
"rights": {}
}
}News extension
{
"data": {
"article": {},
"publisher": {},
"syndication": {}
}
}12. The hard limit on “all internal fields”
I cannot provide a genuine internal OpenAI backend object with every private field because:
- I do not receive the raw backend transport payload.
- The visible tool response may already be transformed.
- The model-facing representation may differ from the UI-facing representation.
- Different upstream providers may have different schemas.
- The same result type may be delivered differently across ChatGPT, the Responses API, mobile widgets, Enterprise Search, and specialized providers.
- OpenAI does not publicly document full internal schemas for finance, sports, news, or image cards.
- Some widget data may be passed directly to the client interface rather than included in textual model context.
OpenAI’s documentation confirms that search can involve third-party providers and that structured prompt information may be shared with providers to return weather, sports, finance, calculations, and other specialized r(OpenAI Help Center)field-level internal responses from those providers.
The most precise conclusion is:
The public web-search API has a thin, documented URL-source schema. The internal research interface exposes richer rendered result objects. Specialized finance, sports, image, and news cards clearly contain additional structured information, but their raw, complete internal JSON schemas are not exposed to me. The JSON abov separates directly observed fields from fields that are merely derived, proposed, or unknown.