# KAEL Changelog The KAEL Changelog records verified changes to KAEL behavior, integrations, API surfaces, and documentation. | Field | Value | |---|---| | Documentation status | Active | | Product maturity | Live / evolving | | Maintainer | AeThex | ## 2026-06-27 ### Added - Generated a machine-readable grounding corpus from all documentation pages, split into source-addressable sections. - Connected Ask KAEL to relevant documentation chunks and clickable source records. - Added server-side corpus resolution so the public client sends source IDs rather than trusted excerpts. ### Security - Limited documentation grounding to bounded records fetched by the API from `docs.aethex.support`. - Removed embedded API credential fallbacks and added tracked-tree secret scanning. ## 2026-06-26 ### Documented - 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 - 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 - Created the dedicated KAEL documentation section. - Added the initial overview, build, endpoint, and changelog pages. - Linked `chat.aethex.tech` and `kael.aethex.tech`. ### Clarified - Established KAEL as AeThex’s intelligence layer rather than only a chatbot. - Established authentication, authorization, and auditability as requirements for permissioned actions. ## Changelog rules Each entry must contain: 1. Date. 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 ## YYYY-MM-DD ### Added - Shipped behavior and affected surface. ### Changed - Compatibility or behavior change. ### Fixed - Resolved defect. ### Security - Security-impacting change without reproducing credentials. > [!NOTE] > Keep this changelog factual. Do not describe planned work as shipped.