# `Nous.KnowledgeBase.Store.ETS`
[🔗](https://github.com/nyo16/nous/blob/v0.17.1/lib/nous/knowledge_base/store/ets.ex#L1)

ETS-backed knowledge base store implementation.

Uses four unnamed ETS tables (documents, entries, links, slugs) so multiple
instances can coexist. Text search uses `String.jaro_distance/2` for
fuzzy matching on entry content and title.

## Ownership & lifetime (read before "fixing" the `:public` tables)

This store is **intentionally ephemeral and run-scoped**. `init/1` returns the
table references inside `state`, which the caller threads through `ctx.deps`
for the life of a knowledge-base session — there is no global registration and
no supervised owner. When the process holding `state` exits, ETS reclaims the
tables; that is the designed lifetime, not a leak. Persistence across runs is
the job of a different `Nous.KnowledgeBase.Store` implementation, not this one.

The tables are `:public` on purpose: a single KB session is driven from several
processes (the agent loop plus tool-execution tasks all receive the same
`state` and read/write it), so a `:protected` table — writable only by the
process that called `init/1` — would break those cross-process writes. Access
is gated by *possession of the table reference*, which never leaves the
session's `ctx`, rather than by an ETS access mode.

Writes (e.g. `store_entry/2`) are sequences of individual ETS operations, not
transactions. Operation order is chosen so a torn write degrades safely (a
stale slug → a miss), but if you need cross-write atomicity, route writes
through a serializing owner process instead of using this store directly.

# `state`

```elixir
@type state() :: %{
  documents: :ets.table(),
  entries: :ets.table(),
  links: :ets.table(),
  slugs: :ets.table()
}
```

---

*Consult [api-reference.md](api-reference.md) for complete listing*