Provisa / One model
One model.
Federation, metrics, ontology and governance from a single model. Nothing to keep in sync.
Most estates run these as four tools. A federation engine knows where the data is, a metrics layer knows what the numbers mean, a catalog or knowledge graph knows what the terms mean, and a policy service knows who may see what. Each holds its own description of the same data, and the descriptions drift apart. Provisa keeps one description and runs from it, so the four stay in step because there is only one of them.
Federation
62 source types, including Salesforce, ServiceNow and Stripe, are reached in place. The SaaS systems the business runs on are tables beside the databases, with no pipeline into a warehouse first. You register the tables you want; nothing a source offers is registered for you.
Query in SQL, GraphQL or Cypher over nine protocols: pgwire, Bolt, Arrow Flight, gRPC, JDBC, REST, WebSocket, Airport and MCP. Any Postgres-wire client can connect, so a BI tool or a metrics tool can sit on top. All 62 sources. The languages and protocols.
Metrics
A metric is a named, governed aggregate: a name, an expression, a data type, a description. It is defined once and every tool and language that asks gets the same definition. A metric carries the same role visibility and stewardship as a table, and the joins it needs come from the registered relationships rather than from each tool's own copy of them.
Ontology
The business glossary is a graph. Terms are derived from the field names in the model, linked to the physical columns they name, and connected by the relationships between those tables. You can also add any concept of your own, give it a definition, and link it into the glossary. That is an ontology: a graph of concepts, their definitions and the relationships between them. Provisa maps it to the database structures that hold the values, which is the step that lets it answer questions about your data. A concept is a draft until it reaches data, directly or through other concepts. Only then is it part of the model. It is separate from the metrics: a glossary term says what a concept is, a metric says how a number is computed.
The graph is what Cypher queries run over, what finds the path between any two tables, and what an agent reads to work out what connects to what. The glossary is itself queryable metadata, so reporting on it goes through the same governance as any other query.
Governance
Six layers are compiled into every query plan, on every language and every protocol: introspection filtering, public access, domain access, row-level security, column visibility and masking, and a predicate guard with approval. The policy is part of the plan that runs, so no route in goes around it. How each layer works.
No invalid join ever runs on your data. A JOIN or a graph traversal is legal only if it matches a registered, approved relationship, and a refused join names the valid paths. Roles are governed by default; opting out is a deliberate grant of the ignore-relationships right to a role you trust. An agent's token maps to a role, so an agent gets the same layers a person does.
Alongside context layers
Data catalogs that provide a context layer tell an agent what it should do. Provisa enforces what it can do. They are complementary, and Provisa publishes its model into those catalogs.