# Production incidents after the code has changed

By the time you look at a production failure, the code may have moved on.
Every production event names the build it came from and its `.jadpo`
frames, and `jadpo incident` takes that event and tells you two things:

1. **Where it happened**, in the source of that build: the file, the line
   and the lines around it. `jadpo build` records the git commit in the
   deployable's build stamp, the small record of what was built
   ([Production builds](production-builds.md)).
   The runtime logs the stamp with every event, so the command can read
   the old source from git.
2. **Where that code is now**: the same declaration on your current
   branch. Jadpo finds it by its stable identity, an ID that follows a
   declaration through renames and moves
   ([Stable identity](stable-identity.md)). If the
   declaration has changed, been removed or been split, the command says
   so rather than guessing.

```text
$ jadpo incident event.json
int_overflow in action price_line
  then   domains/ordering/actions/price_line.jadpo:4   (build src_2c78…, commit 8d113e6)
  now    domains/ordering/actions/price_line.jadpo:6   (changed since: 2 commits)
  path   POST /orders → place_order → price_line
  next   capture it as a test: jadpo test new --from-event event.json
```