# TAC Escalation Packet Builder > Describe the issue you are about to escalate; a fixed rule set assembles a complete vendor-support packet and a checklist of the artifacts still to collect before opening the case, dropping what you already have. It structures the hand-off; it does not open a case or contact any vendor. - Tool: https://ronutz.com/en/tools/tac-escalation-packet-builder - Family: Operations & Fieldcraft --- ## What it does Describe the issue you are about to escalate to vendor support - the product domain, the severity as the vendor would grade it, whether it is reproducible, what you have already collected, and what you have already tried - and a fixed registry of twelve original rules assembles a complete escalation packet. The packet has eight fixed sections: the problem statement, severity and business impact, environment, timeline, what has been tried, what is attached, what is still to collect, and the ask. The most useful part is that last-but-one section: a checklist of the diagnostic artifacts you should gather before opening the case, because the single biggest cause of a slow support case is a first contact missing the diagnostic the vendor will ask for anyway. Anything you have already collected drops off the checklist and moves to the attached list. Some items carry a command-level hint flavored to the product domain. A coarse readiness read - ready, nearly, or gather first - tells you how complete the packet is. One click exports the packet as Markdown for the case. ## What it deliberately is not This tool does not open a case, does not contact any vendor, and does not collect diagnostics from your systems - it tells you which to attach; you collect them. It does not diagnose the issue; it structures the hand-off so a support engineer can start fast. It makes no network connections and asks for no credentials or secrets. Product-domain names are used only to indicate which diagnostic applies, and no domain implies any training or support-partner authorization. The free-text notes (problem summary, environment, case reference) flow into the exported packet where they belong, but they never influence which rules fire. ## How the packet is built - and how it is verified Each rule is a pure predicate over the structured input; when it fires it adds to-collect items and optionally a readiness note. Every case gets the core artifacts - a problem statement, the exact error, a timeline, the business impact, exact versions, the vendor's diagnostic bundle, and the configuration - and the specifics layer on from the severity (a high-severity case adds a topology sketch and a capture), the reproducibility (reproducible adds exact repro steps; intermittent stages a capture to catch the next occurrence), and the product domain (a TLS case adds a handshake capture; a DNS case adds the query logs). Anything already marked collected is dropped from the checklist. The coarse readiness read is derived from the highest-severity readiness note. The "Why this checklist?" panel lists every fired rule with its reason, so the packet is auditable rather than oracular. Because there is no single "correct" packet for an advisory tool, classic golden vectors do not apply. The verification model - the ruling set by the Fault Hypothesis Builder pilot for the whole Operations and Fieldcraft family - is rule-firing snapshot vectors: for each test input, the build asserts exactly which rules fire, the exact fixed section order, the exact to-collect checklist with already-collected artifacts dropped, the exact readiness notes, the exact cautions, and the coarse readiness read. Twelve vectors (six scenarios, six rejects) pin the current registry; any drift breaks the build. ## API input The API-parity entry takes a JSON object: `{"vendor", "severity", "reproducibility", "collected": [], "tried": [], "notes": {"problemSummary", "environment", "caseReference"}}`. The vendor, severity, and reproducibility use the closed vocabularies shown in the form; `collected` and `tried` are arrays drawn from their own closed vocabularies. An out-of-vocabulary value is a format error, never a guess; the arrays may be empty. ## Standards and references - Original TAC-escalation ruleset (D-18: original by construction) - the 12-rule registry, 11 to-collect diagnostic artifacts with vendor-flavored command hints, the collected-satisfies mapping, 8 fixed packet sections, 5 readiness notes, and the readiness derivation are original editorial work encoding standard vendor-support hand-off practice (problem statement, exact error, timeline, environment, diagnostics, reproduction, impact, the ask); the diagnostic artifact names are generic operational captures and no vendor procedure or specification is reproduced ## Related reading - [TAC Cases That Get Triaged Fast](https://ronutz.com/en/learn/tac-cases-that-get-triaged-fast.md): The slowest support cases are rarely the hardest problems; they are the ones that opened without the diagnostic the vendor needs. A case that arrives complete - clear problem, exact error, the diagnostic bundle, the impact - skips the round trips and starts with an engineer actually working it.