Cross-File Correlation
One archive. One situation. Read together.
A bug rarely lives in one file. Drop the whole bundle (bugreports, kernel logs, CAN traces, configs, and reference databases) and logcat.ai correlates across all of them, reconciles one identity, and answers with a cited cross-file root cause.
One question, answered across the whole bundle
126 files, one situation. The investigation rules out the obvious causes, decodes the CAN trace through the bundle's own signal database, and lines up three files on one timeline to name a root cause none of them shows alone.
“Why does the TCU drop telematics every few hours on this build?”
TCU firmware state-machine bug
The telematics unit drops every few hours because of a firmware state-machine bug in the TCU — not WiFi, thermals, or memory. Decoding the CAN trace through the bundle's own signal database surfaced a recurring TCU_Status = FAULT (DTC U0155); each one lines up with a RACH timeout in the modem log and a TELEMATICS_STATE → DISCONNECTED transition in the vehicle HAL. No single file showed it — the answer only appears when the three are read on one timeline.
The archive decodes itself
Most bundles already carry their own key. A CAN signal database, a device-fingerprint table, a symbol map — logcat.ai matches each reference file to the siblings whose raw IDs it resolves, verified by value overlap, and turns opaque codes into named signals and devices.
One identity, findings rolled up
Before any question, the bundle is reduced to a single reconciled identity (each fact cited to the file it came from) and a roll-up that shows which findings recur across how many files.
TCU_Status = FAULT recurs in 3 of 126 files — the disconnect root cause, decoded from the CAN trace.
RACH timeout (T310 expired) in 2 files, time-aligned with every TCU fault.
TELEMATICS_STATE → DISCONNECTED logged at each fault window.
No driver crash or low-memory-killer events — rules out the WiFi and memory hypotheses.
Temperatures nominal across the capture — throttling ruled out.
One vehicle reconciled from 126 files; every fact cited back to its source file.
Charts the whole bundle makes
Auto-generated across files: the composition of the archive, and a roll-up where one file reading zero is itself the clue, every value traced back to a leaf.
Illustrative cross-file output · synthetic bundle
Why Multi-File Diagnostics Are Hard
The story lives in the relationships between files, not in any single log. Reading them one at a time is how cross-component bugs hide.
Fragmentation
A real capture is a hundred files in a dozen formats. Opening them one by one means never seeing how they line up.
Opaque identifiers
Logs are full of raw IDs (CAN arbitration codes, MAC addresses, symbol offsets) whose meaning lives in a separate reference file you cross-reference by hand.
Scattered identity
Which device? Which build? Which window? The answer is spread across a dozen files, each holding one piece.
Cross-file correlation
The fault shows in the CAN trace, the timeout in the modem log, the disconnect in the HAL. Only together do they name a root cause.
The Real Cost of Reading a Bundle by Hand
- 01Opening a hundred files one at a time, holding the timeline in your head.
- 02Cross-referencing raw IDs against a separate database, row by row.
- 03Reassembling one device's identity from a dozen scattered files.
- 04Missing the cross-component pattern because no single file shows it.
- 05Re-deriving all of it for the next engineer who picks up the bundle.
What logcat.ai Does With a Bundle
Not a file viewer: a correlation engine over the whole archive.
Reconciled identity
One device, build, and time window assembled from every file in the bundle, each fact cited back to the file it came from.
Cross-file joins
The archive's own reference files (a CAN signal database, a device-fingerprint table, a symbol map) automatically decode the opaque IDs in their sibling logs.
Findings roll-up
Every leaf is analyzed, then findings roll up across the bundle: "this fault in 3 of 126 files", with charts no single file can produce.
Built for scale
A gigabyte and a hundred-plus mixed-format files as one investigation — rotations collapsed, the whole bundle asked as a single question.
What Counts as a Bundle
Any archive that captures one situation across many files — the support bundle, diagnostic dump, or device snapshot your team already collects. logcat.ai recognizes the shape and reads it as a whole.
A vendor bugreport plus dozens of app logs, dumpsys, and framework traces from one device.
Access-point logs, per-radio configs, a roaming daemon, and a client-fingerprint database.
CAN traces, a DBC signal database, telematics and vehicle-HAL logs from one drive cycle.
A panic dump alongside rotated dmesg and last-kmsg from the boot that died.
A dozen numbered logcat segments the system collapses back into one stream.
An index that fans out to many per-result files — read through its manifest.
You showed up with one of these
Three ways a bundle lands on you, and what comes back.
A pile of files and no thread
A hundred logs, configs, and dumps from one incident, and no idea where to start. The investigation above read all 126 together and named a cross-file root cause: cited, on one timeline.
Logs full of IDs you can't read
Raw CAN codes, MAC addresses, symbol offsets — meaningless without the reference file next to them. The bundle's own databases decode them automatically, into named signals and devices.
A bundle you need to see, not read
You want the shape of the whole capture, not a hundred open tabs. The dashboard reads the bundle's structure and what's breaking across files, then draws the charts that fit: composition, and findings by file.
Common questions
Frequently Asked Questions
Cross-file bundle analysis, answered.
Any mix of files, logcat, bugreports, dmesg, CAN traces, Perfetto, pcap, configs, and reference databases (DBC, SQLite, fingerprint tables), inside a .zip, .tar, .tar.gz, .tar.xz, or .tar.zst. Nested archives (a bugreport zip inside an outer archive) are recognized and expanded.
Each file is analyzed on its own, the bundle's structure and one reconciled identity are computed, and reference files are matched to the siblings whose IDs they resolve, verified by value overlap, not guessed. Deep research and the dashboard then query the whole bundle at once.
When the archive carries a reference file (a CAN signal database, a device-fingerprint table, a symbol map) logcat.ai uses it to decode the opaque identifiers in its sibling logs automatically. A DBC turns CAN arbitration IDs into named signals; a fingerprint table turns MAC addresses into device and OS.
Comfortably a gigabyte and a hundred-plus files in one investigation. Rotated logs are collapsed into groups, and very large bundles are triaged so the files that carry signal are analyzed first.
No. Single files work too, and each has its own analyzer. A bundle is for when the answer lives across files; you get the cross-file correlation only an archive can provide.
Bundles are processed in your own tenant and never used to train shared models. The cross-file reasoning derived from your data stays isolated to your enterprise.
Bring us a real bundle.
The fastest way to see cross-file correlation is to drop in an actual diagnostic archive (a bugreport plus its siblings, an AP snapshot, a drive-cycle capture) and watch one cited answer come back from all of it.