DMOS — Data Management Operating System

Your data has
an OS now.

DMOS is the operating system for your entire data stack. It senses anomalies, compiles pipelines, enforces quality, and manages the full data lifecycle — across every warehouse, lake, and storage layer you already use.

11
DMBOK domains
9
cognitive senses
0
vendor lock-in
cognitive-engine / live cycle
What is DMOS

An operating system for your entire data stack

Linux doesn't care what hardware you run. DMOS doesn't care where your data lives. It sits above your existing warehouse, lake, or database and manages the full lifecycle — ingestion, transformation, quality, catalog, lineage, governance, security, and observability — as one coherent system.

Your storage
Snowflake, Databricks, PostgreSQL, S3, Iceberg, DuckDB — whatever you already use
You own this
DMOS Control Plane
API gateway, identity, metadata catalog, pipeline registry, lineage graph
DMOS
Cognitive Engine
9 senses, confidence scoring, autonomous reasoning, policy gates, episodic memory
DMOS
Intelligence Layer
NL-to-pipeline compiler, quality contracts, governance, security, AI-assisted ops
DMOS

DMOS deploys as a complete per-tenant instance — like Snowflake provisions a warehouse per customer. Your data never leaves your infrastructure. Zero vendor lock-in on the storage layer.

0
storage lock-in

Keep Snowflake, Databricks, Postgres, S3, Iceberg — DMOS works with all of them

1
platform

One system for the entire data lifecycle instead of 6-8 point solutions stitched together

24/7
cognitive sensing

The engine senses, reasons, and acts autonomously within policy boundaries — no alert fatigue

DMOS Platform

The full data lifecycle, one platform

DMOS covers every domain in the DMBOK — from ingestion to governance, quality to security, observability to cost management. Not 8 point solutions glued together. One coherent operating system.

DMBOK 6Live

Data Integration

Connect any source — databases, APIs, files, streams. AI maps fields to your catalog. Schema evolution handled before it breaks anything downstream.

DMBOK 5Live

Transformation & Pipelines

Describe pipelines in plain English. PDL compiles them to typed, lineage-proven SQL. Column references verified against the live catalog at compile time.

DMBOK 11Live

Data Quality

Quality checks are first-class language constructs, not YAML configs bolted on after. AI generates expectation suites from data profiles. Anomaly root cause analysis in plain English.

DMBOK 10Live

Metadata & Catalog

Auto-populated from every pipeline run. Natural language search across all assets. AI writes documentation. Column-level lineage traced from source to report.

CognitiveLive

Observability

9 cognitive senses monitor freshness, volume, schema drift, meaning shift, and more. The engine detects anomalies before your stakeholders notice. AI explains root cause.

DMBOK 1Building

Data Governance

Policy-as-code governance. PII detection and classification. Data ownership and stewardship. Compliance evidence generated from the audit log — GDPR, SOC2, HIPAA.

DMBOK 6Live

Security & Access

Role-based access control, row-level security, encrypted credential storage, SSO/SAML. Per-domain compute isolation. Per-tenant deployment with zero cross-tenant data paths.

DevOpsBuilding

DataOps

Every pipeline is a versioned, reviewable artifact. AI reviews changes for type safety, quality coverage, and lineage impact. CI/CD for data with promotion gates.

DMBOK 2Live

Data Architecture

Mesh Grid / Mesh / Domain / Asset hierarchy. Data products with SLAs. Architecture-as-code. Blast radius analysis before any change reaches production.

DMBOK 8Planned

Reference & Master Data

Golden record management. Cross-source entity resolution. Consistency sensing detects when the same entity has conflicting values across systems.

EnterprisePlanned

FinOps & Cost Management

Per-domain and per-pipeline cost attribution. Compute resource quotas. Query cost estimation before execution. Usage dashboards for data platform ROI.

Cognitive Engine

It doesn't alert you. It handles it.

Nine sensors watch every dataset continuously. The engine reasons about anomalies with explicit confidence, acts within your policy boundaries, and remembers every episode. You read the resolution report at 9 a.m. instead of debugging at 3 a.m.

Sense

9 sensors detect anomalies across freshness, volume, schema, semantics, and more

Reason

Rule engine + optional LLM scores confidence and proposes typed actions

Act

Policy gates enforce boundaries — the engine self-heals within rules you set

Remember

Every incident becomes an episode with causal graph, resolution, and reasoning

Nine cognitive senses

FreshnessPhysical
Time since last successful run vs SLA threshold
VolumePhysical
Row count deviation from rolling baseline (z-score)
Schema ChangePhysical
Column adds, removes, and type changes detected
Meaning DriftSemantic
Column semantic shift detected via embeddings
Lineage DepthSemantic
Upstream failure propagation risk assessment
ReliabilityIntent
Historical failure rate over rolling 30-day window
RiskIntent
Blast radius — downstream asset dependency count
ConsistencyIntent
Cross-source value agreement for shared entities
LearningIntent
Operator feedback patterns and override frequency

Confidence bands — the engine knows what it doesn't know

Every autonomous action is gated by explicit confidence. Low confidence means log-only. High confidence means self-heal. Destructive actions always require human approval regardless of confidence.

Low
Tentative
Strong
Very Strong
Low< 0.4

Log only. No autonomous action.

Tentative0.4 — 0.6

Notify operator. LLM may refine.

Strong0.6 — 0.8

Autonomous low-risk actions.

Very Strong> 0.8

Autonomous non-destructive actions.

Episodic memory
Every incident, decision, and autonomous action is recorded with confidence levels, reasoning chain, and causal graph — a flight recorder for your data platform.

How it works

English in. Proven pipelines out.

