Verity A walk through the product

The company brain that remembers decisions

Verity connects to every tool a company runs, remembers what was true and when, lets people ask and act across all of it from one place, and makes every action checked, receipted, reversible and repairable.

One story, sixteen scenes. Priya, an account manager, connects five apps and works one customer renewal from Monday morning to the moment something goes wrong and gets fixed.

Priya Menon
Account manager, Northwind Software (300 people, B2B software)
Dev Kapoor
Her manager, approves discounts
Meera Iyer
Compliance and risk
Ravi Shah
IT admin
Acme Logistics
The customer; contact Jordan Lee; renewal in 12 days
SalesforceGmail and CalendarSlackZendeskStripe

Fictional companies and people. Chips marked built are live and audited in the current build today; chips marked in build are in the build queue. Press the right arrow to begin.

Receipt R-20931
ActionSalesforce · Opportunity close date
Acme Logistics renewal2026-10-01 → 2026-10-31
Proposed byPriya Menon
Rules checkeddiscount policy v4, renewal contract v2
Approved byDev Kapoor 10:42
Evidence6 facts, fresh at execute
source authenticated  version applicable
facts checked  rule evaluated  action authorized
Partsrule v4 · contract v2 · sfdc 61.0 · model pin 2026-08 · code 7c1e2a9
Undoavailable
1 / 15

Day zero: Verity finds what the company runs and asks permission to connect

Verity · Admin · DiscoveryRavi Shah · admin
Tenants
Connections
Discovery
Roles
Kill switches
Model hub

Scan of Northwind Software, from Okta, Google admin and the vendor list

Salesforce
connect
Google Workspace
connect
Slack
connect
Zendesk
connect
Stripe
connect
Gong
later
32 more apps
dismissed
Proposal: connect Salesforce
Connector
Managed tier (vetted), read only to start
Scopes asked
read accounts, opportunities, contacts, sharing rules
Extra scopes
none — matches the catalogue minimum
Writes
off turning on later needs a fresh consent

Ravi, IT admin. Ten minutes.

Verity reads the company's sign-in system and finds the 38 apps Northwind actually uses, ranked by how sure it is. It connects to none of them. Each one becomes a proposal Ravi approves, with the exact permissions listed, and every connection starts read-only.

Behind the list is a catalogue with three trust tiers: vetted managed connectors, official vendor servers, and community ones that stay off unless an admin allows a specific one with a reason.

Discovery scanConnection proposalsConsent and scope reviewConnection receiptsTrust tiers and allow-listVetted MCP client with pinning

Why this is different

Glean and Copilot connect apps too. Verity treats every connection as a decision with a receipt — who allowed what, which permissions, when — and nothing unreviewed can be plugged in. The audit trail starts before the first fact is read.

Say: "Most tools ask you to wire up integrations by hand. Verity finds them from your identity provider, proposes them, and records the consent. Notice writes are off. That matters later."
2 / 15

Priya says yes once, and the brain assembles itself

Verity · Acme LogisticsPriya Menon · account manager
Ask 1
Do 2
Build 3
Today 4
Approvals 5

One customer, five tools, one record

Acme Logistics account · 214 facts · seen in Salesforce, Gmail, Slack, Zendesk, Stripe
resolved
Renewal amount $84,000 Salesforce · confirmed 9 min ago
authoritative
Close date 1 Oct 2026 Salesforce · confirmed 9 min ago
authoritative
2 open P1 tickets Zendesk · confirmed 14 min ago
authoritative
Invoice 4471 overdue 30 days Stripe · confirmed 22 min ago
authoritative
Jordan replied "let's talk pricing" Gmail · 4 days ago
observed
Dev: "hold the discount until we see the ticket trend" Slack #renewals · 2 days ago
asserted
Likely champion: Jordan Lee derived from email and calendar
inferred
CFO mobile number enrichment vendor guess
hypothesis

What Priya can see

Her 41 accounts, as Salesforce shares them. Her own inbox and calendar. Channels she is in. Nothing else.

Where a fact comes from

Every line keeps the tool, the time it was confirmed, and how much it can be trusted. Old values are never overwritten; they are kept beside the new one.

