Blame

be64c9 AeThex Docs 2026-06-27 00:39:17
Build out operational docs platform
1
# KAEL Roadmap
2
3
The roadmap records intended direction without presenting planned work as shipped behavior.
4
5
| Field | Value |
6
|---|---|
7
| Documentation status | Active |
8
| Product maturity | Live / evolving |
9
| Last reviewed | 2026-06-26 |
10
11
## Now — document and stabilize
12
13
- Publish the public API contract.
14
- Separate public, tenant, operator, and owner endpoints.
15
- Keep capabilities synchronized with implemented source.
16
- Add source-linked answers inside the documentation surface.
17
- Improve history and memory transparency.
18
- Define stable event shapes for streaming clients.
19
20
## Next — unify identity and integrations
21
22
- Clarify Passport and ARM clearance behavior.
23
- Standardize Discord, Telegram, web, and API session semantics.
24
- Provide explicit tenant onboarding and key rotation guidance.
25
- Add integration examples that never require privileged credentials in browser code.
26
- Publish retention and deletion behavior for KAEL state.
27
28
## Later — permissioned operations
29
30
- Expand auditable workflow execution.
31
- Add confirmation boundaries for mutating tools.
32
- Provide operator-visible action logs.
33
- Connect more AeThex systems through scoped service identities.
34
- Graduate stable Labs experiments into supported KAEL capabilities.
35
36
## Not commitments
37
38
Roadmap entries are direction, not release promises. A capability becomes supported only when it:
39
40
1. Exists in the running system.
41
2. Has a defined authorization boundary.
42
3. Has user-facing documentation.
43
4. Appears in [[KAEL Changelog]].
44
45
## Related documentation
46
47
- [[KAEL Build]]
48
- [[KAEL Capabilities]]
49
- [[KAEL Safety]]
50
- [[KAEL Changelog]]