Data & security

Reads where your data already lives. Proves every action without asking you to trust the database.

Vyom reaches into the systems you already run, matches the right connector to each kind of source, and folds your records and the outside world into the one model your company runs inside. Your data never moves. Learning shared across companies is patterns, never records. And every action an agent takes is authorized against policy and written to a log your own browser re-verifies on its own math.

Reaching your systems

The right connector for each kind of source, all feeding one place.

The environment reaches into your stack where it already lives, and it meets each system on that system’s own terms. Every source type gets its own connector, built for how that system actually works. Whatever the source, it lands as the same thing: a dated, sourced observation attached to the part of the business it touches, ready to enter the one model everything else on this page is built on. The badges are honest about what runs end-to-end today versus what’s built and waiting on a live hookup. We put that distinction up front rather than in a footnote.

Source typeHow it connectsLatency
Modern SaaSProcore, QuickBooks, Salesforce, Slack, Stripe, GitHub, Notion, over OAuth and native APIs. You authorize with the vendor; Vyom reads through the interface they expose.near real-time
DatabasesRead off the transaction log: logical replication on Postgres, the binlog on MySQL. Every insert, update, delete as it commits. No table polling.sub-second
OT / plant floorOPC-UA, Modbus, and MQTT edge agents meet industrial systems on their own protocols.100ms–1s
High-frequencyPush-first over WebSocket and webhooks instead of a poll interval.sub-second
DocumentsContracts, filings, scanned records parsed into structured evidence.batch / async
The model everything runs on

Internal and external signals, one causal model. This is the spine of the page.

Everything else here is this. Isolation is the boundary this model holds. Federation is this model getting sharper. Audit is this model proving what it did. Read the sections below as different sides of the same structure, not separate controls. Most tools keep your data in one place and leave the outside world in another dashboard you have to read yourself. Vyom folds the two together. Your jobs, invoices, schedules, and change orders enter the same model as the weather over your sites, commodity prices, macro rates, regulatory filings, and news. They arrive through different connectors, but they don’t just land side by side. Each external signal is interpreted through the causal model before it enters: assigned to the nodes it affects, given an effect prior, and scored for confidence. That grounding is what turns a forecasted freeze into a reasoned threat to a specific concrete pour, or a steel-price move into a reasoned change to a live bid. You get a causal chain instead of two widgets sitting next to each other. And every observation carries its source, so you always see whether a number came from your live systems or from a starting estimate.

The boundary it holds

One tenant can’t see another’s data. Access is decided by policy, denied by default.

For the model to be one world per company, the boundary around each company’s copy of it has to hold. Two questions come first in any security review: can one customer reach another’s data, and how do we control what our own people see. Isolation is enforced, not trusted. Every query is scoped to its tenant and checked before it runs, and a query that isn’t correctly scoped fails closed rather than returning a row. Above it sits an attribute-based policy engine: access is denied unless a rule explicitly permits it, and every decision is explainable. Enterprise sign-in maps a verified identity from your provider to a Vyom principal in the right tenant. SCIM ties access to your HR lifecycle, so a termination revokes access without manual cleanup.

Tenant isolationScoped & checked on every read; fails closed
Policy engineAttribute-based, deny-by-default, explainable
SSOOkta, Azure AD, Google via Clerk
SCIM provisioningTied to your HR lifecycle
StatusEngine & bridges built & verified; your IdP hookup is a setup step per partner
How it sharpens

Learning that shares patterns, never data.

The same model that stays inside your boundary also gets sharper as more companies run on it, and that never means your data leaves your control. What crosses between companies is patterns rather than records: the strength and direction of a causal relationship, expressed as statistics, with formal differential-privacy noise added before anything is released. Adding or removing any single company changes the shared result by a bounded, provable amount, so no one company’s contribution can be reverse-engineered. Three controls sit in front of release.

DP noise
A Gaussian differential-privacy mechanism bounds any single company’s influence on the released result.
Minimum cohort
A pattern isn’t released until a minimum number of distinct companies have contributed, so no small pool can expose one member.
No identifying fields
Before any contribution is counted, it’s checked to carry no identifying fields.

So a new company starts with priors learned across the field instead of from zero, and no company ever sees another’s numbers.

How it proves what it did

Every governed action authorized, signed, and re-verified in your browser.

Because the model acts, not just reports, every action it takes has to be provable. Before a governed agent acts, the action is checked against policy (who may do what, on which resource, under which conditions) and denied by default unless a rule explicitly permits it. Once it runs, it’s written to a tamper-evident log: each entry is hash-chained to the one before it, so altering or deleting any record breaks the chain and the break is visible. Entries are also rolled into a Merkle tree, which produces a single root that stands for the whole log. Your browser re-verifies the full chain and recomputes that root on its own math, so you confirm the record without trusting Vyom’s database. Browser and server use the identical construction, and parity is proven in our CI.

Live audit ledger · try to tamper with it ● real SHA-256, computed in your browser
Ledger root · stands for the whole log

Each row is a governed action Vyom took, hashed together with the one before it. Change a single character in any value and that record and every record after it turn red, and the root stops matching. This is the same check your browser runs on the real log, so you confirm what happened without trusting our database.

To defend against a compromise of Vyom’s own servers, the root can be published to an external witness (OpenTimestamps or immudb). Until a witness is configured, the log reports its tamper-evidence honestly as unwitnessed, rather than claiming a guarantee it doesn’t have.
The floor beneath it

Keys stay in the vault. Data is encrypted. Deletion is complete, with one named exception.

The rest is the plain hygiene under all of it. Secrets go straight to an encrypted vault, AES-256-GCM; the setup flow never sees the value. OAuth tokens are authorized with the vendor; the token lives in the vault. In transit, TLS everywhere. Access is policy-as-code: explicit permissions, every denial logged. Data is labeled by origin, so a live figure is never shown as a prior, or the reverse. Deletion is complete: records are erased from Convex and Postgres automatically, and the Neo4j graph is cleared on request.

SecretsStraight to an encrypted vault, AES-256-GCM. Setup flow never sees the value
OAuth tokensAuthorized with the vendor; token lives in the vault
In transitTLS everywhere
AccessPolicy-as-code: explicit permissions, every denial logged
Data labelingLabeled by origin: a live figure is never shown as a prior, or the reverse
DeletionRecords erased from Convex & Postgres automatically; Neo4j graph cleared on request
The rules around it

Where your data lives, how long it’s kept, and where we are on certification.

The mechanisms above prove how the environment behaves. This is the governance a procurement team asks for, stated plainly, including what isn’t done yet. Data residency is enforced, not promised: set a region and the router never serves a read or write from outside it. A request that can only be satisfied across the boundary is refused rather than allowed to leak, the same fail-closed discipline as tenant isolation. Retention is bounded: backup snapshots expire within 90 days under the default policy. Erasure removes a tenant’s records from the primary stores automatically and the graph on request. The one deliberate exception is tamper-evident audit history, kept for accountability; erase the tenant itself to remove that too.

On formal certification, we are direct
Vyom is pre-seed and not yet SOC 2 or ISO 27001 certified. The controls those audits look for are built and running: encryption at rest and in transit, policy-as-code access with logged denials, tenant isolation, tamper-evident audit. The audit itself is on the roadmap, timed to the first enterprise deployments. If you need a specific framework, region, or sub-processor list to move forward, that’s a conversation we have directly in the design-partner program.
Design partners

We’ll walk this against your stack.

Become a design partner and we’ll walk the connector architecture, isolation model, residency and audit chain against your specific systems, and share our compliance roadmap and sub-processor list. Or see how the model reasons over this data.

Request access   See the platform →