> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vexlo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Use cases

> Six questions execution data answers, and which part of the data answers each one.

Six questions come up often enough to name. Each one is answered by reading a different part of
the same data.

| Use case | The question | What you read |
| - | - | - |
| Debugging | Why did this request fail? | One trace, its errored step, and the values on the steps around it |
| Coding | What actually depends on the code I am changing? | The function index: that function's observed callers and observed callees |
| Verification | Did my change alter behaviour the tests did not catch? | Real executions of the function, with their inputs and outputs |
| Performance | Where does the time actually go in this request? | Every attempt's start offset and duration inside one trace |
| Understanding | How does this part of the service really work, and how often does each path run? | The call tree that ran, plus observed counts per function |
| Testing | What real inputs should I test with? | The captured input slots of real executions |

## Debugging

Open the trace of the request that failed and walk it. The errored step names its exception
class, and the steps around it carry the inputs they were given and the outputs they returned. A
step that succeeded and returned nothing useful is as informative as the step that raised. [The
execution graph](https://docs.vexlo.ai/concepts/execution-graph.md) walks one rejected request from its trace body down
to the values on its root.

## Coding

Before changing a function, ask what called it. The function index holds observed caller and
callee pairs per service and function name, kept for 90 days, so it outlives the traces they
were derived from. Any marked function that ran has a row. The lists are observed, which is the
whole claim: they name what was recorded calling that function, never everything that can.

## Verification

After a change ships, read real executions of the function it touched and compare their inputs
and outputs with what you expected. Reading a function's examples returns up to five of them, as
previews or as full values, each carrying the `status` of the attempt it names. Nothing here
diffs two deployments for you. What it gives you is concrete behaviour from production to
compare against, for the cases a test suite does not cover because nobody thought of them.

## Performance

Inside one trace, every completed attempt carries its start as an offset from the trace's start
and its own duration, both in microseconds, so the time that went missing is attributable to a
step rather than to a service. Read one trace's steps in duration order and the slow one is
named. Timings stay per request: the function index carries counts and instants, not durations,
so there is no aggregate timing anywhere to read.

## Understanding

A trace shows the path a request actually took, which is a different thing from the paths the
code allows. Read a few traces of the same entry point and the common shape appears; the
function index ranks functions by how often they were observed running, which answers how often
a path runs rather than whether it can. That count counts steps once each rather than records,
so a record delivered twice does not inflate it, and a slow path does not outrank a frequent
one.

## Testing

Test inputs are the one thing captured values hand over directly. A function's examples carry
the arguments real callers passed it, so a regression test starts from a value that occurred
rather than one you invented.

## For an AI agent

An AI agent reads all six answers from the same data through the MCP server's tools, in the same
order a person would: find the request, read its shape, then fetch only the values it needs.
[Debugging with an agent](https://docs.vexlo.ai/mcp/debugging-with-an-agent.md) walks one rejected request through those
tools, with the token cost of each call.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.