Architecture

Product, Naven, strategy provider, and venue boundaries for managed trading runtimes.

Naven exposes a provider-neutral Strategy Runtime contract. Products integrate with Naven rather than coupling their identity, data model, and interface to one strategy engine or trading venue.

System boundary

┌────────────────────────────────────────────────────────────┐
│ Product                                                     │
│ Strategy discovery · Agent setup · Portfolio experience    │
└──────────────────────────┬─────────────────────────────────┘
                           │ Naven Strategy Runtime API
┌──────────────────────────▼─────────────────────────────────┐
│ Naven                                                       │
│ Tenant identity · Runtime lifecycle · Metering · Results    │
└──────────────────────────┬─────────────────────────────────┘
                           │ Provider adapter
┌──────────────────────────▼─────────────────────────────────┐
│ Strategy-runtime provider                                  │
│ Scheduling · Context · Decision · Risk · Execution          │
└──────────────────────────┬─────────────────────────────────┘
                           │ Venue-native requests
┌──────────────────────────▼─────────────────────────────────┐
│ Trading venue                                               │
│ Orders · Fills · Balances · Positions                       │
└────────────────────────────────────────────────────────────┘

Why the provider adapter matters

The first implementation may delegate strategy operation to an existing provider. That is an implementation choice, not the public Naven contract.

The adapter translates between Naven resources and provider resources:

Naven concept	Provider responsibility
Strategy Version	Store or resolve the executable strategy definition
Account	Provision or connect a compatible wallet or exchange account
Runtime	Create and synchronize the provider's deployment or agent
Runtime status	Map active, paused, stopped, failed, and review states
Execution	Normalize scheduled and manual run records
Error	Convert provider failures into stable Naven error categories

The preview adapter keeps provider base URLs and route naming out of product code. Resource identifiers may still be provider-generated until Naven's durable mapping layer is introduced.

Control plane and runtime plane

Naven control plane

The control plane accepts product requests and maintains a stable view of:

Product and end-user ownership.
Strategy metadata and immutable versions.
Runtime configuration and lifecycle intent.
Provider assignment and synchronization health.
Usage, billing, and normalized execution history.

Creating or updating a Runtime is asynchronous when the provider cannot finish immediately. providerStatus distinguishes Naven's desired state from the last confirmed provider state.

Provider runtime plane

The provider performs long-running strategy work:

Reconcile schedules.
Load market context and configured data sources.
Evaluate the Strategy version.
Apply capital, leverage, drawdown, and provider-specific safety checks.
Sign and submit venue actions.
Reconcile ambiguous orders and persist authoritative outcomes.

Naven does not need to prescribe whether the provider uses an LLM, deterministic rules, a hosted model, or a native venue strategy. The normalized Runtime and Execution contracts remain the same.

Products authenticate to Naven with a Project API key. During the current preview, private operations also carry an explicit user-scoped Trading Authorization in a separate header. The adapter forwards only that credential to the provider for the current request. It never forwards the Naven key, browser cookies, or a fabricated Naven identity.

This lets Naven use an independently operated provider through its existing public API contract: the provider requires no Naven environment variables and no Naven-specific code. A future account-connection layer can replace the per-request credential with provider-native OAuth or service credentials while keeping the Naven resource paths stable.

Provider authorization and signing material must remain in server-side secret storage and never enter product frontend code.

Reliability model

Control-plane mutations use idempotency keys. Provider synchronization is retryable and records both desired and confirmed state.

For an Execution:

Create or observe a provider run.
Persist the provider run ID in the adapter mapping.
Normalize status, decision, risk assessment, and order result.
Poll or receive provider updates until the run reaches a terminal state.
Emit a Naven Event or webhook for product consumers.

The provider remains responsible for venue-level order idempotency and reconciliation. Naven remains responsible for delivering one stable runtime history to every integrating product.