Yobitel AI Applications Suite

Overview#

Most teams that adopt AI in production do not want to assemble a model, a retrieval system, a serving stack, a compliance posture, and a UI themselves. They want a working application — a clinical decision-support tool, a fraud-detection assistant, a manufacturing-defect inspector — that already understands the shape of their industry and that they can point at their own data, their own identity provider, and their own brand. That gap between 'we have a Yobibyte workspace' and 'our clinicians are using MediQuery for drug-interaction lookups' is what the AI Applications Suite closes.

The suite is the application layer of the Yobitel stack. It is a catalogue of first-party Yobitel applications — MediQuery is the headline; the broader vertical suite covers regulated finance, manufacturing, retail, telco, agriculture, and the public sector — and verified partner-published applications, all of which are deployed into a customer's Yobibyte workspace and configured against the customer's own data and identity. Customers do not pick models, runtimes, or accelerators inside an application; those choices belong to the application's verified deployment recipe, which Yobitel operates on the customer's behalf.

Compared with consuming a raw model from a marketplace and wiring up retrieval, prompt-engineering, evaluation, identity, audit, and a UI in-house, the AI Applications Suite collapses that work into deploy-and-configure. Compared with stitching together vertical SaaS, the suite keeps every application on a single managed runtime so identity, sovereignty, audit, observability, and billing inherit from the workspace rather than fragmenting across vendors. The contract is consistent: Yobitel operates the runtime end-to-end; the customer owns the data, the configuration, and the user experience.

Yobitel Communications — a UK-headquartered AI infrastructure company and NVIDIA Inception partner — publishes and operates the first-party applications and curates the partner-published ones. Every application carries declared sovereignty eligibility, licence terms, integration surface, configuration revisions, and pricing in USD, so procurement and platform teams can decide once and the developers can move.

Who uses AI Applications#

The suite is consumed by two audiences inside a customer organisation: the application end-users (clinicians, fraud analysts, plant-floor inspectors, store ops, public-sector caseworkers) and the platform operators (IT, identity, data governance, FinOps) who run the workspace the applications sit inside. The end-user experience is a customer-branded application; the operator experience is the marketplace, the configuration wizard, and the workspace's audit and billing surface.

Vertical personas the suite is designed against:

• Clinical — consultants, registrars, nurses, pharmacists, and clinical governance leads in NHS trusts and US health systems consume MediQuery and related clinical applications for cited decision support and drug intelligence.
• Financial services — fraud-ops analysts, KYC teams, AML investigators, and supervisor reviewers in retail and wholesale banks consume fraud-detection, KYC-assistance, and operational-resilience applications under FCA-aligned controls.
• Manufacturing and industrial — plant-floor inspectors, maintenance leads, and OEE owners consume vision-QA, predictive-maintenance, and operator-copilot applications against existing MES and historian systems.
• Retail and consumer — merchandising teams, store ops, and category managers consume demand-forecasting, assortment, and store-ops copilot applications against existing point-of-sale and supply-chain feeds.
• Telco — network ops, fault triage, and customer-care teams consume churn-explainability and incident-triage applications against the operator's OSS and BSS estate.
• Public sector — caseworkers, FOI teams, accessibility and translation teams in central and local government consume case-handling and FOI-response applications under OFFICIAL-tier controls.
• Platform operators — IT, identity, data governance, and FinOps own the workspace, the OIDC federation, the data-source bindings, the audit configuration, and the spend caps that every deployed application inherits.

Customer experience walkthrough#

A platform operator signs in to the Yobibyte console with the organisation's identity provider. OIDC federation is configured once at the workspace level and the same SSO bounce works for every application deployed into that workspace. The operator picks the workspace whose sovereignty region (UK NCSC OFFICIAL, EU Data Boundary, US HIPAA / FedRAMP-equivalent) matches where the application's data will live; that pin propagates to every application deployed inside it.

The operator opens the marketplace and switches to the AI Applications view, browsing by industry, by category (decision support, vision QA, document understanding, agentic workflows, recommendation), or by sovereignty. Each entry shows the publisher (Yobitel or named partner), the deployment footprint, the configuration surface, the supported integrations, and the USD pricing tier. Filtering by the workspace's sovereignty pin first ensures only deployable applications are visible.

The operator clicks Deploy on the chosen application — for a UK trust adopting MediQuery, that opens the application's configuration wizard. The wizard captures data-source bindings (the trust's EHR, imaging archive, formulary feeds), RBAC role mappings against the trust's IdP groups, knowledge-base ingestion sources, branding assets, and policy bindings (consent boundaries, retention windows, audit destinations). The runtime recipe behind the application is operated by Yobitel against the application's verified deployment profile; the customer never picks models, inference profiles, or accelerators.