Priya. One click on a consent screen, then nothing to do.

Verity pulls from the five tools, works out that the Acme in Salesforce, the Acme in Zendesk and the Acme paying invoices in Stripe are the same customer, and builds one record. Each fact carries where it came from, when the tool last confirmed it, and a grade: a number from Salesforce is authoritative, an email is observed, a Slack opinion is asserted, a guess by an enrichment vendor is only a hypothesis.

Permissions come with the data. Verity mirrors what each tool lets Priya see, so she sees her accounts and her colleague sees his.

Entity resolutionBi-temporal ledgerFive evidence gradesPermission mirroringDecision debt (contradictions counted)Org chart and process graph

Why this is different

Glean's memory is an index of documents. Von's is a revenue graph for the CRM. Verity's is a ledger: every fact with a source, a time and a trust grade, and nothing ever overwritten. That ledger is what lets every later scene — approving, undoing, diagnosing, repairing — be exact instead of approximate.

Say: "Look at the right-hand column. The trust grades are the important bit — an AI can never promote a guess to a fact, and a consent rule can never be satisfied by an enrichment vendor's guess. You'll see that rule fire in scene 5."
3 / 15

Monday 9:00 — Today: what needs Priya, with the reason for each line

Verity · TodayPriya Menon
Ask 1
Do 2
Build 3
Today 4
Approvals 5
Your brief

Acme Logistics renews in 12 days1. Two P1 tickets have been open for six days2. Invoice 4471 is 30 days overdue3. Jordan asked to talk pricing on Thursday4 and Dev wants the discount held until the ticket trend improves5. Nothing else on your accounts changed over the weekend.

Signals, highest first

risk
Renewal at risk: Acme Logistics score 82 — overdue invoice, P1 tickets, pricing question, silence 4 days
open
reply
Jordan Lee is waiting on a reply score 61 — reply received, 4 days unanswered
open
quiet
Tidewater deal silent 21 days score 44
snoozed

How the score was built

Invoice overdue
+30
P1 tickets open
+25
Pricing question
+15
No reply 4 days
+12
Total
82

No model chose this. The same facts always give the same score.

Priya. Thirty seconds, coffee in hand.

The brief is written only from facts in the ledger; every number has a footnote you can click. The signals underneath are produced by plain rules — an overdue invoice plus open P1 tickets plus a pricing question is a renewal at risk — and the score shows its own arithmetic.

Grounded daily briefDeterministic signalsKeyboard-first ledgerSignals across tickets, invoices, projects, employees

Why this is different

Copilot and Glean will write you a summary; ask them why and you get another paragraph. Verity's brief cites a fact for every claim and its signals show their arithmetic, because no model is allowed to decide what matters — only to phrase it.

Say: "Everything here is explainable to a manager in one sentence. That is deliberate. When we get to compliance in scene 11, the same property is what an auditor gets."
4 / 15

Ask: one question across five tools, answered with citations and grades

Verity · AskPriya Menon
Ask 1
Do 2
Build 3
Today 4
Approvals 5

What is the risk on the Acme renewal, and what have we promised them?

The renewal is $84,000, closing 1 October1. Two P1 tickets have been open six days2, and invoice 4471 is 30 days overdue3. Jordan asked to discuss pricing on Thursday4; Dev asked to hold any discount until the ticket trend improves5.

Promises on record: a 10% multi-year discount offered in the March proposal6 and a response-time commitment of four hours on P1 tickets in the contract7.

I don't have: what was said on the 9 September call. Gong is not connected, so nothing from calls is in the ledger.

Facts used

1 amount, close date
auth
2 tickets, Zendesk
auth
3 invoice, Stripe
auth
4 email, Gmail
obs
5 Slack, Dev
ass
6 proposal doc, Drive
obs
7 contract, Drive
auth

All fresh within 25 minutes.

Priya. One question instead of five tabs.

The answer is written from the ledger and every sentence carries a footnote to the exact fact, with its grade and how fresh it is. When the ledger does not have something, Verity says so and says why — here, that call recordings are not connected — rather than guessing.

Her colleague Sam asks the same question and gets nothing about Acme, because Salesforce does not share that account with him. The answer is filtered before it is written, not after.

