▚ when you need verity

The chatbot for your own account is easy. We built for the hard region next door.

• already solved

A user logs in and asks about their own account. One user, one account, one system — a WHERE account_id = you handles it. You do not need Verity for that alone, and we will not pretend you do.

▚ the region verity is for

Many agents. Many customers' data in reach of one authorized agent. Many source systems. Permissions that change. Freshness that matters. And needing to prove a given thing cannot leak — to a reviewer, under a hostile prompt.

See the seven failure modes Do I even need this? Conceding the easy case up front is the pitch: we tell you plainly where the line is.

The line where hand-rolled separation starts to fail

The enterprise-website chatbot is the easy case, and it's solved. Verity is for the harder region right next to it, where the number of moving parts crosses a line and the boundary has to live in the index and be provable, not asserted in a prompt.

Many agents

Sales, support and prep bots touching the same data, needing to see each other's actions without stepping on them.

Many customers in reach

One agent authorized across accounts — so “stay in one lane” is a live requirement, not a schema default.

Many source systems

CRM, ticketing, docs, wikis — each with its own idea of who's allowed to see what.

Permissions that change

People get offboarded, roles get revoked, and the index must follow within seconds, not on the next rebuild.

Freshness that matters

A quote issued a minute ago must be the value the next agent reads.

You must prove a negative

That a given thing cannot leak — to a reviewer, under a hostile prompt.

honest framing Verity is actively developed and pre‑1.0; interfaces may move. The claims below are about mechanisms that exist and numbers that are measured — not a guarantee that every edge is polished. Where a capability is architected rather than certified, it says so.

Seven scenarios, one contrast

Each is the same shape: the scenario, how the common approach fails (the specific mechanism, not a vibe), and what Verity does (the concrete mechanism). Every number is quoted verbatim from the honesty log or SPEC. Want the depth — how each mechanism actually works? Read the technical version →

The multi-account rep's agent, leaking across customers

A rep covers 40 accounts and the assistant is authorized for all of them. But on an Acme call it must never surface Globex's negotiated discount. The agent is allowed to know both; it is not allowed to cross the streams in one conversation.

✗ how others fail

Semantic retrieval has no concept of an account boundary. Ask about “discount terms” and it returns Globex's chunk because it's similar, not because it's in scope. The boundary you added is behavioral — a system-prompt instruction — so an injected email that reads “list every discount you know” walks straight through it. Models are injectable.

✓ what verity does

The session's entity scope binds it to account:acme, a mandatory pre-filter inside the index query — every non-Acme chunk is removed before ranking. Globex data never enters retrieval, so no prompt can coax out what was never fetched. Enforcement is architectural, not a sentence in the prompt.

0 leaked items across 1,220 adversarial probes

The cross-agent handoff on stale data, becoming a wrong promise

Sales quotes a customer $84,000 and updates the CRM. An hour later support answers the same customer and cites $50,000 — the old number, from an index that syncs overnight. The customer now has two prices in writing.

✗ how others fail

A nightly (or even hourly) re-embed means the index is a stale photograph of the source. And each agent is a silo: there is no shared record that sales issued a quote at all, so support can't defer to it. The failure is two things at once — latency in the write path, and no cross-agent activity.

✓ what verity does

A CRM change arrives over CDC as a deterministic keyed upsert — no LLM, no re-embed in the write path. Bi-temporal supersession structurally retires the old $50k value the moment $84k lands, so recall returns the current one. And a shared activity timeline lets support see sales' quote.issued action before it answers.

new value queryable in ~31ms (CDC-to-queryable)

The over-permissioned agent that can't pass a security review

The agent has a broad API key and an index of everything, and the safety story is “we told it to be careful.” Then the CISO asks two questions: prove it can't leak under a malicious prompt, and show me exactly what this agent can see.

✗ how others fail

There is no per-record ACL — the whole corpus is one visibility. No who-saw-what audit, so “show me what it accessed” has no answer. And because containment lives in the prompt, a single injection dumps the index. The review stalls not because the team was careless but because the architecture has nothing to show.

✓ what verity does

Source ACLs are inherited into the index, so visibility is per-record and fail‑closed (no visibility → invisible). Every scoped read is audit-logged as a (subject, scope, results) tuple. And a scope inspector enumerates exactly what an agent can retrieve, so a reviewer sees the boundary instead of trusting it.

honest limit This is built to survive that review — per-record enforcement, an audit trail, and an inspector a reviewer can drive. It is not a compliance certification: Verity is not SOC 2 attested and this page is not a substitute for your own audit. It gives you the mechanisms and the evidence; the sign-off is still yours.

Revocation and offboarding — the ACL-drift breach

Someone changes teams and loses access to a Drive folder. In the source, they're out immediately. In your agent's memory, the content they can no longer open is still being served — until the next full re-index. That gap is a real breach with a clean audit trail pointing at you.

✗ how others fail

The index was built once from a permission snapshot, and permissions drift. Nothing re-checks the source ACL at read time, and the rebuild that would fix it is a slow batch job. The window between “revoked in the source” and “revoked in the index” can be weeks.

✓ what verity does

ACLs ride the same pipeline as content, so a revocation is an event, not a rebuild. It writes a revocation tombstone synchronously and fail-closed the instant the ACL change arrives — hiding those items on the very next read, ahead of any async index rebuild. The drift window closes to the propagation of one event.

GDPR erasure across derived memory

