# Change Validation

When you make a code change, Kerno rebuilds your app with the new code, runs your existing scenarios against it, and captures the new backend behaviour. If the behaviour matches the\
baseline, you get no diff. If something changed, Kerno shows you exactly what.

### How validation works

{% code expandable="true" %}

```mermaid
  flowchart LR
      A[Code change] --> B[Rebuild app]
      A --> C["Rebuild env (if env changed)"]
      B --> D[Run scenarios]
      C --> D
      D --> E[Compare to baseline]
      E --> F{Changed?}
      F -->|No| G[No diff]
      F -->|Yes| H[Diff reported]
```

{% endcode %}

Kerno compares each scenario result to its baseline in two passes.

First, a structural check compares the HTTP status code, JSON shape, field types, and field presence. Dynamic fields marked `{{dynamic}}` in the baseline are skipped. This pass is fast and requires no LLM call.

If the structural check detects a difference, a semantic pass runs. The semantic pass determines whether the difference is meaningful: a missing key, a type change, or a value change on a non-dynamic field. Differences in key ordering, array ordering, and numeric precision are ignored.

If both passes find no difference, validation reports no diff for that scenario.

### Validation scope

By default, Kerno validates with `changed` scope. When you ask your agent to validate, Kerno detects which endpoints were affected by your changes and re-runs validation only for those. This keeps validation fast during active development.

You can instruct your agent to use a different scope:

| Scope                   | What it validates                                         |
| ----------------------- | --------------------------------------------------------- |
| `changed`               | Only endpoints affected by your current changes (default) |
| `all`                   | Every endpoint in the app                                 |
| `file:<path>`           | All endpoints in a specific file                          |
| `endpoint:METHOD /path` | A single endpoint (e.g. `endpoint:POST /api/orders`)      |

See [Scopes](/docs/references/scopes.md) for the full reference.

### Responding to a diff

When validation surfaces a diff, you decide whether the new behaviour is correct.

{% code expandable="true" %}

```mermaid
flowchart LR
      A[Diff detected] --> B{Expected?}
      B -->|Yes| C[Approve]
      B -->|No| D[Reject]
      C --> E[Baseline updated]
      D --> F[Fix code]
      F --> G[Run validation]
      G --> A
```

{% endcode %}

**Approve** — the new behaviour is what you expected. Kerno updates the baseline to reflect it. If your change introduced new endpoints or removed existing ones, Kerno adjusts the scenario suite accordingly.

**Reject** — the behaviour is not what you expected. Fix the code and re-run validation.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://kerno.gitbook.io/docs/core-concepts/change-validation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.