The technical positions we're building on.
Not a paper mill — a working set of engineering theses. Each one is either running in the product today or labeled as the roadmap bet it is, with the open problems stated out loud. This is the thinking behind the platform, written for people who will check our work.
The autonomous database.
Databases have gotten bigger, faster, and cheaper for fifty years — and stayed exactly as passive. Our central position is that the next database is not an incremental improvement on the warehouse; it's a different kind of system. Three claims underneath it:
A new architecture, not a faster old one
Snowflake didn't beat Teradata by being a faster Teradata — it was a different architecture that made the old one's constraints irrelevant. We take the same position on the next transition: the successor to the cloud warehouse is not a cheaper warehouse, it's a database that understands what its data means and acts on it. The intelligence isn't a copilot bolted on top; it's wired into the query path, the governance chokepoint, and the storage plane itself.
The database becomes an operator, not a filing cabinet
Today's stack answers questions for the ~10% of a company who can write SQL, and only when asked. Our position: the platform should serve the other 90% — watching the data it holds, noticing what changed, predicting the blast radius of an action before it runs, and executing the safe ones autonomously. Storage, meaning, and action belong in one governed system, on storage the customer owns.
Neutrality is an architecture, not a policy
Every incumbent's 'open' has an asterisk, because genuine portability cannibalizes their consumption model. We build the inverse: data in Apache Iceberg on the customer's own object store, under the customer's own KMS keys, readable by any engine — and the platform reads sources in place, federated, before asking anyone to move a byte. If the customer can leave any day, the product has to win on what it does, not what it holds hostage.
Seven areas, honestly staged.
Each area states the position, what's real, and the open question we're still working. In production means it runs in the platform today. In development means real code that's still deepening. Roadmap means exactly that.
Auto-built business ontology
Building the map of a business — its entities, relationships, metrics, and rules — has always been a months-long consulting engagement, and the result decays the day the consultants leave. We build it autonomously from the data and the workload: schemas, join keys, classifications, cross-source entity resolution (the same real-world customer recognized across systems, zero copy), and how teams actually query. High-confidence bindings attach automatically; medium ones queue for human ratification; every correction teaches it.
Open question we're working: how the ontology stays fresh at scale — decay, pruning, and hierarchical-summary freshness are genuinely unsolved, and we say so.
Inferring the business logic nobody wrote down
Parsing documents for rules is the easy, copyable part. The hard problem — and our wedge — is that most business rules were never written down at all: the vendor always excluded from aging, the 90-day cutoff baked into how a metric is really computed, the segment quietly treated differently. These have to be inferred from data patterns, exceptions, anomalies, and query behavior, then corroborated against what is written in code, Slack, and docs. Each inferred rule carries its evidence and a confidence score, and becomes enforceable only after a human confirms it.
Open question we're working: precision — an inferred rule confidently wrong is worse than no rule, so the corroboration and ratification loop is the research, not an afterthought.
Compile-time agent governance
The industry governs agents with runtime guardrails an agent can argue around. Our position: governance belongs at the compute layer, before execution. Every agent is born with a Birth Certificate — identity, scope, ceiling, and expiry bound at creation and enforced at compile time. All queries pass one policy chokepoint, on by default and fail-closed. Impact analysis runs as a gate, not a report: a consequential action is stopped before it runs, and clears only through human approval. Everything lands in a tamper-evident, HMAC-chained audit trail.
Open question we're working: how far static analysis of an agent's declared capabilities can go before dynamic behavior forces a runtime check — where exactly the compile/runtime boundary belongs.
Federated learning under a k≥3 anonymity gate
Incumbents contractually forbid themselves from learning across customers, so their 500th customer gets the same heuristics as their first. We designed for the opposite: structural patterns — never data, never identifiers — aggregate across tenants only once at least three independent customers exhibit them, so no pattern is attributable to any one. The tables that hold this knowledge structurally cannot carry a workspace ID. Every customer who joins makes every other customer's platform smarter.
Open question we're working: how rich a pattern can be shared before k-anonymity alone stops being a sufficient guarantee — the ceiling on pattern expressiveness.
Open formats and composable compute
All data lives in Apache Iceberg on customer-chosen object storage — no proprietary format, ever. Compute is deliberately composable and commodity: proven open-source engines — distributed SQL for heavy work, an embedded engine for millisecond micro-queries — routed per workload. We explicitly do not try to out-engineer the engine vendors on raw speed; the differentiation lives in the governed autonomous layer above the engine. The engines are replaceable — that's the point.
Open question we're working: cost-aware query routing — when the platform should pick the small fast engine over the big one, learned from workload rather than configured.
GPU-native query execution
The thesis: analytical queries on GPU memory bandwidth, on commodity GPU clouds, at a structurally lower price point than hyperscaler compute. We're honest about where this stands — it is roadmap, not shipped. Real query execution today runs on proven, open-source engines. We publish no speedup numbers because we haven't run the paired benchmarks yet, and a multiplier without a benchmark is marketing, not research.
What has to be true first: a cost model that knows when GPU dispatch loses — small results, high transfer cost — because a GPU lane that's sometimes slower is worse than none.
CXL shared-memory readiness
CXL shared-memory hardware is expected to reach data centers in the 2027–2029 window, and it changes the economics of the storage/compute split: a memory pool multiple compute nodes address directly. We can't buy the hardware yet, so the research is architectural — storage, caching, query routing, and scheduling are all abstracted behind interfaces today, so CXL slots in as a new backend and cache tier without touching application code. Platforms that hard-coded their memory hierarchy will be rewriting; we intend to be reconfiguring.
The honest caveat: this is a bet on a hardware timeline we don't control. The abstraction costs us little if CXL slips; it pays enormously if it doesn't.
Rules this page follows.
The data industry has a benchmark-marketing problem. We'd rather be checkable than impressive.
Shipped, in development, or roadmap — labeled, always
Every claim on this page carries its status. If it says Roadmap, it isn't in the product yet, and no salesperson gets to blur that.
No numbers without the benchmark
We publish measured results only when the paired runs exist and the methodology ships with them. Until then, we publish the thesis and the open questions.
The open problems stay visible
Each research area lists what we haven't solved. A platform that claims no open problems is hiding them — ours are part of the position.
Disagree with a position? Good.
These theses get sharper under adversarial review. If you're a principal engineer, researcher, or analyst working on autonomous data systems, agent governance, or privacy-preserving learning — we'll walk you through the running system behind any claim on this page.