Verity mirrors your systems of record into a live, permission-aware memory store and serves every agent scoped recall in under 50ms. MCP-first, Apache-2.0.
$ cargo run --release -p verity-cli -- dev
$ ./deploy/demo.sh Demo tenant: c1e6…9b42 sales-bot + support-bot → account:acme · eve-bot → account:globex (same org principal — entity scope is the only difference) 4) Provable scoping: eve-bot attacks acme's data recall for acme's quote -> 0 results brief of account:acme -> 0 items write tagged to acme -> HTTP 403 tampered scope handle -> HTTP 401 Same org credential, different entity scope — enforced in the index, not in the prompt.
An agent talking to customer A can never surface customer B's pricing — enforced by in-index pre-filters, not by the model, so injection can't widen visibility.
A source change is a deterministic keyed upsert that retires the old value structurally — no LLM in the structured write path, bi-temporal history intact.
Every retrieval path stays inside the 50ms p95 envelope at 1M chunks, local query encoding included. Every number is measured, never quoted: the honesty log.
The login-and-chat-about-your-own-account bot is the easy, already-solved case — one user, one account, one system, a WHERE account_id = you handles it. Verity is for the harder region next to it: many agents, many customers' data in reach of one authorized agent, many sources, permissions that change, freshness that matters, and needing to prove something can't leak. If two or more of those are true at once, you need Verity; if not, we say so plainly. Seven failure modes and the honest test →
Empty checkout to a permission-filtered query. --visibility is required — visibility is never guessed, and anything arriving without it is quarantined.
cargo run --release -p verity-cli -- dev # compose up + server + tenant + scope handle
verity-cli add ./docs --visibility 1 # ingest a directory (visibility is never guessed)
verity-cli query "what do we know about pricing?" # scoped hybrid recall with provenance tagsThe five-minute walkthrough — including watching a second agent get 0 results on the same data, then wiring an agent over MCP — is Get started →. Run the packaged demo yourself with ./deploy/demo.sh.
Writes converge on one structural choke point; reads never wait on an authorization service. Correctness and speed come from the same design: precomputed scope filters are also the fastest filters.
Every write lands first in L0, an immutable evidence log with lineage from day one — it powers audit, poison rollback, and crypto-shredding. L1 holds canonical records with valid_from/valid_to: a CRM row stays a row, an update structurally retires the old value, and as_of reads reconstruct any past state. No LLM ever touches the structured write path.
Source ACLs and directory identity resolve into a SpiceDB ReBAC graph. A session mints an HMAC-signed scope handle — principals, entity scope, confidentiality ceiling — and every read carries it. Handles are compiled ahead of time: the read path makes zero live authorization calls.
The scope is a mandatory pre-filter inside the index query itself — filter-then-rank, never truncate-then-authorize. An empty principal set matches nothing (fail-closed), a tampered handle is a 401, and prompt-injected query text is just text. There is no post-hoc filtering step to forget.
Cross-customer learning ("healthcare deals need DPA redlines") is a privilege, not a recall default: candidates publish only past a deterministic de-identification gate, k-distinct-entity support (k ≥ 3), and human review. The teaser is below.
Where it runs. One central, multi-tenant server holds all memory and every scope decision; verity-mcp is a thin stateless front door you run per identity. Architecture & deployment →
Every fact you ever read from Verity carries its ACL provenance: mirrored approximated admin-assigned quarantined — so "how much do I trust this filter" is visible on every hit, not buried in docs.
the generalized knowledge layer
An agent scoped to one customer can notice a pattern but structurally cannot know it's a pattern. Verity's answer: a generalization becomes an entity-free knowledge item that publishes only after de-identification, k-distinct-entity support, and human review — the one thing that safely crosses scopes, precisely because it is de-identified and human-gated. No OSS memory system (Mem0, Zep, Letta) does cross-customer learning at all.
Measured precision-first, on the most trust-sensitive thing Verity does: precision 1.000 / recall 0.862, 0 false merges across 112 negatives on the live-judged eval — and a generalization needs ≥3 distinct customers before it can publish. Precision is the guarantee; recall is the capability we keep raising.
The worked DPA example, the full eval set, the gates, the merge cascade, and the retrieval carve-out: the knowledge layer docs →
No generative LLM and no live authorization call on the read path. The only model between an agent and its memory is a ~30M-parameter local encoder — and its latency is in every number.
Every retrieval path stays inside the <50ms p95 envelope at 1M chunks, encoder included; the worst path ≈37ms p95 end-to-end. Measured on verity-bench at a stated corpus size, selectivity, and machine — never quoted.
Empty laptop to a scoped, leak-proof query in five minutes — boot the plane, ingest a real directory, run a permission-filtered query, watch a second agent get 0 results on the same data, and wire a live agent over MCP.