# What is actually inside an Aurora diagnostic report > The one consent switch that governs what an Aurora diagnostic report carries, the state that switch opens in, what each state attaches, and the real members of the package. PRIVACY · 21 AUGUST 2026 · UPDATED 18 SEPTEMBER 2026 · 9 MIN READ One switch decides whether a report carries your transcript, chat, recording and screenshot — and on a session report it starts on. What each state attaches, and what is really in the package. Aurora engineering 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.** When you report a problem from inside a session, the form's one content switch — "Include session details in report" — **starts on**, and it attaches that session's transcript, its Ask Aurora chat, its recording and a screenshot. Sending is always your action; leaving that content attached is the part that happens by default. Aurora's product contract still calls reports content-free by default, and on this point the contract is wrong about the build. ## 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? One switch governs content. There is no second, quieter control: in Aurora's source the consent type maps a single flag to the report tier, and the audio and screenshot properties return that same flag, so transcript, chat, recording and screenshot cannot drift apart into contradictory settings. The form's own subtitle names all of them. That switch starts on for a session report. 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. 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 switch says, and the form says so in its own subtitle. Two things are still worth knowing about that case: the switch can still attach a screenshot of the screen you were on, and a report that begins at a crash prompt has no screenshot at all. Audio is gated twice more besides: the session must exist and it must actually have audio. ## 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. Standard report — categories included | 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. ## 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.** The labels you assigned manually. 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 does ## What 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 is the selected session's title and tags, its transcript and summary, its Ask Aurora chat, a screenshot of what was on screen, the description you type, and — when the session has audio — the recording itself. Those are not separate checkboxes. They ride the one switch together, which is a deliberate trade: a single honest control whose label names everything it attaches, rather than four controls of which you only notice three. The cost of that design is that the 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. - **`audio.m4a`** — only for a full session report, and only when that session has audio. - **`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, which attachments the switch is currently including. 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. Aurora's other network activity is limited and enumerable: the one-time model download, an aggregate setup-time estimate, a free-minutes counter in your own iCloud storage, an entitlement check when you open a subscription screen, optional iCloud settings sync and optional web research — both off until you turn them on — and a setup measurement you are asked about once. 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 1. [Privacy Notice: diagnostic reports](https://auroraisyours.com/privacy/#diagnostic-reports) — the same switch, every tier, and how long a report is kept. 2. [Privacy Notice: what can leave, and why](https://auroraisyours.com/privacy/#app-egress) — the complete list of network paths, with defaults. 3. [What happens to your audio after you press record](https://auroraisyours.com/blog/what-happens-to-your-audio) — where the recording lives before any of this. 4. [FAQ: are my recordings uploaded for transcription?](https://auroraisyours.com/#faq) ## More from the blog 5 Aug 2026 · Product · 6 min ## Why Aurora does not send a bot to your meeting https://auroraisyours.com/blog/no-meeting-bot 14 Jul 2026 · Engineering · 9 min ## What on-device transcription costs on an iPhone https://auroraisyours.com/blog/on-device-transcription-cost