KAEL Architecture

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.

System map

flowchart LR
    U[User or integration] --> S[Chat, KAEL, Discord, Telegram, API]
    S --> A[AeThex API / KAEL runtime]
    A --> I[Identity and clearance]
    A --> K[AeThex knowledge]
    A --> M[Model provider]
    A --> P[Persistent state]
    A --> T[Permissioned tools]
    P --> H[History]
    P --> R[Memory]
    P --> W[World model]

Public surfaces

• chat.aethex.tech — conversational client.
• kael.aethex.tech — dedicated KAEL system and operator interface.
• api.aethex.tech — Express API serving chat, streaming, identity, history, memory, documents, feeds, agents, and integrations.
• Discord interactions — slash commands delivered through the signed Discord interactions endpoint.
• Telegram and audio modules — optional capabilities enabled only when their runtime credentials are configured.

Request lifecycle

For a standard streaming request:

1. The API validates that a message or image exists.
2. It resolves optional tenant credentials.
3. It resolves the signed-in identity, ARM state, and operator authorization.
4. It calculates clearance and rate limits.
5. It selects a permitted model.
6. It loads recent history.
7. It injects matched AeThex knowledge.
8. When permitted, it injects user memory or the KAEL world model.
9. It executes the model stream and any allowed tools.
10. It emits Server-Sent Events and stores updated history.

Knowledge layer

KAEL loads structured JSON entries from its knowledge directory. Each entry contains:

• An identifier.
• Match phrases or keywords.
• A canonical response.
• Optional related topics.

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.

Models

KAEL exposes stable client-facing model keys while provider model IDs can change. Runtime providers currently include:

• A standard Nous-compatible inference provider.
• Anthropic-backed higher tiers and image handling when configured.
• OpenRouter-backed model routing where enabled.

Clients should request a catalog key from /kael/models, not a provider model ID.

Identity and clearance

Identity may come from:

• An anonymous network session.
• A KAEL authentication cookie.
• AeThex Passport profile data.
• ARM membership.
• An invite or ARM cookie.
• A tenant key.
• A permissioned operator token.

Operator tokens and tenant keys have different purposes and must not be treated as interchangeable.

Persistent state

KAEL stores operational state in Supabase-backed tables, including:

• Session history.
• User memory.
• Ratings and featured conversations.
• Generated documents.
• Rate-limit counters.
• Invites.
• Tenant configuration.
• Operator records.
• Observations.
• Agent runs.
• World-model entries.

See KAEL Memory and KAEL Safety for lifecycle and access guidance.

Integrations

• Discord requests are verified using Discord signatures.
• Git deployment webhooks use a shared HMAC signature.
• Telegram initializes only when a bot token is configured.
• Audio routes expose transcription and speech capabilities only when their providers are configured.
• A DB-backed scheduler runs configured recurring tasks such as briefs.

Related documentation

• KAEL Capabilities
• KAEL API
• KAEL Memory
• KAEL Safety
• Discord Integration