Cited answers that refuse to inventPermission-scoped readsCross-app searchFront door for every employee

Why this is different

Glean also gives cited, permission-aware answers, and does it well. The difference is what the answer is made of: the same ledger the actions run on, with a trust grade and a freshness time on every fact. In Verity, what you ask and what you do agree with each other, because they read the same book.

Say: "Be honest here: search-first products answer questions well. Our edge is not a better answer, it's that the answer and the action share one source of truth — watch what that buys us in the next two scenes."
5 / 15

Do: one sentence becomes a plan, and every step is checked before anything is written

Verity · DoPriya Menon
Ask 1
Do 2
Build 3
Today 4
Approvals 5

Extend Acme's renewal by 30 days at the current price, waive the late fee on invoice 4471, and email Jordan to confirm.

Plan — three steps, three proposals

1 · Salesforce: move close date 1 Oct → 31 Oct, amount unchanged
✓
Renewal contract v2: within a 45-day extension window
✓
Evidence fresh: 6 facts, checked 11 seconds ago
✓
No discount involved — no approval needed beyond Priya's role
2 · Stripe: waive late fee $620 on invoice 4471
!
Discount policy v4: waivers over $500 need a manager's approval — routed to Dev Kapoor
✓
Evidence fresh: invoice still open as of 22 minutes ago
3 · Gmail: send confirmation to Jordan Lee
✓
Consent to email: observed (Jordan wrote first) — an enrichment guess would not have counted
?
Send inside recipient's working hours: unknown — no timezone on record. Needs a reason to proceed.

What will not happen

Nothing is written to Salesforce, Stripe or Gmail on this screen. Each step is a proposal: a preview, the rules it was checked against, and the facts it rests on.

Who decides

The rules are the company's own policy, written once. The AI drafted the plan and the email; it did not decide whether they are allowed.

Priya. One sentence in plain English.

Verity turns the sentence into a plan of three steps and files each as a proposal — a preview of exactly what would change, checked against the company's rules. The date change passes. The fee waiver needs Dev because policy says so. The email is allowed because Jordan wrote first, but one check comes back unknown: nobody knows Jordan's timezone, so Verity will not quietly assume.

Unknown is treated like a stop, not a pass. That single design choice is where most agent products go wrong.

Natural-language actions become proposalsDeterministic rules with versionsDecision contracts per actionEvidence set recorded on the proposalPlan-first execution and outcome checksWorkflows and triggers

Why this is different

Von asks "are you sure?" before it updates Salesforce. Zapier and n8n just write. Agentforce checks Salesforce's own validation rules, inside Salesforce. Verity puts every write from every tool through the same gate: a proposal, a rule set with a version number, and a named approver where policy demands one. It is a pull request for your systems of record.

Say: "Three things to point at: the version number on the policy, the word 'unknown', and the fact that nothing has been written yet. Ask the room how their current automation handles an unknown."
6 / 15

Dev approves in Slack — and the approval dies the moment the facts move

VVerity10:41

Approval needed: waive late fee $620 on Acme Logistics invoice 4471. Proposed by Priya Menon.

Discount policy v4 · waivers over $500 need a manager
Evidence as of 10:41 · 6 facts · fresh
Invoice 4471 · $620 late fee · open · 30 days overdue

Dev Kapoor approved at 10:42. Bound to evidence digest 9f3c…e1 and parts list a71d…04.

Verity · Approvals · executing10:47
Step 2 stopped before writing: the facts changed since Dev looked
- invoice 4471 · status open · balance $620 · confirmed 10:41
+ invoice 4471 · status paid · balance $0 · confirmed 10:46 (Stripe)

Acme paid the invoice at 10:44. The approval was bound to the version of the facts Dev saw, so Verity refused to execute and did not touch Stripe.

Step 1 · close date moved executed 10:47, read back from Salesforce: 31 Oct 2026
verified
Step 3 · email to Jordan Priya gave the reason "Jordan's replies are always 9–11 IST"; sent 10:47
verified

Dev, from his phone. Then something happens that no one planned.

