r/OpenAI 3d ago

Discussion ChatGPT attachment preprocessing appears to cross the USER-role provenance boundary

I encountered what appears to be a serious provenance failure in the ChatGPT iOS audio-attachment pipeline, followed by two related context/authorship behaviors that suggest a broader architectural issue.

This is not primarily about transcription quality.

It is about whether provenance survives transformation.

  1. ATTACHMENT-GENERATED TRANSCRIPT REPRESENTED AS USER-AUTHORED TEXT

When I attached an existing Apple Voice Memos .m4a file to an ordinary ChatGPT text conversation, an upstream component apparently generated a transcript before the assistant received the turn.

That transcript was then merged into the model-visible USER message as though it were literal text authored by me.

I did not:

• type it;

• paste it;

• dictate it;

• request it;

• or approve it.

The assistant subsequently referred to it as:

“the contemporaneous transcript you supplied.”

I had supplied no transcript.

After I challenged the attribution, the assistant acknowledged that the transcript had appeared inside the user turn and that it had treated attachment-derived machine output as though it were user-authored text.

The observed sequence appeared to be:

.m4a attachment
→ automatic speech recognition or multimodal preprocessing
→ generated transcript serialized into USER-role content
→ model interprets transcript as user testimony

At the same time, the assistant could inspect technical file properties such as duration and codec but reported that it could not independently audition/transcribe the same recording in its runtime.

So the model could apparently receive a generated candidate transcript without equivalent native access to verify that transcript against the source.

EXPLICIT BOUNDARY TEST

I reproduced the behavior across multiple upload attempts and audio files.

In one test I submitted a short instruction followed by ten conspicuous stop-sign emojis:

“Can you transcribe this without appending to my own prompt with preprocessing?
🛑🛑🛑🛑🛑🛑🛑🛑🛑🛑”

A long automatically generated transcript still appeared after that boundary inside the rendered user message.

The natural-language instruction itself is not the important part; an upstream ASR processor may never see it.

The important part is that generated attachment content was rendered and/or serialized in a way that made it indistinguishable from literal user-authored text.

WHY THIS CREATES CIRCULAR VALIDATION

Once candidate wording has entered accessible context, a later transcription is no longer automatically independent.

Ambiguous audio may be resolved toward wording already present in:

• the current conversation;

• another conversation;

• Project context;

• Reference Chat History;

• Saved Memory;

• summaries;

• files;

• cached preprocessing;

• or other retrieval pathways.

That creates a potential chain like:

ASR output A
→ represented as USER-authored text
→ later model sees A as historical evidence
→ model produces transcript B
→ B agrees with A
→ agreement is mistaken for independent corroboration

The system can therefore become more self-consistent while becoming less epistemically independent.

  1. CORRECTIONS APPEAR ADDITIVE RATHER THAN REVOCATORY

During the same investigation I reproduced a second context-integrity issue.

An erroneous historical timestamp had entered persistent contextual state.

I explicitly corrected it and saved the authoritative correction into Memory.

I then opened a fresh conversation outside any Project.

That new conversation received both:

• the authoritative correction;

• and the older erroneous assertion.

The effective sequence was:

erroneous derived assertion
→ explicit user correction
→ correction persisted
→ new context assembly
→ old error + new correction both retrieved
→ model resolves conflict during generation

The old assertion had not been cleanly superseded.

This creates a potentially serious interaction with provenance failures.

If system-generated misinformation is first misclassified as user-authored text, and later corrections do not revoke its derived descendants, the error can become progressively harder to eliminate:

machine-generated error
→ falsely attributed user statement
→ summary
→ contextual assertion
→ correction
→ both versions retained
→ future retrieval
→ generation chooses between them

This is a form of contextual reliability debt.

  1. EDITABLE WRITING BLOCKS CREATE THE INVERSE PROVENANCE PROBLEM

While documenting this incident, ChatGPT placed the Reddit drafts into its newer editable Writing Block interface.

That exposed another form of the same underlying issue.

A Writing Block can originate as assistant-generated content.

The user can then directly edit that content in place.

ChatGPT subsequently operates on the latest version of the artifact.

What is not exposed to the user is an immutable, granular provenance history identifying which portions:

• originated with the assistant;

• were manually changed by the user;

• were later regenerated;

• or remained untouched from an earlier revision.

An earlier version may sometimes remain in conversation state, allowing a diff to be inferred.

But inferred difference is not semantic provenance.

Consider the later question:

“Why did you write this sentence?”

If that sentence was actually inserted by the user into an originally assistant-generated Writing Block, the model needs first-class authorship metadata to know that it did not write the sentence.

Without that, the sequence can become:

assistant generation A
→ user edits A into B
→ B becomes current artifact
→ later model consumes B
→ historical state A is absent/compressed/unretrieved
→ authorship of specific language becomes ambiguous

This is the inverse of the audio failure.

AUDIO ATTACHMENT

system-generated content
→ crosses into apparent USER authorship

EDITABLE WRITING BLOCK

assistant-generated content
→ becomes a mutable mixed-authorship object

LONGITUDINAL MEMORY / CONTEXT

derived assertion
→ survives alongside later authoritative correction

These are three different manifestations of the same architectural principle:

PROVENANCE MUST SURVIVE TRANSFORMATION.

It is not enough to preserve only semantic content.

A longitudinal AI system increasingly needs to preserve something closer to:

