Architecture
How context, memory, tools and approvals flow — what exists today and what is in development
This page separates two things: the architecture of the GENIE platform as it runs today (Available), and the target architecture in development for OmniGENIE inside OmniOmni (In development). Diagram edges that are in development are drawn dashed and labelled.
Today: the GENIE platform
The productive platform is a self-hosted, containerised stack with these building blocks:
| Building block | Role | Status |
|---|---|---|
| Voice transport | WebRTC media server for real-time sessions; SIP trunk for telephony. | Available |
| Voice pipeline | Speech-to-text, language model and text-to-speech as a cascade; an alternative speech-to-speech mode. Automatic fallback for text-to-speech only. | Available |
| Memory engine | Fact extraction after each turn, revision chain, sensitivity tiers, recall with relevance thresholds, asynchronous graph projection. | Available |
| Tool dispatch | Tools tagged with sensitivity tiers; invocations logged with argument digests and outcomes. | Available |
| Web application and API | Account, memory management, correction and deletion, administration surface behind an explicit allowlist. | Available |
| Data stores | PostgreSQL with vector extension; Redis for queues and caches. | Available |
| Background workers | Queue worker, graph projection worker, scheduled jobs. | Available |
| Language-model gateway | Model access through a gateway with a configurable model allowlist. | Available |
In development: OmniGENIE inside OmniOmni
The target design places OmniGENIE as a horizontal layer that reads context from OmniOmni components and prepares actions, while every write stays on the components' existing authorised paths. None of the dashed edges exist today.
Trust boundaries
| Boundary | Principle | Status |
|---|---|---|
| User to assistant | Every request runs in the context of an authenticated account; today this is consumer OAuth, in the target design the institution's identity provider. | Available / In development |
| Assistant to memory | Memory is scoped per account. Institution-level tenant isolation is part of the target design. | Available / In development |
| Assistant to tools | Tools are tiered by sensitivity and every invocation is logged. In the target design a policy layer maps tools to action tiers per institution. | Available / In development |
| Assistant to OmniOmni | Read interfaces only; any write is a prepared action handed to the existing approval path. | In development |
| Assistant to model providers | Model access through a gateway; providers receive conversation content required for inference. Data-residency configuration is an institutional decision (see Deployment). | Available |
| Untrusted content | Third-party text and responses from other agents are framed as data, not instructions, at specific boundaries; a system-wide layer is in development. | Implemented, not enabled / In development |
Action tiers (target design)
In development| Tier | Name | Scope | Gate |
|---|---|---|---|
| 0 | Observe | Read authorised documents, memory and component status. | Runs within the user's own permissions. |
| 1 | Draft | Produce summaries, case files, message drafts. | Output is labelled as a draft; nothing is sent or stored in a system of record. |
| 2 | Recommend | Propose next steps or options. | Output carries a notice that a person decides. |
| 3 | Execute with approval | Prepare an action in OmniAsset, OmniSafe or OmniEagle. | Execution only after an explicit human approval through the component's authorised mechanism (Proof-of-Action via OmniPersona). |
| 4 | Auto-execute | Autonomous execution without a human step. | Disabled for financial-market actions. |
Existing building blocks that the target design would reuse: the graded routing outcomes (allow, allow with summary, require approval, block, escalate) and the single-use approval token bound to the exact payload — both Implemented, not enabled in the GENIE platform for other purposes today.
Approved action: sequence (target design)
What is recorded
OmniGENIE is designed to record operational artefacts, not the model's internal reasoning. Internal model reasoning is neither published nor stored as an audit artefact.
- the input and the permitted context,
- the sources used,
- model, prompt and policy versions,
- tool calls with parameter classes and argument digests,
- permission and policy checks,
- approvals and the executing identity,
- result, status and errors,
- a short, human-readable rationale.
Of these, tool invocation logging with argument digests, voice-session lifecycle events and administrative audit events exist today (Available); the complete artefact set per action is part of the target design (In development).
Diagrams on this page show relationships that are either implemented in the GENIE platform or explicitly labelled as in development. No OmniOmni endpoint is shown that is not documented in the respective component's API reference.