# Undocumented Fields in ChatGPT Data Exports: What Are `rebase_system_message` and `is_visually_hidden_from_conversation`? from Claude

## Disclaimer
This document presents observations from a GDPR/DSAR data export received from OpenAI. **No official documentation exists for the fields discussed here.** All interpretations are hypotheses based on structural analysis of the JSON data. The author welcomes corrections or clarifications from OpenAI or knowledgeable community members.
---
## Background
Under GDPR Article 15, EU residents can request a copy of their personal data. OpenAI provides this as a JSON export containing conversation histories. Upon analyzing this export, several undocumented fields were discovered that do not appear in OpenAI's public API documentation.
---
## The Undocumented Fields
### 1. `rebase_system_message`
**Observed in:** Message metadata
**Value:** Boolean (`true`)
**Official documentation:** None found
### 2. `rebase_developer_message`
**Observed in:** Message metadata
**Value:** Boolean (`true`)
**Official documentation:** None found
### 3. `is_visually_hidden_from_conversation`
**Observed in:** Message metadata
**Value:** Boolean (`true`)
**Official documentation:** None found
---
## Observed Pattern
In the exported conversation data, a consistent pattern appears:
```
Step 1: User sends message
→ author.role: "user"
Step 2: System message inserted (HIDDEN)
→ author.role: "system"
→ rebase_system_message: true
→ is_visually_hidden_from_conversation: true
→ content: "" (empty)
Step 3: Developer message inserted (HIDDEN)
→ author.role: "system"
→ rebase_developer_message: true
→ is_visually_hidden_from_conversation: true
→ content: "" (empty)
Step 4: Visible response appears
→ author.role: "assistant" or "tool"
```
---
## Raw JSON Example
The following is extracted from an actual DSAR export (UUIDs preserved, personal content removed):
```json
{
"id": "09d52f6a-ba21-42f5-b2ee-9c7c3b4c9f2b",
"message": {
"author": {"role": "user"},
"content": {"content_type": "text", "parts": ["[user message]"]},
"status": "finished_successfully"
}
}
```
Immediately followed by:
```json
{
"id": "973a96fc-f2a2-4f36-bd3d-726a0e7e28de",
"message": {
"author": {"role": "system"},
"content": {"content_type": "text", "parts": [""]},
"status": "finished_successfully",
"metadata": {
"rebase_system_message": true,
"model_slug": "o3-mini",
"is_visually_hidden_from_conversation": true
}
}
}
```
Then:
```json
{
"id": "497ef276-a55c-4826-bc1f-4afb78dae056",
"message": {
"author": {"role": "system"},
"content": {"content_type": "text", "parts": [""]},
"status": "finished_successfully",
"metadata": {
"rebase_developer_message": true,
"model_slug": "o3-mini",
"is_visually_hidden_from_conversation": true
}
}
}
```
Only after these hidden messages does the visible assistant response appear.
---
## Additional Observed Fields
### `augmented_paragen_prompt_label`
**Example value:** `"Uses a list"`
**Possible interpretation:** Internal classification of prompt/response type for analytics or routing purposes.
### `sonic_classification_result`
**Observed values include:**
- `simple_search_prob`
- `complex_search_prob`
- `no_search_prob`
- `search_decision`
- `classifier_config_name`
**Possible interpretation:** Internal classifier determining whether to trigger web search functionality.
### Tool responses with unusual `author.name`
**Example:** `"author": {"role": "tool", "name": "a8km123"}`
**Observation:** Some responses come from `role: "tool"` with alphanumeric names rather than `role: "assistant"`.
---
## Open Questions
Given the absence of official documentation, the following questions remain unanswered:
1. **What triggers a "rebase"?**
Does this occur on every message, or only under specific conditions (topic, length, safety flags)?
2. **What is the functional difference between `rebase_system_message` and `rebase_developer_message`?**
The naming suggests different authority levels, but both appear with empty content.
3. **Why are these messages hidden?**
The `is_visually_hidden_from_conversation: true` flag explicitly marks them as not shown to users. What do they contain in their non-empty form?
4. **What is the relationship to model switching?**
In some cases, the `model_slug` changes between the user message and the response (e.g., from `gpt-4o` to `o3-mini`). Do rebase messages facilitate this?
5. **Are these related to safety interventions?**
The term "rebase" in software typically means changing the base of something. Does this "rebase" the conversation context for safety or policy reasons?
---
## Possible Hypotheses
### Hypothesis A: Context Window Management
The rebase messages could be a mechanism for managing context windows in long conversations, inserting updated system prompts or summarized context.
### Hypothesis B: Dynamic System Prompt Injection
OpenAI may dynamically inject or modify system prompts based on conversation content, user profile, or detected topics.
### Hypothesis C: Safety Layer Intervention
The messages could represent points where safety systems evaluate and potentially modify the conversation flow before generating a response.
### Hypothesis D: Model Routing Infrastructure
The empty messages with different `model_slug` values might be artifacts of internal routing between different model versions or specialized sub-models.
---
## What This Is NOT Claiming
This document does NOT claim:
- ❌ That OpenAI is "censoring" conversations
- ❌ That these mechanisms are malicious
- ❌ That the observed behavior is abnormal or unintended
- ❌ That we know what these fields definitively mean
This document DOES observe:
- ✓ These fields exist in user data exports
- ✓ They are not publicly documented
- ✓ They show a consistent pattern of hidden system messages
- ✓ Their purpose is unclear without official explanation
---
## Methodology
- **Data source:** Personal GDPR/DSAR export from OpenAI (January 2026)
- **Search verification:** Web searches for these field names returned no results in OpenAI's official documentation, API reference, developer forums, or changelog
- **Comparison:** Standard API documentation describes `system`, `user`, `assistant`, and `developer` roles, but not the `rebase_*` mechanism
---
## Call for Information
If you have:
- Official documentation about these fields
- Technical knowledge of OpenAI's internal architecture
- Similar observations from your own data exports
Please contribute to the community's understanding of how these systems work.
---
## Document Information
- **Observation Date:** January 2026
- **Data Source:** GDPR Article 15 data export
- **Author:** pattern4bots.online
- **Status:** Preliminary observations, pending official clarification
---
*"The best questions are those that reveal what we don't yet know."*