Within 10–30 minutes the application transitions to Ready and surfaces a workspace-scoped, customer-branded URL the end users can sign into. End users see their organisation's brand and their own SSO experience, not Yobitel's. The configuration wizard is the application's permanent surface — adding a new data source, rotating a knowledge base, or rebinding RBAC after an IdP migration is done through the wizard, and every change creates a configuration revision that audit logs reference.

Configuration surface#

The suite introduces a small set of concepts that sit above the workspace primitives. The mental model is: a published application is a packaged outcome; deploying it instantiates a configuration surface; the customer fills that surface in; Yobitel operates the runtime; revisions and audit flow through the workspace.

• Application Catalogue — the curated set of first-party Yobitel applications and verified partner-published applications. Catalogue listings carry sovereignty, licence, industry/vertical, integration, footprint, and pricing metadata. Customers see only applications eligible for their workspace's sovereignty pin and tier.
• Deployment Profile — the verified runtime recipe attached to a catalogue entry. It defines the model selection, inference profile, retrieval and evaluation behaviour, fine-tune cadence, and GPU SKU shape the application is operated against. Profiles are versioned and revisable by the publisher; customers see only the active profile and its release notes.
• Configuration Surface — the customer-owned settings the deployment wizard captures: data-source bindings, knowledge bases, RBAC mappings, branding, policy bindings, retention windows, and audit destinations. Every save creates a configuration revision with a hash, an author, and a diff.
• Data Source Binding — the link from the application to a customer-owned data system (object storage, database, EHR, ticketing system, content management system, message bus). Bindings carry credentials supplied via the workspace's secret manager and a scope declaration (read-only, write-back, event-stream).
• RBAC Roles — the application's user roles mapped onto the customer's existing IdP groups. Default applications ship with sensible role templates (Clinician / Pharmacist / Auditor for MediQuery, for example); customers refine the mapping during the wizard.
• Branding — application-level theming (logo, colour, domain, login screen) so internal users see a customer-branded experience rather than a Yobitel-branded one. This is configuration, not a fork.
• Configuration Revision — an immutable snapshot of the configuration surface at a point in time. Revisions are referenced by audit logs and can be rolled back; the runtime always serves against a specific revision so there is no implicit cutover.
• Application Identity — every application deployment is a first-class identity inside the workspace, so its downstream calls (to data sources, to other workspace inferences, to audit sinks) are attributed and audited as the application, not as the user.

Data integrations#

Applications integrate with the systems the customer already has. Each application declares the integrations its deployment profile supports; the configuration wizard captures the customer-side endpoints and the credentials, sourced from the workspace's secret manager. The runtime that talks to those systems is operated by Yobitel against the application's published profile.

The common integration set across the catalogue today: EHR connectivity via FHIR R4 and HL7v2 (Epic, Cerner Millennium, Meditech, EMIS Web, TPP SystmOne); CRM and case-management via Salesforce, ServiceNow, and Dynamics 365; ERP via SAP S/4HANA and Oracle; observability and SIEM via Splunk, Microsoft Sentinel, Elastic, and the workspace's OpenTelemetry collector; clinical reference connectors for NICE, BNF, FDA, DrugBank, RxNorm, PubMed, Cochrane, UpToDate, ClinicalKey, DynaMed; and generic object storage and database connectivity (S3-compatible, Postgres, SQL Server) for customer-curated content. Each application's marketplace entry lists the integrations its deployment profile certifies.

Data-source bindings carry a scope declaration (read-only, write-back, event-stream) and authenticate via the workspace's secret manager. Credentials never reach the application's user-facing surface, and every read or write is recorded in the workspace audit stream against the application identity rather than the user identity.

Identity and RBAC#

Identity federation is configured once at the workspace level via OIDC against the customer's primary identity provider (Okta, Microsoft Entra ID, NHS Care Identity, Keycloak, and others); the same SSO bounce works for every application deployed into that workspace. Optional SCIM 2.0 provisioning keeps users and groups in sync without manual mapping.

Each application carries a set of RBAC roles — MediQuery uses Clinician, Pharmacist, Auditor as a representative example; partner-published applications carry their own role taxonomy. The configuration wizard maps each application role onto the customer's IdP groups; the runtime resolves the role at sign-in and surfaces the application's role-specific defaults. Every authentication, every role resolution, and every authorised action is written to the workspace audit stream with both the user identity and the application identity captured.

Workspace-scoped roles cut across applications: workspace owners and platform operators see the deployed-applications view and the configuration wizard, while end users see only the applications their IdP groups are mapped into. Data governance roles (audit-only, compliance-officer) read the audit stream and configuration revisions without being able to mutate them.

Deployment modes#

The suite supports three deployment modes per application. The mode is declared on the application's catalogue entry; some applications support all three, others (typically partner-published) support a subset. Each mode inherits the host workspace's sovereignty pin.

