Scope and boundaries
Naia Build is designed to accelerate application development within the Neptune DXP - Open Edition App Designer. Understanding where its scope ends and where developer and administrator responsibility begins is relevant both for planning development workflows and for setting accurate expectations with stakeholders.
Application scope
Naia Build operates within the context of a single application per session. It has no knowledge of other applications in the Neptune DXP environment and cannot access, reference, or modify them. Data structures from another application are not available to Naia Build unless they are exposed through an API explicitly added to the current application’s Data tab.
This boundary applies equally to AI-generated output and to the session context Naia Build uses to process requests. Naia Build’s awareness is limited to what exists within the current application at the time of the request.
Development scope
Naia Build generates and modifies application components, for example, UI, logic, and data integrations, within the App Designer.
The following are outside its scope:
- Deployment
-
Naia Build does not deploy applications to a launchpad, configure server scripts, or create platform infrastructure artifacts. Deployment is handled via standard Neptune DXP processes outside of Naia Build.
- Agent logic configuration
-
Naia Build manages the placement and API connectivity of AI agents within an application’s UI. The configuration of agent logic and behavior is handled in Naia Agent Studio and is not accessible from within Naia Build.
- Architecture decisions
-
Generated output follows Neptune DXP development standards and best practices. Broader architectural decisions, for example, system design, integration strategy, data governance, remain the developer’s responsibility and are not addressed by Naia Build.
- Validation and testing
-
Naia Build does not perform functional validation or replace formal testing processes. Generated logic should be reviewed and tested against application requirements before release.
Developer responsibility
Naia Build generates code and configuration that becomes part of the application’s standard low-code structure.
Developers are responsible for:
-
Reviewing generated logic for correctness and compliance with enterprise standards
-
Validating that generated data bindings reference the correct operations and field types
-
Ensuring that application behavior meets functional and non-functional requirements before release
-
Maintaining awareness of iteration consumption and session boundaries during active development
Generated output is a starting point, not a finished deliverable. The developer remains the accountable party for what is released.
Session scope
Each session is bounded by a single developer task and a single application context. Conversation history, in-session context, and any source code retrieved during the session are discarded when the session ends.
There is no persistent memory between sessions. Naia Build has no awareness of decisions made, prompts submitted, or output generated in previous sessions.
Application components are saved in the Neptune DXP environment and persist across sessions. The context that produced them does not.