elephant
command assembles these into a managed runtime.
Default runtime
meerkat-recall serve runs HTTP, MCP, and managed workers in one process. Workers and
request handlers share the configured storage backend.
The API accepts an ingest and records work. Workers then render evidence, plan
extraction, validate and commit artifacts, and process truth-maintenance events.
The pipeline overview describes that sequence; the
domain model describes the records it produces.
Boundaries that matter
Meerkat provides model execution. Meerkat Recall owns the knowledge schema, policies,
pipeline scheduling, artifact validation, and storage. The MCP server uses the
Rust
rmcp transport. See MCP profiles for the tool surface;
tool visibility also depends on runtime readiness and authorization.
Choose a process and storage layout
meerkat-recall worker rejects the embedded ElephantDB backend: a separate process
would own a different in-memory store. The supplied configuration does not
establish a tested multi-node scaling or high-availability contract. Treat
such a topology as deployment work requiring its own acceptance tests.
Managed embedded storage with a persistent destination synchronizes acknowledged
mutations to a write-ahead log and replays it before startup admission. Shutdown
snapshot export is not the commit durability boundary. Explicitly ephemeral
library/test stores without a persistent destination remain volatile. See
managed embedded commit durability,
deployment and the CLI reference.
Find the implementation
The workspace separates domain contracts from runtime assembly. Start with the smallest owner of the behavior you need to change.
For contribution setup and checks, use development.
For database boundary invariants, use SurrealDB patterns.
For the projection architecture, use Living Wiki.