• Managed multi-tenant on Yobitel NeoCloud — the default for most applications. The customer's workspace is an isolated tenant inside a Yobitel-operated sovereignty region, and the application runs on shared underlying capacity. Suitable for the majority of clinical, financial-services, and cross-industry deployments where workspace-level isolation meets the compliance bar.
• Dedicated single-tenant on Yobitel NeoCloud — for customers that require sole-tenant infrastructure for procurement or compliance reasons. Same managed posture, separate underlying capacity, with a per-customer performance and noisy-neighbour guarantee. Most often used by US health systems on HIPAA where the BAA scope mandates sole tenancy, and by regulated banks under FCA operational-resilience obligations.
• Air-gapped on-premise — for the highest-sensitivity environments where no external network egress is permitted. Yobitel deploys the application runtime into a customer-owned or Yobitel-operated on-premise enclave; data sources are local; audit export writes to an on-premise object store. Connectors that depend on external APIs are replaced with local mirrors maintained by the customer. Currently available for MediQuery and a subset of vertical applications; partner-published applications mark their air-gapped support explicitly.

Compliance posture matrix#

Compliance is declared per application and enforced at admission against the host workspace's sovereignty pin. The matrix below summarises the framework coverage across the catalogue today; per-application attestations are visible in the marketplace listing.

The portfolio today#

The catalogue is curated. Every entry carries a verified deployment profile, a documented configuration surface, declared integrations, and an explicit sovereignty and compliance posture. The table below summarises the portfolio shape; items marked Preview are on the roadmap and not yet generally available.

Pricing#

Application pricing is tiered in USD and layered on top of the workspace's inference and storage consumption. The tier covers the application's published deployment profile (runtime envelope, configuration capacity, support SLA); incremental inference, fine-tuning, knowledge-base storage, and audit-stream destinations flow through the workspace's standard FOCUS 1.1 billing export and are attributed back to the application as a line-item tag.

Customers see a single FOCUS-shaped bill that pivots cleanly by application, by workspace, or by business unit. Spend caps can be set both at the application level (a hard ceiling for that application's incremental consumption) and at the workspace level (an overall safety net).

Outcomes#

Customers adopting from the AI Applications Suite typically measure success on four signals across the verticals. The exact numbers depend on the application, but the leading indicators are consistent because every application inherits the same workspace and audit surface.

• Time to first user — deploy-and-configure flows reach first end-user sign-in within days rather than the months a bespoke build would take. A UK NHS trust adopting MediQuery typically reaches first clinical use within four to six weeks of contract; partner-published apps in less regulated verticals can reach first user inside one or two weeks.
• End-user engagement — active-user count as a fraction of licensed seats is the cleanest engagement signal. Healthy clinical and case-handling deployments converge on 60-80% weekly active by the end of pilot; sub-40% indicates a configuration problem (wrong knowledge sources, wrong default surface) rather than an application problem.
• Workflow quality — the application-specific quality metric (citation coverage for clinical decision support, fraud catch-rate for fraud detection, defect-detection precision for vision QA) is published in the application's dashboard and tracked through the audit stream. Each application's expected band is published on the catalogue entry.
• Compliance evidence — the workspace audit stream becomes a single source of truth across the deployed application estate. Trusts under DSP Toolkit, banks under FCA operational-resilience reporting, and public-sector bodies under OFFICIAL-tier audit can pull a unified per-application evidence pack rather than reconciling across multiple vendor surfaces.

Where the AI Applications Suite fits in the Yobitel stack#

The AI Applications Suite sits at the customer's consumption surface — it is what end users actually see and interact with. Yobibyte sits underneath as the runtime layer: it operates the workspace, the managed inference and fine-tune surface, the identity and audit pipeline, and the FOCUS-aligned billing export that every application inherits. The distinction matters: a customer adopting Yobibyte directly is buying a managed platform to run their own deployments against; a customer adopting from the AI Applications Suite is buying a packaged workflow that Yobibyte happens to operate underneath.

Omniscient Compute is the capacity layer below Yobibyte; it knows every accelerator, region, and price across the broader marketplace, and the runtime supporting each application is grounded in current capacity and pricing. InferenceBench sits alongside as the public benchmarking and economics layer; the catalogue uses InferenceBench-sourced ranking as a public reference point, so the deployment profile attached to MediQuery (or to any other application) reflects the same public methodology anyone can verify at inferencebench.io.

Practically, a customer can adopt the stack at any layer. A platform team can adopt Yobibyte and operate their own deployments directly. An application team can deploy from the AI Applications Suite without ever touching the layers beneath. The contracts are stable at each boundary, and the same workspace identity, audit, and billing surface holds whether the customer is consuming a managed inference, a fine-tune workflow, or a deployed application.