Source-grounded findings
Source-grounded findings
On supported platforms logcat.ai resolves a log line back to the place in the platform source that printed it and shows you the file, the line, and what that code does. Grounding never blocks or delays an analysis, and a grounded run can reach conclusions an ungrounded one cannot, such as noticing that something the code normally prints is missing.
Two things decide whether you get citations
Your account and the capture. Source-grounded analysis is included on some accounts and not others; without it findings simply arrive with no citations, and the candidate-fix and source-search features are not offered. It appears as “Source-grounded analysis” on Plans and pricing; if it isn’t on yours, ask us. The rest of this page is about the capture.
What a citation looks like
A citation is a small chip next to a finding or inline in a report:
⌖ aosp-15 · CachedAppOptimizer.java:2593
The platform label says which source tree to open, since the same path exists in several platforms and versions. Then the file and the line. Hover for the full path; click to open the code. A citation that names a function rather than a line copies the path instead.
Reading the code
Clicking a citation opens a panel beside the finding with the cited line in context, the platform release it came from, and what that code is recorded as doing. From there you can copy the path, ask for a candidate fix, or step outward: the other logging sites in the same function, each with how often it fired in this capture (zero is a real answer), then the function’s callers and callees. Locations the device could not have run are left out, and the panel says how many.
When the panel has no code to show it says why: the release’s tree doesn’t carry that file, we hold no source for the release, or the source was briefly unavailable. Shared report links and exported PDFs have no code panel, since reading source needs a signed-in account; their citations still name the file and line.
A grounded finding also offers ready-made questions about itself. Picking one drops it into the investigation box on the same capture; nothing runs until you run it.
A citation into a crash
A line of a stack trace is a location, not a description. A finding citing one carries the sentence the analysis wrote about that line, marked as coming from the analysis rather than from the code, and opens the rest of that crash as a call chain in the order the device printed it. Where two crashes cannot be told apart, no chain is shown.
Searching the source yourself
The References page has a search box over the source your own files have been matched against: ask whether we hold a symbol, a log string or a file and where it sits. The sources a search covers are listed above the box. Results are pointers, not citations, so they don’t open the code panel.
Where citations show up
| Surface | What you get |
|---|---|
| Dashboard, Overview tab | A Findings located in source table for the highest-severity findings: severity, finding, file and line, platform label, what the code does, and how many locations were cited |
| Findings list | Citation chips under each finding with a one-line note on what the code does |
| Log overview, AI insights | Each insight names the source file and line behind it |
| Bugreport analysis | A Source-Grounded Findings panel grouped by subsystem |
| Deep Research, Delta, Quick Search | Inline citations in the answer, alongside the log-line citations. In a Delta answer, read which device a citation belongs to from the surrounding text |
Which platforms are supported
Grounding applies to Android logs and Linux kernel logs. In a bugreport, that means the Android log and the kernel log it contains, not its crash dumps or ANR traces. Everything else (network captures, traces, databases, modem logs, an app’s own log) is analyzed normally with no citations, because there is no platform source behind it.
We hold recent Android platform releases and a set of Android Linux kernel trees: the Android common kernels and the Pixel 6 kernel. The References page lists the source your account can reach and how many of your captures matched each, and lets you filter your captures by what was found; check it there rather than here, especially on a self-hosted deployment, where the set is chosen at setup. Some source belongs to one organization, so a colleague elsewhere may see a different list. If the platform you work on isn’t covered, tell us.
A log needs an exact version match
A log is grounded only when the version it states matches available source exactly: an Android 15 log is not cited against Android 14 source. A near miss produces citations that name the right file at the wrong line and look exactly as trustworthy as correct ones, so you get none rather than approximate ones.
The version is read from the capture itself, and only where the device states it about itself: a build header in a buffer any app can write is ignored, and a version belonging to one part of the device is not taken as the platform’s. A log that arrived inside a bugreport or crash dump inherits that capture’s version, which matters for kernel logs, whose boot banner has usually scrolled out of the ring buffer.
The release is only half of the match
Kernel logs also depend on which kernel tree is available. A log can state a release you have source for while coming from a different vendor’s tree at that release. Check the platform label against the machine the log came from; if they don’t match, treat the citation as wrong.
Android logs from a manufacturer’s own build or an aftermarket distribution carry changes over the platform release, so a line the manufacturer changed can be shown as code that ran when it did not. Where the build says it is one of those, the capture is marked. Read the mark as a prompt to check the cited file against your own tree, not as an error; an unmarked capture has not been cleared.
The source can move after a capture is analyzed
A citation is resolved once, when the capture is analyzed. Source updated since means the tree was re-read after that; most files survive unchanged. Source code changed since means the files themselves differ from the ones the citations were read against. Neither removes anything. Re-run the analysis to refresh the coordinates.
When a capture isn’t grounded
Nothing is wrong. The source cards and chips simply don’t appear, and everything else works. A note at the top of the file’s Overview says which of these applies:
| What it says | What it means for you |
|---|---|
| Not included on this account | Source citations aren’t part of your plan. Findings arrive as usual, without chips |
| Doesn’t say which platform version it came from | Nothing to match against. Capture the log with its build header, or upload the bugreport it came from |
| Names a version we can’t rely on | A version was found but not one the device stated about itself. Same remedy |
| Names two different platform versions | Nothing settles which one the device is running. Upload the bugreport, or a capture whose build header agrees with the device settings |
| Could not be matched to platform source | No readable log lines, or none of them are in the source we have. Nothing to fix |
| We don’t hold source for this release yet | Tell us which release you need |
| We couldn’t determine which source matches | We’re looking into it |
| Citations were unavailable at the time | Usually clears on its own. Upload again |
| No record of why | Older files predate the reason being recorded |
A line with no citation has not been shown to have no origin; it means we couldn’t resolve one. Treat an absent citation as unknown, not as evidence.
Reaching this from the API
Every read on this page is on the API, with an API_KEY header:
| What you want | Call |
|---|---|
| Which platform source your account can be cited against | GET /api/v1/source/coverage |
| How each of your files matched it | GET /api/v1/source/captures |
| The code behind a citation | GET /api/v1/source/window?graph_label=…&file=…&line_no=… |
| Everything one source file said about a file | GET /api/v1/files/{id}/source/evidence?label=…&file=… |
| What the source expected and a file never printed | GET /api/v1/files/{id}/source/missing-signals |
| A candidate fix already generated for a cited line | GET /api/v1/source/fix-proposal?graph_label=…&file=…&line_no=… |
| Which cited lines you have candidate fixes for | GET /api/v1/source/fix-proposals?graph_labels=… |
The three parameters are exactly what a citation carries. Two things are Console-only: asking for a new candidate fix, because it spends your quota, and stepping outward from a cited line. The fix read returns what exists and never generates, so it is safe to poll. An attempt that was charged and produced nothing is returned too: it carries no proposal, and its outcome field says why (model_stopped, unreadable_answer or plane_failed). A completed fix carries answered, or bounded_rounds / bounded_reads when it stopped at a limit; a fix generated before outcomes were recorded carries an empty value. The list of sites omits a site whose only attempt failed.
Where the matching happens
Citations are resolved against source held inside the deployment; producing one does not send your capture anywhere. Two things do reach outside: generating a candidate fix, and Deep Research, which may look up public platform source and upstream changes while it investigates, using function and class names from your log as the search terms.
Next
- Analysis output & dashboards: where the grounded findings card sits.
- Deep Research: investigations that cite source alongside log lines.