Conversation, Work, Memory, Library, Log, and multimodal surfaces.
Technology · Delivery and operating authority
Choose who operates Indwel OS. Keep the product invariant.
Managed, Dedicated, and Licensed change the operating boundary—not the constitutional system. Unity, the Platform API, the Business App Engine, and Sovereign Cognition remain one Indwel OS.
Compare operating boundariesUnity · Platform API · Business App Engine · Sovereign Cognition
Operated by IndwelHold the invariant
The operating model changes. The product does not fragment.
Deployment is not a feature tier. What changes is who owns and operates the surrounding estate, while the product’s cognitive and authority boundaries remain governed.
Constitutional application resources and governed service boundary.
Domain-native applications with distinct workflows and authority.
Evidence Firewall, Inference Firewall, authority, effects, and Settlement.
Managed / Dedicated / Licensed
Put operating responsibility where your institution requires it.
The same Indwel OS can be operated by Indwel in a managed estate, by Indwel in a more isolated dedicated estate, or by the customer under a licensed operating boundary.
| Responsibility | ManagedIndwel operates | DedicatedIndwel operates isolated estate | LicensedCustomer operates |
|---|---|---|---|
| Infrastructure operator | Indwel | Indwel | Customer |
| Estate / tenancy | Managed multi-tenant boundary | Dedicated customer estate | Customer-operated estate |
| Identity and keys | Integrated customer identity; Indwel-operated service boundary | Customer-specific identity and key boundary | Customer-controlled identity and keys |
| Data and source custody | Customer data under managed custody controls | Customer-isolated data boundary | Customer-operated custody boundary |
| Model / inference boundary | Governed provider choices | Governed provider or private choices | Customer-selected frontier, private, local, or air-gapped inference |
| Integrations and effects | Governed adapters under institutional authority | Governed adapters inside dedicated boundary | Customer-operated adapters and effect boundary |
| Logs and observability | Indwel-operated with customer visibility | Dedicated operational visibility | Customer-operated observability |
| Upgrades and release | Indwel release authority | Coordinated dedicated release | Customer operating schedule under licensed release terms |
| Backup and recovery | Indwel-operated | Dedicated recovery boundary | Customer-operated |
| Operational support | Indwel | Indwel + customer operating coordination | Licensed support boundary |
Infrastructure operatorIndwel
Estate / tenancyManaged multi-tenant boundary
Identity and keysIntegrated customer identity; Indwel-operated service boundary
Data and source custodyCustomer data under managed custody controls
Model / inference boundaryGoverned provider choices
Integrations and effectsGoverned adapters under institutional authority
Logs and observabilityIndwel-operated with customer visibility
Upgrades and releaseIndwel release authority
Backup and recoveryIndwel-operated
Operational supportIndwel
Licensed means customer-operated—not necessarily on-premises. Private cloud, customer cloud, on-premises, and air-gapped patterns may be selected according to the deployment constitution.
Operational consequence
The boundary becomes real when software may participate in action.
Release Readiness shows why operating authority matters. The application can gather evidence, assess gates, and propose action; production authority remains explicit, and the observed result must return before the release can settle.
The same application constitution survives a change in deployment model. What moves is operational responsibility—not the sovereignty of the Work.
Choose the boundary
Start with the institutional requirement—not the hosting label.
Identity, networking, keys, data custody, inference, integrations, observability, recovery, release authority, and support determine the right operating boundary.