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 Fast + verification 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 Verification from performing fresh checks or the later Final Report adjudication from checking the wider capture in Fast + verification. 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. Fast + verification already includes continuing Triage and a Triage-backed Final Report, so this policy does not add a fourth workflow.

Understand the three evidence milestones

• Preliminary Report provides bounded direction from the safely readable capture. It is useful, but explicitly provisional.
• Verification starts from the durable Preliminary Markdown without waiting for full Triage. In a fresh skeptical context it challenges the material conclusions and reports what held up, what did not, and what remains uncertain.
• Final Report follows completed Core Engine Triage. It reconciles the earlier milestone Markdown, capture-wide findings, contradictions, healthy comparisons, and fresh packet checks. When the final evidence changes an earlier outcome, the earlier artifact stays visible and is marked superseded.

Triage is the continuing evidence workstream between these milestones. It is not another report name, and it does not have to finish before the Targeted Verification Outcome.

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 Fast + verification.
• 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 Preliminary Report.
• Fast + verification can send selected Preliminary Report, Verification, and Final Report milestones.
• Triage then report can send its completed Final Report.

Targeted 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 preliminary 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.

A Verification within roughly five minutes of that same readiness point is a separate validation goal for the qualified profile. It is also not a guarantee. The five-minute goal does not include 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 and ~5-minute safe-open validation goals.

Upload transfer, queueing, safe-open, preliminary analysis, targeted verification, Triage, comprehensive adjudication, persistence, and delivery 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