KokuaOS — Architecture Overview

A non-confidential summary of how the KokuaOS Platform is built and how data flows, for security reviewers and procurement teams.

Capitalized terms have the meanings in the KokuaOS Definitions Schedule (kokuaos.com/legal/definitions).

1. Purpose and scope

This overview gives security reviewers, procurement teams, and prospective Customers a high-level, non-confidential picture of the KokuaOS Platform: how it is hosted, how tenants are isolated, how data flows through an AI Employee interaction, and where the responsibility line sits between KokuaOS and Customer- or Service Provider-supplied providers. It describes capabilities and controls at a high level only. It intentionally omits source-level design, proprietary implementation detail, and the specific legal names of model and carrier providers; deeper technical materials are available under NDA. For security and compliance detail, see the Security Overview (kokuaos.com/trust/security) and Compliance Overview (kokuaos.com/trust/compliance).

2. Platform model

KokuaOS is a hosted, multi-tenant SaaS platform operated on Microsoft Azure, using managed Azure services including Azure SQL for relational data. Running on a leading enterprise cloud lets us inherit strong physical and infrastructure security and regional resilience while we focus our controls at the application, data, and orchestration layers. All Customers are served from a common, continuously maintained Platform rather than bespoke per-customer stacks.

3. Tenancy, isolation, and the commercial hierarchy

• Logical per-tenant isolation. Each tenant's data and configuration are logically isolated, and access is tenant-scoped so that one tenant cannot reach another tenant's data through the Services.
• Role-based access control (RBAC). Access is governed by roles mapped to the four-tier commercial hierarchy — Master Admin → Service Provider → Reseller → Customer. Each tier sees and manages only what its role permits, and pricing and administration flow through each account's Commercial Parent.
• Secret isolation. Secrets and credentials are isolated per entity, with no cross-entity inheritance, so that one entity's keys and integration credentials are never shared with another.

4. How an interaction flows

At a high level, a typical AI Employee interaction follows this path:

1. Inbound channel. A contact arrives over a Communication Channel — voice/telephony, SMS, email, web chat, or a messaging channel.
2. Orchestration. The Platform's orchestration layer authenticates and routes the interaction, applies the Customer's configuration (the AI Employee's instructions, Knowledge Base, and any Compliance Shield disclosure, consent, verification, or recording settings), and assembles the context for the AI Services.
3. AI provider. The orchestration layer calls an AI "brain" — a managed large-language-model provider or, where a Service Provider brings its own, a BYO Provider — together with supporting capabilities such as speech-to-text and text-to-speech for voice.
4. Response. The generated AI Output is returned through the same channel to the end user, and the interaction is recorded as one or more Usage Events for metering and reporting.

Throughout, the Customer's configuration and governance settings determine what the AI Employee is permitted to do, what it discloses, and whether the interaction is recorded.

5. Communication channels and telephony

Voice and telephony are delivered through LiveKit for real-time media, integrated with SIP and carrier connectivity for inbound and outbound calling. The Platform also supports non-voice Communication Channels such as SMS, email, web chat, and common messaging channels. Telephone numbers (DIDs) and carrier connectivity may be provided by KokuaOS-managed providers or brought by a Service Provider as part of its own stack; number porting and control are subject to carrier rules, law, and fraud/security review.

6. Managed stack vs. BYO stack

A defining feature of the Platform is a clean split between two operating models:

In the BYO model, the Service Provider (or an enterprise BYO Customer) is solely responsible for its own providers — accounts, fees, credentials, security, compliance, and availability. KokuaOS orchestrates these providers but does not warrant Third-Party or BYO Providers, and their outages are excluded from the SLA and from KokuaOS liability. See the BYO Provider Policy (kokuaos.com/legal/byo-providers).

7. Encryption and secrets

• In transit. Encrypted using industry-standard TLS.
• At rest. Customer Data is encrypted at rest using strong, industry-standard algorithms.
• Field-level secret encryption. Sensitive values such as integration credentials and provider keys receive field-level encryption and are isolated per entity, with no cross-entity inheritance.
• Key management. Encryption keys are managed through the cloud provider's key-management services under access controls and rotation practices.

8. Usage metering and consumption

The Platform includes a usage/consumption metering engine that records Usage Events per tenant, per AI Employee, and per Communication Channel, capturing the measured AI Consumption and related activity that drives reporting and billing. Measured usage records govern billing; dashboards, forecasts, budgets, and alerts are estimates only and do not cap or guarantee cutoff. Sandbox and testing activity can generate billable AI Consumption. See the AI Services & AI Consumption Policy (kokuaos.com/legal/ai-consumption).

9. Compliance Shield

The Compliance Shield is a configurable governance layer that lets Customers apply disclosure, consent, verification, recording, and related data-handling controls to AI Employee interactions. It is a tool designed to support compliance programs; it does not by itself make any party compliant, and the Customer is responsible for selecting and configuring the controls its use case requires. See the Compliance Overview (kokuaos.com/trust/compliance).

10. Integrations and workflows

The Platform provides governed extensibility through three capabilities:

• EasyAPI — connecting the Platform to external systems and APIs.
• EasyFunctions — defining and executing governed custom functions and actions the AI Services may invoke.
• EasyFlow — building and executing multi-step conversational and task workflows.

These capabilities operate within the Platform's access controls and tenant isolation, so that integrations and automations run under the permissions of the entity that configures them.

11. Security and compliance posture

This architecture is operated under the safeguards summarized in the Security Overview (administrative, technical, and physical controls, monitoring, incident response, and vendor management) and the posture described in the Compliance Overview (designed-to-support controls and the shared-responsibility model). Certification status is stated honestly on the Trust Center (/trust): KokuaOS is not SOC 2 or ISO/IEC 27001 certified today; those are on our roadmap.

12. What this overview does and does not do

This page describes the Platform at a high level for transparency and security review. It is not a complete or confidential specification, and it does not disclose source-level design, proprietary implementation, or the specific legal names of model, carrier, or media vendors, which are Confidential Information and, where applicable, available under NDA and in the Subprocessor Policy (kokuaos.com/legal/subprocessors). It describes practices in effect as of the date above, may change as the Platform evolves, and does not modify any agreement or create any warranty or commitment. No architecture can guarantee that the Services will be uninterrupted, error-free, or invulnerable. For questions, contact security@kokuaos.com or trust@kokuaos.com.