> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/core-concepts/memory-and-learning.md).

# Memory and Learning

Understand how Kerno remembers what it learns about your codebase and improves over time.

Memory and learning is how Kerno gets better as it works with your codebase and learns from your feedback.

```mermaid
flowchart LR
    A[Kerno needs an analysis] --> C{In memory and<br/>still current?}
    C -->|Yes| F[Reuse it]
    C -->|No| E[Work it out]
    E --> G[Store it, stamped with<br/>the current revision]
    U[A finding you review] --> G
    G --> F
```

Kerno learns in three ways:

* **From your code** – Kerno works out how your app is structured, which files serve which routes, and how each entry point authenticates. This analysis is slow, so Kerno does it once and reuses it, re-deriving only the parts a code change affects.
* **From running your tests** – While setting up and running tests, Kerno remembers what actually worked, like the steps needed to seed a user before a test can run. The next entry point in the same service reuses that instead of working it out again.
* **From your feedback** – When you dismiss a flagged issue, Kerno saves your decision and applies it on every later run. When you answer a question Kerno asks, like where to find a schema, Kerno reuses your answer for that entry point.

### Reviewing what Kerno learned

As Kerno tests your entry points, it writes down what it works out along the way. How a particular entry point authenticates, say, or what has to exist before a request will succeed. Kerno calls these lessons, and it reuses them when planning your next tests so it never works the same thing out twice.

Sometimes a lesson is wrong. Kerno shows you what it has learned so you can say so.

Ask your agent once a batch of tests has finished:

```
Show me what Kerno learned from that batch.
```

You get each lesson with what it says, which entry points it covers, and how many runs back it up. For each one you can:

* **Agree.** It matches what you saw. Kerno keeps using it and marks it as checked by you.
* **Amend.** The idea is right and the wording is off. Give Kerno better wording and it uses yours from then on.
* **Disagree.** It should not be there at all. Kerno stops using it and will not write it again.

The review also lists what Kerno's analyses read from your code, covering your repository's documentation, your build, your security setup, and the external services your app calls. Each analysis arrives as several records, one per part, and you judge each one the same way. These records come from reading your code, so they carry no run counts.

{% hint style="info" %}
Reviewing is optional and never holds up a run. Kerno carries on using a lesson you have not looked at, and labels it as unchecked while it does, so you can always tell what Kerno worked out on its own apart from what you confirmed.
{% endhint %}

### How Memory is Stored

Memory is kept as a git history alongside Kerno's working copy of your repository, on your machine. Each entry is a commit whose trailer records the code revision it was learned at:

```
kerno-scenarios | scenario memory: GET /users/me
---
refs/HEAD/d3e136b8ec06451739fe5428789268317b976472
```

Kerno also writes a copy of its memory records, such as lessons, into your repository at `.kerno/memory/`, one Markdown file per record with a header that shows whether it was reviewed, plus a generated `README.md`. The folder is meant to be committed, so your team can review what Kerno learned in pull requests, and Kerno removes any line in `.kerno/.gitignore` that would hide it. The copy leaves your machine only when you commit and push it. Kerno never reads it back.

Two consequences worth knowing:

* Memory persists across agent restarts. Clearing Kerno's cache for the whole workspace erases it, including the potential bugs you told Kerno to ignore, which then get flagged again. The copy in `.kerno/memory/` restores nothing.
* Because entries are commits, older versions remain, so a memory that was recomputed still has its previous value in history.

Every memory is stamped with the exact code revision it came from, so Kerno knows when a memory has gone stale and re-derives it.