Blame
|
1 | # KAEL Architecture |
||||||
| 2 | ||||||||
| 3 | KAEL is implemented as a set of public surfaces around the AeThex API, backed by model providers, AeThex knowledge, identity, persistent state, and permissioned tools. |
|||||||
| 4 | ||||||||
| 5 | | Field | Value | |
|||||||
| 6 | |---|---| |
|||||||
| 7 | | Product maturity | Live / evolving | |
|||||||
| 8 | | Documentation status | Active | |
|||||||
| 9 | | API base | `https://api.aethex.tech` | |
|||||||
| 10 | | Public chat | [chat.aethex.tech](https://chat.aethex.tech) | |
|||||||
| 11 | | Last source review | 2026-06-26 | |
|||||||
| 12 | ||||||||
| 13 | ## System map |
|||||||
| 14 | ||||||||
| 15 | ```mermaid |
|||||||
| 16 | flowchart LR |
|||||||
| 17 | U[User or integration] --> S[Chat, KAEL, Discord, Telegram, API] |
|||||||
| 18 | S --> A[AeThex API / KAEL runtime] |
|||||||
| 19 | A --> I[Identity and clearance] |
|||||||
| 20 | A --> K[AeThex knowledge] |
|||||||
| 21 | A --> M[Model provider] |
|||||||
| 22 | A --> P[Persistent state] |
|||||||
| 23 | A --> T[Permissioned tools] |
|||||||
| 24 | P --> H[History] |
|||||||
| 25 | P --> R[Memory] |
|||||||
| 26 | P --> W[World model] |
|||||||
| 27 | ``` |
|||||||
| 28 | ||||||||
| 29 | ## Public surfaces |
|||||||
| 30 | ||||||||
| 31 | - `chat.aethex.tech` — conversational client. |
|||||||
| 32 | - `kael.aethex.tech` — dedicated KAEL system and operator interface. |
|||||||
| 33 | - `api.aethex.tech` — Express API serving chat, streaming, identity, history, memory, documents, feeds, agents, and integrations. |
|||||||
| 34 | - Discord interactions — slash commands delivered through the signed Discord interactions endpoint. |
|||||||
| 35 | - Telegram and audio modules — optional capabilities enabled only when their runtime credentials are configured. |
|||||||
| 36 | ||||||||
| 37 | ## Request lifecycle |
|||||||
| 38 | ||||||||
| 39 | For a standard streaming request: |
|||||||
| 40 | ||||||||
| 41 | 1. The API validates that a message or image exists. |
|||||||
| 42 | 2. It resolves optional tenant credentials. |
|||||||
| 43 | 3. It resolves the signed-in identity, ARM state, and operator authorization. |
|||||||
| 44 | 4. It calculates clearance and rate limits. |
|||||||
| 45 | 5. It selects a permitted model. |
|||||||
| 46 | 6. It loads recent history. |
|||||||
| 47 | 7. It injects matched AeThex knowledge. |
|||||||
| 48 | 8. When permitted, it injects user memory or the KAEL world model. |
|||||||
| 49 | 9. It executes the model stream and any allowed tools. |
|||||||
| 50 | 10. It emits Server-Sent Events and stores updated history. |
|||||||
| 51 | ||||||||
| 52 | ## Knowledge layer |
|||||||
| 53 | ||||||||
| 54 | KAEL loads structured JSON entries from its knowledge directory. Each entry contains: |
|||||||
| 55 | ||||||||
| 56 | - An identifier. |
|||||||
| 57 | - Match phrases or keywords. |
|||||||
| 58 | - A canonical response. |
|||||||
| 59 | - Optional related topics. |
|||||||
| 60 | ||||||||
| 61 | The runtime watches those files and reloads changed entries without requiring a full service restart. Matched entries are added to the model context so stable AeThex facts take precedence over improvisation. |
|||||||
| 62 | ||||||||
| 63 | ## Models |
|||||||
| 64 | ||||||||
| 65 | KAEL exposes stable client-facing model keys while provider model IDs can change. Runtime providers currently include: |
|||||||
| 66 | ||||||||
| 67 | - A standard Nous-compatible inference provider. |
|||||||
| 68 | - Anthropic-backed higher tiers and image handling when configured. |
|||||||
| 69 | - OpenRouter-backed model routing where enabled. |
|||||||
| 70 | ||||||||
| 71 | Clients should request a catalog key from `/kael/models`, not a provider model ID. |
|||||||
| 72 | ||||||||
| 73 | ## Identity and clearance |
|||||||
| 74 | ||||||||
| 75 | Identity may come from: |
|||||||
| 76 | ||||||||
| 77 | - An anonymous network session. |
|||||||
| 78 | - A KAEL authentication cookie. |
|||||||
| 79 | - AeThex Passport profile data. |
|||||||
| 80 | - ARM membership. |
|||||||
| 81 | - An invite or ARM cookie. |
|||||||
| 82 | - A tenant key. |
|||||||
| 83 | - A permissioned operator token. |
|||||||
| 84 | ||||||||
| 85 | Operator tokens and tenant keys have different purposes and must not be treated as interchangeable. |
|||||||
| 86 | ||||||||
| 87 | ## Persistent state |
|||||||
| 88 | ||||||||
| 89 | KAEL stores operational state in Supabase-backed tables, including: |
|||||||
| 90 | ||||||||
| 91 | - Session history. |
|||||||
| 92 | - User memory. |
|||||||
| 93 | - Ratings and featured conversations. |
|||||||
| 94 | - Generated documents. |
|||||||
| 95 | - Rate-limit counters. |
|||||||
| 96 | - Invites. |
|||||||
| 97 | - Tenant configuration. |
|||||||
| 98 | - Operator records. |
|||||||
| 99 | - Observations. |
|||||||
| 100 | - Agent runs. |
|||||||
| 101 | - World-model entries. |
|||||||
| 102 | ||||||||
| 103 | See [[KAEL Memory]] and [[KAEL Safety]] for lifecycle and access guidance. |
|||||||
| 104 | ||||||||
| 105 | ## Integrations |
|||||||
| 106 | ||||||||
| 107 | - Discord requests are verified using Discord signatures. |
|||||||
| 108 | - Git deployment webhooks use a shared HMAC signature. |
|||||||
| 109 | - Telegram initializes only when a bot token is configured. |
|||||||
| 110 | - Audio routes expose transcription and speech capabilities only when their providers are configured. |
|||||||
| 111 | - A DB-backed scheduler runs configured recurring tasks such as briefs. |
|||||||
| 112 | ||||||||
| 113 | ## Related documentation |
|||||||
| 114 | ||||||||
| 115 | - [[KAEL Capabilities]] |
|||||||
| 116 | - [[KAEL API]] |
|||||||
| 117 | - [[KAEL Memory]] |
|||||||
| 118 | - [[KAEL Safety]] |
|||||||
| 119 | - [[Discord Integration]] |
|||||||