> ## Documentation Index
> Fetch the complete documentation index at: https://docs.traversal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Best practices
> Get the most out of Traversal by anchoring investigations in time, asking specific questions, and sharing your team's institutional knowledge.
Traversal is designed to do the exhaustive, machine-scale work of investigation so you can focus on judgment. The more you ask good questions, provide clear time bounds, give feedback, and encode what your team already knows — the more Traversal becomes a true extension of your best engineers.
## Anchor investigations in time
Time is the single most important input for accurate investigations.
Use the moment symptoms were **first observed** as your investigation anchor — not when the alert fired or when the ticket was opened.
Traversal looks primarily backwards from the time you provide. If you set it too early, too late, or omit it entirely, key context may be missed and results may be vague or low confidence.
**Good:** "Investigate checkout failures starting 09:12 UTC."
**Risky:** "Why is checkout broken?" — no time context provided.
When in doubt, the incident ticket start time is a reasonable proxy.
If your results seem vague or the confidence is unexpectedly low, incorrect or missing time context is the most common cause.
## Ask questions naturally — but be specific
If you don't know where to start, enter your question in the **Investigations** search bar. You don't need to choose the right reasoning mode — Traversal determines that automatically.
Ask naturally and use follow-up questions to refine, drill down, or challenge hypotheses.
**Common use cases:**
* Incident investigation
* Alert context
* Service health checks
* Dependency exploration
* Onboarding into unfamiliar systems
## Include specific identifiers when you have them
The more specific your query, the more Traversal can focus its search. Generic descriptions force the agent to cast a wide net; specific identifiers let it go deep immediately.
Useful identifiers to include:
* **Trace or request IDs** — correlate across services instantly
* **Service or application names** — scope the investigation to the right part of your stack
* **Error messages or codes** — match logs and alerts precisely
* **Deployment SHAs or version numbers** — tie symptoms to a specific change
* **UUIDs from tickets or alerts** — link directly to the triggering event
**Good:** "Investigate latency spikes in `payments-api` starting 14:32 UTC. Trace ID: abc123, error: `connection pool exhausted`."
**Less specific:** "Something is slow in payments." — Traversal will still help, but it has to work harder to find the right signals.
## Know when to start a new investigation
* You want more detail on an existing root cause analysis
* You're exploring evidence or timelines
* You're validating or disproving a hypothesis
* The incident time changes
* You switch to a different alert or service
* New information fundamentally reframes the problem
## Share tribal knowledge with Traversal
Traversal learns autonomously, but it becomes more accurate when guided by your team's institutional knowledge.
Use **Knowledge Bank** to encode:
* Runbooks
* Preferred debugging paths
* Business-critical services
* Known failure modes
Give feedback when an investigation misses practical nuance. Traversal is strongest when paired with what your team already knows.
## Use Traversal for learning and onboarding
Traversal isn't only for active incidents. Use it to build team-wide system understanding.
Review historical incidents to understand patterns and common failure modes across your stack.
Query Traversal about a service's history to surface recurring issues before they become incidents.
Let new team members ask questions freely to ramp up on unfamiliar systems without requiring senior engineer time.
Over time, Traversal becomes a shared source of system understanding — not just an incident response tool.