# What the graph and production evidence add

Each of these joins the compiler's graph to path IDs. Every request
records the path it took through your app, the route, each action and
query, and each branch taken inside them, as a number the graph can
decode ([Path IDs](path-ids.md)). Production data is always
an optional input: a file exported from your monitoring tool, or a service
that holds it. Every command works without it.

## Coverage by path

`jadpo test` reports which paths your tests ran, not which lines. Line
coverage says a branch ran once; path coverage says which combinations of
branches ran.

Given production path counts, it also lists the paths that ran in
production but have no test, busiest first, and
`jadpo test new --from` writes the missing test. Paths in the graph that
production hasn't used for 90 days are listed as candidates for removal.

## Production in review

Given production path counts, the approval report says how much a change
touches what is in use: "touches paths that served 38% of requests last
week; one failed 12 times".

## Replaying a production request

Time, randomness, calls to providers and the database are all declared
effects, so the runtime knows every source of results that can differ from
one run to the next. A deployment can opt in to recording what each effect
returned for a failing request:

- only failing requests are recorded;
- personal fields are replaced, using their `personal:` marks
  ([Marking personal fields](marking-personal-fields.md));
- the recordings expire, as logs do.

`jadpo replay` then runs that request on your machine and gets the same
results. It extends `test new --from` from `jadpo dev` to production.

## Query cost of a change

The compiler counts the queries on every path by itself, so the approval
report can say "adds 2 queries to `POST /orders`". Given production
counts, it also says which of those paths is busiest.