Describe what you need. The compiler verifies it. Your warehouse executes it. The engine watches it. Four steps — from intent to autonomous operation.

01

Describe

Tell DMOS what you need in plain English. "Build a daily revenue pipeline from our orders table with a freshness SLA of 6 hours."

$ dmos generate
"Build a daily revenue pipeline from orders
with freshness SLA of 6h, abort if total = 0"
02

Compile

AI generates PDL — a typed pipeline language. The compiler verifies types, resolves catalog references, proves lineage, and catches errors before execution.

✓ Lexing ... done
✓ Name resolution ... catalog://sales.orders → resolved
✓ Type checking ... Row<{id:Int, amount:Decimal}>
✓ Lineage check ... acyclic, 2 stages, 1 sink
✓ Quality contracts ... 1 expectation verified
● Compilation successful. Lineage written to catalog.
03

Execute

The compiled pipeline runs on your existing storage — Snowflake, Databricks, PostgreSQL, DuckDB, or S3. DMOS pushes compute to where your data lives.

▸ Executing on: snowflake://analytics.prod
✓ Stage completed: 847,231 rows filtered
✓ Stage daily_rev: 365 rows aggregated
✓ Quality: daily_rev.total > 0.0 — passed
✓ Sink: catalog://finance.revenue_daily — written
04

Sense

From this moment on, the cognitive engine monitors your pipeline's data. Freshness, volume, schema changes, distribution shifts — continuously, autonomously.

cognitive-engine: monitoring revenue_daily
SENSE freshness OK — last run 2h ago (SLA: 6h)
SENSE volume 847K rows — within baseline (±1.2σ)
SENSE schema stable — no changes detected
● all senses nominal. next cycle in 15m.
Built for your role

Every seat at the table, one platform

Delete your on-call anxiety.

The pain you know

60% of your week is debugging, not building — tracing schema changes through undocumented hops

The 3 a.m. Slack ping. Quality tools detect; nothing acts. Every alert is your problem to triage.

AI tools that lie confidently — LLM-generated SQL looks right, runs, and silently produces wrong numbers

How DMOS solves it

Lineage is a compiler artifact — it cannot drift from reality because it IS the pipeline

The engine quarantines bad data, pauses downstream jobs, and writes a resolution episode. You read it at 9 a.m.

Natural language goes through a real compiler — lexer, parser, type checker, codegen. If it compiles, it's correct.

Stop being the alerting system.

Competitive positioning

Keep them. That's the point.

DMOS is not in the stack. It's above the stack. Every tool below is an excellent place to store, compute, or observe data. DMOS is the operating system that manages what happens across all of them — no migration, no rip-and-replace.

vs
Snowflake
Warehouse

A place your data lives. DMOS manages data wherever it lives — including inside Snowflake.

vs
Databricks
Lakehouse

A powerful compute and lakehouse engine. DMOS is the cognitive layer that keeps everything running on it healthy and governed.

vs
dbt
Transform

Templates SQL and suggests structure. DMOS compiles pipelines through a type checker with proven lineage — and covers the ten DMBOK areas dbt never touches.

vs
Monte Carlo / Atlan
Observability

Observability tools tell you what's wrong. DMOS senses, reasons, and acts — detection is a sensor input, not the product.

vs
Collibra
Governance

Documents governance policy. DMOS executes it — policies become runtime boundaries the engine enforces, not workflows people follow.

DMOS works with the infrastructure you already invested in. Your data never moves. Your warehouse stays. You gain management, governance, and cognitive sensing — across all of them, from one system.

See how DMOS fits your stack
Architecture

A Rust engine. A real compiler. Your boundary.

Per-customer isolated deployments, a cognitive core built for continuous operation, and a pipeline compiler with formal type checking.

$ dmos architecture
┌──────────────────────────────────────────────────────────────┐
YOUR TEAM — dashboards, catalog, pipeline IDE, cognitive feed │
├──────────────────────────────────────────────────────────────┤
DMOS CONTROL PLANE (Go) │
API Gateway · Identity · Metadata Catalog · Engine Gateway │
├──────────────────────────────────────────────────────────────┤
COGNITIVE ENGINE (Rust) │
9 senses · confidence bands · policy gates · episodic memory │
├──────────────────────────────────────────────────────────────┤
INTELLIGENCE LAYER (Python) │
NL→PDL compiler · AI reasoning · pipeline execution (DuckDB) │
├──────────────────────────────────────────────────────────────┤
YOUR STORAGE (you choose) │
Snowflake · Databricks · PostgreSQL · S3 · Iceberg · DuckDB │
└──────────────────────────────────────────────────────────────┘
deployment: per-customer isolated instance
engine: 18-crate Rust workspace, 317+ tests
compiler: lexer → parser → resolver → type checker → codegen
transport: gRPC (internal) · NATS JetStream (events) · GraphQL (UI)
isolation: K8s namespace per tenant · RLS · subject-scoped NATS

Per-customer isolation

Every customer gets their own DMOS instance in a dedicated K8s namespace — like Snowflake deploys a warehouse per account.

Real compiler, not AI vibes

Lexer, parser, name resolver, type checker, codegen. If a pipeline compiles, its types check and its lineage is proven. No hallucinations ship.

Rust cognitive core

18-crate workspace with 317+ tests. Memory-safe, zero-cost abstractions, sub-millisecond sense cycles. Built for continuous autonomous operation.

Early access

Your data estate is about to
get an operating system.

DMOS is rolling out as isolated per-customer deployments. Join the waitlist to get early access — your data stays where it is, and DMOS manages all of it as one coherent system.

No spam. No vendor lock-in. Building in public at github.com/dataastra