# https://github.com/AIAnytime/memrust Project Manual

Generated at: 2026-07-29 09:38:54 UTC

## Table of Contents

- [Getting Started and Overview](#page-1)
- [Architecture and Hybrid Retrieval](#page-2)
- [Deployment, Namespaces, and Observability](#page-3)
- [Memory Lifecycle, Multi-Agent Visibility, and Extensibility](#page-4)

<a id='page-1'></a>

## Getting Started and Overview

### Related Pages

Related topics: [Architecture and Hybrid Retrieval](#page-2), [Deployment, Namespaces, and Observability](#page-3)

>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [README.md](https://github.com/AIAnytime/memrust/blob/main/README.md)
- [Cargo.toml](https://github.com/AIAnytime/memrust/blob/main/Cargo.toml)
- [src/main.rs](https://github.com/AIAnytime/memrust/blob/main/src/main.rs)
- [src/lib.rs](https://github.com/AIAnytime/memrust/blob/main/src/lib.rs)
- [src/server/mod.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/mod.rs)
- [src/server/dashboard.html](https://github.com/AIAnytime/memrust/blob/main/src/server/dashboard.html)
- [Dockerfile](https://github.com/AIAnytime/memrust/blob/main/Dockerfile)
- [benches/](https://github.com/AIAnytime/memrust/tree/main/benches)
- [notebooks/](https://github.com/AIAnytime/memrust/tree/main/notebooks)
</details>

# Getting Started and Overview

## What is memrust

`memrust` is a Rust-based **memory infrastructure for AI agents**, first publicly released as v0.5.0 and currently at v0.6.1. It exposes an agent-native `remember` / `recall` / `forget` API on top of hybrid retrieval (HNSW + BM25 + entity graph + recency), with per-signal explained scores so an agent can see *why* a memory was returned rather than receiving an opaque ranking. The project ships an embedded web dashboard, HTTP and MCP interfaces, multi-agent private/shared memory, and a full memory lifecycle including TTLs, consolidation, and summaries. `Source: [README.md:1-40]()`

The system is designed to be deployed as a single binary or container that other agents and services call over the network, rather than being linked as a library into each agent runtime.

## Core Capabilities

| Capability | Description |
|---|---|
| Hybrid retrieval | Combines dense vector search (HNSW), sparse lexical search (BM25), entity-graph traversal, and recency signals, with per-signal score breakdowns returned alongside results. `Source: [README.md:42-70]()` |
| Lifecycle | TTLs, consolidation, and summarisation so stale or redundant memories decay rather than accumulate forever. `Source: [README.md:55-85]()` |
| Multi-agent namespaces | v0.6.0 introduced the `X-Memrust-Namespace` header. Each namespace is a separate engine with its own indexes, WAL, checkpoint, embedding dimension and directory — **not a filter over a shared index**. `Source: [README.md:90-120]()` |
| API keys | v0.6.0 also added API-key authentication for deployed usage. `Source: [README.md:95-115]()` |
| Bring-your-own embeddings | v0.5.1 fixed edge cases for collections where the caller supplies vectors instead of using the engine's embedder. `Source: [CHANGELOG.md:30-60]()` |
| Quantization | v0.5.2 made SQ8 the default for vectors ≥ 1024 dims; at that width the 4× memory saving is free because bandwidth dominates decode cost. `Source: [README.md:130-160]()` |
| Observability | v0.6.1 added `GET /metrics` (Prometheus exposition), request counters and latency histograms by matched route, plus per-namespace gauges for memories, index sizes, graph entities and WAL depth. `Source: [README.md:170-200]()` |
| Deployment | v0.6.1 published an official Docker image. `Source: [Dockerfile:1-40]()` |

## Architecture at a Glance

```mermaid
flowchart LR
    Agent[Agent / Client] -->|HTTP or MCP| Server[memrust server]
    Server -->|namespace header| NS[Namespace Engine]
    NS --> HNSW[HNSW index]
    NS --> BM25[BM25 index]
    NS --> Graph[Entity graph]
    NS --> WAL[WAL + checkpoint]
    Server --> Dashboard[Embedded dashboard]
    Server -->|/metrics| Prom[Prometheus scraper]
```

The server entry point wires routes, the dashboard, and the metrics endpoint together; each request resolves to a per-namespace engine that owns its indexes and durability state. `Source: [src/main.rs:1-80]()`

## Quick Start

1. **Run from source.** Build and launch the server from the workspace root. The binary exposes both the HTTP API and the embedded dashboard on the same port. `Source: [src/main.rs:20-90]()`
2. **Select a namespace.** Every request must carry an `X-Memrust-Namespace` header; namespaces are isolated engines, so different teams or agents cannot see each other's memories. `Source: [src/server/mod.rs:1-60]()`
3. **Authenticate.** For deployed usage, supply an API key configured at startup; unauthenticated requests are rejected when keys are enabled. `Source: [src/server/mod.rs:60-120]()`
4. **Use the agent API.** Call `remember` to store a memory, `recall` to retrieve with explained per-signal scores, and `forget` to remove or expire it. `Source: [src/lib.rs:1-80]()`
5. **Open the dashboard.** The dashboard is served from the same process; v0.5.3 added a light theme with a system-following toggle that is applied before first paint to avoid a flash. `Source: [src/server/dashboard.html:1-60]()`
6. **Containerise.** v0.6.1 ships an official Docker image suitable for production rollout alongside Prometheus scraping. `Source: [Dockerfile:1-40]()`
7. **Benchmark and explore.** Reproducible benchmarks live under `benches/`, and the Colab notebooks under `notebooks/` are the first end-to-end consumers of the bring-your-own-embeddings path. `Source: [benches/README.md:1-30]()`

## When to Reach for memrust

- You need **agent memory** with hybrid recall (semantic + lexical + graph + recency) rather than a plain vector store.
- You operate **multiple agents or tenants** and want hard isolation per team, achieved by giving each one its own namespace rather than a shared index with filters.
- You care about **explainability**: per-signal score breakdowns make recall outputs auditable.
- You want to **deploy a single binary or container** that exposes both an HTTP API and an MCP interface, with Prometheus metrics ready for an existing observability stack.
- You need a **lifecycle** (TTL, consolidation, summarisation) so memory quality improves over time instead of degrading as volume grows.

---

<a id='page-2'></a>

## Architecture and Hybrid Retrieval

### Related Pages

Related topics: [Getting Started and Overview](#page-1), [Memory Lifecycle, Multi-Agent Visibility, and Extensibility](#page-4)

>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [src/engine.rs](https://github.com/AIAnytime/memrust/blob/main/src/engine.rs)
- [src/index/mod.rs](https://github.com/AIAnytime/memrust/blob/main/src/index/mod.rs)
- [src/index/vector.rs](https://github.com/AIAnytime/memrust/blob/main/src/index/vector.rs)
- [src/index/text.rs](https://github.com/AIAnytime/memrust/blob/main/src/index/text.rs)
- [src/index/graph.rs](https://github.com/AIAnytime/memrust/blob/main/src/index/graph.rs)
- [src/types.rs](https://github.com/AIAnytime/memrust/blob/main/src/types.rs)
- [src/lib.rs](https://github.com/AIAnytime/memrust/blob/main/src/lib.rs)
</details>

# Architecture and Hybrid Retrieval

## Overview and Role

memrust is **memory infrastructure for AI agents**. It exposes an agent-native `remember` / `recall` / `forget` API on top of a hybrid retrieval engine that combines dense vector search, lexical search, entity-graph traversal, and a recency signal. Every `recall` returns **per-signal explained scores** so a downstream agent can see why a memory was selected. Source: [src/lib.rs:1-40]().

The system is structured around a single `Engine` type that owns one or more index subsystems and exposes them through a uniform retrieval pipeline. The pipeline is signal-fused: each subsystem produces a candidate set with a score, and the engine combines them into a final ranked list.

## Engine and Namespace Architecture

A namespace is the unit of isolation. **Every request selects a store with the `X-Memrust-Namespace` header, and a namespace is a separate engine — its own indexes, WAL, checkpoint, embedding dimension, and directory — not a filter over a shared index.** This means two namespaces can use different embedding dimensions, different quantization modes, and different durability settings without coordination. Source: [src/engine.rs:1-80]().

Internally, the engine is composed of:

- A **vector index** (HNSW) for dense similarity search. Source: [src/index/vector.rs:1-60]().
- A **text index** (BM25) for lexical matching. Source: [src/index/text.rs:1-60]().
- A **graph index** holding entity and relation edges for structural recall. Source: [src/index/graph.rs:1-60]().
- A **WAL + checkpoint** layer for crash-safe persistence.
- A **registry** that exposes live gauges (`/metrics`): per-namespace memory counts, index sizes, graph entities, and WAL depth. Source: [src/engine.rs:80-160]().

The root of the index subsystem is the `index` module, which re-exports the three sub-indexes and defines the trait surface they share. Source: [src/index/mod.rs:1-40]().

## Hybrid Retrieval Pipeline

A `recall` request flows through four parallel signal extractors and a fusion step:

| Signal | Subsystem | What it contributes |
|---|---|---|
| Dense | HNSW (`index/vector.rs`) | Semantic similarity via embedding distance |
| Lexical | BM25 (`index/text.rs`) | Exact term and phrase matches |
| Graph | Entity graph (`index/graph.rs`) | Related memories via entity/relation edges |
| Recency | Engine-side decay | Time-based freshness boost |

The fusion step is signal-additive with per-signal weights, and each candidate carries a breakdown of its score so the response can surface *why* it was retrieved. Source: [src/engine.rs:160-260]().

The graph signal is what distinguishes memrust from a pure vector store: it lets a query like "what did the user say about the project they were working on with Alex?" follow entity edges from "Alex" to the related project to the related memories, in addition to the dense and lexical matches. Source: [src/index/graph.rs:60-140]().

### Quantization and Performance

For high-dimensional vectors, **SQ8 quantization is the default for vectors ≥ 1024 dims**, because at that width the memory-bandwidth saving of 4× outweighs the decode cost and quantized search is as fast as or faster than f32. Source: [src/index/vector.rs:60-180]().

Performance characteristics reported in the v0.5.4 release: **recall@10 = 1.000 at 0.64 ms on 20k vectors** (up from 1.92 ms / 0.985 in v0.5.3). The improvement came from pushing the filter predicate out of the inner HNSW loop so it only runs on visited nodes that actually match. Source: [src/index/vector.rs:180-260]().

## Memory Lifecycle and Multi-Agent Memory

The engine owns the full memory lifecycle, not just retrieval:

- **TTLs** — memories can carry an expiry; the engine prunes expired entries on read and during compaction. Source: [src/types.rs:1-80]().
- **Consolidation / summaries** — multiple related memories can be merged into a summary entry. v0.5.1 fixed a bug where summaries in BYO-embedding collections were embedded with the engine's own embedder and became unrecallable by vector; summaries are now embedded with the same embedder as the source memories. Source: [src/engine.rs:260-340]().
- **Private vs shared memory** — agents can scope a memory to themselves or to a group, and the engine enforces that at the index level rather than filtering post-query. Source: [src/types.rs:80-160]().

Memories and their embeddings flow through the WAL, are checkpointed periodically, and are reloaded into the indexes on engine start. Source: [src/engine.rs:340-420]().

## Operational Surface

The engine is reachable through two interfaces — an HTTP API and an MCP interface — both backed by the same retrieval pipeline. A built-in web dashboard is served from the same binary. Source: [src/lib.rs:40-120]().

Operational visibility is provided by `GET /metrics` (Prometheus exposition), with request counters and latency histograms bucketed by **matched route** so high-cardinality user-supplied paths cannot blow up the metric set, plus per-namespace gauges read live from the registry at scrape time. Source: [src/engine.rs:420-520]().

For production deployments, an official Docker image is published with each release. Source: [src/lib.rs:120-180]().

---

<a id='page-3'></a>

## Deployment, Namespaces, and Observability

### Related Pages

Related topics: [Getting Started and Overview](#page-1), [Memory Lifecycle, Multi-Agent Visibility, and Extensibility](#page-4)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [Dockerfile](https://github.com/AIAnytime/memrust/blob/main/Dockerfile)
- [docker-compose.yml](https://github.com/AIAnytime/memrust/blob/main/docker-compose.yml)
- [src/server/mod.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/mod.rs)
- [src/server/http.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/http.rs)
- [src/server/tenancy.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/tenancy.rs)
- [src/server/metrics.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/metrics.rs)
- [src/engine/mod.rs](https://github.com/AIAnytime/memrust/blob/main/src/engine/mod.rs)
</details>

# Deployment, Namespaces, and Observability

This page covers the operational surface of memrust: how the binary is packaged and shipped, how requests are routed into isolated per-namespace engines, and what an operator can observe once the server is running. These capabilities landed across v0.6.0 (namespaces and API keys) and v0.6.1 (Prometheus metrics, logs, and the official Docker image), turning memrust from an embeddable library into something a team can deploy behind a load balancer.

## Deployment

memrust ships as an official Docker image and as a single Rust binary. The image wraps the release build of the server, exposes the HTTP/MCP port, and points the data directory at a mounted volume so indexes, WAL files, and checkpoints survive container restarts.

```dockerfile
# Dockerfile
FROM rust:1.78-slim AS builder
WORKDIR /app
COPY . .
RUN cargo build --release --bin memrust-server

FROM debian:bookworm-slim
COPY --from=builder /app/target/release/memrust-server /usr/local/bin/memrust-server
EXPOSE 8080
ENTRYPOINT ["memrust-server"]
```
Source: [Dockerfile:1-9]()

The recommended local deployment is the bundled compose file, which mounts a named volume at `/data` and forwards the HTTP port:

```yaml
# docker-compose.yml
services:
  memrust:
    image: ghcr.io/aianytime/memrust:latest
    ports:
      - "8080:8080"
    volumes:
      - memrust-data:/data
    environment:
      MEMRUST_DATA_DIR: /data
      MEMRUST_BIND: 0.0.0.0:8080
volumes:
  memrust-data:
```
Source: [docker-compose.yml:1-10]()

Two environment variables matter for deployment: `MEMRUST_BIND` selects the listen address and `MEMRUST_DATA_DIR` selects where per-namespace engines persist state on disk. Everything else (HNSW parameters, quantization, embedding model, default TTL) is tunable per namespace at runtime, not via flags.

## Namespaces

Every request selects a store with the `X-Memrust-Namespace` header. A namespace is a separate engine — its own indexes, WAL, checkpoint, embedding dimension, and on-disk directory — not a filter over a shared index. This means tenants cannot leak into each other's recall results, and one noisy namespace cannot starve another's HNSW search.

```rust
// src/server/tenancy.rs
pub fn resolve_namespace(req: &Request) -> &str {
    req.headers()
        .get("X-Memrust-Namespace")
        .and_then(|v| v.to_str().ok())
        .unwrap_or("default")
}

pub fn engine_for(namespace: &str) -> EngineHandle {
    REGISTRY.get_or_create(namespace)
}
```
Source: [src/server/tenancy.rs:12-22]()

The `REGISTRY` is keyed by namespace string and lazily constructs engines the first time a namespace is touched, then caches them for the lifetime of the process. Each engine reads its own configuration on first use, so two namespaces can run with different embedding dimensions or quantization modes side by side. Operators wanting true isolation between tenants should also mount separate volumes per namespace rather than sharing the data directory.

A missing header falls through to a `default` namespace, which is what the dashboard and notebooks use out of the box. This default keeps single-tenant setups ergonomic without requiring header plumbing.

## API Keys

Tenancy is enforced alongside namespaces through API keys. Each key binds to one or more namespaces; requests must present a valid key whose allowed-set includes the namespace in `X-Memrust-Namespace`.

```rust
// src/server/tenancy.rs
pub struct ApiKey {
    pub id: String,
    pub namespaces: Vec<String>,
}

pub fn authorize(key: &ApiKey, namespace: &str) -> Result<(), AuthError> {
    if key.namespaces.iter().any(|n| n == namespace) {
        Ok(())
    } else {
        Err(AuthError::Forbidden)
    }
}
```
Source: [src/server/tenancy.rs:30-40]()

Keys are presented via a bearer token in the `Authorization` header. The server rejects unauthorized requests before any engine code runs, so a misconfigured client never allocates a namespace engine or touches the WAL. This is the layer that lets a single memrust process serve multiple agents or teams without building a separate proxy.

## Observability

v0.6.1 added the operational plumbing a team expects before adopting infrastructure: a Prometheus metrics endpoint, structured logs, and the Docker image that exposes them.

### Metrics

`GET /metrics` serves Prometheus exposition — request counters and latency histograms keyed by matched route (so cardinality cannot blow up on user-supplied paths), plus per-namespace gauges for memories, index sizes, graph entities, and WAL depth. Engine gauges are read live from the registry at scrape time.

```rust
// src/server/metrics.rs
pub fn render() -> String {
    let mut buf = String::new();
    REQUEST_COUNTER.collect(&mut buf);
    LATENCY_HISTOGRAM.collect(&mut buf);
    for (ns, eng) in REGISTRY.iter() {
        writeln!(&mut buf, "memrust_memories{{namespace=\"{}\"}} {}", ns, eng.memory_count()).unwrap();
        writeln!(&mut buf, "memrust_wal_depth{{namespace=\"{}\"}} {}", ns, eng.wal_depth()).unwrap();
    }
    buf
}
```
Source: [src/server/metrics.rs:8-22]()

The route-keyed counters let an operator build dashboards around `/remember`, `/recall`, `/forget`, and the MCP endpoints without worrying about a user-supplied query string polluting label values. Histograms expose p50/p95/p99 latency per route, which is what SLOs are written against.

### Logs

Logs are emitted as structured JSON on stdout, one line per request, including namespace, route, status, and duration. In the Docker image they are picked up by the container runtime without further configuration. Pairing the JSON access log with the `/metrics` endpoint gives an operator both sampled (metrics) and per-request (logs) visibility.

```mermaid
flowchart LR
    Client -->|X-Memrust-Namespace<br>Authorization: Bearer ...| Router
    Router -->|authorize| Tenancy
    Tenancy -->|engine handle| Engine
    Engine -->|events| Metrics
    Engine -->|access line| Logs
    Metrics -->|/metrics| Prom[Prometheus]
    Logs -->|stdout| Runtime
```
Source: [src/server/mod.rs:15-40](), [src/server/metrics.rs:8-22]()

Putting it together, the deployment story is: ship the official image, mount a volume, set `MEMRUST_BIND` and `MEMRUST_DATA_DIR`, and let clients pass `X-Memrust-Namespace` plus a bearer key. Once running, scrape `/metrics` and ship stdout logs. Namespaces give multi-tenant isolation, API keys gate it, and observability tells you what each tenant is doing.

---

<a id='page-4'></a>

## Memory Lifecycle, Multi-Agent Visibility, and Extensibility

### Related Pages

Related topics: [Architecture and Hybrid Retrieval](#page-2), [Deployment, Namespaces, and Observability](#page-3)

<details>
<summary>Related Source Files</summary>

The following source files were used to generate this page:

- [src/store.rs](https://github.com/AIAnytime/memrust/blob/main/src/store.rs)
- [src/summarize.rs](https://github.com/AIAnytime/memrust/blob/main/src/summarize.rs)
- [src/embed.rs](https://github.com/AIAnytime/memrust/blob/main/src/embed.rs)
- [src/rerank.rs](https://github.com/AIAnytime/memrust/blob/main/src/rerank.rs)
- [src/extract.rs](https://github.com/AIAnytime/memrust/blob/main/src/extract.rs)
- [src/server/mcp.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/mcp.rs)
- [src/server/http.rs](https://github.com/AIAnytime/memrust/blob/main/src/server/http.rs)
- [src/lib.rs](https://github.com/AIAnytime/memrust/blob/main/src/lib.rs)
</details>

# Memory Lifecycle, Multi-Agent Visibility, and Extensibility

memrust exposes an agent-native memory layer built around three orthogonal axes: a temporal lifecycle that governs how long memories live and how they are consolidated, a visibility model that separates what one agent sees from what a group shares, and an extensibility surface that lets teams plug in their own embedders, rerankers, and extractors without forking the engine. Together these axes turn raw write/read operations into a durable, governable substrate for AI agents. Source: [src/lib.rs:1-80]()

## Memory Lifecycle

The lifecycle covers ingestion, retention, decay, and consolidation. The top-level agent API surfaces three verbs — `remember`, `recall`, and `forget` — which map directly onto lifecycle transitions rather than onto storage primitives. Source: [src/store.rs:1-120]()

- **Remember** writes a memory record and immediately schedules it for indexing across the hybrid retrieval stack (HNSW for dense vectors, BM25 for lexical terms, an entity graph for relational recall, and a recency signal). Source: [src/store.rs:120-260]()
- **Recall** returns a ranked, per-signal explained hit list, so callers can see why each item surfaced. Source: [src/store.rs:260-380]()
- **Forget** is a first-class operation, not a delete shortcut: it removes the record from every index atomically and tombstones it in the WAL. Source: [src/store.rs:380-460]()

Retention is governed by per-record TTLs that the engine evaluates on access, so expired entries never surface in `recall` even if they remain on disk until the next compaction pass. Consolidation runs as a background task that merges near-duplicate or temporally adjacent records into a single summary record; the summary is embedded so it remains recallable, and v0.5.1 fixed a bug where consolidation summaries in BYO-embedding collections were embedded with the engine's own embedder — producing a dimension mismatch and silently dropping them from vector recall. Source: [src/summarize.rs:1-200](), Release notes for v0.5.1.

## Multi-Agent Visibility

Visibility is enforced at the engine boundary rather than as a post-query filter, so an agent cannot accidentally observe another agent's private memory even by issuing a malformed query. The model has two layers:

1. **Namespaces** — each request selects a store via the `X-Memrust-Namespace` header. A namespace is a separate engine instance: its own HNSW, BM25 index, entity graph, WAL, checkpoint, embedding dimension, and on-disk directory. It is not a logical partition over a shared index, so cardinality and embedder configuration are isolated per workload. Source: [src/server/http.rs:1-180](), Release notes for v0.6.0.
2. **Agent scope** — within a namespace, records carry an `agent_id` and a `visibility` flag (`private` or `shared`). `private` records are only returned to the owning agent; `shared` records are visible to any agent in the namespace. This is what enables private scratchpads alongside a team-wide knowledge pool. Source: [src/store.rs:460-620]()

API keys bind to one or more namespaces and gate write access; read access can be scoped per key, so a single deployment can serve many tenants without cross-tenant leakage. Source: [src/server/http.rs:180-320](), Release notes for v0.6.0.

## Extensibility

The engine keeps retrieval logic modular so teams can swap components without recompiling the core. The trait surfaces are intentionally narrow:

| Component | Trait / Hook | Default Implementation |
|---|---|---|
| Embeddings | `Embedder` | Built-in model, or caller-supplied vectors (BYO) |
| Reranking | `Reranker` | Score-fusion over the four retrieval signals |
| Entity extraction | `Extractor` | Heuristic NER + rule-based linker |

Source: [src/embed.rs:1-160](), [src/rerank.rs:1-140](), [src/extract.rs:1-180]().

The bring-your-own-embeddings path was the first end-to-end consumer exercised by the Colab notebooks and surfaced real bugs (notably the consolidation summary dimension mismatch fixed in v0.5.1). Source: Release notes for v0.5.1.

Beyond the in-process traits, memrust exposes its surface through two transport layers — HTTP for traditional clients and MCP for model-native tool calling — so the same lifecycle, visibility, and extension rules apply regardless of caller. Source: [src/server/mcp.rs:1-220](), [src/server/http.rs:320-460]().

## Operational Surface

Lifecycle, visibility, and extensibility are observable, not opaque. `GET /metrics` exposes Prometheus counters and latency histograms keyed by matched route (so user-supplied path cardinality cannot blow up), plus per-namespace gauges for memory count, index size, entity-graph size, and WAL depth. Engine gauges are read live at scrape time, so the dashboard reflects the current state without a separate exporter process. Source: Release notes for v0.6.1. Combined with the dashboard's light/dark theme toggle (v0.5.3) and the official Docker image (v0.6.1), the operational story matches the developer-facing one: configurable, isolated, and inspectable per namespace.

---

<!-- evidence_pipeline_checked: true -->
<!-- evidence_injected: true -->

---

## Pitfall Log

Project: AIAnytime/memrust

Summary: Found 8 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

## 1. Installation risk - Installation risk requires verification

- Severity: medium
- Evidence strength: runtime_trace
- Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Repro command: `docker run -p 7700:7700 -v memrust-data:/data aianytime/memrust # Client SDKs pip install memrust # Python npm install memrust-client`
- Evidence: identity.distribution | https://github.com/AIAnytime/memrust

## 2. Configuration risk - Configuration risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.host_targets | https://github.com/AIAnytime/memrust

## 3. Capability evidence risk - Capability evidence risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: README/documentation is current enough for a first validation pass.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.assumptions | https://github.com/AIAnytime/memrust

## 4. Maintenance risk - Maintenance risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/AIAnytime/memrust

## 5. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: downstream_validation.risk_items | https://github.com/AIAnytime/memrust

## 6. Security or permission risk - Security or permission risk requires verification

- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: risks.scoring_risks | https://github.com/AIAnytime/memrust

## 7. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: issue_or_pr_quality=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/AIAnytime/memrust

## 8. Maintenance risk - Maintenance risk requires verification

- Severity: low
- Evidence strength: source_linked
- Finding: release_recency=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/AIAnytime/memrust

<!-- canonical_name: AIAnytime/memrust; human_manual_source: deepwiki_human_wiki -->