Investigation Path Guide · Documentation

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

Workflow	First result	PacketSafari Core Engine	Follow-up	Best for	Main tradeoff
Fast answer	One clearly labelled Preliminary Report as soon as the capture is safely readable.	PacketSafari Triage is optional and can continue after the first result.	No automatic Targeted Verification Outcome or Comprehensive Final Report.	A concrete operator question or focused starting point. A specific symptom can qualify without an exact selector.	It may miss correlations and competing evidence elsewhere in the capture.
Fast + verification	A focused Preliminary Report while PacketSafari Triage processes the wider capture.	Indexing, rules, ranking, and correlation continue independently after the fast result.	A fresh Targeted Verification Outcome does not wait for full Triage. Later, a Comprehensive Final Report adjudicates all typed evidence and can supersede an earlier outcome.	A concrete operator problem/question needing early direction and capture-wide confidence afterward.	The Comprehensive Final Report has a separate, potentially much longer clock.
Triage then deep	The Comprehensive Final Report waits for indexed context.	Capture-wide rules, protocol signals, priority flows, and correlations are prepared first.	Agent adjudicates the strongest indexed candidates with fresh packet checks.	Preset-only broad requests, small summary/security cases, or large unfamiliar captures.	Slowest time to the first report.

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 deep 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 deep 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 Targeted Verifier from performing fresh checks or the later Comprehensive Final 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

Goal and input	Recommended workflow
Any preset without a concrete operator-entered problem/question	Triage then deep
Executive summary below 5 MiB	Triage then deep
Security review up to 10 MiB	Triage then deep, with full IDS plus Triage
Security review at any size	Always requests full IDS plus Triage
Larger capture with a concrete problem/question	Fast + verification can provide early milestones while Triage/IDS continue

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 Comprehensive 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.
Targeted Verification Outcome starts from the durable preliminary claim ledger without waiting for full Triage. In a fresh skeptical context it marks every strong candidate verified, partially_verified, contradicted, or inconclusive.
Comprehensive Final Report follows completed Core Engine Triage. It reconciles the preliminary ledger, targeted dispositions, 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.

Choose the question separately

The upload prompt describes what PacketSafari should answer:

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.

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, Targeted Verification Outcome, and Comprehensive Final Report milestones.
Triage then deep can send its completed Comprehensive 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 Targeted Verification Outcome 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 Comprehensive 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.