Evidence you can inspect before trusting the workflow.
These examples show the output buyers actually need: a failure boundary, evidence table, recommended fix, and a file that can leave the app.
- Support evidence handoff IPv4 header-masking review for a support case A sample review of IPv4 header masking and subset selection. It explicitly does not claim that application payloads or unknown protocols have been sanitized.Failure boundary The original capture contains useful protocol evidence and private IPv4 headers. Header masking alone is not enough to make the file customer-safe because payloads can still contain identifiers or credentials.Likely cause Support workflows need a reviewable preparation step, but the current release only masks supported headers and cannot certify payload privacy.
- Reproducible test fixture Checksum-safe IP and port rewrite for a lab fixture A sample report for rewriting endpoints in a PCAP while preserving protocol structure and repairing IPv4, TCP, and UDP checksums.Failure boundary The useful packet sequence is valid, but endpoint values must be rewritten before the capture can become a repeatable lab fixture.Likely cause The capture was collected in a customer network and needs deterministic test-lab addresses without invalidating checksums.
- Incident evidence reduction Large capture trimmed to the failure window A sample handoff for reducing a large PCAP to the packets that explain the failure while preserving timing and packet context.Failure boundary The full capture is too large and noisy for review; the failure is isolated to a specific packet window and endpoint pair.Likely cause Support or incident response needs a focused artifact rather than a full network trace.