Screenshot and log artifact parser

Customers attach evidence and expect someone to look at it. A screenshot of a red banner. A photo of a monitor taken with a phone. A text file holding four hundred lines of stack trace. That material sits unread until an agent opens the ticket, and removing that delay is the point of parsing at intake.

A parser produces extracted fields, not conclusions. Error code and message string. Product surface visible in the image. Version or build identifier. The top frames of the exception and the first line touching customer code. A pointer back to the region of the image or the line range of the log.

The pointer is what makes the extraction usable. An error code with no coordinates is a claim. An error code with a crop of the dialog it came from can be checked in seconds.

What the parser must not do is name a cause. "Authentication token expired" is text read off a screen. "The customer's credentials are misconfigured" is a diagnosis, and diagnosis has its own stage, including compression of attached logs into ranked hypotheses.

Screenshots are the least controlled artifact in support. A customer photographing an error also captures browser tabs, email previews, other people's records, and sometimes a token sitting in a URL bar. Set the handling rules before switching this on.

Four rules cover most of it. Redact during ingestion rather than after, masking tokens, keys, card numbers, and personal identifiers. Keep retention short, since parsed fields outlive the need for the raw image. Log every access to the original. And exclude parsed output from training or evaluation sets unless someone has cleared it.

Then define the extraction targets. Error code with its expected format. Message string, verbatim. Product area from a list of known surfaces. Version, matched against known releases. Exception type and frame list for traces. Anything outside that list stays unextracted, however interesting it looks.

Set a readability bar and let the parser decline. A clean capture, a phone photo at an angle, a cropped region, and a plain text log are different inputs with different reliability. If nothing readable is present, write nothing. Fields populated from a blurry image are the fastest way to lose agents' trust in the entire panel.

The two artifact types need different treatment, even when they arrive together.

For images, extract text with location. Every string should carry a bounding region, so an agent can see where on the screen it appeared. Position carries meaning. A code in a modal dialog is the failure; the same string in a background console may be stale.

For traces, structure rather than summarize. Exception type, message, the ordered frame list, and the first frame belonging to customer or product code rather than the framework. That frame is what an engineer looks for. Preserve line numbers and file paths exactly, because a transposed digit sends the investigation into the wrong module.

Match extracted values against known lists. A code that exists in the product's code table is confirmed. One that does not is either a misread or an undocumented string, and the difference matters. Flag unmatched values instead of correcting them to the nearest neighbor.

When both artifacts arrive, extract them separately and record whether they agree. A screenshot showing one code and a trace showing a different exception is a signal by itself. Merging them into one tidy field destroys it. Precise fields also give retrieval of similar resolved tickets something better to search on than a paraphrase.

This scenario is invented. A data integration vendor sells connectors that sync application data into customer-managed warehouses. An analytics engineer reports that the nightly sync failed. She attaches two things: a screenshot of the run detail page and a downloaded log.

The screenshot is a clean capture. The parser reads run status failed, the connector name, the destination warehouse type, the run start time, and a red banner reading "Destination write rejected: column type mismatch." Each string is stored with its region. A partially visible sidebar suggests the previous run succeeded, so that goes in as context at lower confidence, because the text is cut off.

The log is 412 lines. The parser extracts the exception type, the message, and eleven frames. The first frame outside the framework points at the type-mapping module. Each extracted item carries its line range.

Both artifacts agree on the failure surface, and the parser records that agreement as a field.

One thing is missing, and the parser says so. Neither artifact shows the connector version. That field stays empty, flagged as not present in attachments. The blank is what tells the agent to ask, which beats a version inferred from the interface theme.

The ticket lands with six populated fields, one empty field with a reason, and both originals attached with regions highlighted. The first reply asks about the version and any recent schema change, instead of asking what the error said.

Extraction errors here are unusually costly, because they look authoritative.

Misread characters change meaning. A zero read as an O, or an 8 as a B, yields a code that does not exist. Worse, it can yield one that means something else. Match against the known code list and mark anything unmatched.

Cropped screenshots hide the relevant part. Customers crop to what they think matters and cut the timestamp, the account context, or half the message. Note when an extracted string appears truncated at an image edge.

Old screenshots get reattached. An image pasted from three weeks ago parses perfectly and describes a state that no longer exists. Extract a timestamp where the image shows one. Where it does not, mark the artifact undated.

Photos of screens degrade fast. Angle, glare, and motion blur break character recognition in ways that partial extraction hides. A field read from a photo should carry lower confidence than the same field from a screenshot file.

The last failure is scope drift. A parser that starts on error codes and ends up proposing fixes has entered the resolve stage without that stage's controls. Generating a configuration change is its own job with its own review.

Extracted fields are a reading of what the customer sent. They are not a reading of the customer's system. The agent opens the original, checks the code against what the panel claims, and looks at the account before acting on any of it.

Confidence belongs on every field. A code read from a crisp dialog and one read from a glare-covered photo cannot appear in the same style. Shade or sort the panel so the weak values are obvious.

Empty fields stay empty and stay visible. A missing version, a missing timestamp, or a missing account identifier is each a question worth asking. Asking at first reply is cheaper than asking at hour six. Where those questions are predictable, the better fix sits upstream, in the questions asked while the customer is still submitting.

Routing follows confirmed fields, not raw ones. An exception pointing at one module suggests a specialist, but the assignment decision belongs to the routing rules and the person who owns them.

Audit against outcomes. Once a month, take the tickets where the extracted code differed from the code recorded at resolution. Then look at what the artifact actually showed. Those cases name the failure modes in one product's own screens, which no general accuracy figure will.