The question that settles a governance conversation
Ask any vendor: if someone connects a Postgres client directly to your platform instead of using your console, what enforces the policy? On most platforms the honest answer is “the catalog, if they go through it.”
Here the wire re-enters the same authorizer, and the predicates are compiled into the plan before the engine runs it, across SQL, OLAP, graph, document, key-value, search, stream and vector alike.
| Stage | What happens |
|---|---|
| Request | From a BI tool on the PostgreSQL wire, a notebook or query kernel, an agent inside the cell, or a Redis-protocol client. |
| Security context | Built from the request: the entity, its grants, its clearance, and any purpose declared for the access. |
| Resolution | Policies resolved with deny taking precedence. |
| Compilation | Engine-native predicates and projections emitted; masks bound as functions. |
| Enforcement | Applied inside each engine type (SQL, OLAP, graph, document, key-value, search, stream and vector) beneath the query rather than in front of it. |
| Result | Masks applied to what remains, lineage captured into a per-cell tamper-evident chain, usage metered, and a read-audit event recording who looked. |
What the area contains
Engines and the structure surface
A multi-model engine over transactional and analytical stores, with document, property-graph, vector and time-series providers on one substrate. Alongside it, a data-structure engine with a native Redis-protocol server, your existing clients connect over a raw socket and gain classification, workspace scoping, authorization, audit and cross-cell replication that a cache does not give them.
The wire is not an authorization bypass. It is deny-by-default until the connection authenticates, and every command re-enters the same engine-boundary authorizer the HTTP surface uses.
Catalog, lineage and contracts
Three-level naming across every engine, column-level lineage extracted by parsing queries, impact analysis, tag propagation that pushes labels through lineage, and classification propagation that makes a downstream table inherit the highest sensitivity of its sources.
Lineage capture is deny-by-default: a mutation that cannot be lineage-captured can be rejected rather than silently proceeding, and gaps are recorded as first-class events.
Lakehouse in open formats
Iceberg and Delta both write (append, overwrite, replace, delete, merge, with position deletes and deletion vectors) over a format-agnostic core, plus bidirectional metadata conversion, a REST metadata catalog, and the Delta Sharing protocol as both server and client.
Open formats mean your data outlives your contract with us. That is the point of them.
Pipelines and ingestion
A distributed pipeline fabric where one partition runs on one cell and a logical flow spreads across many, with leasing, draining, staging, backfill, dead-letter remediation and schema-drift healing. A declarative DSL with quality expectations, and transformation projects in the vocabulary analysts already use.
The generated SQL still executes behind row and column policy, still emits lineage, and still meters. The surface is familiar; the governance underneath is not.
Streaming and perception
Complex event processing over sequences, streaming SQL with temporal joins and watermarks, KQL and PromQL surfaces, live queries that fire only when results change, and a perception stage that decodes arriving bytes, extracts entities and observables, classifies sensitivity, and routes by classification.
A message carries the same classification, workspace scope and audit trail as a table, because it is the same substrate.
Object storage
A content-addressed, deduplicating block store with erasure coding selected by topology, placement across failure domains, and a durability claim you can check, a namespace declares its protection and an endpoint returns measured conformance over a reported sample, counting what could not be evaluated separately rather than folding it into “conforming”.
Encryption can be made mandatory: the block store refuses a plaintext write rather than warning and proceeding.
Sharing and data products
Typed input and output ports validated against an open specification, certification as a recorded state, provenance envelopes, subscriptions with federation access checks, and service-level monitoring with breach records. Three sharing mechanisms, deliberately different: an open protocol for anyone, workspace shares inside an estate, and public datasets.
A share is not an export. The policy that governed the data at rest is compiled and travels with it in a signed envelope, and every read is logged against the recipient.
The workbench
Notebooks with immutable, server-hashed version snapshots on named branches, pipeline binding, scheduling, publication as an API endpoint, and governed run history. Kernels with syscall filtering, import-hook module filtering and egress restriction, with row and column security enforced inside the kernel.
Authoring, versioning, binding, scheduling and publication persist to real storage everywhere. Execution is a different claim: running an ordinary workspace notebook is not offered, and clean-room notebook execution (where the code is reviewed and cryptographically signed before it can run) is built and governed end to end but has not yet been demonstrated in a deployed cell.
A scanned PDF inherits the same policy surface as a table
Most platforms are honestly good at structured data and bolt unstructured on beside it. Here the two converge: content is decoded, its entities and observables extracted, its sensitivity classified, its embeddings written to the vector engine, its derived artifacts given provenance, and the result registered as a catalog asset.
Which means a file share, a mailbox, a scanned document and a recording all carry the same classification ladder, the same row and column policy surface, the same lineage chain, the same audit and the same workspace scope as a table.
| Stage | What happens |
|---|---|
| Discover | Connectors walk relational stores, object and blob stores, file shares and network-attached storage, catalogs, BI tools, SaaS applications, Office estates and streaming sources, driven by a scan kernel with scheduling, checkpoints and live progress. |
| Parse | Format detection plus extractors for a wide document set, including recursive archives, source code and optical character recognition, with several chunking strategies. |
| Understand | Entity, schema, observable, temporal and spatial extraction; content, security and sensitivity classification; embedding through local providers. Entity extraction is guided by your ontology rather than a generic model. |
| Govern | The result is registered as a catalog asset, and at that moment inherits the classification ladder, the row and column policy surface, the lineage chain, the audit trail and the workspace scope of a table. |
| On the device | The same chain runs offline against a synchronised subset of your ontology, so content is structured at the point of capture rather than re-inferred at the core. |
Your existing clients connect
Adoption does not require retraining a BI team or rewriting an application. The platform speaks the protocols your tools already speak, and federates sources that stay exactly where they are.
8
engine types under one compiled data-security policy
106
stream connectors in the built-in catalog, across seven domains
34
data-structure types over the Redis protocol, 33 customer-visible, one internal
PostgreSQL wire · Arrow Flight SQL · Redis protocol · Gremlin · GQL · GraphQL · SQL · KQL · PromQL · streaming SQL · Iceberg REST catalog · Delta Sharing (server and client) · OpenMetadata-compatible REST · S3 · WebHDFS · SFTP · native REST and gRPC · MQTT 5.0 · AMQP. Foreign catalogs and databases register as federated sources, so the data does not have to move for the platform to catalog it, classify it, lineage it and enforce policy on it. 3 distinct sharing mechanisms, each for a different question.
The Data Exchange: trust that crosses the org boundary, and verifies offline
A share moves governed data between parties who already know each other. The Data Exchange is the next boundary out: a marketplace where organizations that do not share a secret can list, discover and consume each other’s data products — and where the trust that crosses that boundary is cryptographic and checkable without a network.
A listing is a signed attestation, not a database row. Publishing an offer mints a cross-org listing that binds the offer’s identity, a fingerprint of its content, its reach, an attenuating scope cap — the authority in a listing can only ever shrink relative to the ceiling the importer pinned for that publisher — and a validity window. It is signed with the publishing org’s private key and verifiable offline by anyone holding only that org’s public key. The data never crosses; only the signed listing does.
The signature is post-quantum hybrid, and it fails closed
Each listing carries a hybrid signature — Ed25519 today and ML-DSA-65 for the post-quantum era, the two carried together, the post-quantum half independently pinned. A verifier pinned to hybrid refuses a listing that drops the post-quantum half or substitutes a key: there is no downgrade path, and the signing input is domain-separated so a listing signature can never be replayed as a receipt or a grant.
This is the differentiator, stated precisely: org-boundary post-quantum hybrid trust with offline verification. The cloud data platforms verify cross-org trust through their own control plane; here it is verified on the cell, offline, on an air-gapped network, against a clock the verifier supplies.
A storefront where provenance is checked twice
Buyers browse a provenance-verified marketplace — search, detail pages and pagination over the catalog — and every listing is verified both when it is rendered for the visitor and when it is ingested. A foreign, tampered, wrong-key or forged listing is rejected against real cryptography, deny-closed.
A buyer places a request; the seller’s cell runs the grant lifecycle; and the terminal decision — pending, declined with a reason, or provisioned — is reflected back to the buyer, with a re-request allowed after a decline.
One revoke, and serving stops everywhere
The exchange’s grant edge is the same canonical governance edge the platform serves from. A revoke on it is the authoritative deny at all three serving faces — the marketplace, Delta Sharing and the Iceberg REST catalog — so withdrawing access actually stops serving, and an ungoverned asset is deny-closed rather than open by default.
An accounting ledger underneath, signed per cell
Every metered cross-org read books double-entry onto a signed, hash-chained per-cell accrual ledger: a buyer debit and a seller credit. The ledger is denominated in Compute Units — it is the accounting of the exchange, signed and verifiable per cell.
It is an accrual ledger, not a payments rail: no real money has moved, and there is no platform take-rate on a priced sale — a seller receives the full listed price.
The buyer and seller journey
One console, five surfaces — the same names buyers and sellers see in the product.
Discover
Browse the provenance-verified storefront and place a request.
Offer
Publish a data product as a signed cross-org listing.
Manage
Run the grant lifecycle on requests you receive.
Earnings
The seller-credit side of the accrual ledger.
Spend
The buyer-debit side, against a prepaid balance.
Said honestly, before you assume it
The marketplace is early on catalog scale and on network effects, and its economy is an accrual ledger rather than a live payout rail — the differentiator is the cryptographic axis: signed, post-quantum-hybrid trust that a recipient verifies offline. Where an edge deployment collocates a full cell, the whole exchange — serving, marketplace and settlement — runs locally, sovereign and air-gapped, with no cloud in the loop.