Neptune DXP - Naia Build

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.

Governance and runtime controls

Naia Build applies the following controls during active development:

Access control: A developer can select and use a BYOK key only after an administrator turns on access for that user in the Neptune DXP Portal, and only within the spend limit the administrator sets. An account can hold multiple keys, each scoped to a team, so access and cost attribution stay granular rather than shared across the organization.
Input and file controls: Input filtering, file-handling controls, and rate limiting are enforced on requests.
Data visibility: Naia Build acts only on data you provide or expose within the application. It reads API definitions, not API responses. It gains access to Neptune DXP - Open Edition Cockpit artifacts only after you approve the MCP server connection. See Open Edition Cockpit and MCP server integration.
Logging and monitoring: Request logging and usage monitoring are provided through the Neptune DXP Portal and the Naia Build Dashboard. A developer sees only their own request logs.
Human oversight: Naia Build does not enforce a mandatory human approval step. As with any AI provider, review generated output before you rely on it.
Generation conventions: Custom rules let a team constrain how Naia Build generates output, for example, enforcing naming standards or architectural patterns. Rules are scoped to an individual or shared across the account. See Define custom rules.

Developer responsibility

Naia Build generates code and configuration that becomes part of the application’s standard low-code structure.

Developers are responsible for:

Using any BYOK key only within the Neptune DXP Portal, and not sharing it or reusing it in other systems
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.