Commit be64c9
2026-06-27 00:39:17 AeThex Docs: Build out operational docs platform| /dev/null .. api-quickstart.md | |
| @@ 0,0 1,75 @@ | |
| + | # API Quickstart |
| + | |
| + | This quickstart uses the public AeThex API at `https://api.aethex.tech`. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Base URL | `https://api.aethex.tech` | |
| + | | OpenAPI | [[OpenAPI Reference]] | |
| + | | Last verified | 2026-06-26 | |
| + | |
| + | ## 1. Check service health |
| + | |
| + | ```bash |
| + | curl https://api.aethex.tech/health |
| + | ``` |
| + | |
| + | The response reports the API service version, uptime, loaded knowledge count, and enabled model classes. Treat model identifiers as runtime information; clients should not hard-code them. |
| + | |
| + | ## 2. List available KAEL models |
| + | |
| + | ```bash |
| + | curl https://api.aethex.tech/kael/models |
| + | ``` |
| + | |
| + | The returned catalog contains stable client keys such as `standard` and their current access tier. |
| + | |
| + | ## 3. Send a streaming request |
| + | |
| + | `POST /kael/stream` returns Server-Sent Events. |
| + | |
| + | ```bash |
| + | curl --no-buffer https://api.aethex.tech/kael/stream \ |
| + | -H 'Content-Type: application/json' \ |
| + | -d '{ |
| + | "message": "What is AeThex Passport?", |
| + | "sessionId": "quickstart-example", |
| + | "source": "docs", |
| + | "model": "standard" |
| + | }' |
| + | ``` |
| + | |
| + | The stream begins with model metadata, emits JSON events containing response tokens, and ends with: |
| + | |
| + | ```text |
| + | data: [DONE] |
| + | ``` |
| + | |
| + | ## 4. Handle errors inside the stream |
| + | |
| + | Because the response is an event stream, some errors arrive as SSE data rather than a non-2xx HTTP response: |
| + | |
| + | ```json |
| + | {"error":"rate_limit","clearance":1,"limit":20,"message":"..."} |
| + | ``` |
| + | |
| + | Clients should: |
| + | |
| + | - Parse each `data:` event. |
| + | - Stop when receiving `[DONE]`. |
| + | - Handle `error` objects separately from token events. |
| + | - Reconnect only when appropriate; do not automatically replay a completed prompt. |
| + | |
| + | ## 5. Choose an identity model |
| + | |
| + | Public requests can operate without a Passport session but receive lower limits. Signed-in and approved identities can receive expanded capabilities. Tenant keys and operator tokens are separate credentials and must never be embedded in browser code. |
| + | |
| + | ## Next steps |
| + | |
| + | - [[API Reference]] |
| + | - [[Authentication]] |
| + | - [[Rate Limits]] |
| + | - [[KAEL API]] |
| + | - [[Webhooks]] |
| api-reference.md .. | |
| @@ 45,4 45,3 @@ | |
| See [[Authentication]]. | |
| - | {{PageIndex}} |
| architecture.md .. | |
| @@ 31,9 31,8 @@ | |
| ## Key Topics | |
| - [[Platform Overview]] | |
| - | - [[Passport Architecture]] |
| + | - [[Passport]] |
| - [[Multi-Tenancy]] | |
| - [[Security Model]] | |
| - [[Database Design]] | |
| - | {{PageIndex}} |
| /dev/null .. discord-integration.md | |
| @@ 0,0 1,57 @@ | |
| + | # Discord Integration |
| + | |
| + | KAEL and AeThex Bot provide related but distinct Discord capabilities. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Community | [discord.gg/athx](https://discord.gg/athx) | |
| + | | AeThex Bot | [aethex.bot](https://aethex.bot) | |
| + | | Last verified | 2026-06-26 | |
| + | |
| + | ## Choose the integration |
| + | |
| + | | Surface | Use it for | |
| + | |---|---| |
| + | | AeThex Bot | General Discord-community automation and community-facing integrations | |
| + | | KAEL Discord application | AeThex intelligence commands backed by the KAEL service | |
| + | | AeThex community | Direct participation in the official AeThex Discord | |
| + | |
| + | ## Current KAEL commands |
| + | |
| + | The API currently implements Discord interaction handling for: |
| + | |
| + | - `/kael` — ask KAEL using the caller’s Discord identity as session context. |
| + | - `/ask` — route a question through the deeper reasoning mode. |
| + | - `/status` — check the configured AeThex service set. |
| + | - `/agent` — run a bounded agent goal and return the result to Discord. |
| + | |
| + | Command availability depends on which commands are registered for the Discord application. |
| + | |
| + | ## Interaction security |
| + | |
| + | The Discord endpoint: |
| + | |
| + | - Accepts Discord interaction payloads at `/discord/interactions`. |
| + | - Verifies Discord’s Ed25519 request signature and timestamp. |
| + | - Rejects unsigned or invalid requests. |
| + | - Defers long-running commands before posting the final response. |
| + | |
| + | Never expose the Discord bot token, application credentials, signing keys, or webhook URLs in documentation, browser code, screenshots, or issue reports. |
| + | |
| + | ## Session behavior |
| + | |
| + | KAEL derives a Discord session identifier from the Discord user ID. Recent messages may be retained as conversational history for that session. Discord responses are truncated to fit Discord message limits. |
| + | |
| + | ## Community installation |
| + | |
| + | Public self-service installation behavior should be documented on [aethex.bot](https://aethex.bot). Do not assume the KAEL Discord application is available for arbitrary third-party installation unless the application’s installation flow explicitly offers it. |
| + | |
| + | ## Related documentation |
| + | |
| + | - [[KAEL]] |
| + | - [[KAEL Architecture]] |
| + | - [[KAEL Safety]] |
| + | - [[Webhooks]] |
| + | - [[Security]] |
| /dev/null .. documentation-standards.md | |
| @@ 0,0 1,58 @@ | |
| + | # Documentation Standards |
| + | |
| + | These standards keep AeThex documentation operational, reviewable, and honest about the maturity of each system. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Maintainer | AeThex documentation maintainers | |
| + | | Last verified | 2026-06-26 | |
| + | |
| + | ## Required page header |
| + | |
| + | Product and service pages should identify: |
| + | |
| + | - Product maturity: research, alpha, beta, live, maintenance, or deprecated. |
| + | - Documentation status: draft, active, needs verification, or archived. |
| + | - Public URL when one exists. |
| + | - Owning AeThex program. |
| + | - Last verified date. |
| + | - Source repository when public. |
| + | |
| + | ## Content requirements |
| + | |
| + | A stable product page should answer: |
| + | |
| + | 1. What is this system? |
| + | 2. Who is it for? |
| + | 3. What works now? |
| + | 4. How does someone begin? |
| + | 5. Which identities or permissions are required? |
| + | 6. What data does it store? |
| + | 7. What are its known limitations? |
| + | 8. Where are changes recorded? |
| + | |
| + | ## Maturity language |
| + | |
| + | | Label | Meaning | |
| + | |---|---| |
| + | | Research | Exploring the problem; interfaces are not commitments | |
| + | | Alpha | Implemented but expected to change | |
| + | | Beta | Usable with known limitations | |
| + | | Live | Publicly available and actively operated | |
| + | | Maintenance | Supported with limited active development | |
| + | | Deprecated | Scheduled for removal or replacement | |
| + | |
| + | ## Verification |
| + | |
| + | - “Last verified” means a maintainer checked the page against the running system or current source. |
| + | - Automated health checks do not replace behavioral verification. |
| + | - Pages older than 90 days should be reviewed or marked as needing verification. |
| + | - Never publish credentials, private operator endpoints, internal hostnames, or user data. |
| + | |
| + | ## Change discipline |
| + | |
| + | - Update the changelog before announcing a shipped capability. |
| + | - Link behavior changes to the affected reference page. |
| + | - Keep future plans in roadmaps, not API reference pages. |
| + | - Preserve historical entries; add corrections rather than silently rewriting history. |
| foundation.md .. | |
| @@ 35,4 35,3 @@ | |
| - [[Community]] | |
| - [[Open Source]] | |
| - | {{PageIndex}} |
| gameforge.md .. | |
| @@ 47,4 47,3 @@ | |
| - [[Webhooks]] | |
| - [[Architecture]] | |
| - | {{PageIndex}} |
| getting-started.md .. | |
| @@ 1,84 1,89 @@ | |
| # Getting Started | |
| - | Welcome to AeThex. |
| + | Choose the path that matches what you are trying to accomplish. AeThex is an ecosystem of identity, development, intelligence, community, and research services; you do not need to learn every part before beginning. |
| - | This guide explains the core concepts of the AeThex ecosystem and helps users begin with their first account, organization, and project. |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Maintainer | AeThex | |
| + | | Last verified | 2026-06-26 | |
| + | | Service map | [[Service Directory]] | |
| - | --- |
| + | ## Choose your path |
| - | ## What is AeThex? |
| + | <div class="docs-grid"> |
| + | <a class="docs-card" href="/Passport-Quickstart">Create an identity</a> |
| + | <a class="docs-card" href="/Project-Quickstart">Start a project</a> |
| + | <a class="docs-card" href="/API-Quickstart">Use the API</a> |
| + | <a class="docs-card" href="/KAEL-Quickstart">Talk to KAEL</a> |
| + | <a class="docs-card" href="/Discord-Integration">Connect Discord</a> |
| + | <a class="docs-card" href="/GameForge">Enter GameForge</a> |
| + | </div> |
| - | AeThex is a platform for identity, collaboration, governance, development, and digital experiences. |
| + | ## Understand the system |
| - | The platform is built around five core concepts: |
| + | AeThex is organized around several connected layers: |
| - | 1. Passport |
| - | 2. Organizations |
| - | 3. Projects |
| - | 4. Teams |
| - | 5. Services |
| + | | Layer | Purpose | Start here | |
| + | |---|---|---| |
| + | | Network | Routes people to AeThex services | [aethex.net](https://aethex.net) | |
| + | | Identity | Establishes who a person or organization is | [[Passport Quickstart]] | |
| + | | Platform | Provides developer systems and shared infrastructure | [aethex.dev](https://aethex.dev) | |
| + | | Intelligence | Provides KAEL chat, memory, workflows, and integrations | [[KAEL Quickstart]] | |
| + | | Foundation | Governs community and public-interest programs | [[Foundation]] | |
| + | | Labs | Explores experimental systems | [[Labs]] | |
| + | | GameForge | Supports game-development cohorts and credentials | [[GameForge]] | |
| - | --- |
| + | ## Identity first |
| - | ## Create a Passport |
| + | Use [aethex.id](https://aethex.id) when a workflow requires an AeThex identity. Passport can connect identity across supported AeThex services. |
| - | Passport is the identity system that powers the entire AeThex ecosystem. |
| + | Before authorizing a service: |
| - | Through Passport users can: |
| + | - Verify the hostname. |
| + | - Review the requested permissions. |
| + | - Never share authentication codes, cookies, API keys, or operator tokens. |
| + | - Use [aethex.support](https://aethex.support) when the expected flow is unclear. |
| - | - Authenticate |
| - | - Join organizations |
| - | - Manage projects |
| - | - Collaborate with teams |
| - | - Access AeThex services |
| + | ## Build with the public API |
| - | See [[Passport]] for details. |
| + | The AeThex API is available at `https://api.aethex.tech`. |
| - | --- |
| + | Start with: |
| - | ## Organizations |
| + | ```bash |
| + | curl https://api.aethex.tech/health |
| + | ``` |
| - | Organizations are the primary ownership model within AeThex. |
| + | Then follow [[API Quickstart]] for a streaming KAEL request and [[OpenAPI Reference]] for the public contract. |
| - | Organizations can own: |
| + | ## Use KAEL |
| - | - Projects |
| - | - Teams |
| - | - Assets |
| - | - Resources |
| - | - Services |
| + | - [chat.aethex.tech](https://chat.aethex.tech) is the conversational surface. |
| + | - [kael.aethex.tech](https://kael.aethex.tech) is the dedicated KAEL system surface. |
| + | - `api.aethex.tech` provides programmatic access. |
| - | See [[Organizations]]. |
| + | KAEL capabilities depend on identity, clearance, active model availability, and enabled integrations. See [[KAEL Capabilities]]. |
| - | --- |
| + | ## Join the community |
| - | ## Projects |
| + | - Join the AeThex Discord at [discord.gg/athx](https://discord.gg/athx). |
| + | - Review [[Community]] for participation guidance. |
| + | - Use [[Discord Integration]] for the distinction between AeThex Bot and KAEL’s Discord application. |
| - | Projects represent work being performed inside an organization. |
| + | ## Get help |
| - | Examples include: |
| + | | Need | Destination | |
| + | |---|---| |
| + | | Product documentation | [docs.aethex.support](https://docs.aethex.support) | |
| + | | Guided support | [aethex.support](https://aethex.support) | |
| + | | Current service health | [status.aethex.tech](https://status.aethex.tech) | |
| + | | Community help | [discord.gg/athx](https://discord.gg/athx) | |
| + | | Service inventory | [[Service Directory]] | |
| - | - Applications |
| - | - Games |
| - | - Websites |
| - | - APIs |
| - | - Research |
| + | ## Continue learning |
| - | See [[Projects]]. |
| - | |
| - | --- |
| - | |
| - | ## Teams |
| - | |
| - | Teams allow groups of users to collaborate on projects. |
| - | |
| - | See [[Teams]]. |
| - | |
| - | --- |
| - | |
| - | ## Next Steps |
| - | |
| - | - [[Passport]] |
| - | - [[Organizations]] |
| - | - [[Projects]] |
| - | - [[Teams]] |
| + | - [[Platform Overview]] |
| + | - [[Architecture]] |
| + | - [[Security]] |
| + | - [[Documentation Standards]] |
| /dev/null .. kael-api.md | |
| @@ 0,0 1,55 @@ | |
| + | # KAEL API |
| + | |
| + | The KAEL API is served from `https://api.aethex.tech`. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Base URL | `https://api.aethex.tech` | |
| + | | Machine-readable contract | `/static/custom/openapi.yaml` | |
| + | | Last source review | 2026-06-26 | |
| + | |
| + | ## API groups |
| + | |
| + | | Group | Purpose | |
| + | |---|---| |
| + | | Health | Service health, ping, and active-session counts | |
| + | | Models and chat | Model catalog, non-streaming chat, and SSE streaming | |
| + | | Authentication | Session inspection, login, logout, email code, and verification | |
| + | | History | Save, list, load, and delete conversations | |
| + | | Memory | List, save, delete, and clear keyed memory | |
| + | | Identity and profile | Linked identity and usage summaries | |
| + | | Documents | Generate and manage KAEL-produced documents | |
| + | | Feed | Featured conversations and activity highlights | |
| + | | Integrations | Signed Discord interactions and deployment webhooks | |
| + | |
| + | ## Public versus privileged routes |
| + | |
| + | The machine-readable public contract intentionally excludes owner-only operations such as deployment, world-model mutation, operator creation, and tenant administration. |
| + | |
| + | Those routes are operational interfaces—not browser APIs. |
| + | |
| + | ## Streaming |
| + | |
| + | `POST /kael/stream` uses Server-Sent Events: |
| + | |
| + | - Model metadata is emitted first. |
| + | - Generated text arrives in JSON token events. |
| + | - Errors can arrive as JSON events. |
| + | - `[DONE]` closes the logical stream. |
| + | |
| + | See [[API Quickstart]] for a complete request. |
| + | |
| + | ## Authentication |
| + | |
| + | KAEL uses secure cookies for signed-in browser sessions. Tenant keys can be supplied to tenant-aware requests through the dedicated tenant field or header. Operator tokens are separate and must remain server-side. |
| + | |
| + | ## Reference files |
| + | |
| + | - [Download OpenAPI YAML](/static/custom/openapi.yaml) |
| + | - [[API Reference]] |
| + | - [[Authentication]] |
| + | - [[Rate Limits]] |
| + | - [[KAEL Memory]] |
| + | - [[KAEL Safety]] |
| /dev/null .. kael-architecture.md | |
| @@ 0,0 1,119 @@ | |
| + | # 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. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | API base | `https://api.aethex.tech` | |
| + | | Public chat | [chat.aethex.tech](https://chat.aethex.tech) | |
| + | | Last source review | 2026-06-26 | |
| + | |
| + | ## System map |
| + | |
| + | ```mermaid |
| + | 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]] |
| kael-build.md .. | |
| @@ 1,62 1,93 @@ | |
| # KAEL Build | |
| - | KAEL Build tracks how KAEL is being built: architecture direction, working surfaces, near-term development priorities, and the difference between current capability and intended capability. |
| + | KAEL Build tracks how the implemented system is being stabilized and extended. |
| - | <div class="docs-section-heading"> |
| - | <h2>Build direction</h2> |
| - | <p>KAEL is being shaped as the intelligence layer for AeThex, starting with conversation and documentation support.</p> |
| - | </div> |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Roadmap | [[KAEL Roadmap]] | |
| + | | Last source review | 2026-06-26 | |
| - | The KAEL build should move in stages. Each stage should be useful by itself, but also prepare the system for deeper AeThex integration later. |
| + | ## Layer 1 — Surfaces |
| - | ## Stage 1 — Identity and surfaces |
| + | Implemented: |
| - | Current focus: |
| + | - Public chat at `chat.aethex.tech`. |
| + | - Dedicated KAEL surface at `kael.aethex.tech`. |
| + | - API runtime at `api.aethex.tech`. |
| + | - Discord interactions. |
| + | - Optional Telegram and audio modules. |
| - | - Establish the KAEL docs section. |
| - | - Connect the public surfaces: **chat.aethex.tech** and **kael.aethex.tech**. |
| - | - Define KAEL's role inside the AeThex ecosystem. |
| - | - Keep a current [[KAEL-Changelog]]. |
| - | - Avoid overstating unfinished capabilities. |
| + | Current work: |
| - | ## Stage 2 — Knowledge layer |
| + | - Keep responsibilities distinct. |
| + | - Make identity and state visible to users. |
| + | - Improve client error handling and accessibility. |
| - | KAEL should understand AeThex docs and support materials before it takes actions. Priority knowledge sources include: |
| + | ## Layer 2 — Knowledge |
| - | - [[Home]] and the docs index. |
| - | - [[Platform-Overview]] |
| - | - [[Passport]] |
| - | - [[Authentication]] |
| - | - [[Projects]] |
| - | - [[Permissions]] |
| - | - [[Security]] |
| - | - [[Api-Reference]] |
| + | Implemented: |
| - | ## Stage 3 — Guided workflows |
| + | - Structured AeThex knowledge entries. |
| + | - Runtime reload when knowledge files change. |
| + | - Query matching before model generation. |
| + | - Tenant-specific knowledge injection. |
| - | Once the knowledge layer is stable, KAEL can guide users through workflows: |
| + | Current work: |
| - | - Finding the right docs page. |
| - | - Explaining AeThex concepts. |
| - | - Helping users prepare support requests. |
| - | - Walking developers through API and SDK setup. |
| - | - Helping admins reason about organizations, teams, and permissions. |
| + | - Add source links and verification dates. |
| + | - Detect stale knowledge. |
| + | - Connect stable documentation to the KAEL retrieval path. |
| - | ## Stage 4 — Permissioned actions |
| + | ## Layer 3 — Context and continuity |
| - | Action-taking should come later and must respect [[Authentication]], [[Permissions]], [[Security-Model]], and [[Multi-Tenancy]]. Examples may include: |
| + | Implemented: |
| - | - Creating draft docs or support summaries. |
| - | - Preparing project setup steps. |
| - | - Checking status or configuration. |
| - | - Suggesting changes before a human approves them. |
| + | - Recent session history. |
| + | - Passport-associated history. |
| + | - Visitor- and Passport-scoped memory. |
| + | - Profile and ARM context. |
| - | > [!WARNING] |
| - | > KAEL should not perform destructive, security-sensitive, or external actions without explicit permission and a clear audit trail. |
| + | Current work: |
| - | <div class="docs-grid"> |
| - | <a class="docs-card" href="/KAEL">KAEL Overview</a> |
| - | <a class="docs-card" href="/KAEL-Changelog">Changelog</a> |
| - | <a class="docs-card" href="/KAEL-Endpoints">Endpoints</a> |
| - | <a class="docs-card" href="/Security-Model">Security Model</a> |
| - | </div> |
| + | - Make retention behavior explicit. |
| + | - Improve inspect/delete controls. |
| + | - Prevent identity scope confusion. |
| + | |
| + | ## Layer 4 — Permissioned tools |
| + | |
| + | Implemented for authorized levels: |
| + | |
| + | - Web and service retrieval. |
| + | - Ecosystem lookup. |
| + | - Observations. |
| + | - World-model access. |
| + | - Agent execution. |
| + | - Tenant and operator workflows. |
| + | - Deployment-related operations. |
| + | |
| + | Current work: |
| + | |
| + | - Narrow permissions by operation. |
| + | - Add confirmation boundaries. |
| + | - Improve action auditability. |
| + | - Keep privileged routes out of public browser clients. |
| + | |
| + | ## Release requirements |
| + | |
| + | A capability is supported only when: |
| + | |
| + | 1. The running system implements it. |
| + | 2. Its authorization boundary is defined. |
| + | 3. Failure behavior is documented. |
| + | 4. User data controls are available where needed. |
| + | 5. It appears in [[KAEL Changelog]]. |
| + | |
| + | ## Related documentation |
| + | |
| + | - [[KAEL Architecture]] |
| + | - [[KAEL Capabilities]] |
| + | - [[KAEL Safety]] |
| + | - [[KAEL Roadmap]] |
| + | - [[KAEL Changelog]] |
| /dev/null .. kael-capabilities.md | |
| @@ 0,0 1,74 @@ | |
| + | # KAEL Capabilities |
| + | |
| + | This page separates implemented KAEL behavior from roadmap items. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Last source review | 2026-06-26 | |
| + | | Changelog | [[KAEL Changelog]] | |
| + | |
| + | ## Implemented public capabilities |
| + | |
| + | - Non-streaming and Server-Sent Events chat. |
| + | - Model catalog discovery. |
| + | - Anonymous and authenticated sessions. |
| + | - Recent conversational history. |
| + | - Key/value user memory. |
| + | - AeThex knowledge matching. |
| + | - Identity and profile summaries. |
| + | - Feedback ratings. |
| + | - Featured and activity feeds. |
| + | - Generated-document creation and storage. |
| + | - Email one-time-code and AeThex OAuth-style sign-in flows where configured. |
| + | - Image-aware requests through a compatible model tier. |
| + | |
| + | ## Implemented integrations |
| + | |
| + | - Discord interaction verification and slash-command handling. |
| + | - AeThex service-status checks. |
| + | - Signed deployment webhooks. |
| + | - Optional Telegram bot initialization. |
| + | - Optional transcription and text-to-speech routes. |
| + | - DB-backed scheduled tasks and daily briefs. |
| + | - Tenant-specific prompts, knowledge, models, and rate limits. |
| + | |
| + | ## Permissioned capabilities |
| + | |
| + | Depending on clearance and operator authorization, KAEL can expose tools for: |
| + | |
| + | - Live web retrieval. |
| + | - AeThex service checks. |
| + | - Passport and ecosystem lookup. |
| + | - Persistent world-model reads and writes. |
| + | - Observations and operator context. |
| + | - Agent execution. |
| + | - Deployment actions. |
| + | - Tenant administration. |
| + | |
| + | > [!WARNING] |
| + | > The existence of a server route does not make it a public API. Operator and owner routes require explicit authorization and are intentionally excluded from public client examples. |
| + | |
| + | ## Capability boundaries |
| + | |
| + | KAEL does not guarantee: |
| + | |
| + | - That every provider model is always enabled. |
| + | - That a public user has access to every tool. |
| + | - That experimental endpoints remain stable. |
| + | - That generated answers are authoritative without a linked source. |
| + | - That an available hostname means every feature is production-ready. |
| + | |
| + | ## Client guidance |
| + | |
| + | - Discover models using `/kael/models`. |
| + | - Treat clearance as server-calculated. |
| + | - Expect rate-limit events inside an SSE response. |
| + | - Store no operator token in browser code. |
| + | - Keep session IDs unguessable when they protect anonymous continuity. |
| + | - Provide users a way to inspect and clear memory. |
| + | |
| + | ## Roadmap |
| + | |
| + | Planned work belongs in [[KAEL Roadmap]]. Shipped behavior belongs here and in [[KAEL Changelog]]. |
| kael-changelog.md .. | |
| @@ 1,45 1,56 @@ | |
| # KAEL Changelog | |
| - | The KAEL Changelog records visible changes to KAEL docs, surfaces, behavior, integrations, and build direction. |
| + | The KAEL Changelog records verified changes to KAEL behavior, integrations, API surfaces, and documentation. |
| - | <div class="docs-section-heading"> |
| - | <h2>Living update log</h2> |
| - | <p>Use this page to keep KAEL current instead of letting the docs drift away from the build.</p> |
| - | </div> |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Product maturity | Live / evolving | |
| + | | Maintainer | AeThex | |
| - | ## 2026-06-23 |
| + | ## 2026-06-26 |
| - | ### Added |
| + | ### Documented |
| - | - Created the dedicated KAEL docs section. |
| - | - Added the main [[KAEL]] overview page. |
| - | - Added [[KAEL-Build]] to describe how KAEL is being developed. |
| - | - Added [[KAEL-Endpoints]] to document public KAEL-related surfaces. |
| - | - Documented **chat.aethex.tech** as the conversational KAEL entry point. |
| - | - Documented **kael.aethex.tech** as the dedicated KAEL surface. |
| + | - Audited the KAEL runtime against its implemented Express routes. |
| + | - Added [[KAEL Architecture]], [[KAEL Capabilities]], [[KAEL API]], [[KAEL Memory]], [[KAEL Safety]], and [[KAEL Roadmap]]. |
| + | - Added [[KAEL Quickstart]], [[API Quickstart]], and [[Discord Integration]]. |
| + | - Documented streaming SSE behavior, model discovery, history, keyed memory, identity context, tenant behavior, and Discord request verification. |
| + | - Published a machine-readable public OpenAPI contract. |
| ### Clarified | |
| - | - KAEL should be treated as AeThex's intelligence layer, not merely a chatbot. |
| - | - KAEL documentation should distinguish current capability from future intent. |
| - | - Permissioned actions should require authentication, authorization, and auditability. |
| + | - Separated public API behavior from tenant, operator, and owner operations. |
| + | - Clarified that server-calculated clearance controls tools, models, limits, and persistent context. |
| + | - Clarified that planned work belongs in the roadmap and only shipped behavior belongs in capabilities. |
| + | |
| + | ### Security |
| + | |
| + | - Added explicit guidance for secret handling, memory privacy, webhook verification, and privileged tools. |
| + | - Excluded owner-only mutation and deployment routes from public API examples. |
| + | |
| + | ## 2026-06-23 |
| + | |
| + | ### Added |
| - | ### Next documentation tasks |
| + | - Created the dedicated KAEL documentation section. |
| + | - Added the initial overview, build, endpoint, and changelog pages. |
| + | - Linked `chat.aethex.tech` and `kael.aethex.tech`. |
| + | |
| + | ### Clarified |
| - | - Add screenshots or interface notes once the public KAEL surfaces stabilize. |
| - | - Document supported commands, flows, or intents when they exist. |
| - | - Add integration notes for Passport, support routing, and developer workflows. |
| - | - Define which KAEL behaviors are experimental, beta, or stable. |
| + | - Established KAEL as AeThex’s intelligence layer rather than only a chatbot. |
| + | - Established authentication, authorization, and auditability as requirements for permissioned actions. |
| ## Changelog rules | |
| - | When KAEL changes, add an entry with: |
| + | Each entry must contain: |
| 1. Date. | |
| - | 2. Surface affected: chat, KAEL site, docs, API, support, or backend. |
| - | 3. Type: added, changed, fixed, removed, security, or experimental. |
| - | 4. Plain-language summary. |
| - | 5. Links to affected docs pages. |
| + | 2. Affected surface. |
| + | 3. Type: added, changed, fixed, removed, security, experimental, or documented. |
| + | 4. A plain-language summary. |
| + | 5. Links to affected reference pages. |
| ## Entry template | |
| @@ 47,19 58,19 @@ | |
| ### Added | |
| - | - Summary of new behavior or surface. |
| + | - Shipped behavior and affected surface. |
| ### Changed | |
| - | - Summary of changed behavior. |
| + | - Compatibility or behavior change. |
| ### Fixed | |
| - | - Summary of resolved issue. |
| + | - Resolved defect. |
| - | ### Notes |
| + | ### Security |
| - | - Any migration, limitation, or follow-up. |
| + | - Security-impacting change without reproducing credentials. |
| > [!NOTE] | |
| - | > Keep this changelog factual. Do not describe planned work as shipped work. |
| + | > Keep this changelog factual. Do not describe planned work as shipped. |
| kael-endpoints.md .. | |
| @@ 1,60 1,71 @@ | |
| # KAEL Endpoints | |
| - | KAEL Endpoints documents the public KAEL-related web surfaces and what each one is supposed to represent. |
| + | KAEL uses several public web surfaces. This page maps their responsibilities; use [[KAEL API]] for the HTTP contract. |
| - | <div class="docs-section-heading"> |
| - | <h2>Public surfaces</h2> |
| - | <p>These domains should point users to the right KAEL experience without blurring their purpose.</p> |
| - | </div> |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Last verified | 2026-06-26 | |
| + | | Health endpoint | [api.aethex.tech/health](https://api.aethex.tech/health) | |
| ## chat.aethex.tech | |
| - | **Purpose:** conversational entry point. |
| + | **Purpose:** public conversational client. |
| - | Use **chat.aethex.tech** for direct interaction with KAEL-style chat experiences. This surface should focus on conversation, guidance, support preparation, docs navigation, and user-facing assistant behavior. |
| + | Current responsibilities: |
| - | Expected responsibilities: |
| + | - Stream KAEL responses. |
| + | - Maintain a browser session. |
| + | - Offer sign-in when configured. |
| + | - Expose history, memory, model, and profile controls supported by the API. |
| + | - Route users toward relevant AeThex resources. |
| - | - Let users ask questions in natural language. |
| - | - Explain AeThex concepts and docs. |
| - | - Help users find the right AeThex page or support path. |
| - | - Keep user-facing behavior clear and approachable. |
| + | [Open KAEL Chat](https://chat.aethex.tech) |
| ## kael.aethex.tech | |
| **Purpose:** dedicated KAEL identity and system surface. | |
| - | Use **kael.aethex.tech** as the KAEL-specific home for build notes, experiments, agent interface work, deeper system behavior, and future KAEL-specific workflows. |
| + | This surface presents KAEL as an AeThex system and can expose deeper operator-oriented or experimental interfaces according to the viewer’s authorization. |
| - | Expected responsibilities: |
| + | [Open KAEL](https://kael.aethex.tech) |
| - | - Present KAEL as a named AeThex system. |
| - | - Host or link KAEL-specific experiments. |
| - | - Point to the changelog and docs. |
| - | - Separate KAEL system identity from general support or marketing pages. |
| + | ## api.aethex.tech |
| - | ## Related AeThex surfaces |
| + | **Purpose:** KAEL and AeThex API runtime. |
| - | - **docs.aethex.support** — durable documentation and operating notes. |
| - | - **aethex.support** — support and help entry point. |
| - | - **aethex.net** — broader AeThex network/gateway presence. |
| + | Public endpoint groups include: |
| - | <div class="docs-grid"> |
| - | <a class="docs-card" href="https://chat.aethex.tech">chat.aethex.tech</a> |
| - | <a class="docs-card" href="https://kael.aethex.tech">kael.aethex.tech</a> |
| - | <a class="docs-card" href="/KAEL-Changelog">KAEL Changelog</a> |
| - | <a class="docs-card" href="/KAEL-Build">KAEL Build</a> |
| - | </div> |
| + | - Health and discovery. |
| + | - Chat and SSE streaming. |
| + | - Authentication. |
| + | - History and memory. |
| + | - Identity and profile summaries. |
| + | - Generated documents and feeds. |
| + | - Signed integration entry points. |
| + | |
| + | [Check API health](https://api.aethex.tech/health) |
| + | |
| + | ## docs.aethex.support |
| + | |
| + | **Purpose:** durable operating documentation and public API reference. |
| - | ## Endpoint documentation checklist |
| + | The docs describe stable behavior, maturity, security boundaries, and integration workflows. They are not an operator console. |
| - | For each KAEL surface, track: |
| + | ## aethex.support |
| - | 1. Current status. |
| - | 2. Intended audience. |
| - | 3. What users can do there today. |
| - | 4. What is experimental. |
| - | 5. Where bugs, support, or feedback should go. |
| + | **Purpose:** user-facing support routing. |
| + | |
| + | Use support when a user needs assistance, incident routing, or clarification that is not resolved by the docs. |
| + | |
| + | ## Related documentation |
| + | |
| + | <div class="docs-grid"> |
| + | <a class="docs-card" href="/KAEL-Quickstart">Quickstart</a> |
| + | <a class="docs-card" href="/KAEL-API">KAEL API</a> |
| + | <a class="docs-card" href="/KAEL-Architecture">Architecture</a> |
| + | <a class="docs-card" href="/KAEL-Changelog">Changelog</a> |
| + | </div> |
| > [!WARNING] | |
| - | > Do not document private admin URLs, tokens, hidden endpoints, internal credentials, or unfinished privileged routes on public docs pages. |
| + | > Do not publish private admin URLs, tokens, internal hostnames, active webhook URLs, or unfinished privileged interfaces. |
| /dev/null .. kael-memory.md | |
| @@ 0,0 1,74 @@ | |
| + | # KAEL Memory |
| + | |
| + | KAEL supports recent conversation history and persistent keyed memory. They are separate systems with different behavior. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Data plane | Supabase-backed KAEL tables | |
| + | | Last source review | 2026-06-26 | |
| + | |
| + | ## Conversation history |
| + | |
| + | History stores ordered user and assistant messages associated with a session. Signed-in histories can be associated with a Passport subject. Anonymous histories depend on the session identifier supplied by the client. |
| + | |
| + | Public history operations include: |
| + | |
| + | - Save a conversation. |
| + | - List available sessions. |
| + | - Load a session. |
| + | - Delete a signed-in user’s session. |
| + | |
| + | The streaming runtime also keeps a bounded recent context window rather than sending unlimited prior history to the model. |
| + | |
| + | ## Persistent memory |
| + | |
| + | Memory stores key/value facts associated with either: |
| + | |
| + | - A signed-in Passport subject. |
| + | - A visitor or session identifier when no Passport identity is available. |
| + | |
| + | Public memory operations include: |
| + | |
| + | - List memory. |
| + | - Save or replace a key. |
| + | - Delete one key. |
| + | - Clear the current identity or session scope. |
| + | |
| + | ## Identity precedence |
| + | |
| + | When a signed-in Passport subject is available, it becomes the primary memory scope. Otherwise KAEL uses the visitor or session identifier supplied by the client. |
| + | |
| + | Do not reuse one anonymous session identifier across unrelated users. |
| + | |
| + | ## What belongs in memory |
| + | |
| + | Appropriate examples: |
| + | |
| + | - Preferred name. |
| + | - Communication preference. |
| + | - Active project context. |
| + | - A user-approved long-running goal. |
| + | |
| + | Do not intentionally store: |
| + | |
| + | - Passwords or authentication codes. |
| + | - API keys, tenant keys, operator tokens, or cookies. |
| + | - Payment details. |
| + | - Government identity documents. |
| + | - Private information about another person without a legitimate purpose. |
| + | |
| + | ## User controls |
| + | |
| + | Clients should expose: |
| + | |
| + | - A visible indication when persistent memory is active. |
| + | - A list of stored keys. |
| + | - Delete controls. |
| + | - A clear-all action. |
| + | - An explanation of whether the user is signed in or using visitor-scoped memory. |
| + | |
| + | ## API |
| + | |
| + | See [[KAEL API]] for request contracts and [[KAEL Safety]] for privacy and authorization requirements. |
| /dev/null .. kael-quickstart.md | |
| @@ 0,0 1,48 @@ | |
| + | # KAEL Quickstart |
| + | |
| + | KAEL is AeThex’s Knowledge-Augmented Execution Layer. The quickest public entry point is [chat.aethex.tech](https://chat.aethex.tech). |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Chat | [chat.aethex.tech](https://chat.aethex.tech) | |
| + | | Operator surface | [kael.aethex.tech](https://kael.aethex.tech) | |
| + | | API | [api.aethex.tech](https://api.aethex.tech/health) | |
| + | | Last verified | 2026-06-26 | |
| + | |
| + | ## 1. Open KAEL Chat |
| + | |
| + | Visit [chat.aethex.tech](https://chat.aethex.tech). Anonymous use is available with limited daily access. |
| + | |
| + | ## 2. Ask a grounded question |
| + | |
| + | Start with a concrete AeThex topic: |
| + | |
| + | ```text |
| + | What is Passport, and where do I create one? |
| + | ``` |
| + | |
| + | KAEL loads relevant entries from its AeThex knowledge base before generating an answer. For current web status or recent information, KAEL can use live retrieval when the active clearance level permits it. |
| + | |
| + | ## 3. Use a stable session |
| + | |
| + | A stable session identifier allows the chat surface to retain recent conversational history. Signed-in identities can receive stronger continuity than an anonymous browser session. |
| + | |
| + | ## 4. Understand clearance |
| + | |
| + | KAEL calculates access from identity, Passport state, ARM membership, invite state, tenant credentials, and operator authorization. Higher clearance can expand message limits, tools, models, and persistent context. |
| + | |
| + | Do not place tenant keys or operator tokens in public client code. |
| + | |
| + | ## 5. Manage memory |
| + | |
| + | KAEL can store keyed memories for a signed-in identity or visitor session. Review and remove memory through the supported chat controls when available. See [[KAEL Memory]] for the API behavior. |
| + | |
| + | ## Next steps |
| + | |
| + | - [[KAEL Capabilities]] |
| + | - [[KAEL Architecture]] |
| + | - [[KAEL Memory]] |
| + | - [[KAEL Safety]] |
| + | - [[KAEL API]] |
| /dev/null .. kael-roadmap.md | |
| @@ 0,0 1,50 @@ | |
| + | # KAEL Roadmap |
| + | |
| + | The roadmap records intended direction without presenting planned work as shipped behavior. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Product maturity | Live / evolving | |
| + | | Last reviewed | 2026-06-26 | |
| + | |
| + | ## Now — document and stabilize |
| + | |
| + | - Publish the public API contract. |
| + | - Separate public, tenant, operator, and owner endpoints. |
| + | - Keep capabilities synchronized with implemented source. |
| + | - Add source-linked answers inside the documentation surface. |
| + | - Improve history and memory transparency. |
| + | - Define stable event shapes for streaming clients. |
| + | |
| + | ## Next — unify identity and integrations |
| + | |
| + | - Clarify Passport and ARM clearance behavior. |
| + | - Standardize Discord, Telegram, web, and API session semantics. |
| + | - Provide explicit tenant onboarding and key rotation guidance. |
| + | - Add integration examples that never require privileged credentials in browser code. |
| + | - Publish retention and deletion behavior for KAEL state. |
| + | |
| + | ## Later — permissioned operations |
| + | |
| + | - Expand auditable workflow execution. |
| + | - Add confirmation boundaries for mutating tools. |
| + | - Provide operator-visible action logs. |
| + | - Connect more AeThex systems through scoped service identities. |
| + | - Graduate stable Labs experiments into supported KAEL capabilities. |
| + | |
| + | ## Not commitments |
| + | |
| + | Roadmap entries are direction, not release promises. A capability becomes supported only when it: |
| + | |
| + | 1. Exists in the running system. |
| + | 2. Has a defined authorization boundary. |
| + | 3. Has user-facing documentation. |
| + | 4. Appears in [[KAEL Changelog]]. |
| + | |
| + | ## Related documentation |
| + | |
| + | - [[KAEL Build]] |
| + | - [[KAEL Capabilities]] |
| + | - [[KAEL Safety]] |
| + | - [[KAEL Changelog]] |
| /dev/null .. kael-safety.md | |
| @@ 0,0 1,74 @@ | |
| + | # KAEL Safety |
| + | |
| + | KAEL combines generated output, persistent state, identity, external integrations, and permissioned tools. Safety therefore depends on access control and system design—not only model prompting. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Applies to | KAEL clients, API integrations, operators, and tenants | |
| + | | Last source review | 2026-06-26 | |
| + | |
| + | ## Core rules |
| + | |
| + | 1. The server calculates clearance; clients do not grant it. |
| + | 2. Operator tokens, tenant keys, provider keys, cookies, and webhook secrets never belong in public code. |
| + | 3. Tool access must be narrower than conversational access. |
| + | 4. A generated statement is not proof that an action occurred. |
| + | 5. Destructive or external actions require explicit authorization and auditable results. |
| + | 6. Users need controls for history and memory. |
| + | |
| + | ## Clearance |
| + | |
| + | KAEL can use anonymous identity, authenticated identity, Passport data, ARM memberships, invites, tenants, and operator records to determine access. |
| + | |
| + | Clearance can affect: |
| + | |
| + | - Daily message limits. |
| + | - Available models. |
| + | - Available tools. |
| + | - Access to persistent context. |
| + | - Operator-only endpoints. |
| + | |
| + | Do not reproduce clearance logic in a client as an authorization boundary. |
| + | |
| + | ## Prompt and tool separation |
| + | |
| + | Untrusted text—including webpages, user messages, uploaded files, Discord messages, and retrieved documents—must be treated as data. It must not silently override tool policies or operator authorization. |
| + | |
| + | Tool implementations should validate: |
| + | |
| + | - The resolved identity. |
| + | - The required clearance. |
| + | - Arguments and target resources. |
| + | - Whether the action is read-only or mutating. |
| + | - Whether confirmation is required. |
| + | |
| + | ## Memory and privacy |
| + | |
| + | - Store only data needed for a user-facing feature. |
| + | - Avoid secrets and high-risk personal data. |
| + | - Keep signed-in and visitor-scoped memory separate. |
| + | - Expose deletion controls. |
| + | - Do not show one user’s memory or history to another. |
| + | |
| + | ## Integrations |
| + | |
| + | - Verify Discord interaction signatures. |
| + | - Verify deployment webhook HMAC signatures. |
| + | - Restrict CORS to intended browser origins for credentialed requests. |
| + | - Rate-limit authentication, chat, agent, and webhook surfaces. |
| + | - Log authorization failures without logging credentials. |
| + | |
| + | ## Incident response |
| + | |
| + | If a credential appears in source, logs, screenshots, or documentation: |
| + | |
| + | 1. Revoke or rotate it at the provider. |
| + | 2. Remove it from active configuration and repository history. |
| + | 3. Review access logs and affected actions. |
| + | 4. Replace it with an environment or secret-manager reference. |
| + | 5. Document the incident without reproducing the secret. |
| + | |
| + | ## Reporting |
| + | |
| + | Report suspected security issues through [aethex.support](https://aethex.support). Do not post active credentials in Discord or a public issue. |
| kael.md .. | |
| @@ 1,55 1,82 @@ | |
| # KAEL | |
| - | KAEL is AeThex's intelligence layer: the assistant, operator, and system-facing agent being built to understand AeThex context, help users move through the ecosystem, and eventually coordinate work across AeThex services. |
| + | KAEL is the Knowledge-Augmented Execution Layer of AeThex: a conversational system, knowledge interface, integration runtime, and permissioned operator layer. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live / evolving | |
| + | | Documentation status | Active | |
| + | | Chat | [chat.aethex.tech](https://chat.aethex.tech) | |
| + | | System surface | [kael.aethex.tech](https://kael.aethex.tech) | |
| + | | API | [api.aethex.tech](https://api.aethex.tech/health) | |
| + | | Last source review | 2026-06-26 | |
| <div class="docs-hero"> | |
| - | <p class="docs-kicker">KAEL // AeThex intelligence layer</p> |
| - | <h1>Build the assistant that understands <span>AeThex itself.</span></h1> |
| - | <p class="docs-hero-copy">KAEL is being developed as a living system: chat surface, platform agent, documentation guide, workflow helper, and future orchestration layer for AeThex users and teams.</p> |
| + | <p class="docs-kicker">KAEL // Knowledge-Augmented Execution Layer</p> |
| + | <h1>AeThex knowledge, context, and <span>permissioned action.</span></h1> |
| + | <p class="docs-hero-copy">KAEL connects chat, AeThex knowledge, identity, memory, integrations, models, and carefully scoped tools through one evolving runtime.</p> |
| <div class="docs-actions"> | |
| - | <a class="docs-button" href="https://chat.aethex.tech"><i class="fas fa-comments"></i> Open chat.aethex.tech</a> |
| - | <a class="docs-button is-secondary" href="https://kael.aethex.tech"><i class="fas fa-terminal"></i> Open kael.aethex.tech</a> |
| + | <a class="docs-button" href="https://chat.aethex.tech"><i class="fas fa-comment-dots"></i> Open KAEL Chat</a> |
| + | <a class="docs-button is-secondary" href="https://kael.aethex.tech"><i class="fas fa-brain"></i> Open KAEL</a> |
| </div> | |
| </div> | |
| - | <div class="docs-section-heading"> |
| - | <h2>What KAEL is</h2> |
| - | <p>KAEL is not just a chatbot. It is the named intelligence layer for AeThex.</p> |
| + | ## Start here |
| + | |
| + | <div class="docs-grid"> |
| + | <a class="docs-card" href="/KAEL-Quickstart">KAEL Quickstart</a> |
| + | <a class="docs-card" href="/KAEL-Capabilities">Capabilities</a> |
| + | <a class="docs-card" href="/KAEL-Architecture">Architecture</a> |
| + | <a class="docs-card" href="/KAEL-API">API</a> |
| + | <a class="docs-card" href="/KAEL-Memory">Memory</a> |
| + | <a class="docs-card" href="/KAEL-Safety">Safety</a> |
| </div> | |
| - | KAEL should become the connective assistant across AeThex: able to explain docs, guide users through platform flows, help developers integrate with APIs, support communities, and eventually take carefully-scoped actions inside AeThex systems. |
| + | ## What is implemented |
| - | ## Current surfaces |
| + | KAEL currently provides: |
| - | - **chat.aethex.tech** — the conversational entry point for KAEL-style interaction. |
| - | - **kael.aethex.tech** — the dedicated KAEL surface for system identity, experiments, builds, and future agent workflows. |
| - | - **docs.aethex.support** — the source of operational documentation KAEL should be able to reference. |
| - | - **aethex.support** — the user-facing support layer KAEL may eventually help route or explain. |
| + | - Streaming and non-streaming conversation. |
| + | - AeThex knowledge matching. |
| + | - Model selection based on access. |
| + | - Session history and keyed memory. |
| + | - Passport-aware identity context. |
| + | - Discord interactions. |
| + | - Tenant-specific prompts and knowledge. |
| + | - Generated documents, feeds, and ratings. |
| + | - Permissioned tools, agents, observations, and world-state operations for authorized roles. |
| - | <div class="docs-grid"> |
| - | <a class="docs-card" href="/KAEL-Build">KAEL Build</a> |
| - | <a class="docs-card" href="/KAEL-Changelog">KAEL Changelog</a> |
| - | <a class="docs-card" href="/KAEL-Endpoints">KAEL Endpoints</a> |
| - | <a class="docs-card" href="/Aethex-Os">AeThex OS</a> |
| - | </div> |
| + | See [[KAEL Capabilities]] for exact boundaries. |
| + | |
| + | ## System model |
| + | |
| + | KAEL is not one webpage. It is a connected set of surfaces: |
| - | ## Build philosophy |
| + | | Surface | Role | |
| + | |---|---| |
| + | | `chat.aethex.tech` | Public conversation | |
| + | | `kael.aethex.tech` | Dedicated KAEL and operator experience | |
| + | | `api.aethex.tech` | Runtime, state, integrations, and streaming | |
| + | | Discord | Signed command interactions | |
| + | | AeThex knowledge | Canonical ecosystem context | |
| + | | Passport and ARM | Identity and clearance inputs | |
| - | KAEL should be built as a trustworthy system component, not as a gimmick. That means: |
| + | ## Documentation map |
| - | - It should know when to answer, when to ask, and when not to act. |
| - | - It should understand AeThex products, docs, services, communities, and governance context. |
| - | - It should keep a clear separation between explanation, suggestion, and action. |
| - | - It should respect authentication, permissions, and tenant boundaries. |
| - | - It should leave a traceable record for meaningful changes. |
| + | - [[KAEL Quickstart]] — begin as a user. |
| + | - [[KAEL Architecture]] — understand the runtime and data flow. |
| + | - [[KAEL Capabilities]] — distinguish shipped behavior from plans. |
| + | - [[KAEL API]] — public API groups and OpenAPI contract. |
| + | - [[KAEL Memory]] — history, persistent memory, and user controls. |
| + | - [[Discord Integration]] — Discord behavior and security. |
| + | - [[KAEL Safety]] — permissions, privacy, tools, and incident handling. |
| + | - [[KAEL Build]] — staged implementation model. |
| + | - [[KAEL Roadmap]] — intended direction. |
| + | - [[KAEL Changelog]] — dated shipped changes. |
| - | ## Near-term goals |
| + | ## Operating principle |
| - | 1. Establish KAEL's public identity and documentation. |
| - | 2. Connect the chat and KAEL surfaces to the same product narrative. |
| - | 3. Build a living changelog for updates. |
| - | 4. Define what KAEL can safely do now versus later. |
| - | 5. Prepare integration paths with [[Passport]], [[Projects]], [[Support]], and [[Api-Reference]]. |
| + | KAEL should be useful before it is powerful, transparent before it is autonomous, and explicitly authorized before it changes an external system. |
| - | > [!NOTE] |
| - | > This section should stay practical and current. If KAEL changes, update [[KAEL-Changelog]] first, then reflect stable behavior here. |
| + | > [!IMPORTANT] |
| + | > If the documentation conflicts with the running system, treat that as a documentation defect. Record the observed behavior, verify it against source, and update [[KAEL Changelog]]. |
| labs.md .. | |
| @@ 53,4 53,3 @@ | |
| - [[KAEL]] | |
| - [[KAEL-Build]] | |
| - | {{PageIndex}} |
| /dev/null .. openapi-reference.md | |
| @@ 0,0 1,69 @@ | |
| + | # OpenAPI Reference |
| + | |
| + | The AeThex KAEL API publishes an OpenAPI 3.1 contract for public and user-facing routes. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | API version | 4.0 | |
| + | | OpenAPI version | 3.1 | |
| + | | Base URL | `https://api.aethex.tech` | |
| + | | Contract | [openapi.yaml](/static/custom/openapi.yaml) | |
| + | | Last source review | 2026-06-26 | |
| + | |
| + | ## Download |
| + | |
| + | [Download the OpenAPI YAML](/static/custom/openapi.yaml) |
| + | |
| + | You can import this file into tools such as Swagger UI, Redocly, Postman, Insomnia, or an OpenAPI client generator. |
| + | |
| + | ## Scope |
| + | |
| + | The public contract includes: |
| + | |
| + | - Health and discovery. |
| + | - Chat and Server-Sent Events streaming. |
| + | - Authentication. |
| + | - Conversation history. |
| + | - Keyed memory. |
| + | - Identity and profile summaries. |
| + | - Generated documents. |
| + | - Feed and leaderboard reads. |
| + | |
| + | It intentionally excludes owner-only deployment, operator creation, tenant administration, and world-model mutation routes. |
| + | |
| + | ## Validate locally |
| + | |
| + | Using Redocly: |
| + | |
| + | ```bash |
| + | npx @redocly/cli lint openapi.yaml |
| + | ``` |
| + | |
| + | Using Swagger CLI: |
| + | |
| + | ```bash |
| + | npx swagger-cli validate openapi.yaml |
| + | ``` |
| + | |
| + | ## Generate a client |
| + | |
| + | Example with OpenAPI Generator: |
| + | |
| + | ```bash |
| + | openapi-generator-cli generate \ |
| + | -i https://docs.aethex.support/static/custom/openapi.yaml \ |
| + | -g typescript-fetch \ |
| + | -o aethex-kael-client |
| + | ``` |
| + | |
| + | ## Streaming caveat |
| + | |
| + | Generated OpenAPI clients do not always provide ergonomic Server-Sent Events handling. For `/kael/stream`, a small fetch-based stream parser may be preferable. See [[API Quickstart]]. |
| + | |
| + | ## Related documentation |
| + | |
| + | - [[KAEL API]] |
| + | - [[API Reference]] |
| + | - [[Authentication]] |
| + | - [[Rate Limits]] |
| + | - [[KAEL Safety]] |
| overview.md .. | |
| @@ 12,13 12,13 @@ | |
| | Resource | Description | | |
| | ------------------- | ----------------------------------------------------------- | | |
| | [[Getting Started]] | Launch your first AeThex project in under 30 minutes | | |
| - | | [[Platform Guide]] | Learn Dashboard, Passport, Organizations, and Collaboration | |
| + | | [[Platform Overview]] | Learn Dashboard, Passport, Organizations, and Collaboration | |
| | [[API Reference]] | Complete API documentation and examples | | |
| | [[Tutorials]] | Step-by-step implementation guides | | |
| - | | [[CLI Tools]] | Manage AeThex from the command line | |
| - | | [[Code Examples]] | Production-ready implementation patterns | |
| - | | [[Integrations]] | Connect external services and providers | |
| - | | [[Curriculum]] | Structured learning paths | |
| + | | [[CLI]] | Manage AeThex from the command line | |
| + | | [[API Quickstart]] | Production-ready implementation patterns | |
| + | | [[Discord Integration]] | Connect external services and providers | |
| + | | [[Tutorials]] | Structured learning paths | |
| --- | |
| /dev/null .. passport-quickstart.md | |
| @@ 0,0 1,57 @@ | |
| + | # Passport Quickstart |
| + | |
| + | Passport is the AeThex identity entry point. Start at [aethex.id](https://aethex.id). |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Product maturity | Live | |
| + | | Documentation status | Active | |
| + | | Public URL | [aethex.id](https://aethex.id) | |
| + | | Owner | AeThex | |
| + | | Last verified | 2026-06-26 | |
| + | |
| + | ## 1. Create or access your identity |
| + | |
| + | 1. Open [aethex.id](https://aethex.id). |
| + | 2. Follow the available sign-in or registration flow. |
| + | 3. Complete any identity verification requested by the service. |
| + | 4. Confirm that you can access your Passport profile. |
| + | |
| + | > [!NOTE] |
| + | > Available sign-in methods can change. Treat the live Passport interface as authoritative for the identity providers currently enabled. |
| + | |
| + | ## 2. Understand your surfaces |
| + | |
| + | Passport is the identity layer used across AeThex. Related public profile and project surfaces may include: |
| + | |
| + | - `aethex.me` for creator identity and profile presentation. |
| + | - `aethex.space` for studio, group, project, or game presentation. |
| + | - AeThex services that use Passport authentication or linked identity. |
| + | |
| + | ## 3. Link services carefully |
| + | |
| + | When a service requests access: |
| + | |
| + | 1. Verify the hostname. |
| + | 2. Read the requested scope. |
| + | 3. Approve only the access required for the workflow. |
| + | 4. Review linked accounts periodically. |
| + | |
| + | See [[Linked Accounts]] and [[Permissions]]. |
| + | |
| + | ## 4. Verify the session |
| + | |
| + | After signing in to an AeThex service: |
| + | |
| + | - Confirm the displayed identity is yours. |
| + | - Avoid sharing session cookies or authentication codes. |
| + | - Sign out on shared devices. |
| + | - Report suspicious access through [aethex.support](https://aethex.support). |
| + | |
| + | ## Next steps |
| + | |
| + | - [[Passport]] |
| + | - [[Profiles]] |
| + | - [[Linked Accounts]] |
| + | - [[Security]] |
| + | - [[KAEL Quickstart]] |
| passport.md .. | |
| @@ 51,4 51,3 @@ | |
| - [[Profiles]] | |
| - [[Security]] | |
| - | {{PageIndex}} |
| /dev/null .. project-quickstart.md | |
| @@ 0,0 1,58 @@ | |
| + | # Project Quickstart |
| + | |
| + | Projects are the working units owned by an AeThex organization. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Applies to | Organizations, teams, and product work | |
| + | | Last verified | 2026-06-26 | |
| + | |
| + | ## Before you begin |
| + | |
| + | You should have: |
| + | |
| + | - An AeThex identity. |
| + | - An organization or program responsible for the work. |
| + | - A clear project purpose and owner. |
| + | - A decision about whether the project is public, internal, or experimental. |
| + | |
| + | ## Define the project |
| + | |
| + | Record: |
| + | |
| + | 1. Project name and short purpose. |
| + | 2. Owning organization. |
| + | 3. Maintainer or team. |
| + | 4. Repository and deployment surface. |
| + | 5. Data classification and access requirements. |
| + | 6. Product maturity. |
| + | 7. Support and incident route. |
| + | |
| + | ## Establish permissions |
| + | |
| + | Use least privilege: |
| + | |
| + | - Readers can view project information. |
| + | - Contributors can change project content. |
| + | - Maintainers can approve and deploy changes. |
| + | - Administrators control identity, secrets, and destructive operations. |
| + | |
| + | ## Connect documentation |
| + | |
| + | Every public project should link to: |
| + | |
| + | - Its product or service page. |
| + | - Setup instructions. |
| + | - Repository when public. |
| + | - Changelog. |
| + | - Security/reporting instructions. |
| + | - Current status surface. |
| + | |
| + | ## Next steps |
| + | |
| + | - [[Projects]] |
| + | - [[Organizations]] |
| + | - [[Teams]] |
| + | - [[Permissions]] |
| + | - [[Documentation Standards]] |
| /dev/null .. service-directory.md | |
| @@ 0,0 1,66 @@ | |
| + | # Service Directory |
| + | |
| + | The Service Directory is the operational map of AeThex’s public surfaces. “Live” means the URL responded successfully when this page was last verified; it does not guarantee that every feature behind the surface is complete. |
| + | |
| + | | Field | Value | |
| + | |---|---| |
| + | | Documentation status | Active | |
| + | | Maintainer | AeThex | |
| + | | Last verified | 2026-06-26 | |
| + | | Health dashboard | [status.aethex.tech](https://status.aethex.tech) | |
| + | |
| + | > [!IMPORTANT] |
| + | > Product maturity and service availability are different signals. Experimental software can be reachable, and a mature product can experience an outage. Check the status dashboard for current health and the product page for maturity. |
| + | |
| + | ## Core network |
| + | |
| + | | Service | URL | Role | Availability | |
| + | |---|---|---|---| |
| + | | AeThex Network | [aethex.net](https://aethex.net) | Ecosystem gateway and network map | Live | |
| + | | Support | [aethex.support](https://aethex.support) | Support routing and user assistance | Live | |
| + | | Documentation | [docs.aethex.support](https://docs.aethex.support) | Operating manual and technical reference | Live | |
| + | | Status | [status.aethex.tech](https://status.aethex.tech) | Public service-health dashboard | Live | |
| + | | Git | [git.aethex.tech](https://git.aethex.tech) | Source repositories and project collaboration | Live | |
| + | |
| + | ## Identity and platform |
| + | |
| + | | Service | URL | Role | Availability | |
| + | |---|---|---|---| |
| + | | Passport | [aethex.id](https://aethex.id) | AeThex identity and account entry point | Live | |
| + | | Developer Platform | [aethex.dev](https://aethex.dev) | Developer infrastructure, tools, and platform access | Live | |
| + | | AeThex API | [api.aethex.tech](https://api.aethex.tech/health) | KAEL and ecosystem API service | Live | |
| + | | Foundation | [aethex.org](https://aethex.org) | Governance, community, stewardship, and public-interest programs | Live | |
| + | |
| + | ## Intelligence |
| + | |
| + | | Service | URL | Role | Availability | |
| + | |---|---|---|---| |
| + | | KAEL | [kael.aethex.tech](https://kael.aethex.tech) | Dedicated KAEL operator and identity surface | Live | |
| + | | KAEL Chat | [chat.aethex.tech](https://chat.aethex.tech) | Public conversational interface | Live | |
| + | | AeThex API | [api.aethex.tech](https://api.aethex.tech/health) | Streaming, memory, history, identity, and integration endpoints | Live | |
| + | |
| + | ## Creation and research |
| + | |
| + | | Service | URL | Role | Availability | |
| + | |---|---|---|---| |
| + | | GameForge | [forge.aethex.org](https://forge.aethex.org) | Game-development cohorts, certification, and creator programs | Live | |
| + | | AeThex Labs | [labs.aethex.co](https://labs.aethex.co) | Research, prototypes, and emerging systems | Live / experimental | |
| + | | AeThex Bot | [aethex.bot](https://aethex.bot) | Discord-community automation and integrations | Live | |
| + | | Ignis | Not publicly released | Independent user-generated game platform under development | Research | |
| + | |
| + | ## Ownership and update rules |
| + | |
| + | - The owning AeThex program maintains product behavior. |
| + | - Documentation maintainers record stable public behavior here. |
| + | - Experimental claims must be labeled as experimental. |
| + | - A service should not be marked live solely because a placeholder page responds. |
| + | - Update this directory whenever a public hostname, product owner, or maturity state changes. |
| + | |
| + | ## Related documentation |
| + | |
| + | - [[Platform Overview]] |
| + | - [[Architecture]] |
| + | - [[Security]] |
| + | - [[KAEL]] |
| + | - [[Labs]] |
| + | - [[GameForge]] |