PRIVACY · 10 MIN READ
What is actually inside an Aurora diagnostic report
Session details (transcript, chat, summary and images) start attached; the recording has its own switch, and it starts off. What each switch attaches, and what is really in the package.
Published · Updated
Does an Aurora diagnostic report send my transcript or recording?
From a session, the transcript goes by default and the recording only if you turn it on. A report leaves the device only when you submit it. As of October 2026, the session-details switch starts on and attaches the session's title, transcript, summary, Ask Aurora chat and images, including an automatic screenshot. The recording switch starts off. Every report also carries the description you type, app and device details, technical logs and diagnostics. For a technical report only, turn session details off before sending; a transcript bug cannot be diagnosed from timing data alone.
A bug report should not become a data leak. That sentence is the design constraint for the whole of Aurora's diagnostics system, and this article is the receipt: what the report form actually attaches, in which state it opens, and what is in the package it builds.
Read this first. The report form has two content switches. "Include session details in report" starts on, and from inside a session it attaches that session's title, transcript, summary, Ask Aurora chat and images, including an automatic screenshot. "Include the recording" is a separate switch and starts off: the audio goes only if you turn it on. The description you type is always sent. Sending is always your action; leaving session details attached is the part that happens by default. Aurora's product contract still calls reports content-free by default, with transcript and audio needing explicit selection. For the audio that is now true of the build; for the rest of the session it is still not.
What is an Aurora diagnostic report for?
An Aurora diagnostic report exists so that a failure you experienced can be understood by someone who was not there. When transcription stops mid-recording, when a speaker is split into three, or when the app becomes hot and slow, the useful evidence is the state of the machine at the moment it went wrong, not the conversation you were having.
Aurora creates diagnostic information locally, continuously, as part of running. That information stays on the device. A report is assembled and transmitted only when you explicitly choose to submit one. Collection and transmission are separate events, and only the second one involves us.
What is switched on when the form opens?
Two switches govern content, and they do not start in the same place. The first, "Include session details in report", is on every form: a report from a session, one started from Settings, and one that begins at a crash prompt. The second, "Include the recording", appears only on a session report whose audio is still on the device, and it can be on only while session details is on. In Aurora's source the consent type maps the first switch to the report tier and attaches audio only when both say yes, so the recording cannot ride along on the first switch.
The session-details switch starts on, on every form. The consent type declares the flag as off, and then the draft the form opens constructs it as on, so the tested default of the shipping form is the full tier, not the safe one. We would rather publish that than describe a default the app does not have. The decision the form puts in front of you is therefore "shall I leave my transcript attached", and turning it off is one tap. The recording switch is the other way round: it starts off, and leaving the audio behind takes no action at all.
The form does not show tiers. It shows a caption under each switch saying what will be sent. With session details off: "Sends your description, app and device details, technical logs, and diagnostics. No transcript, chat, summary, notes, or images." On, from a session: "Sends your description, app and device details, technical logs, and diagnostics, plus this session's title, transcript, summary, Ask Aurora chat, and any images below." Under the recording switch: "Attaches this session's audio recording." or "The recording stays on this device."
A report you start without a session attached (from Settings rather than from a recording) never carries a transcript, a chat, a note or a recording, whatever the switches say, and its caption says so: "plus any images below. No transcript, chat, or summary." What session details can still attach there is images, and a report that begins at a crash prompt has no automatic screenshot. Once a recording's audio has been removed from the device (Aurora deletes it after seven days), the recording switch is not shown at all, because there is nothing left to attach.
What does a standard diagnostic report contain?
A standard report contains machine state and event metadata. Every field below describes the device or the software's behavior; none of them carries what was said.
| Category | Examples |
|---|---|
| Device and OS | Model identifier, OS version, available memory, thermal state, Low Power Mode |
| App build | Version, build number, configuration, which model tier was selected |
| Session shape | Duration, number of detected speakers, sample rate, whether the app was backgrounded |
| Pipeline events | Model load and unload timings, recognizer state transitions, queue depth, dropped-buffer counts |
| Errors | Error codes, failure reasons, stack traces from Aurora's own frames |
| Performance | Throughput multiples, latency percentiles, memory high-water marks |
The distinction that matters is between metadata about a recording and the recording. "A 47-minute session detected three speakers and dropped 12 audio buffers at minute 31" is a diagnosis. The audio from minute 31 is a conversation. A standard report carries the first and not the second.
Every report, standard or full, also carries the description you type. It is not optional: the form will not send without one.
What does a standard report exclude?
A standard Aurora report omits every category of conversation content:
- Recorded audio. No samples, no clips, no waveform data from which speech could be reconstructed.
- Transcripts. Neither the live transcript nor the refined one.
- Notes. Anything you typed against a session.
- Generated content. Summaries and action items produced by the on-device models.
- The Ask Aurora chat. The questions you asked about the session and the answers it gave.
- Speaker names. Any name the on-device model read out of the conversation, stored with that session.
- Images. Neither the automatic screenshot nor any image you added.
Session titles are treated as content, because people name meetings after what the meeting is about. A report identifies a session by an opaque identifier rather than by the name you gave it.
Sending is your decision every time. Leaving your transcript attached is the one part that happens unless you act.
What Aurora's report form actually doesWhat does a full report add, and when?
A full report carries selected conversation content, and it exists because some bugs are genuinely unreproducible without the input that triggered them. A transcript that changed the meaning of a sentence cannot be diagnosed from timing data alone.
What it adds, from a session, is the session's title, its transcript and summary, its Ask Aurora chat, and the images on the form. The images are an automatic screenshot of Aurora's own window, not the whole screen, taken when the form opens, plus any you add from the photo picker on iPhone or as image files on a Mac, up to six in total. Added images can be removed. Every image is re-encoded on the device as a compressed JPEG no larger than 1,600 pixels on its longest side, and its metadata (location, camera, date) is not copied; the form's footer says "Up to 6 images. Added photos are sent without location or camera details." Session notes are never attached. The recording is added only if you also turn on its own switch.
That split is a deliberate trade. Session details is one switch whose caption names everything it attaches, rather than four controls of which you only notice three; the recording, the most sensitive thing a report can carry, gets a separate yes of its own. The cost of that design is that the first switch's default state matters a great deal, and today that state is on.
What is actually in the package?
A report is a .auroradiag archive, schema-validated before it is
encrypted. Its members are a published contract rather than a mystery:
report.json: the typed report envelope, currently schema version 2: the manifest, the diagnostic timeline of events, the MetricKit payloads, and the optional content section.logs.txt: the scrubbed, size-bounded diagnostic log.- Environment, model and recent-outcome evidence: the device's recent environment history, which models are present and verified, and how recent sessions ended.
screenshot-1.jpg…screenshot-N.jpg: only with session details on: the automatic screenshot first, then the images you added, six at most.<session id>.m4a: the recording, only for a session report with the recording switch on, and only while that audio is still on the device.diagnostic-timeline.json: only for a full session report. Bounded voice-activity, diarization, activity, timing and confidence values. The contract forbids it from carrying recognized text, raw speaker embeddings, filesystem paths, credentials, device or account identifiers, or a session identifier of its own.
We are not printing an example payload here. Publishing a plausible-looking one would be an illustration pretending to be evidence; the member list and the field contract above are what the code actually guarantees, and they are the part you can hold us to.
Can I read the report before it is sent?
Not as a file, today. The report flow has no Share, Files or Save control, so the package it builds is not something you can open, archive or inspect yourself; it is created for the delivery you started and deleted when that delivery finishes or you discard it. What you do get before sending is the form telling you, in words, what the switches currently include, and the images themselves, shown on the form. After a successful send it says "Thank you for your feedback." and shows no ticket number.
That is weaker than we would like, and we would rather say so than imply an inspection surface that does not exist. The contract above is published in the app's own documentation, and the consent behavior described in this article was read out of the shipping source, so disagreeing with us is still possible, just with the code rather than with a file on your phone.
Does any of this happen without me?
No diagnostic report leaves the device unless you submit it. After a crash Aurora may ask once whether to send what it collected, and declining sends nothing. At start the app may fetch the report service's delivery settings (where a report goes and which key encrypts it), and that request carries nothing about you. Aurora's other network paths are few, and the Privacy Notice lists each one with its default. None of them sends a recording, and conversation sync, which carries transcript text, is off until you turn it on and goes to your own iCloud.
Aurora does not claim that nothing ever leaves your device, because that claim would be false. You can export a transcript, and you can send a report. What Aurora claims is narrower and true: conversation content is not uploaded for transcription, and the paths that could move it are ones you open, while being honest that on the report form, one of those paths opens with content already attached.
Related
- Privacy Notice: diagnostic reports: the same two switches, every tier, and how long a report is kept.
- Privacy Notice: what can leave, and why: the complete list of network paths, with defaults.
- What happens to your audio after you press record: where the recording lives before any of this.
- FAQ: are my recordings uploaded for transcription?