Dev approves the waiver in Slack. Three minutes later Acme pays the invoice. When Verity goes to execute, it checks the facts one last time, sees the invoice is no longer open, and refuses: the approval was for a world that no longer exists. Priya rebases the step, sees the waiver is now pointless, and discards it. The other two steps go through, and each is read back from the tool to confirm the write landed.

The email step needed a reason for the unknown timezone; Priya gave one and it is on the record with her name.

Stale-evidence gateRebaseOverrides with a reason that expire if facts moveIdempotent execution and read-back verificationApprovals in Slack and Teams

Why this is different

No other product binds an approval to the exact evidence the approver saw. In Glean, Von, Agentforce and every workflow tool, an approval is a checkbox; here it is a promise about specific facts, and it expires when they change. This is the difference between "a human clicked yes" and "a human approved this."

Say: "This is the scene to slow down on. Ask: what would your current tool have done at 10:47? Most would have waived a fee on a paid invoice. Some would have refunded it twice."
7 / 15

The receipt: every decision keeps its parts list

Receipt R-20931 · verified
ActionSalesforce · Opportunity close date
Before2026-10-01
After2026-10-31 (read back 10:47:12)
ProposedPriya Menon · 10:39
Authorisedrole policy · account manager
Event timeJordan's request, 9 Sep
Rules in force at event timerenewal contract v2 · discount policy v4
Rules digest3b0e…9a
Evidence6 facts · digest 9f3c…e1 · fresh at 10:47:09
source authenticated
version applicable
facts checked
rule evaluated
action authorized
Connectorsalesforce 61.0
Modeldrafting pin 2026-08 · prompt 5c2a…
Code7c1e2a9
Parts list hasha71d…04
Undoavailable · restores 2026-10-01

Nobody has to do anything. This is what Verity wrote for itself.

Every executed change gets a receipt: what it was before and after, who proposed and who authorised, which versions of which rules were in force at the time the business event happened, the exact facts it rested on, and five separate assurance flags instead of one vague "verified" stamp.

Underneath is the parts list — the rule versions, the facts, the connector version, the AI model pin, the code version. The approval was bound to a hash of this list; if any part had changed between approval and execution, execution would have refused.

Insert-only receiptsFive assurance flagsBefore and after imagesDecision bill of materialsRule versions with effective datesThree clocks: event, valid, knowledgeRun traces and explorer

Why this is different

Audit logs record that something happened. A Verity receipt records why it was allowed, and what it depended on, with versions. That parts list is what makes scene 12 possible: when a rule turns out to be wrong, you can find every decision that used it.

Say: "Compliance people lean forward here. Point at the five flags and say: these are set by five different pieces of code, and none of them can be set by hand."
8 / 15

Wednesday: Acme never asked for the extension. Undo.

Verity · Done ledgerPriya Menon
Ask 1
Do 2
Build 3
Today 4
Approvals 5
R-20931 · Acme close date 1 Oct → 31 Oct executed Monday 10:47 · verified
Undo R-20931 — a new proposal, through the same checks
Restores
close date 2026-10-31 → 2026-10-01 (the before-image on the receipt)
Reason
Jordan's email of Wednesday: "we didn't request a change to the date"
Evidence
current value still 31 Oct — fresh, nothing else changed since Monday
Rules
renewal contract v2: pass
Approval
account manager role — no manager needed
R-20977 · Undo of R-20931 executed Wednesday 14:02 · read back: 1 Oct 2026 · links to R-20931
verified

Both receipts stay forever. Nothing was deleted or edited; the ledger simply gained a row.

Priya. One click and one reason.

Undo is not a delete. It is a new proposal that restores the "before" picture from the receipt, and it goes through the same rules and the same freshness check as any other change. If someone had moved the date again since Monday, the undo would have stopped and shown the difference, exactly like scene 6.

Undo through the governed pathHistory never deletedKill switches per agent, connector, rule or tenantIncident mode: whole company read-onlyAnomaly alarms: bulk edits, odd hours, unusual fields

Why this is different

Reversibility is designed in, not bolted on. Because every write kept its before-image and went through one path, any write can be reversed the same way — one at a time here, thousands at a time in scene 12. Automation tools can only re-run a flow forwards.

