Exporting and Sharing Flight Log Analysis with LogHat

TL;DR: LogHat’s export and share surface gives you three outputs from every analysed flight: a downloadable forensic PDF, a structured JSON bundle (vector_analysis.json, flight_metadata.json, report_digest.json), and a private share URL with optional access controls. The PDF is for human review; the JSON is for integration into your own dashboards or maintenance-ticket system; the share URL is for handing a single flight to an insurer, a regulator, or a teammate without giving them dashboard access.

What you get after every upload

When a log finishes processing through the LogHat pipeline (typically under a minute for a 20-minute flight), you can access:

• The forensic PDF. A multi-section report covering flight envelope, mode timeline, root-cause hypotheses, parameter snapshot at takeoff, and AI-generated narrative. Designed to be printable and to stand on its own without account access.
• The 3D replay. Interactive in-browser flight visualisation with telemetry overlay. Scrub to any timestamp, see the failure happen, read the sensor traces at that moment.
• The JSON artifacts. Structured machine-readable outputs of the analysis. Used to feed your own automation.
• The share URL. A private link that gives anyone read-only access to the report and 3D replay without needing a LogHat account.

What’s in the forensic PDF

The PDF is broken into sections so a human reader can find what matters quickly:

• Executive summary — the verdict in one paragraph.
• Flight envelope — duration, distance, peak altitude, peak velocity, total motor energy.
• Mode timeline — every MODE transition with its reason.
• Failsafes and errors — every ERR Subsys/ECode entry decoded with the human-readable subsystem and code names.
• Root cause hypotheses — the AI’s ranked causes with the supporting log evidence per hypothesis.
• Parameter snapshot — the values at takeoff for the parameters most likely to be relevant (FS_*, EK3_*, BATT_*, FRAME_*, SERVO*_FUNCTION).
• Telemetry plots — key time series for vibration, altitude tracking, battery voltage, rate-loop response.
• Annexure — detailed sensor health and EKF status traces for deeper review.

The JSON artifacts

Three structured files for integration:

• vector_analysis.json — the event timeline. Every detected event (failsafe, mode change, anomaly) as a timestamped record with severity and supporting fields.
• flight_metadata.json — the flight envelope summary. Duration, distances, peak values, parameter snapshot, vehicle identity.
• report_digest.json — the text-form digest the Vector AI uses for chat-based follow-up. Smaller than the PDF, designed for downstream LLM consumption.

These files are the contract for anyone integrating LogHat into a fleet management system. The PDF and 3D replay surfaces are built on top of them.

The share URL flow

Every completed analysis can have an autoshare URL generated automatically (set share_enabled = true in the ticket). The URL serves the report PDF and 3D replay without requiring login. Access controls:

• Default: URL is private until share_enabled is flipped. You don’t accidentally share by default.
• Optional expiry: Time-bound share URLs for insurance claims that close after a window.
• Optional password: For sensitive flights, an optional access password gates the URL.

The share URL is the right surface for handing a single flight to a regulator, an insurance assessor, or a maintenance partner without giving them broader access. They click, see the report, no account creation required.

Common team patterns

1. Per-flight maintenance review. Operator uploads the .bin after every flight. LogHat’s analysis writes the JSON artifacts to a fleet bucket. The fleet’s automation reads vector_analysis.json, identifies any maintenance triggers per the per-airframe preventive workflow, and opens tickets in the team’s ticketing system.
2. Insurance claim packet. Operator pulls the forensic PDF and the share URL for the relevant flight, packages them with the incident narrative, sends to the assessor. The PDF stands as the technical record; the share URL gives the assessor interactive access if they need to drill deeper.
3. Cross-team incident review. A maintenance engineer reads the PDF; a flight ops manager reviews the 3D replay; a fleet director gets the executive summary. The same analysis serves three audiences without anyone having to extract the right view manually.
4. Long-term trend analysis. Per-flight flight_metadata.json records build into a time series across the fleet. Track VIBE trends, hover-throttle drift, battery resistance, and tuning quality over months without re-analysing each log.

Data residency for Indian operators

LogHat’s storage backend runs in the AzureIndia region. Uploaded logs, generated PDFs, and JSON artifacts stay in country — relevant for operators with data-residency obligations under the DPDP Act 2023 or contract terms with Indian customers. The 7-year retention path for DGCA compliance — see our DGCA retention post — combines the LogHat artefacts with the NPNT permission artefacts handled separately by your autopilot stack and Digital Sky integration.

What we don’t export

• Raw video. The PDF and JSON describe the flight; video feeds (if any were captured) live in your video storage, not in LogHat.
• Original raw log. The .bin remains in your Azure Blob storage and can be re-downloaded; we don’t republish it in the share URL.
• Pilot personally-identifying information beyond what you uploaded. If the .bin doesn’t carry pilot identity, the share URL doesn’t either.

When LogHat helps — and when it doesn’t

For analytics, forensic reports, structured event timelines, and team-shareable flight summaries, this is the surface. For raw log storage at scale (the seven-year retention archive), we recommend a dedicated long-term storage tier alongside LogHat — the analytics layer and the archival layer benefit from being separately managed.