dbxKi has three clearly separated workspaces. They use the same basic idea – briefing, full context, testable outcome, and explicit approval – but edit different items.
1
Content
Pages, texts, SEO data, media notes and translations within dbxContent
2
Design
Design packages, page layout, menu shape, branding, skins, assets, and Responsive representation.
3
Modules
Domain modules, DD, FD, templates, services, tests and controlled extensions of the application.
- [Content-KI](documentation-ai-content)
- [Design-KI](documentation-ai-design)
- [Modul-KI](documentation ki modules)
What all three areas have in common
- The user describes the goal and expected result.
- dbxKi complements the binding rules and the required source files.
- The AI provides a clearly limited response package.
- dbxapp checks contract, paths, files and target area.
- The user sees the result before the takeover.
- Only a explicit release changes the system.
Clear limits
| Area | May process | May not take over |
|---|---|---|
| Content AI | dbxContent pages, language-related content and SEO suggestions | Modules, DD, Rights or Design Packages |
| Design AI | Files of the specified target design | Logic, database tables or module rights |
| Module CI | expressly commissioned module and test files | free changes outside the package order |
Choosing the right AI space is part of security. One
Content change is not executed as a module job, and a design job
must not change any technical logic.