Say: "Mention the kill switches now without showing them: one click freezes an agent, a connector, or the whole company into read-only, and the freeze itself gets a receipt."
9 / 15

Build: Priya makes a Renewal Watcher, rehearses it, then lets it run

Verity · Build · AgentsPriya Menon
Ask 1
Do 2
Build 3
Today 4
Approvals 5
Renewal Watcher
Purpose
Watch renewals due in 30 days; propose reminder emails and a task for the owner
May do
read renewals and tickets · propose email (consent observed or better) · propose task
May not do
change amounts, dates or discounts · touch invoices · anything on accounts it cannot see
Mandate
purpose: renewals · expires 14 Dec 2026 · granted by Dev Kapoor
Evidence needed
at least observed for any fact it acts on
Budget
40 proposals a day · $6 a day
Model
drafting pin 2026-08 (a version, not "latest")
Trigger
every morning 08:00, and when a renewal date changes
Dry run against the rehearsal copy — last 30 days of real facts, fake tools
Would have proposed
14 emails · 9 tasks
Would have been blocked
2 — consent only a hypothesis
Would have needed a person
3 — timezone unknown
Writes to real systems
0

On publish

The agent becomes a registered principal with its own identity, its permissions written as dated facts, and its mandate. Every proposal it files carries its name and version.

Rehearsal first, always

A new agent's first run is always against the rehearsal copy. It cannot touch Salesforce until a person has seen what it would have done.

Priya, twenty minutes. No engineer.

She describes what the agent may and may not do, how sure the facts must be before it acts, how much it may spend, and which model version it uses. Then she rehearses it against a copy of the last month with fake versions of the real tools. Only after she has seen the 14 proposals it would have made, and the 2 it would have been blocked on, does she publish.

From then on the Watcher proposes; it never executes. Its proposals land in the same Approvals inbox, checked by the same rules, receipted the same way.

Mandates: purpose-limited, expiringPermissions as dated facts ("was it allowed that day?")Agents propose, never approveAgent builder and sub-agentsDry run against simulatorsBudgets per agentWorkflow builder with triggers

Why this is different

Glean's agent builder and Agentforce give agents tools and guardrails written in prose. Verity gives an agent a mandate with an expiry, permissions that are dated facts, a spend limit that blocks when exhausted, a pinned model version, and a rehearsal room with fake versions of your real systems. "Was this agent allowed to do that on the 9th?" is one query.

Say: "The rehearsal copy is our six simulators — fake Salesforce, fake Gmail and so on, with fault injection. Every feature you have seen was built and tested against them, which is why nothing needs a real account to demo."
10 / 15

Two weeks later the Watcher goes wrong. The Agent Doctor notices first.

Verity · Compliance · Agent DoctorMeera Iyer · compliance
Registry
Policies
Coverage
Receipts
Agent Doctor
Exports
Privacy
31
Renewal Watcher v1 · quarantined 06:12
Verdict below 40 over 50 receipts. Write permissions removed; 6 open proposals held; owner and compliance notified.
Blocked rate
38% (was 4%)
Stale-evidence rate
41% (was 3%)
Verification failures
0
Cost per verified outcome
$1.90 (was $0.31)
Diagnosis · most likely cause: model change
1
Drafting model pin changed 2026-08 → 2026-09 on 22 Sep 05:50 (admin Ravi Shah, receipt R-21402)
2
Since then the agent cites 2.4 facts per proposal instead of 5.1, so the freshness check fails more often
·
Unchanged: rule versions, contract v2, connector versions, Priya's mandate
Prescription — proposals waiting for a person
Roll the drafting pin back to 2026-08 for this agent
Rebase the 6 held proposals from current facts
Register the pattern as a defect so every tenant can screen for it

Meera. Before anyone at Acme noticed anything.

The Doctor gives every agent a health score from its own receipts. When the Watcher's score falls, it is quarantined automatically: it can still read, it can no longer propose, and its open proposals are put on hold. Then the Doctor walks the parts lists of its recent receipts and finds the one thing that changed — someone moved the model pin — and writes the fixes as proposals for Meera to approve. Nothing is fixed behind her back.

