SRE · HAM · Build dossier

What the code says

• HAM expands to Holographic Associative Memory: the SRHAM1 file magic and the FastAPI description confirm it, and the core class is HolographicMemory

  Source sre/store/persistence.py

• Embeddings run locally through sentence-transformers clip-ViT-B-32 (about 512 dimensions, text and image); no external embedding API is called

  Source sre/memory.py

• Search encodes the query as a complex one-dimensional wave, then runs a single dense torch.matmul over all stored waves plus topk: a brute-force O(N) scan per query

  Source sre/memory.py

• There is no ANN index (HNSW, IVF, LSH) and no BM25 or full-text path: exact dense scan only

  Source sre/store/search.py

• The C++ extension sre_ext (about 558 lines) covers 3-D interference, Barnes-Hut, defragmentation, a sharding plan and Matryoshka truncation; CI builds it

  Source sre_csrc/grid_interference.cpp

• The Rust workspace is version 15.0.0 with six crates, but Python imports only sre_storage.RustWal; the key sre-tensor and sre-spatial functions are stubs

  Source sre-core-rs/Cargo.toml

• The FastAPI node exposes REST /api/v1 with JWT, RBAC roles, rate limiting and Prometheus metrics, plus OpenAI-shaped /v1 routes

  Source sre/server/main.py

• A measured latency table is committed in the repository: 0.270 ms at 100 records up to 182.379 ms at 100,000

  Source docs/SCIENTIFIC_QA_REPORT.md

Module state

1. implemented

   Holographic memory with dense semantic search

   Local CLIP embeddings, wave encoding and a full-matrix torch.matmul with topk return correct results, and latency grows with corpus size.

   Source sre/memory.py

2. implemented

   A service node with auth, RBAC, metrics and a cluster

   REST /api/v1 and the OpenAI-style routes are implemented and wired: JWT, roles, slowapi, Prometheus, broadcast search and WAL sync.

   Source sre/server/main.py

3. implemented

   .holo persistence with a Rust-backed WAL

   A torch.save snapshot, an optional numpy memmap for large tensors and an append-only JSONL WAL fsynced through sre-storage.

   Source sre/store/persistence.py

4. partial

   Optional native acceleration in C++

   sre_ext holds real kernels, but Python imports it inside a try/except with a torch fallback, so native speed stays optional.

   Source sre/wave.py

5. partial

   The RESP TCP server is a subset

   sre/redis implements part of the protocol over asyncio on port 6379; despite the naming this is not full Redis compatibility.

   Source sre/redis/__init__.py

6. not implemented

   Rust spatial and tensor kernels, and multimodal ingestion

   sre-tensor is a stub and sre-spatial insert() is empty, so its interference returns zero. Only text and images embed, and only Markdown parses.

   Source sre-core-rs/sre-spatial/src/lib.rs

7. on roadmap

   The edge engine: WASM and WebGPU

   docs/RUST_WASM_PORT.md is an explicit phased plan; only the sre-wasm glue and the sre-wave module exist, and edge ONNX embeddings are unimplemented.

   Source docs/RUST_WASM_PORT.md

8. illustrative

   The sre_studio showcase

   Telemetry values come from Math.random under a Simulate live data label, and HologramCanvas is a decorative animation with no link to the engine.

   Source sre_studio/src/components/Telemetry.tsx

How this was checked

• Search is linear, not constant-time

  The package description promises O(1) semantic search, yet every query runs one torch.matmul across the whole db_waves matrix plus topk.

  Source pyproject.toml

• The compute stays in Python

  The docs claim all compute is offloaded to C++ and Rust, but wave.py imports sre_ext with a torch fallback and the matmul runs in Python.

  Source sre/wave.py

• Latencies were really measured and saved

  docs/SCIENTIFIC_QA_REPORT.md holds a table from 0.270 ms (100) to 182.379 ms (100k), which also refutes the claim that 10M documents match 100k on latency.

  Source docs/SCIENTIFIC_QA_REPORT.md

• The showcase is not connected to the kernel

  No sre_studio component reaches the search engine: metrics generate client-side and the visuals are decorative.

  Source sre_studio/src/components/Telemetry.tsx

Limits of these claims

• Retrieval is a brute-force dense scan at O(N); no ANN index for large corpora exists in the code.
• Supported modalities are text and image; audio, video and source-code ingestion is unimplemented.
• The sre-spatial and sre-tensor crates are non-functional: the advertised algorithms return zero or a stub.
• Prebuilt native binaries are platform-specific and untracked, so the extensions must be rebuilt on every machine.
• Version identifiers disagree: pyproject 17.0.0, Cargo 15.0.0, TS SDK 11.0.0 and a FastAPI title of V5.
• The docs call the phase-offset scheme quantum-resistant and speak of homomorphic encryption; in code it is additive offsets derived from a local key.
• The repository is named math-wave while the package distributes as sre-ham; no separate math-wave web product exists inside it.

Why there is no live build

Why there is no live build

There is nothing to publish as a site: the product is a Python library and service. The sre_studio showcase builds with Next.js but renders simulated metrics and is not wired to the engine.