How Naia Build works
Naia Build processes prompts against the full application context at the time of submission, producing output across UI, logic, and data integration layers. Context scope, session behavior, and API schema handling govern how generated output reflects real application structure.
Request processing
When you submit a prompt via the Chat tab, Naia Build assembles a structured request that includes both the prompt and the current application context, for example, the component structure, page names, model names, and any connected API schema metadata. The AI model receives this combined input rather than the prompt in isolation.
As a result, generated output is specific to the current state of the application. The same prompt submitted against two different applications will produce different results. Output quality also increases as the application develops. Later prompts benefit from the accumulated structure of what has already been generated.
Output produced by the AI is applied directly to the application as standard Neptune DXP - Open Edition App Designer component configuration.
Development layers
Naia Build generates and modifies application components across three layers, independently or in combination:
- UI generation
-
creates and updates UI5 application components. Covers page structure, layout, and the visual elements users interact with.
- Logic generation
-
implements application behavior, including event handlers, business rules, conditional logic, and data processing.
- Data integration
-
connects the application to APIs and data sources added via the Data tab. Once an API operation is present in the application context, generated UI and logic references its actual schema, for example, field names, types, and operation types, rather than placeholder bindings.
A single prompt frequently addresses more than one layer simultaneously. Naia coordinates across all three within a single generation step.
Context awareness
Naia Build maintains awareness of the current application state throughout a session. Each request is processed with the full accumulated application context at that point, which is why prompt specificity directly affects output accuracy. Selecting a component via Smart Inspect before prompting narrows the working context and increases the precision of the result.
Context awareness is bounded by the following constraints:
-
Application scope: Naia has no knowledge of other applications in the Neptune DXP environment
-
Session scope: When a session ends, all in-session context is discarded from volatile memory. Application components are saved in the Neptune DXP environment, but conversational context is not recoverable.
API schema context
When you add API operations via the Data tab, their schema metadata, for example, field names, data types, and operation types, is automatically included in every subsequent request. No additional prompting is required.
All generation from that point forward references real data structures from the connected API. This is why APIs should be connected early in a session, before generating data-bound UI or logic. Output produced before an API is connected will use placeholder bindings that require correction afterward.
The following data is not transmitted to the AI model under any circumstances:
-
endpoint URLs
-
credentials
-
API response data
-
connection details
The AI receives structural schema information only.