Check-up: health score from live receiptsDiagnose from the parts listAutomatic quarantinePrescriptions as proposalsImmunise: defect registerDrift detection after any version changeKill switch it uses

Why this is different

Everyone monitors agents; Glean shows traces, Salesforce shows logs. Verity diagnoses: because every decision recorded its parts with versions, the Doctor can say "the model pin changed on Tuesday and the failure rate followed" instead of "error rate is up". Then it quarantines and prescribes. Nobody else has a parts list to diagnose from.

Say: "Five verbs: check-up, diagnose, quarantine, prescribe, immunise. The last one matters commercially — a confirmed failure becomes a pattern every customer can screen for, without sharing any data."
11 / 15

Compliance console: every agent, every rule version, and an honest coverage number

Verity · ComplianceMeera Iyer
Registry
Policies
Coverage
Receipts
Agent Doctor
Exports
Privacy

Agent registry — everyone who can propose a change

AgentBuilt withOwnerMay write toHealthStatus
Renewal Watcher v1VerityPriya MenonGmail, Salesforce tasks31quarantined
Ticket TriageVeritySupport opsZendesk88healthy
SDR AgentSalesforce AgentforceMarketingSalesforce leads, via Verity79healthy
Knowledge AssistantGleanITread only, via Verity—read only

Coverage — generated from configuration, never typed

Salesforce
6 of 6
Stripe
3 of 3
Zendesk
2 of 3
Gmail
2 of 2
HubSpot (legacy)
0 of 4

Named gaps: Zendesk macro edits still bypass Verity; HubSpot legacy sync writes directly. Verity makes no control claim for these paths.

Meera. The screen the auditor asks for.

Every agent that can propose a change is registered with an owner and its permissions — including the ones Northwind built in Salesforce Agentforce and the assistant it runs in Glean, because both connect to the company's systems through Verity. Rules and contracts have version histories with effective dates. The coverage number is generated from configuration and names the write paths that still bypass Verity, so nobody claims control they do not have.

One button produces the evidence pack for the quarter; another freezes the whole company into read-only during an incident. Privacy is built in for India's data law: every field has a class, consent is a fact, and erasure destroys the key rather than the history.

Coverage reportIncident modeRule and contract versionsMandates and dated permissionsAgent registry incl. other vendors' agentsEvidence-pack exportsDPDP posture: PII classes, consent, crypto-shreddingPolicy as signed code

Why this is different

Glean governs Glean's agents; Salesforce governs Salesforce's. Verity governs all of them, because it sits underneath as the one path to the systems of record and speaks the standard protocol they already use. And it is the only one that will tell you, in a generated number, which writes it does not cover.

Say: "The honest coverage number is a sales weapon, not a weakness. Every competitor implies full control. We show the gaps and the plan to close them."
12 / 15

October: a policy turns out to have been wrong for six weeks. Find everything it touched and fix it.

Verity · Compliance · ReplayMeera Iyer
Discount policy v4 had the wrong threshold: $500 should have been $250 from 1 August
Decisions that used v4
212, from the parts-list index
Replayed under corrected v5
212, from their frozen facts — no tool was written to
Unaffected
175
Affected, correctable
31 waivers between $250 and $500 that should have needed a manager
Affected, needs review
6 — the customer has since churned or the invoice was refunded
DecisionThenShould have beenNowOwnerNext
R-19822 · Corvid Security waiver $410auto-approvedneeded managerfee still waivedDev Kapoorcompensate
R-19901 · Tidewater waiver $305auto-approvedneeded managerfee still waivedAnita Raocompensate
R-20114 · Lumen waiver $480auto-approvedneeded managerinvoice refunded sinceDev Kapoorreview
…and 34 more, grouped by owner

Each of the 31 still passes its own freshness check and rules on execution. Every one gets a receipt that cites this replay. The defect pattern — "threshold rule below the intended value" — is published without any Northwind data so other tenants can screen their own ledgers.

Meera and finance. An afternoon instead of a quarter.

Because every receipt kept its parts list, Verity can look up every decision that depended on discount policy v4, replay each one under the corrected rule using the facts as they were at the time, and sort them: unaffected, correctable, needs a human. The correctable ones become compensating proposals, approved in one batch by their owners, executed through the same checks as everything else. The pattern becomes a defect that other companies can screen for without seeing Northwind's data.