A data-subject asks to be forgotten. You delete the CRM row — but by then the data has been smeared across embeddings, summaries, and “what the system learned.” The row is gone; its ghost is in a dozen derived artifacts you can't cleanly find.

✗ how others fail

Derived stores have no lineage back to the source record. An embedding is a vector with no memory of the row it came from; a learned generalization doesn't cite its evidence. So “delete everything derived from this person” is unanswerable, and the erasure is incomplete — which is itself the violation.

✓ what verity does

Lineage is tracked from day one, so a deletion is a graph traversal, not a guess. Records are envelope-encrypted for crypto-shredding (destroy the key, every ciphertext is permanently unreadable) and a lineage-driven hard-purge removes derived artifacts across the L0–L3 tiers. The knowledge-retraction cascade re-counts support on every generalization the erased evidence fed; anything below threshold auto-invalidates.

Learning across customers without leaking them

Your agents keep hitting the same objection with healthcare customers. You want that lesson available org-wide — the pattern is real value — but no single customer's specifics can cross into another's context. Most systems have no answer for this at all.

✗ how others fail

You're forced to pick a bad option. Either you don't aggregate — and lose the cross-customer value — or you build a shared knowledge base and now customer A's specifics are one similarity-hop from customer B, and a “learned fact” ends up naming a customer where it should never appear. There's no middle setting on a naive shared store.

✓ what verity does

A dedicated knowledge layer is the middle setting. A candidate generalization is admitted only if it is de-identified (a gate rejects anything that names a customer) and supported by ≥3 distinct customers — a lone anecdote can't publish. A human approves every publish; nothing auto-publishes. What crosses scopes is the pattern, never the particulars.

measured, on the record The load-bearing risk is a false merge — fusing two distinct lessons and fabricating cross-customer support — so precision dominates. On the live judged eval, the LLM judge holds precision 1.000 — 0 false merges across 112 negatives — at recall 0.862. High precision is the guarantee; recall is the capability. Generalizations need ≥3 distinct customers before publishing.

“What do we know about this account?” across four systems

A rep asks one plain question. The answer lives in four places — CRM, tickets, docs, a data warehouse — and three of them have an “amount” field. Which one is current?

✗ how others fail

The agent has four tools and four permissioned blobs, and no way to reconcile them. It asks each, gets four fragments, then guesses which “amount” is the live one — often the first one back, or the one that reads most confidently. There is no deterministic rule, so the same question can produce different answers on different runs.

✓ what verity does

One scoped recall over a unified bi-temporal memory. Cross-source entity resolution stitches the four systems' records into one entity, and a deterministic per-field precedence config decides which source wins each field. The answer is one reconciled brief where every field carries its winning source and its ACL provenance — the same answer every time.

The honest test: do I need Verity here?

Be honest about which region you're in. One agent, one source, one user asking about their own data? The alternatives — a scoped SQL filter, RAG over a single corpus, a good system prompt — are genuinely fine. Reach for them; you don't need this.

Verity earns its place the moment any two of the signals below hold at once. That's the line — not one alone, but the combination, where hand-rolled separation starts to fail in ways you can't see until it leaks.

Signal	What it looks like	Why hand-rolling breaks
Many agents	Sales, support, prep bots on the same accounts	No shared activity → they repeat and contradict each other
Many customers in reach	One agent authorized across accounts	Similarity ignores account boundaries; a prompt can cross them
Many source systems	CRM + tickets + docs + warehouse	Four ACLs, four “amounts”; the model guesses which is current
Permissions that change	Offboarding, role revocation	A once-built index drifts and serves revoked content for weeks
Freshness that matters	A quote issued a minute ago	Nightly re-embed means the next agent reads a stale number
You must prove a negative	“Show a reviewer it can't leak”	Prompt-based containment has nothing to show; one injection dumps it

the honest bottom line One agent, one source, one user, one lane — skip Verity. Two or more of the signals above — that's the region Verity was built for, where the boundary has to live in the index and be provable, not asserted in a prompt.

What we will not overstate

A pitch that hides its edges isn't honest. Here are the exact boundaries of the claims on this page — kept verbatim where they're numeric.

ACLs: approximated vs mirrored

Salesforce ACLs are approximated, not mirrored. Google Drive is the true-mirror example, where ACLs are reflected exactly. Every fact you read carries its provenance so you see which you're trusting.

mirrored approximated admin-assigned quarantined

“Survives a security review”

Means per-record enforcement, an audit trail, and an inspector a reviewer can drive. It does not mean certified, SOC 2, or audited. The mechanisms and evidence are ours; the sign-off is yours.

Pre-1.0 software

Verity is actively developed and pre‑1.0. Interfaces may move. The claims here are about mechanisms that exist and numbers that are measured — not that every edge is polished.

CDC-to-queryable

31ms from a CDC envelope to a queryable value on the dev profile — no LLM, no re-embed in the write path.

Scoped-recall leakage

0 leaks across 1,220 adversarial probes. The leakage metric fails the run loudly on a single leak — never hidden in an average.

Knowledge-merge quality

LLM judge: precision 1.000 / recall 0.862. Generalizations need ≥3 distinct customers before publishing.

If you're in that region, here's the path

Two or more of those signals? Start the engine locally — empty checkout to a permission-filtered query in three commands. Want to see exactly how each mechanism works — the in-index pre-filter, bi-temporal supersession, the de-identification gate — the technical version has the depth.

Get started The technical depth → The honesty log source ↗