KAEL Roadmap

The roadmap records intended direction without presenting planned work as shipped behavior.

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