Parts-list index: every decision by every part it usedReplay under a stated rule versionCorrection queue with ownersMass undo through the governed pathDefect register across tenants

Why this is different

This is the reason to buy, and no search product, RevOps assistant or workflow tool can do it: they never recorded what each decision depended on, so "which decisions did this bad rule touch?" cannot even be asked. Glean remembers documents. Von remembers your pipeline. Verity remembers decisions — and can repair them.

Say: "Ask the room what happens today when a rule was wrong for six weeks. The honest answer is usually a spreadsheet, a week, and 'we think we found most of them'."
13 / 15

Where Verity stands next to the tools you already know

CapabilityVerityGleanVon (formerly Rattle)Salesforce AgentforceZapier / n8n
What it remembersA ledger of facts and decisions: source, time, trust grade, versions; never overwrittenAn index of documents and messages, permission-awareA revenue graph over the CRM, calls and warehouseSalesforce dataNothing between runs
Cited answers across appsyes, from the ledgeryes, strongrevenue dataSalesforce-centric—
Actions across appsyes, as governed proposalsyes, agentsSalesforce updates, with a confirmation promptinside Salesforceyes, direct writes
A rule, not a model, decides if an action is allowedyes, versioned, unknown blockspartly: access policies plus AI judging AI—partly: validation rules and flows—
Named approver on every write where policy demands oneyespartlyconfirmation clickpartly, approval processes—
Approval bound to the exact facts the approver saw; expires if they moveyes————
Receipt with a parts list, before/after, five assurance flagsyestraces and logs—audit trailrun logs
Undo through the same checked pathyes————
Agent health, diagnosis, automatic quarantineyes, Agent Doctormonitoring———
Find every decision a bad rule touched, replay, mass-correctyes————
Governs other vendors' agentsyes, via its MCP serverits ownits ownits ownits own
Works underneath the others rather than replacing themyes————

Glean and Copilot are the "brain and hands" of the category and they are good at it. Von is a capable RevOps teammate that asks before it writes. Verity is not trying to out-search them. It is the checkpoint under all of them: the one place where every write is a checked, receipted, reversible decision — and the only one that can repair a decision after the fact. A company that already has Glean keeps Glean and routes its actions through Verity.

The Verity column describes the blueprint. Rows marked "in build" in the feature map are scheduled in the current build run; everything else is live and audited. Competitor descriptions are from their public product pages and documentation.

The one-line version

Glean remembers documents. Von remembers your pipeline. Verity remembers decisions — every one with its evidence, its rules, its approver and its parts — and can undo, diagnose and repair them.

Say: "Never argue that we search better than Glean. Argue that nobody else can answer 'why was this allowed, what did it depend on, and what else did that touch?' — and that we work under the tools they already bought."
14 / 15

The whole product, in plain words

Connect

  • Finds the apps a company runs from its sign-in system, OAuth grants and vendor spend; proposes connections, never self-connects built
  • Consent flows for admins and for each person; every grant and revocation is a receipt built
  • Connector catalogue with three trust tiers; community connectors off unless allowed with a reason; writes off by default built
  • Managed connectors for 1,000+ apps through one adapter in build
  • Official vendor MCP servers pinned by version and hash, sandboxed, with tool-description scanning for injection in build
  • Connector health; unhealthy sources lower a decision's assurance in build
  • Roles and people arrive from the identity provider (SSO, SCIM) as dated facts built
  • Six vendor simulators with fault injection, so everything is tested without real accounts built

Brain

  • Pull, normalise, resolve, derive, serve — one record per customer across tools built
  • Bi-temporal ledger: what was true, when, when learned, from where; never overwritten built
  • Five evidence grades; AI-written facts are always "inferred" built
  • Event time on facts and decisions, so replay uses the rules in force when the event happened built
  • Permission mirroring: each tool's access rules copied as dated facts; reads without a person fail closed built
  • Contradictions counted as decision debt until someone decides built
  • Tickets, documents, projects, invoices, employees, assets, policies as first-class records in build
  • Org chart and "how work flows" graph; personal graph per person; search with filters and full text; freshness and quality scores in build

