# Packet Capture Plan Builder > Command builders answer how to capture; this answers where, why, and what it would mean. Describe the path and the symptom; a 35-rule original registry designs a phased capture plan: ranked points on named boundaries, expected observations, an interpretation matrix with supports and weakens decided before collection, and sync/authorization discipline. It plans captures - it never ingests them. - Tool: https://ronutz.com/en/tools/packet-capture-plan-builder - Family: Operations & Fieldcraft --- ## What it does Describe the path and the symptom through seven structured fields - path archetype, symptom, traffic class, intermediaries, transformation, capture access, and time behavior, plus a command-family preset - and a fixed registry of 35 original rules fires deterministically over that description. Out comes a PHASED CAPTURE PLAN: ranked capture points on 13 named boundaries (endpoint, pre/post-firewall, VIP-front, member-side, proxy-front/back, VPN outer/inner, resolver, egress, mirror), each with a vendor-neutral filter template and the observations it can establish; an interpretation matrix stating, for every candidate conclusion, what would SUPPORT it and what would WEAKEN it - decided IN ADVANCE, before a single packet is collected; a synchronization and authorization checklist; and minimal-exposure warnings for sensitive traffic classes. One click exports the plan as Markdown for the ticket, the bridge chat, or the capture request to another team. ## What it deliberately is not Command builders answer "how do I capture?"; this tool answers "where, why, and what would it mean?" - and it stops there. It PLANS collection and never ingests capture files (that privacy boundary is structural, not policy). It provides no interception, evasion, or decryption-bypass guidance. Filter hints are templates with ``, never claimed accurate for a specific product version; preset notes name command families nominatively only. Capture authorization, retention, and access control are named as YOUR responsibility on every plan - the authorization rule fires unconditionally. Free-text labels and notes flow only into the export; they never influence the rules. ## How the plan is built - and how it is verified Each rule is a pure predicate over the structured input contributing points to catalog capture points, plus optional expectations, checklist items, warnings, and interpretation-matrix candidates. Ranking is score-descending with catalog order as the deterministic tie-break; the signal badge is a score band (strong ≥ 60, moderate ≥ 30, weak below) describing which rules fired, never a probability. Phase 1 is the minimum viable set (top points scoring ≥ 30, capped at four, floor of two); phase 2 is the expansion. The "Why these points?" panel exposes every fired rule. Verification follows the cluster's rule-firing snapshot model: for each test input, the build asserts exactly which rules fire, the exact ranked point list with scores and signal bands, the exact warning set, and - specific to this tool - the exact phase-1 set. Thirteen vectors (nine scenarios, four rejects) pin the current registry; any drift breaks the build. ## API input The API-parity entry takes a JSON object: `{"archetype", "symptom", "trafficClass", "intermediaries", "transformation", "access", "timeBehavior", "preset", "notes": {"labels", "reference", "notes"}}`. All fields except `notes` use the closed vocabularies shown in the form; an out-of-vocabulary value is a format error, never a guess. ## Standards and references - Original capture-planning ruleset (D-18: original by construction) - the 35-rule registry, 13-point capture catalog, 9 interpretation-matrix candidates, scoring weights, signal bands, phase construction, and quality warnings are original editorial work encoding standard capture practice (boundary pairing, absence-as-evidence, clock synchronization, minimal exposure); no external specification is claimed or reproduced ## Related reading - [Capture Points Before Packets](https://ronutz.com/en/learn/capture-points-before-packets.md): The instinct under pressure is to start tcpdump somewhere convenient and stare at the flood. The senior habit is the opposite: decide where to observe, in what order, and what each observation would mean - before a single packet is collected. Evidence is designed, not fished for.