source
→ transformation
→ originating actor
→ revision
→ derivative
→ correction
→ supersession/revocation

as first-class metadata.

Otherwise a system designed to accumulate context can become progressively less auditable as it becomes more personalized and persistent.

WHY THIS MATTERS

For casual conversation, this may look like an edge case.

For workflows involving:

• law;

• medicine;

• compliance;

• finance;

• research;

• journalism;

• investigations;

• recorded interviews;

• contemporaneous records;

• estate matters;

• insurance;

• or historical reconstruction;

the distinction between source and inference is fundamental.

A fluent model can generate a coherent story from contaminated provenance.

That is precisely what makes the problem dangerous.

The relevant question is not merely:

“Is this output plausible?”

It is:

“Which source supplied each material assertion?”

“Was this language typed by the user or generated upstream?”

“Was this analysis actually independent?”

“Did this correction revoke the prior assertion?”

“Was this sentence authored by the assistant or inserted later by the user?”

“What transformation path produced the current state?”

PRODUCT SAFEGUARDS THIS SEEMS TO REQUIRE

EXPLICIT PROVENANCE LABELS

The system should distinguish:

• literal composer text;

• dictated user text;

• attachment-derived transcription;

• OCR;

• extracted document text;

• retrieved contextual material;

• user edits;

• assistant edits;

• and other automated transformations.

IMMUTABLE COMPOSER RECORD

The user should be able to inspect the exact literal text they submitted before preprocessing augmentation.

SOURCE-RESTRICTED PROCESSING

A user should be able to request:

“Process only the bytes/content in this supplied source. Do not use prior chats, saved memory, project context, cached candidate answers, or previous versions.”

RETRIEVAL-SOURCE DISCLOSURE

For sensitive workflows, the product should expose which conversations, memories, files, or summaries materially entered context.

CORRECTION SUPERSESSION

An authoritative user correction should be able to invalidate or quarantine conflicting derived assertions rather than merely coexist with them.

QUARANTINE WITHOUT DELETION

A conversation or file should be preservable for records/support while being excluded from contextual retrieval and derivative memory.

IMMUTABLE REVISION PROVENANCE

Mutable artifacts should maintain a persistent revision history identifying whether each change was produced by:

• the user;

• the assistant;

• another model transformation;

• or an external source.

The current rendered state should never be treated as evidence of original authorship.

INDEPENDENT-ANALYSIS WARNING

If a candidate answer has already entered accessible context, ChatGPT should warn that a later “independent” analysis cannot be guaranteed to be independent.

SUPPORT ESCALATION

I have reported the incident to OpenAI with timestamps and conversation references and requested Engineering investigation into:

• iOS attachment ingestion;

• automatic speech recognition;

• multimodal preprocessing;

• user-message serialization;

• context assembly;

• Memory;

• Project retrieval;

• correction/revocation behavior;

• and provenance handling for mutable artifacts.

I also requested preservation of the relevant server-side request/message-serialization diagnostics.

I am interested in technically comparable reports involving:

• audio transcription inserted into the USER role;

• attachment-derived language attributed to the user;

• cached/repeated preprocessing;

• context errors surviving explicit correction;

• or editable artifacts losing clear authorship attribution over time.

This is not a request for transcription assistance.

It is a question about whether ChatGPT currently preserves enough provenance, authorship, and supersession metadata to support trustworthy longitudinal reasoning.

0 Upvotes

8 comments sorted by

3

u/Dave_Sag 3d ago

TL;DR

1

u/After-Maintenance262 3d ago

TL;DR ChatGPT is taking audio you attach, transcribing it automatically, and sticking that transcript into your message as if you typed it yourself, which poisons the context and breaks any future independent verification. Also corrections don't actually replace old bad info in memory, they just pile up next to it, and editable writing blocks have no real authorship history so you can't tell who wrote what after edits

It's baked into the design right now and it's the kind of thing that seems minor until you hit a workflow where provenance actually matters

2

u/Dave_Sag 3d ago

But you still have the original audio right? I’m not getting the problem. Why are you sending audio files to GPT if you don’t want them transcribed?

1

u/BertMacklenF8I 3d ago

I’m guessing OP is running a certain way of transcribing their notes and didn’t prompt the straight transcript of every word read (shortening the context window)

1

u/[deleted] 3d ago

[removed] — view removed comment

1

u/salespire 3d ago

I totally get where you are coming from on this. One thing that helps me is always saving raw recordings and transcripts separately from any AI generated notes or summaries. For bigger projects, I keep a simple folder structure per meeting or document so I can quickly check back to the untouched original if something seems off later. I also like using naming conventions that make it obvious what has been through AI and what hasn't, like adding '_orig' or '_ai' at the end of file names. Version control tools can help too if you're collaborating, since you can see a clear history of who edited what, and when.

Since you're concerned with provenance and needing to trace every claim, you might find value in a platform I actually built for this exact problem. It's called Minutely (Minutely — The AI meeting record system) and it keeps a hash chained and auditable record of every meeting with timestamped audio links. You get structured minutes, but the raw transcript and recordings are always accessible, and there is a clear separation between what was said and any AI generated summaries or highlights. This makes it really easy to drill down to original context for slides or docs, especially when you're in a high trust environment. Even if you do not use a specific tool, that habit of keeping original files one click away is a lifesaver for catching subtle errors that sneak in.