[event memory 2/6] Rename the segment store to the event memory store (port of #1659's rename) - #1686

…tion

A vector store's schema is fixed when the store is built, so EventMemory
takes it as a parameter, the same schema the composition root built the
vector store with, rather than reading it from each partition it opens.

- EventMemoryParams gains `store_schema`. EventMemory checks once, at
  construction, that the schema declares the fields EventMemory requires,
  and hands each partition handle the declared fields and the similarity
  metric. A handle's `similarity_metric` and its score direction come
  from them.
- The service locator builds the vector store and EventMemory from one
  schema, `event_backend_store_schema`.
- `VectorStorePartition` no longer has a `store_schema` property; each
  store's partitions keep the schema privately.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

LongTermMemory has had a single search since its unscored `search` went,
so `search_scored` no longer tells it apart from anything. It is `query`,
as the calls above and below it are: EpisodicMemory.query_memory and
EventMemoryPartition.query. Its two backend branches are
`_query_declarative` and `_query_event`. DeclarativeMemory keeps
`search_scored`, which it tells apart from its unscored `search`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`_declarative_params` was one statement and `_event_params` a block with
one caller, each standing between `long_term_memory_params_from_config`'s
match and the work it routes to. The work now sits in the match arms, as
it does in `delete_long_term_memory_storage` beside it. `_declarative_memory`
and `_event_memory` stay, since building and deleting both use them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Once the service locator built each backend's memory, the two backend
params differed only in that memory: a DeclarativeMemory, or an
EventMemoryPartition with the episode storage that turns its results into
episodes and the reranker that sets its score direction. LongTermMemory
now takes the memory itself, with those two as keywords, and each request
matches on the memory's type. An EventMemoryPartition without episode
storage is refused when the LongTermMemory is built.

DeclarativeBackendParams, EventBackendParams, their union, the backend
literal, and the session id, which nothing read, go. The service locator's
`long_term_memory_from_config` builds the LongTermMemory in each match arm,
and the episodic service locator takes it from there. The evaluation
helper passes its DeclarativeMemory directly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The episodic service locator's `delete_episodic_memory_storage` only
checked whether the stored configuration builds long-term memory and
passed it on. EpisodicMemoryManager.delete_episodic_session now makes that
check and calls `delete_long_term_memory_storage` itself, so deleting a
session goes from the manager straight to the long-term layer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Event memory bounds when its vector writes are sent by cancelling an
upsert at a deadline, which needs a written guarantee of what cancelling
does. VectorStorePartition.upsert now states that cancelling the call
stops it from sending further requests to the backend, and that a
request already sent may still be applied, so a cancelled upsert may
have written some of the records. RegistryBackedVectorStorePartition's
`_upsert` hook states the same obligation for its implementations.

Every implementation honors it:

- RegistryBackedVectorStorePartition awaits the registration check,
  `_upsert`, and the check again in sequence, so a cancellation stops at
  the await it lands on.
- Qdrant and Milvus await each request, and send the halves of a batch
  the server refuses as too large one after another, so a cancellation
  raised in a request ends the call. Neither client catches
  CancelledError: qdrant-client's REST path catches Exception only, and
  pymilvus's retry decorators catch grpc.RpcError, MilvusException, and
  Exception, so a cancelled RPC surfaces as CancelledError and is not
  retried.
- sqlite-vec writes in one transaction. A statement already queued to
  aiosqlite's thread finishes there; SQLAlchemy treats the cancellation
  as a disconnect and invalidates the connection, so the transaction
  never commits and nothing more is executed on it.
- The engine-backed SQLite store commits its records and pending
  operations, then applies them to the search engine, then marks them
  applied. A cancellation in the engine step leaves the operations
  pending, and startup replays them.
- The in-memory test partition has no await in its upsert.

Tests cancel an upsert mid-call and check that nothing more goes out:
for Qdrant and Milvus with a fake client that refuses the batch as too
large and holds its first half (the second half is never sent, and the
registration is not checked after it), and against the server (the
request in flight; for Milvus counted at the gRPC stub, so a pymilvus
retry would show); for both SQLite stores, cancelling at the upsert's
first statement, and for the engine-backed one also while its search
engine applies the records, no further statement executes.

Verification: ruff, ruff format, and ty clean; the vector store unit
tests, 401 passed, 5 skipped. The fake-client tests fail when the
halving swallows the cancellation and sends the second half. The
integration tests need Docker and were not run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…forgets

The segment store and the vector store share no transaction, so an ingest
that stopped after storing its events left them unsearchable, and a forget
racing an ingest or a late vector write could leave vectors of forgotten
events behind.

The segment store now holds the events themselves, and two queues of work
the vector store still owes:

- Pending derivatives: an ingest stores its events, segments, derivative
  links, and one pending record per event in one transaction, upserts the
  vectors within a write budget, and deletes the record. A record left
  behind is claimed by any process once the budget has passed, and
  written again within a budget of its own.
- Tombstones: a forget locks its events, deletes their pending records,
  records the derivatives it unlinked in one tombstone, and deletes the
  events in one transaction. The vectors are deleted at once and again
  after the tombstone retention, which outlasts any write sent within
  its budget.

Claims hold a lease, back off doubling on failure, and stop after
repeated failures, which is logged. A search drops a hit with no link
and deletes its vector once, best effort. Partitions are deleted from
the segment store first. Each purge call stays within its bound across
segments, events, and the derivatives tombstones name.

design/event_memory_ingest_and_deletion.md gives the protocol and why
it is safe.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

EventMemory's background work claims pending derivatives and tombstones
from the whole segment store database, and its records name no vector
store or embedder: it writes and deletes with its own. That is right only
if one EventMemory serves every partition in the database, and only if it
runs whether or not a session is opened.

The resource manager now builds the deployment's EventMemory from the
episodic memory's long-term memory configuration, starts its background
work, and shuts it down on close. The server builds it at startup when
that configuration names a segment store. A session opens its partition
on it, and the deployment's segmenter, deriver, and reranker serve every
session.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…deployment

The deployment's one EventMemory serves every event session with its own
segmenter, deriver, and reranker, so the copies a session saved no longer
apply. The session's event configuration no longer has those fields, and
rows saved earlier load with them ignored; creating a project checks a
reranker only on the declarative backend.

A project's `reranker` applies to the declarative backend only, as its
description now says, and an event project's response names none, as for
`embedder`. The OpenAPI document is regenerated for these fields only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Adding events and claiming pending derivatives and tombstones depend on
RETURNING, which SQLite added in 3.35: the event insert returns the
events it stored, and each claim returns the row it took. The store's
params refuse an older SQLite runtime, after the check that each session
gets its own connection to one database, and a test raises the minimum
past the runtime to see the refusal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…tamp under it

MemMachine and its users share one property key space. A key beginning
with `memmachine_` now belongs to MemMachine: `reserved_property_key`
builds one as `memmachine_<system>_<field>`, and every key is a valid
vector store identifier, `[a-z0-9_]` and at most 32 bytes.

EventMemory writes its timestamp under `memmachine_em_timestamp`. It
refuses an event whose property key is reserved or not a valid
identifier, through `validate_user_property_key`; a key is used exactly
as given, never rewritten.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

An EventMemory filter, and a segment store's, named a property in two
ways: `m.<key>` for the key itself, and a bare name for `_<name>`, the
layout one consumer gives its own fields. The bare form tied both to
that consumer's keys.

A filter field is now `timestamp` or `m.<key>` (or `metadata.<key>`).
EventMemory refuses any other field before it searches, and the segment
stores refuse it as well. The vector search filters on the timestamp,
under its reserved key, and on the declared properties. The long-term
memory adapter names its system fields as properties when it hands a
filter to EventMemory, so its client filters are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

MemMachine reserved two key namespaces at once. EventMemory refused a
property key beginning with `memmachine_`, while the long-term memory
adapter wrote its own fields under a leading underscore and refused a
caller key beginning with one. So a caller could not use an underscore,
and the adapter's fields sat outside the namespace meant for them.

The adapter now writes its fields under `memmachine_ltm_<field>`, and
refuses a caller key that is not a legal user property key. A filter
still names a system field by its bare name, and refuses a `m.<key>`
in the reserved namespace.

The reserved namespace is divided by the system that writes each key.
EventMemory refuses only its own `memmachine_em_` keys, in an event
and in a filter, so the component that embeds it can write its own
reserved keys. `is_reserved_property_key` takes the system to ask about
one system's keys.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

An episode's metadata keys become event properties, and the event
backend refuses a key that is not a legal user property key. That
refusal came while the episode store and semantic memory were writing
the same episodes in parallel, so the request failed after they had
kept them, and a request over HTTP got a 500.

`MemMachine.add_episodes` now checks every metadata key of every entry
with `validate_user_property_key` before it writes anything, and the
add-memories route answers a ValueError with 422, as the other routes
do. The metadata field's description states the key rule.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The metadata field's description gives the key rule in words instead
of a pattern. EventMemory's filter check and the adapter's conversion
state what holds for a reserved key, and `MemMachine.add_episodes`
says its refusal comes before any store is written.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

EventMemory and the segment stores spelled out how a client names a
property in a filter, and EventMemory checked a filter's fields against
that spelling before it searched. The spelling belongs to the filter
language and to the API that accepts a client's filter.

EventMemory no longer checks a filter's fields: the long-term memory
adapter checks a client's filter, and the segment stores refuse a field
that names neither a property nor the timestamp. For the vector search,
EventMemory translates the timestamp to its reserved key and a property
to its key, and passes any other name unchanged. The docstrings describe
a filter over the segments' properties and timestamp.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…hine#1597, without session)

The part of MemMachine#1597 that is not session: events and segments carry a
nullable source id; query and expand take since/until and source_ids;
expand walks outward from a seed, which is an address located whatever
the filters say, and returns a Neighborhood that excludes it; query
answers QueryHits (score, seed, neighborhood); rendering is
render_segments with a DateTimeFormat; the segment store answers
get_segments and get_segment_neighborhoods in place of
get_segment_contexts; the v2 adapter lifts timestamp/created_at bounds
and producer_id conjuncts out of the filter into the typed parameters;
the timestamp column holds a UTC instant.

On this base:
- A neighborhood is MemMachine#1713's walk: the partition's order next to the
  seed, filters applied inside its window of 1,000 segments per side.
  The ordering index keeps main's shape.
- The vector stage gets MemMachine#1684's predicates on the reserved keys and,
  joined with AND, the part of the property filter that names declared
  fields alone, as MemMachine#1702's `extract_filter` routing has it; the segment
  store still gets the whole filter, and its seed lookup leaves out a
  seed the filter rejects. A record's declared properties are its
  event's, which every segment carries unchanged, as the segmenter
  contract now states.
- On the event memory recovery PRs (MemMachine#1839, MemMachine#1840), the data operations
  and expand are EventMemoryPartition's, and rerank and render_segments
  are static on EventMemory; the reranker leaves EventMemory's
  parameters, since LongTermMemory reranks with the deployment's. A
  pending derivatives record holds its event's properties once
  (segment_store_pd), and its derivatives their source id and no
  context (segment_store_pd_dv), following Derivative, so encode and
  the background work build a record from the same properties. The
  search's cleanup of unlinked records stays a helper of its own.
- On MemMachine#1828's key rule, the source is EventMemory's own reserved key,
  `memmachine_em_source`, which `source_ids` reaches. A timestamp
  condition in the filter still reaches the vector search under its
  reserved key, beside the since/until predicates.
- Episode uids are UUIDs since MemMachine#1707: the search path reads each hit's
  episode uid back as a UUID, and the tests key their episodes by
  `_uid(name)` as main's do.
- Session and block kind are split out: the block kind column,
  parameter and record key go to the kinds PR, which is their first
  consumer, and session goes to its own PR.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YBbQgZiCqeoLu83EkbEFHE

Mechanical: the store now holds events, segments, links, pending
derivatives and tombstones, so its name follows its dependent.
`SegmentStore` and every derived name become `EventMemoryStore` and
theirs, the module and test directories move with them, the tables and
indexes take the `event_memory_store_` prefix, and the configuration key
`segment_store` becomes `event_memory_store` in the API spec, the client,
the docs, the sample configs, the Helm chart and the compose files. No
behavior changes; tables are recreated. Applied by the same
substitutions to this tree rather than rebased.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YBbQgZiCqeoLu83EkbEFHE