Provisa / Vendor leverage

Locked-in ecosystems become replaceable execution engines.

Provisa front-ends your disparate systems so your semantics live with you, not your vendors — turning the platforms you're currently stuck inside into components you can swap without rewriting a query or a policy.

No lock-in to an engine or a source

Your model, semantics, and governance live above the infrastructure rather than inside it, which insulates your data consumers from infrastructure churn. Swap the engine — embedded, to Trino, to your warehouse; new CTO, new strategy, switch it to Databricks — and the queries and policies don't change. Re-point a table from Oracle to Postgres, or MongoDB to Snowflake, and consumers never see it move.

That turns data modernization into an incremental effort instead of a big-bang cutover. Migrate sources table by table behind a stable governed API, with one uniform governance model applying to legacy and modern sources alike throughout the transition — which is the part that usually kills these programs, since the interim state normally means two governance models and a spreadsheet reconciling them.

Your warehouse should be a replaceable component, not a place you get stranded. When your semantics live above the engine, vendors compete for your workloads instead of holding them hostage.

We don't lock you in either

Provisa is a handful of primitives — domains, tables, relationships, masking, views — compiled deterministically. There is no proprietary modeling universe to learn and no black box: your model is portable declarative config, and the SQL it compiles is yours to read, export, and keep.

Use it as scaffolding in dev if that's all you want. The semantics you write don't die with the tool, because they were never trapped inside it. A vendor that argues you should be able to leave its dependencies has to be willing to let you leave it, too.

Physical fragmentation, logical coherence

Performance needs fragmentation: the right engine per workload, materialized copies at the right granularity. Consumers need one coherent model. The old cost of fragmenting the physical was fragmenting the logical too — a pile of models with clashing objectives and granularity, physical detail bleeding into logical design.

Provisa splits them. Specialized engines and materialized views underneath, one governed logical model on top, and the physical never bleeds into the contract your consumers see. The knobs that fragment for speed live in the same declarative model that keeps you coherent, so going faster never spawns a second modeling mess.

Domains as products — delegated, not centralized

Give a domain its own owner and scoped rights to build it: register sources, publish tables, wire relationships, ship views — all inside their domain, none of it reaching another. Central policy still governs every query. Authorship is federated; enforcement stays absolute. It's optional — off by default, on when you need it.

Promote config like code

Analysts and developers work freely in a dev lane: register sources, publish tables, wire relationships. Their changes export as a unified-diff config patch that flows to test, then prod, reviewed in git like any pull request. Because the estate is declarative, promotion is a diff, not a migration.

The economic takeaway — you set the compute bill

Pair semantic governance with intelligent query routing and the value shifts from merely managing access to actively optimizing compute economics. Provisa becomes a single point of leverage to optimize execution speed, minimize network egress, and dictate exactly how much you pay vendor compute engines on any given query.

Single-source queries bypass federation entirely and route direct to the driver. Hot lookups inline as VALUES CTEs. Queries rewrite onto a fresh materialized view when one covers them. Each of those is a decision about whose meter is running, made in one place instead of in every team's query.