Architecture overview

Metatate Cloud is a multi-workspace governance-intelligence platform. It reads schema metadata from your data platforms, helps your team turn governance intent into published decisions, and serves those decisions to AI agents as read-only, advisory answers. This page describes the system in the parts you can reason about, where your data lives, and the stance the platform takes toward your systems. Security and Privacy and data handling go boundary by boundary.

Four parts you can reason about

The web app is where your team works: authoring and reviewing policies, browsing the catalog, curating classifications and collections, planning and publishing deployments, and managing members, tokens, and billing. The browser talks only to the web app. It never opens a connection to your data platforms and never sees connector credentials.

The governance pipeline turns intent into serving state. Policy authoring produces canonical policies; from those, Metatate derives deployable instructions; publishing a deployment makes those instructions the workspace's current publication — the single serving state that decision answers are read from. Until something is published there is nothing to serve, and answers say so explicitly instead of guessing. See How governance works.

The MCP serving surface is a dedicated server that exposes seven read-only, advisory tools to AI agents. Decision-bearing answers are read from the current publication and returned as typed answer states — answered, review_required, or not_enough_published_state — never fabricated when published state is missing, conflicted, or unresolved. Tools describe decisions; they never approve, enforce, mask, block, or write anything. See the MCP overview and Answer states.

Connectors keep the catalog current. Metadata sync runs in isolated background workers, separate from the web app. Connectors are metadata-first: workers read schema metadata — databases, schemas, tables, columns — from your platforms, never copy production rows into the catalog, and never enforce anything inside your platforms. See the connectors overview.

Where your data lives

All workspace state — catalog metadata, policies, deployment publications, served decisions, audit events, memberships — lives in managed Postgres. Every workspace-owned row carries its workspace's ID, and row-level security at the database layer is the isolation boundary: reads are scoped to the workspaces you belong to by the database itself, not by application code alone. Cross-workspace access is covered by dedicated negative tests.

Connector credentials are deliberately not part of those tables. They are stored by reference in a managed secrets vault and decrypted only inside sync workers. See Security for the full credential boundary.

What runs where

Three kinds of runtime make up the platform, and each holds only the secrets its job requires:

• The web app serves the UI and your session. Its database access runs under row-level security.
• The MCP server is a separate service. It resolves the workspace entirely from the bearer token on each call and pins every read to that workspace; it holds no connector credentials and no payment secrets.
• Background workers handle connector sync, deployment publication, governance jobs, and billing events. Sync workers are the only processes that decrypt connector credentials and the only processes that open connections to your platforms. Payment-provider secrets are confined to the billing worker.

The advisory stance

Metatate informs decisions; it does not take them for you. MCP tools are read-only and advisory: their answers are inputs to your agents' and reviewers' judgment, and enforcement stays in your own systems. Connectors read metadata and write nothing back. When the published state cannot support a confident answer, the platform returns a typed answer state that says exactly that — a property the whole architecture is arranged to preserve.