Your infrastructure. Your data. Your engine. Context for me, context for you, no central authority skimming context off the top.
Information asymmetry can be weaponized. A boss who sees everything every employee sees, plus everything they don't, has too much. ContextOS as a tool for surveillance is a real risk — and any framework that watches a universe of activity, joins streams, and builds operational context has to address that risk directly. If the engine ships as cloud-only SaaS, the cloud provider becomes the central authority that knows more about the operation than anyone running it. That's the failure mode the design refuses.
Sovereign deployment is the answer. Apps built on ContextOS are designed to run on your infrastructure — your database, your compute, your network. You decide what is captured. Your data doesn't leave your boundary. Your employees see the same observability you do where it concerns their work. This isn't an enterprise upsell or a compliance feature; it's the constitutional shape of the architecture.
Context for me, context for you. No central authority skimming context off the top.
In practical terms, sovereign by default means the operating substrate of any app built on ContextOS runs in the customer's environment. The event log lives on the customer's database (Postgres is the reference implementation; pg_cron handles the heartbeat layer for any single organization without a sweat). The orchestrator runs on the customer's compute. The decision graph stays in the customer's network.
When AI is in the loop, the customer chooses the model boundary. For high-trust deployments, models can run entirely on customer infrastructure (open-weights via vLLM, Ollama, or similar). For lower-stakes work, customers may opt into cloud LLM APIs with explicit data-flow controls — but the decision is theirs, made per signal class, with a clear audit trail. Default is local; cloud is opt-in.
External integrations (WhatsApp, Slack, email, SMS) are necessarily federated — they happen because the customer chose a notification platform — but the data sent to those platforms is the rendered notification, not the underlying signal or thread context. The signal stays sovereign; only the message goes out.
In a world where most AI infrastructure assumes cloud-tenanted multi-customer SaaS, sovereign deployment looks inconvenient. It is — once. The setup cost is real. The payoff is durable.
Employees trust a system more when they know their boss's organization is the only entity that has the data. Customers trust a vendor more when their interaction history isn't co-tenanted with the vendor's other clients. Regulators trust an architecture more when the data residency story is unambiguous. In jurisdictions where automated-decision-making is regulated (GDPR Art. 22), sovereign deployment makes compliance a configuration choice rather than a vendor negotiation.
The cultural moment matters too. After a decade of attention-economy software and SaaS-with-vendor-lock-in, people are exhausted. Calm technology that you actually own is more aligned with the moment than calm technology you rent.
Sovereign deployment doesn't mean isolated. The mechanism pages — three streams, heartbeat engine, confidence model, decision graph — are open architectural patterns. ContextOS is the assembly, not a closed system. Tenants get:
What stays at Umento — the company that publishes the ContextOS approach and builds apps on it — is the methodology, the documentation, the patterns, and (for customers of our apps) shared learnings across deployments (anonymized, opt-in only). The customer's operational reality stays the customer's.
Honest acknowledgment: sovereign deployment isn't right for every shape of organization. A two-person startup running a side-project doesn't need to operate its own infrastructure. A small clinic with no IT staff is better off with a managed deployment of a ContextOS-aligned app from a trusted operator, with explicit data-handling guarantees in the contract.
The architecture supports both shapes. What it refuses is the pattern where one cloud-SaaS vendor accumulates operational context across thousands of unrelated tenants, and uses the aggregate to advantage themselves. That's the surveillance failure mode. An app's engine may be hosted on the customer's behalf, but it should never be co-tenanted in a way that makes the host more powerful than any single customer.
The engine works because the deployment shape protects the people it serves.