Investigation Path Guide

PacketSafari separates time to useful direction from time to a defensible root-cause analysis. A focused Agent can begin before the wider capture is fully processed, while the PacketSafari Core Engine continues protocol decoding, indexing, rule evaluation, correlation, and bounded evidence retrieval.

The right path depends on the incident. The evidence standard does not: material conclusions should remain tied to inspectable frames, filters, streams, timestamps, decoded fields, and capture viewpoints.

For the customer-facing visual explanation, see PCAP Investigation Workflows.

Compare the analysis workflows

Both Fast answer and Full investigation require a concrete operator-entered problem/question or focused starting point. A generic preset alone does not enable either early-start path. Triage then report is the only preset-only broad path. This is not the same as requiring an exact 5-tuple: a specific reported symptom can give bounded discovery enough direction.

For Root cause captures of 5 MiB or more, the upload flow also asks for a structured focus. When it is not known, choose capture-wide discovery; PacketSafari recommends Triage then report because indexed evidence discovery is more likely to matter.

Give an early-start path a concrete question

A concrete symptom or investigation question can be sufficient, for example:

Why do SSH sessions stall after authentication?

When you have one, a structured selector makes the early Agent even more bounded and useful:

• IP address or port
• Call-ID or phone number
• hostname or BSSID
• TCP or UDP stream
• protocol and known error
• time range around the reported symptom

You do not need to invent a selector you do not know. However, a large root-cause request with no concrete symptom and no structured focus should use capture-wide discovery rather than either early-start workflow.

A selector focuses the preliminary investigation. It does not prevent the later Final Report from checking the wider capture in Full investigation. The upload form labels the focus types it recognizes so you can confirm the selector-first start before choosing the analysis workflow.

Goal- and size-aware recommendations

The 10 MiB boundary is the backend Sharkd progressive preliminary-first/indexing gate. It is not a security-postprocessor cutoff: it does not disable IDS below or above that size. Full investigation already includes continuing Triage and a Triage-backed Final Report, so this policy does not add a fourth workflow.

Understand the evidence milestones

• Fast Report provides bounded direction from the safely readable capture. It is useful, but unverified until checked.
• Final Report follows completed Core Engine Triage. It checks the Fast Report against capture-wide findings, contradictions, healthy comparisons, and fresh packet checks, and states where the evidence corrects a conclusion or cannot settle it. When the final evidence changes an earlier outcome, the earlier artifact stays visible and is marked superseded.
• Verification is an optional follow-up to a completed Fast Report. A fresh, independent pass checks the report's conclusions against the packets and reports what held up, what did not, and what remains uncertain.

Triage is the continuing evidence workstream between the Fast Report and the Final Report. It is not another report name.

Continue from a Fast Report

A completed Fast Report offers these follow-ups in the same investigation:

• Run Triage and analyze is the recommended next step. It runs capture-wide Triage and writes a Final Report that checks the Fast Report.
• Verify findings runs the independent Verification without Triage. The investigation is then labelled Fast + verification.
• Continue with verification results appears after a completed Verification. It adds Triage and a Final Report that also reads the Verification.

Report after completed Core processing

Triage then report completes the selected Core workload first. The Agent then receives generation-matched coverage state, retrieves the bounded packet evidence it needs, and writes one Final Report. There is no separate adaptive or forced Explore stage.

Choose the question separately

The upload prompt describes what PacketSafari should answer:

• Is the network at fault? for a quick ownership decision: network primary cause, network contributing factor, no captured network fault, or inconclusive. It requires a reported symptom and recommends Full investigation.
• Executive summary for the main flows, problems, and next actions
• Root cause for the dominant failure family and its packet proof
• Security review for suspicious behavior and escalation-worthy findings
• Custom prompt for a specific operator or report question

Any of these questions can use the analysis workflow appropriate to the incident. A root-cause prompt is not automatically a deep workflow, and a custom prompt is not automatically a fast workflow. Preset text alone uses Triage then deep; both early-start workflows require additional operator-entered problem context.

The network-fault shortcut is deliberately narrower than Root cause. It helps an incident team decide who should investigate next and limits unrelated signals to three. Root cause remains the open-ended option when the goal is a complete causal explanation across network, endpoint, server, application, and policy evidence.

Choose who drives separately

• Inspect manually when you want direct control of filters, packet decode, streams, statistics, and specialist dashboards.
• Copilot guided when you want an interactive, capture-aware investigation and expect to refine the question through follow-ups.
• Agent investigation when you want PacketSafari to plan, test, correlate, and report against packet evidence.

All three can use the same PacketSafari Core Engine facts. They describe the operator-control model rather than the processing-depth workflow.

Privacy and delivery are cross-cutting controls

Anonymize before upload creates a sibling capture and runs the selected Agent workflow on that anonymized copy. It is a privacy choice, not an analysis mode.

Where report email is configured and permitted:

• Fast answer can send the Fast Report.
• Full investigation can send the selected Fast Report and Final Report milestones.
• Triage then report can send its completed Final Report.
• The Verify findings follow-up can send its Verification.

Verification and final emails must state whether the outcome is verified, partially verified, inconclusive, or contradicted. Each selected terminal milestone is delivered at most once. Triage/indexing progress should not create an email flood.

Runtime and large-capture qualification

For validated Teams and enterprise deployment profiles, an evidence-backed Fast Report within roughly two minutes after durable upload/safe-open for a focused single capture up to 1 GiB is a product validation target. It is not a universal current guarantee and does not include network upload time.

The Verify findings follow-up has a separate validation goal of roughly five minutes on the qualified profile. It is also not a guarantee. Neither goal includes full Triage or the Final Report, which may take tens of minutes or longer on a large or complex capture.

The Triage/Comprehensive range shown before upload is a planning estimate based on file size because PacketSafari does not know the packet count yet. After safe-open, PacketSafari may refine that range with the observed packet count. File size, packet count, protocol mix, requested IDS/rule coverage, storage, concurrency, and deployment load can all change the actual duration. That planning range is separate from the ~2-minute Fast Report and ~5-minute Verification follow-up validation goals.

Upload transfer, queueing, safe-open, the Fast Report, Triage, the Final Report, persistence, delivery, and a Verification follow-up have separate clocks. Larger accepted-capture profiles also do not imply the same RCA runtime; protocol mix, packet count, capture structure, question, concurrency, storage, and infrastructure all matter.

See Processing runtime for how PacketSafari refines large-capture work after safe-open.

Related documentation

• Upload PCAPs
• PacketSafari Triage
• Agent
• Copilot
• Raw-First Captures
• PacketSafari anoncap