A memory foundation for agents that outlives the tools on top

Why we built SPM-Polaris as a governed, auditable memory plane — and what "governed" means in production behavior

Veridical Tech, Inc. (SPMOS) · 2026-09-16 · First-party engineering notes with named scopes and dates

Most agent stacks today are careful about model portability and careless about memory portability.

Inference is one environment variable away from another provider. But the knowledge an agent accumulates — customer context, operational facts, decisions captured from conversations — typically lives inside whichever framework, assistant, or SaaS suite the team adopted first. When the platform changes (and platforms change), the memory doesn't migrate; it gets orphaned or abandoned.

SPM-Polaris is our answer to that layer: a hosted, governed memory plane that any agent reads and writes through MCP or OpenAI-compatible APIs, independent of the agent framework, the collaboration platform, and the model provider. This note describes the production behaviors, with the same scope discipline we apply on our public pages.

Governance as concrete behavior

Admission and refusal are deterministic code. Memory candidates are evaluated against tenant, namespace, scope, provenance, and evidence rules before anything reaches the model. If the gate fails, the system returns UNKNOWN with a gate reason and injects nothing. No generative LLM participates in admission, compression, lifecycle, refusal, or receipts — compression adds zero LLM calls. When deep recall reviews evidence, the selector/verifier run on SPM-operated models (never the user's provider), and only the answer-generation call appears as provider tokens on the request receipt.

Provenance is attached at write time. Every memory is stamped user, assistant, or derived. Conflicts resolve by authority rank, and the model can never promote its own claims. A lane_policy parameter separates deliberate saves from passive captures (explicit_first / blended / observed_only) — accepted today, with server-side lane ordering rolling out behind a paired evaluation gate.

Evolution keeps lineage. Related facts consolidate into observations that present the current state with history preserved — "uses Vue (previously: React)" — with proof counts and provenance attached. Nothing is silently overwritten. Auto-captured ambient content passes a quarantine ring before promotion into long-term memory.

Isolation is structural. One API key with the memory:partition scope serves many end users; partitions are fenced across writes, recall, evidence reads, and read tokens. Row-level security, namespace fences, and token replay protection run in the request path.

Deletion is verifiable. Each successful purge returns an HMAC-SHA256 signed receipt stored with the purge record — counters, scope, and key id included. Deleted identifiers are never reused within the same memory generation, so a stale receipt cannot resurrect purged content. For GDPR-style erasure requests, "we deleted it" becomes demonstrable.

Recall economics

Recall is tiered: fast, auto (default), and deep. The fast path recalls with dedicated embedding and reranking models only — zero generative cost. Auto routing sends only low-confidence queries to deep, multi-round evidence collection; deep spend (rounds, selector tokens, latency) is reported on every response. One bounded observation from our benchmarks page: a single eligible hosted request reduced provider input from 66,265 original tokens to 365 forwarded tokens — an example with a named scope and date, not an average or a savings guarantee.

Integration boundaries

Three paths, one memory plane:

Scope discipline

The memory plane is hosted. We publish only bounded first-party observations with named scopes and dates — no leaderboard claims, no universal latency or accuracy numbers. If you evaluate SPM-Polaris, we recommend starting from the frozen probe sets and methodology on the benchmarks page and reproducing against your own workload.

Links