Deployment & Operating Model
Current deployment topology, providers, configuration switches and institutional responsibilities
Deployment today
The GENIE platform is deployed as a self-hosted, containerised stack operated by a single deploying party. Deployment definitions exist as Docker Compose files for production and staging and as Helm charts for Kubernetes.
| Component | Deployment | Status |
|---|---|---|
| Web application and API | Container, Helm deployment | Available |
| Assistant runtime | Container, Helm deployment | Available |
| Background workers (queue, graph projection, scheduled jobs) | Separate deployments and cron jobs | Available |
| Media server and SIP gateway | Self-hosted services (a managed media service is also supported) | Available |
| PostgreSQL with vector extension, Redis | Stateful services in the cluster | Available |
| Health endpoints and session lifecycle events | Built in | Available |
External providers
| Function | Provider class | Fallback |
|---|---|---|
| Language model | Cloud provider via a gateway with a configurable model allowlist (one model family configured) | none automatic |
| Speech-to-text | Cloud provider | none automatic |
| Text-to-speech | Cloud provider | automatic fallback to a second provider |
| Speech-to-speech (optional mode) | Cloud provider | — |
| Telephony | SIP trunk and SMS provider | — |
| Web research (optional) | Search providers, only when configured | — |
| Sign-in | Google OAuth | — |
Configuration switches
Capabilities are individually switchable by configuration. Switches that are off in the current production configuration include the reflection pass, graded agent routing, group mode, voice recognition of enrolled persons and the session-only tone-modulation layer. Switches act as manual kill switches per feature.
Two configuration facts matter for any controlled pilot: cohort gating must be configured explicitly, because without configuration access is open; and the administrative surface is only enabled for an explicitly configured allowlist.
In development for institutional deployment
In development| Option | Description |
|---|---|
| Dedicated private-cloud deployment per institution | A separate stack per institution, operated by ecrop or a partner, in an agreed region. |
| On-premises or customer-VPC deployment | Installation within the institution's own infrastructure. In development; not available today. |
| Enterprise identity federation | Sign-in through the institution's identity provider. |
| Institution-level tenant isolation | Organisation-level isolation in addition to per-account scoping. |
| Log export | Structured export of operational artefacts to the institution's logging and monitoring. |
| Provider region pinning | Contractual and technical region selection for model, speech and telephony providers. |
| Model provider failover | Automatic failover between model providers. |
No packaged on-premises product, no customer-facing deployment selector and no multi-tenant control plane exist today.
Operating model and responsibilities
| Area | ecrop (technology provider) | Deploying institution |
|---|---|---|
| Software and updates | Provides releases, change documentation and evaluation results. | Approves changes according to its own change process. |
| Intended purpose and use cases | Documents capabilities, limits and status labels. | Defines intended purpose, exclusions and human-decision points. |
| Regulatory classification | Provides technical facts. | Classifies per use case (AI Act, DORA criticality, outsourcing, data protection). |
| Identity and access | Provides identity federation (in development) and role mapping. | Manages users, roles and approvals. |
| Third-party providers | Documents provider classes and fallbacks. | Assesses provider dependency, data handling and exit options in its third-party risk process. |
| Recording and retention | Provides memory lifecycle mechanisms and, when built, legal hold. | Defines retention classes and meets recording obligations with its own infrastructure. |
| Incident handling | Provides feature switches, logs and support. | Runs incident management and decides on shutdown. |
| Licensed activities | None. | Performed exclusively by licensed partners. |
Testing and change management
The GENIE platform carries an extensive automated test suite for the assistant runtime and the web application, run through a documented local test script before changes are merged. Automated continuous integration on every commit is not configured in the repository today; this is disclosed here rather than claimed otherwise. For institutional deployment, a release process with evaluation reports and red-teaming results per release is in development.
No availability figures, service levels or capacity numbers are published on this page. Service levels are agreed per deployment.