# 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]]