When you need Verity

When you need Verity — the mechanism-level companion

read this alongside The evaluator-facing version of this — the seven failure modes narrated in full, and the honest 2+-signals test — is Why Verity →. This page is the mechanism-level companion: for each failure mode, the concrete Verity mechanism and where in these docs it is specified, plus the honest edges. It does not repeat the scenario prose or the signals table.

The region Verity is for

The enterprise-website chatbot — where a user logs in and asks about their own account — is the easy case, already solved by a WHERE account_id = you. Verity is for the harder region right next to it, where the moving parts cross a line: 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 negative under a hostile prompt. Why Verity walks that region; below is the mechanism each failure mode maps to.

honest framing Verity is actively developed and pre‑1.0; interfaces may move. The mechanisms below exist and the numbers are measured — not a guarantee that every edge is polished. Where a capability is architected rather than certified, it says so. Every number is quoted verbatim from the honesty log or SPEC.

1 · Leaking across customers → in-index entity scope

The mechanism: the session's entity scope binds to account:acme as a mandatory pre-filter inside the index query — every non-Acme chunk is removed before ranking, so the model never receives what no prompt can then coax out. Enforcement is architectural, not a system-prompt instruction the way separation-by-instruction is (models are injectable). This is the property the scoped-recall benchmark exercises directly: 0 leaked items across 1,220 adversarial probes. Specified in Permissions. (Scenario: Why Verity #1.)

2 · Stale cross-agent handoff → CDC upsert + supersession + activity

The mechanism, three parts: a CRM change arrives over CDC as a deterministic keyed upsert — no LLM, no re-embed in the write path — queryable in ~31 ms; bi-temporal supersession structurally retires the old value the moment the new one lands, so recall returns the current one, not both; and a shared activity timeline lets one agent see another's quote.issued action before it answers. Worked end-to-end in Use cases §2; the write path is in Ingestion. (Scenario: Why Verity #2.)

3 · The security review → per-record ACLs, audit log, scope inspector

The mechanism: source ACLs are inherited into the index, so visibility is per-record and fail‑closed (no visibility → invisible) — the same in-index gate the leakage benchmark hammers, not a prompt instruction. 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. Specified in Permissions. (Scenario: Why Verity #3.)

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.

4 · Revocation & offboarding → ACLs on the content pipeline, revocation tombstones

The mechanism: ACLs ride the same pipeline as content, so a revocation is an event, not a rebuild. A revocation tombstone is written synchronously and fail-closed the instant the ACL change arrives — hiding those items on the very next read, ahead of any asynchronous index rebuild. The drift window closes to the propagation of one event. Specified in Permissions → ACL inheritance. (Scenario: Why Verity #4.)

5 · GDPR erasure → lineage from day one, crypto-shred, retraction cascade

The mechanism: 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. The tiers are in Concepts → memory layers; the cascade in Knowledge layer. (Scenario: Why Verity #5.)

6 · Learning without leaking → the de-identified knowledge layer

The mechanism: 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 — then a human approves every publish; nothing auto-publishes. Only then can the de-identified lesson be recalled inside another customer's entity-bound scope, via the §7g carve-out. What crosses scopes is the pattern, never the particulars. Full treatment on the knowledge layer page. (Scenario: Why Verity #6.)

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, and both are on the record. Source: RESULTS‑anthropic‑judge‑2026‑07‑10.md.

7 · One question, four systems → entity resolution + per-field precedence

The mechanism: one scoped recall over a unified bi-temporal memory. Cross-source entity resolution stitches the four systems' records for that account into one entity, and a deterministic per-field precedence config decides which source wins each field — the highest-precedence source with a current, non-superseded value. The answer is one reconciled brief where every field carries its winning source and its ACL provenance, the same answer every time. See Permissions and Concepts. (Scenario: Why Verity #7.)

The test: do I need Verity here?

The honest test — one agent, one source, one user, one lane means skip Verity; two or more of the six signals holding at once is the region Verity was built for — is stated in full, with the signals table, on Why Verity → the test. It isn't repeated here. When you're in that region, start at Get started, or read the guarantee in Permissions.