Blame
|
1 | # KAEL Build |
||||||
| 2 | ||||||||
| 3 | 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. |
|||||||
| 4 | ||||||||
| 5 | <div class="docs-section-heading"> |
|||||||
| 6 | <h2>Build direction</h2> |
|||||||
| 7 | <p>KAEL is being shaped as the intelligence layer for AeThex, starting with conversation and documentation support.</p> |
|||||||
| 8 | </div> |
|||||||
| 9 | ||||||||
| 10 | The KAEL build should move in stages. Each stage should be useful by itself, but also prepare the system for deeper AeThex integration later. |
|||||||
| 11 | ||||||||
| 12 | ## Stage 1 — Identity and surfaces |
|||||||
| 13 | ||||||||
| 14 | Current focus: |
|||||||
| 15 | ||||||||
| 16 | - Establish the KAEL docs section. |
|||||||
| 17 | - Connect the public surfaces: **chat.aethex.tech** and **kael.aethex.tech**. |
|||||||
| 18 | - Define KAEL's role inside the AeThex ecosystem. |
|||||||
| 19 | - Keep a current [[KAEL-Changelog]]. |
|||||||
| 20 | - Avoid overstating unfinished capabilities. |
|||||||
| 21 | ||||||||
| 22 | ## Stage 2 — Knowledge layer |
|||||||
| 23 | ||||||||
| 24 | KAEL should understand AeThex docs and support materials before it takes actions. Priority knowledge sources include: |
|||||||
| 25 | ||||||||
| 26 | - [[Home]] and the docs index. |
|||||||
| 27 | - [[Platform-Overview]] |
|||||||
| 28 | - [[Passport]] |
|||||||
| 29 | - [[Authentication]] |
|||||||
| 30 | - [[Projects]] |
|||||||
| 31 | - [[Permissions]] |
|||||||
| 32 | - [[Security]] |
|||||||
| 33 | - [[Api-Reference]] |
|||||||
| 34 | ||||||||
| 35 | ## Stage 3 — Guided workflows |
|||||||
| 36 | ||||||||
| 37 | Once the knowledge layer is stable, KAEL can guide users through workflows: |
|||||||
| 38 | ||||||||
| 39 | - Finding the right docs page. |
|||||||
| 40 | - Explaining AeThex concepts. |
|||||||
| 41 | - Helping users prepare support requests. |
|||||||
| 42 | - Walking developers through API and SDK setup. |
|||||||
| 43 | - Helping admins reason about organizations, teams, and permissions. |
|||||||
| 44 | ||||||||
| 45 | ## Stage 4 — Permissioned actions |
|||||||
| 46 | ||||||||
| 47 | Action-taking should come later and must respect [[Authentication]], [[Permissions]], [[Security-Model]], and [[Multi-Tenancy]]. Examples may include: |
|||||||
| 48 | ||||||||
| 49 | - Creating draft docs or support summaries. |
|||||||
| 50 | - Preparing project setup steps. |
|||||||
| 51 | - Checking status or configuration. |
|||||||
| 52 | - Suggesting changes before a human approves them. |
|||||||
| 53 | ||||||||
| 54 | > [!WARNING] |
|||||||
| 55 | > KAEL should not perform destructive, security-sensitive, or external actions without explicit permission and a clear audit trail. |
|||||||
| 56 | ||||||||
| 57 | <div class="docs-grid"> |
|||||||
| 58 | <a class="docs-card" href="/KAEL">KAEL Overview</a> |
|||||||
| 59 | <a class="docs-card" href="/KAEL-Changelog">Changelog</a> |
|||||||
| 60 | <a class="docs-card" href="/KAEL-Endpoints">Endpoints</a> |
|||||||
| 61 | <a class="docs-card" href="/Security-Model">Security Model</a> |
|||||||
| 62 | </div> |
|||||||