SPM SPM Docs

Architecture

One sentence

SPM is a provider proxy with a governed memory plane. Agents send requests to api.spmos.ai; SPM handles memory around each request, and the configured provider serves the inference.

Two planes

Console plane (app.spmos.ai) — accounts, organizations, tenants, API keys, vaulted provider credentials, and subscription and usage metadata.

Request plane (api.spmos.ai) — the request gateway, the authoritative memory store, the derived retrieval index, runtime state, and optional local embedding/reranking.

The request plane has no critical dependency on the console plane. If the console is unavailable, configured keys continue to work because traffic does not pass through the dashboard.

The request chain

client -> edge (TLS, limits) -> gateway
  -> authenticate + resolve tenant/provider
  -> memory recall (lexical + vector legs, fused)
  -> evidence gate (fail-closed)
  -> deterministic compression
  -> provider forwarding (native dialect, streaming)
  -> signed receipt + async ingest

Recall and forwarding are separate stages. The provider does not decide what is remembered, ranked, admitted, or compressed.

Zero-LLM memory

Extraction, ranking, admission, and compression are deterministic. Consequently:

Storage doctrine

The authoritative store holds every memory record, job, receipt, and exact vector. The retrieval index is derived and rebuildable. It can be dropped and reconstructed from the authoritative store at copy speed, so the index is never the sole copy of data.

Failure behavior

When What happens
Cache layer down Rate limiting fails closed (clean 503) and self-recovers; no memory data at risk
Retrieval index down Recall degrades explicitly, never silently; index rebuilds from the authoritative store
Provider down Upstream error mapped to a standard provider error; your retries work
Console down Configured API keys keep serving traffic
Ingest worker down Requests unaffected; jobs queue and drain when the worker returns