Trust
Sovereignty is a configuration, not a slogan.
Some deployment models are proven in a running pilot. Others are implemented and supported but not yet operated at commercial scale. This page says which is which.
What sovereignty actually means in the running system
A sovereign profile makes zero external calls, by construction
When an instance is configured as sovereign, it does not call an external AI provider or any other third-party service. This is a startup-time check, not a policy someone could forget to follow - the process refuses to start in an inconsistent configuration.
One database, one backup, one recovery procedure
Institutional records live in one PostgreSQL system of record, not scattered across several independent stores that would each need their own backup and consent-revocation path.
Deployment choice is a real configuration, not a slide
Sovereign, hybrid and cloud-managed deployment profiles are implemented in the codebase, not only described in a proposal. Which profile an instance runs is explicit configuration, checked at startup.
Data residency follows where the instance actually runs
A deployment's data resides on the infrastructure an operator chooses to run it on - customer- managed, dedicated, or Witness-operated - rather than a fixed default nobody can see.
Stated honestly
Proven versus supported
Cloud-managed: operated in a live pilot
A cloud-managed deployment is running today, operated by Witness on an institution's behalf.
Sovereign and customer-managed: implemented, not yet commercially proven at scale
These deployment models exist in the codebase and are documented for an operator to run. They have not yet been operated as a customer's production system at scale, and this page will not claim that they have.
Tell us which deployment model your institution actually needs.