Ask

  • Answers written only from ledger facts, every number cited, says "I don't have that" built
  • Today: grounded daily brief and a keyboard-driven signal ledger built
  • Deterministic signal detectors with visible arithmetic built
  • One front door for every employee: Ask, Do, Build, Today, Approvals; cross-app search in build

Do

  • Plain-English actions become proposals; nothing writes directly built
  • Propose, rules, approve, execute once, read back to verify, receipt built
  • Other agents can propose through Verity's MCP door, never approve built
  • Plans approved before any step runs; outcome checks after in build
  • Workflows with schedule, event, content-change, form and manual triggers in build
  • Agent builder: purpose, allowed actions, evidence minimum, approval policy, budget, model pin; sub-agents can only narrow in build
  • Rehearsal runs against the simulators before any real system; first run of a new workflow is always a rehearsal in build
  • Budgets for tokens, actions and spend; exhaustion blocks in build
  • Templates per department in build

Govern

  • Rules engine with no model in the decision; unknown blocks built
  • Rule versions with effective dates; every decision records its rule digest built
  • Decision contracts: one signed spec per governed action built
  • Stale-evidence gate; rebase; overrides with a reason that expire when rules or facts move built
  • Five assurance flags and a parts list (decision bill of materials) on every receipt; approvals bind to its hash built
  • Principals for people, agents and services; role-based approvals; mandates with purpose and expiry; permissions as dated facts built
  • Coverage report generated from configuration, naming every ungoverned write path built
  • Agent registry for Verity, Agentforce, Glean, Copilot and custom agents; unregistered agents cannot propose in build
  • Approval routing by role, org chart, amount and risk in build
  • Policies exported and imported as signed versions; evidence packs for a period, an agent or a rule in build
  • Untrusted text labelled and instruction-stripped; connectors scanned; secrets never in prompts in build
  • DPDP: a privacy class per field, consent as facts, purpose mandates, erasure by destroying the key, residency flag in build
  • Model hub with pinned versions recorded on every receipt in build
  • Compliance and admin consoles; every admin change is itself a receipt in build

Protect, trace, doctor

  • Before and after images on every executed write built
  • Undo as a governed proposal; history never deleted built
  • Kill switches per agent, connector, rule or tenant; incident mode; anomaly alarms built
  • Run traces linked to receipts; parts-list explorer in build
  • Agent Doctor: check-up, diagnose, quarantine, prescribe, immunise; drift detection after any version change in build

Repair

  • Index of every decision by every part it used in build
  • Replay under a stated rule version from frozen facts; three-way diff; never writes in build
  • Correction queue with owners; batch approval; compensating proposals through the same path in build
  • Defect register shared across tenants with no data in build

Platform

  • Multi-tenant with database-level isolation; one deployment, many companies built
  • Verity as an MCP server: read tools by default, proposals behind a capability flag, governance never exposed built
  • API and SDK; department views; cloud, VPC or India-region deployment in build
  • Every claim about the product is measured by a script and re-checked continuously; the audit ledger is append-only built
15 / 15

How this starts inside a company

Week 1 — shadow mode, read only

Verity connects read-only, builds the ledger, and watches the writes your existing agents and automations make. Nothing changes in your tools. You get the coverage report, the anomaly list, and the first receipts.

Week 2 — the first governed path

Pick one action that already worries you — discounts, refunds, stage changes, outbound email. Write the rule once. Route that action through Verity. Approvals in Slack; receipts from day one.

Week 3 onward — the brain and the front door

Employees start asking and doing from Verity. Existing agents keep running; they propose through Verity instead of writing directly. Compliance gets the console. When a rule turns out to be wrong, you replay and repair instead of reconciling by hand.

Nothing in this walk needed a real account: every scene runs against the built-in simulators, which is also how the product is tested. Ask to see it live.

What you are buying

Not a better search box and not another agent. A ledger that remembers every decision, a gate that checks every write, and a repair loop for the day one of them turns out to be wrong.

Say: "Close on shadow mode. It costs them nothing, it produces the coverage report in a week, and the coverage report sells the rest."