Deployment, and who is responsible for what
Three deployment models
Your infrastructure
The platform runs in your cloud account, under your controls and your data residency. You hold the keys; we ship releases and support. The model most regulated licensees choose.
Ours
We host and operate it. Faster to launch, and the support model is simpler because there is one environment to reason about. Data residency is selected per engagement and stated in the agreement.
Hybrid
Control plane with us, sensitive components with you — typically signing and key material. More moving parts, and the responsibility split has to be unusually explicit.
Support tiers
| Tier | Coverage | Severity 1 response | Suited to |
|---|---|---|---|
| Standard | Business hours, one timezone | Next business day | Pilot and pre-launch deployments |
| Enhanced | Extended hours, named contact | Within business hours, same day | Live deployments with an internal operations team |
| Managed | 24×7 on-call rota, we operate | Contractual, agreed per engagement | Live deployments with no internal rota |
Response times are the contractual figures for the tier and are restated in the agreement. A severity definition that only the vendor can interpret is not a commitment; the definitions are agreed with the licensee before signature.
Incidents
Where we operate the platform, an incident produces a written post-mortem with the cause, the timeline and the change made — sent to the licensee whether or not they asked. We do not currently publish a public status page or an incident history: a status page showing no history reads as software with no users (D-J), and we would rather ship one when there is a real feed behind it. That decision is recorded on the trust centre gaps page rather than left unexplained.